Free SPF & DMARC checker
Enter a domain to check SPF, DMARC, and subdomain policies. Results come straight from live DNS — no sign-up required.
What we check
SPF record
Verifies which mail servers are authorised to send email for your domain. Prevents simple spoofing.
DMARC policy
Tells receivers what to do with mail that fails SPF/DKIM: monitor, quarantine, or reject.
DMARC strictness
Checks whether your policy is p=none (no protection) vs p=quarantine or p=reject.
Subdomain policy
Ensures your DMARC sp= doesn't leave subdomains unprotected when the parent domain is strict.
Why SPF and DMARC matter for your domain
Without SPF and DMARC records, anyone can send email that appears to come from your domain. Attackers use this to impersonate founders, send fake invoices, run phishing campaigns against your users, and damage your domain reputation with email providers. The attack requires no access to your infrastructure — just knowledge of your domain name.
SPF (Sender Policy Framework) is a DNS record that lists which mail servers are authorised to send email from your domain. When a receiving server gets an email claiming to be from you, it checks your SPF record to see if the sending server is on the list. If it is not, the email can be flagged or rejected.
DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on SPF and DKIM. It tells receiving mail servers what to do when a message fails authentication: monitor and report (p=none), send to spam (p=quarantine), or reject outright (p=reject). A DMARC policy of p=none means no protection — mail that fails authentication is still delivered.
The three most common misconfigurations
No DMARC record
The domain has an SPF record but no DMARC policy. SPF alone stops some spoofing but DMARC is what instructs receivers to actually reject failing mail. Without it, authentication failures are silently delivered.
DMARC set to p=none
A DMARC record exists but the policy is p=none, which means monitor only. Receiving servers report failures back to you (if rua= is set) but still deliver the mail. This is a useful starting point when first deploying DMARC, but it is not protection — it is observation.
Subdomain policy not set
DMARC's sp= tag controls what happens to mail from subdomains. If sp= is not set, subdomains inherit the root policy — which is only helpful if the root policy is quarantine or reject. Many domains lock down the root domain but leave subdomains exposed.
Email security for AI-built apps
If your app sends transactional email — confirmations, password resets, billing notifications — your domain's email reputation directly affects deliverability. Without DMARC enforcement, your sending domain is open to spoofing, which means email providers may treat your legitimate mail with more suspicion. Attackers impersonating your domain also harm your users directly.
AI coding tools do not configure DNS records. They generate application code, not infrastructure. SPF, DMARC, and DKIM records must be set up manually in your DNS provider — Cloudflare, Route 53, Namecheap, or wherever your domain is managed. This checker reads your live DNS records and tells you exactly what is missing and what to add.
For a full security review of your app beyond email — secrets in your JavaScript bundle, missing HTTP security headers, Supabase RLS exposure, and more — run a VibeScan on your deployed URL.