Free Tool
DMARC Record Checker
Validate your domain's SPF, DKIM, and DMARC configuration. See whether you have a DMARC policy in place, what enforcement level it uses, and whether it will actually stop phishing emails spoofing your domain.
Sign in with Google or GitHub to run the scan. Your first scan is free — no credit card required.
ZeriFlow Data — 12,400+ domains scanned
61% have no DMARC policy at all. Of the 39% that do, 79% use p=none — providing visibility into abuse but zero enforcement. Only 8% of all scanned domains have p=reject, the only setting that actually blocks phishing emails.
The Three Layers of Email Authentication
SPF, DKIM, and DMARC work as a system. Each layer has a distinct role — and DMARC only blocks phishing when the other two are correctly configured first.
SPF — Sender Policy Framework
SPF publishes an explicit list of IP addresses and mail services allowed to send email on behalf of your domain. When a receiving mail server gets an email claiming to be from @yourdomain.com, it checks the sending IP against your SPF record. If the IP is not listed, the check fails.
Example SPF TXT record (for Google Workspace)
v=spf1 include:_spf.google.com include:sendgrid.net -all
~all vs -all
~all (SoftFail) marks unauthorized senders as suspicious but delivers the email. Most spam filters treat it as a weak signal. -all (HardFail) explicitly fails the SPF check — combined with DMARC p=reject, it causes the email to be refused entirely. Use -all.
Hard limit: SPF records cannot trigger more than 10 DNS lookups during evaluation. Each include: counts as one lookup. Exceeding 10 causes a permanent SPF error (PermError) — all emails fail.
DKIM — DomainKeys Identified Mail
Your mail server signs each outgoing email with a private key. The signature is included in the email header. The receiving server retrieves your public key from DNS and verifies the signature. If the email body or headers were modified in transit, the signature fails.
Unlike SPF, DKIM signatures survive email forwarding — the signature is tied to the message content, not the sending IP. This makes DKIM the more reliable authentication method in practice.
Example DKIM DNS record (selector: google)
google._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."
The record is published at selector._domainkey.yourdomain.com. Your email provider (Google Workspace, Postmark, SendGrid) generates the key pair and gives you the record to publish.
DMARC — Domain-based Message Authentication, Reporting & Conformance
DMARC is a DNS TXT record published at _dmarc.yourdomain.com. It defines two things: what action to take when SPF or DKIM fail (the policy), and where to send aggregate reports.
p=noneMonitor only
Emails that fail DMARC are delivered normally. Reports are sent to rua. Use this during initial setup to identify all legitimate senders before enforcing.
p=quarantineSpam folder
Failing emails go to the spam/junk folder. Correct approach once SPF and DKIM cover all your legitimate sending sources.
p=rejectBlock delivery
The receiving server refuses to accept the email at all. The only policy that completely prevents phishing from your domain. Target state.
Complete DMARC record example
_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; pct=100; adkim=s; aspf=s"
rua=Aggregate report destination. Daily XML reports from receiving mail servers, showing which IPs sent email for your domain and whether they passed.ruf=Forensic report destination. Per-failure reports with full message headers. Some providers disable ruf delivery for privacy reasons.pct=100Apply the policy to 100% of failing messages. Use pct=10 to gradually roll out a stricter policy while monitoring for false positives.adkim=sStrict DKIM alignment: the domain in the DKIM d= tag must exactly match the From header domain, not just be a subdomain.aspf=sStrict SPF alignment: the MAIL FROM domain must exactly match the From header domain.How to Read a DMARC Aggregate Report
Receiving servers send daily XML reports to your rua address. Each report contains one record per source IP that sent email claiming to be from your domain. Key fields to review:
| Field | What it means | Action if unexpected |
|---|---|---|
| source_ip | The IP address that sent the email | Reverse lookup the IP — is it a known sender (Google, SendGrid, your mail server)? |
| count | Number of messages from this IP in the reporting period | High counts from unknown IPs indicate active spoofing |
| spf / dkim result | pass or fail for each check | Fail from a legitimate sender means you need to add them to your SPF record or configure DKIM |
| disposition | What the receiving server actually did: none, quarantine, reject | Should match your policy. 'none' while p=reject means the receiver doesn't honor DMARC |
| header_from | The domain in the visible From header | Mismatches between this and the authenticated domain indicate alignment failure |
Common DMARC Mistakes
SPF with more than 10 DNS lookups
Each include: directive in your SPF record triggers a DNS lookup at evaluation time. The limit is 10 total lookups, including nested includes from third-party providers. Exceeding this causes a PermError — SPF fails for all senders, including legitimate ones. Use SPF flattening tools or consolidate your sending infrastructure.
DMARC p=none left in place indefinitely
p=none is a monitoring policy, not a protection policy. Email spoofing your domain still reaches recipients — you just get reports about it. The timeline from deployment to p=reject should be 4-8 weeks, not months. Staying at p=none is a false sense of having addressed the problem.
No rua configured
Without aggregate reports, you have no visibility into which services are sending email as your domain. This makes moving to p=reject dangerous — you may block legitimate senders you did not know about. Always include rua= from day one.
SPF passes but DMARC alignment fails
DMARC requires aligned authentication — the domain authenticated by SPF must match the domain in the From header. If your email is sent via a third party (Mailchimp, HubSpot) and the MAIL FROM uses their domain rather than yours, SPF passes but DMARC alignment fails. The fix is to configure the third party to use a subdomain of your domain as the envelope sender, or ensure they support DKIM signing with your domain.
Frequently Asked Questions
What is DMARC and why do I need it?
DMARC (Domain-based Message Authentication, Reporting & Conformance) is a DNS record that tells receiving mail servers what to do when they receive an email claiming to come from your domain that fails SPF or DKIM verification. Without DMARC, anyone can send email that looks like it came from your domain — a technique used in phishing attacks targeting your customers, partners, or employees.
What's the difference between SPF, DKIM, and DMARC?
SPF (Sender Policy Framework) publishes a list of IP addresses and mail servers authorized to send email for your domain. DKIM (DomainKeys Identified Mail) cryptographically signs outgoing emails so the recipient can verify the signature against a public key in your DNS. DMARC ties them together: it specifies what to do when SPF or DKIM fail, and adds alignment checking to ensure the domain in the From header matches the authenticated domain.
How do I add a DMARC record to my domain?
Add a TXT record in your DNS with the name _dmarc.yourdomain.com and a value like: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Start with p=none to collect reports without blocking email, monitor for 2-4 weeks, then move to p=quarantine, then p=reject once you are confident all legitimate senders are covered by SPF or DKIM.
What does DMARC p=none, p=quarantine, p=reject mean?
p=none means monitor only — authentication failures are reported but email is delivered normally. This is the starting point for new DMARC implementations. p=quarantine means emails that fail DMARC should be sent to the spam/junk folder. p=reject means the receiving mail server should refuse delivery of emails that fail DMARC authentication entirely — this is the only policy that actually blocks phishing emails spoofing your domain.
Can I have DMARC without DKIM?
Technically yes — DMARC passes if either SPF or DKIM passes with alignment. However, SPF alone has significant limitations: it breaks when email is forwarded (the forwarding server's IP is not in your SPF record), and it does not protect the visible From address. DKIM signatures survive forwarding and provide stronger authentication. For full protection, you need both SPF and DKIM configured before moving to p=reject.
Check Headers, TLS, and Cookies Too
The DMARC checker covers 8 email security checks. ZeriFlow's full scanner runs 80+ checks across 12 categories — TLS configuration, security headers, cookie flags, DNS security, and content security.