You open the headers of a message and find dmarc=fail. Or Gmail's "Show original" page says DMARC: FAIL in red. Or a message bounces with 550 5.7.26 at Gmail or 550 5.7.509 at Outlook.
All of these mean the same thing: the receiver could not link the message to the domain in its From address. Neither SPF nor DKIM passed for that domain. The good news is that the cause is almost always one of a handful of setup problems, and you can find which one from a single message.
What DMARC actually checks
DMARC does not run its own test. It looks at the results of SPF and DKIM and asks one extra question: did either of them pass for the domain people see in the From address?
That second part is called alignment, and it is where most failures come from. Here is a message sent by a newsletter tool on behalf of example.com:
| Check | Result | Domain checked | Same as From (example.com)? |
|---|---|---|---|
| SPF | pass | bounces.mailtool.example (the bounce address) |
No |
| DKIM | pass | mailtool.example (the signature's d=) |
No |
| DMARC | fail |
SPF passed and DKIM passed, and DMARC still failed, because both passed for the newsletter tool's domains instead of example.com. This is the most common DMARC failure there is, and the people it happens to usually think their setup is fine because they see two passes.
By default, alignment is relaxed: news.example.com and example.com count as the same domain, because they share the same registered domain. If your DMARC record contains adkim=s or aspf=s (strict), the domains must match exactly.
What happens to a message that fails
It depends on the policy your domain publishes in its DMARC record (p=):
p=none: deliver as usual, only report. A failure changes nothing for that message, but the receiver may still find it suspicious.p=quarantine: treat it as suspicious, usually by putting it in the spam folder.p=reject: refuse it. The sender gets a bounce.
Receivers can apply their own rules on top. Gmail and Yahoo require every bulk sender to have a DMARC record, and they look at failure rates when they decide on spam placement. So even with p=none, a domain where most messages fail DMARC is not in good shape.
Find the cause in one message
Send a test message to a Gmail address from the system that has the problem, open it, choose Show original and copy the headers. Paste them into our email header analyzer, or read the Authentication-Results line yourself (our guide to email headers explains each part).
You are looking for three domains:
- The From domain:
header.from=. - The domain SPF checked:
smtp.mailfrom=. - The domain DKIM signed with:
header.d=orheader.i=.
Then compare. The pattern tells you which of the causes below you have.
The usual causes
1. A sending tool that is not set up with your domain
Pattern: SPF and DKIM pass, but for the tool's domains (sendgrid.net, mcsv.net, amazonses.com, mailgun.org…).
Every newsletter platform, CRM, helpdesk and invoicing app that sends as your domain needs to be "authenticated" with it. Look for a page called domain authentication, sender authentication or verified domains in the tool. It gives you DNS records to add, usually CNAME records for DKIM and sometimes one for a custom bounce domain. Once they are in place, the tool signs with d=yourdomain.com and DKIM aligns.
DKIM alignment is enough for DMARC. You do not also need SPF alignment, and with most tools you cannot get it without a custom bounce domain anyway.
2. Forwarding and mailing lists
Pattern: the message passes everywhere except for some recipients, often those who forward their mail to another address, or members of a mailing list.
Forwarding breaks SPF, because the forwarding server's IP is not in your SPF record. DKIM survives plain forwarding, which is one more reason to make sure every message is DKIM-signed with your own domain.
Mailing lists are harder: many of them add a footer or a tag in the subject line, which changes the message and breaks the DKIM signature. Modern list software rewrites the From address to the list's own domain to avoid this. Some forwarders also add ARC headers, which record the original authentication results so the final receiver can take them into account. You cannot fix a third party's list from your side, but you can make sure your own mail is DKIM-signed so plain forwarding keeps working.
3. Subdomains and strict alignment
Pattern: From is news.example.com, DKIM passes with d=example.com (or the reverse), and DMARC still fails.
This only happens with strict alignment. Check your DMARC record (_dmarc.example.com) for adkim=s or aspf=s. Unless you have a specific reason, remove them and let the defaults (relaxed) apply. Our SPF and DMARC checker shows the record and its tags.
4. A broken SPF record
Pattern: spf=permerror or spf=temperror in the results, and no aligned DKIM to make up for it.
SPF breaks when the record needs more than 10 DNS lookups (each include: counts, and the includes inside it too), or when the domain has two SPF records instead of one. In both cases receivers treat SPF as failed for every message. Merge the records into one and remove services you no longer use. The SPF and DMARC checker counts the lookups for you.
5. A missing or changed DKIM key
Pattern: dkim=fail with your own domain in header.d, or dkim=permerror.
The signature uses a selector (header.s=) whose public key is no longer in DNS, or the key in DNS does not match the private key the server signs with. This often happens after a migration, or when someone "cleaned up" old DNS records. Look up the selector in the DKIM checker. If the record is missing, restore it or re-run the domain setup in your sending service.
A security gateway that adds a disclaimer or footer to outgoing mail after it was signed causes the same failure. The fix is to sign after the gateway, or to have the gateway sign.
6. Someone else is using your domain
Pattern: the failing messages come from IPs and services you have never heard of.
That is DMARC doing its job. Spammers put real domains in the From address all the time. If you are at p=none, these messages may be getting through; a stricter policy is what stops them.
Use DMARC reports to see the whole picture
One message shows one sender. To see every service that sends as your domain, add a report address to your DMARC record with the rua= tag. Receivers like Google, Microsoft and Yahoo then send you a daily XML file listing each source IP, how many messages it sent, and whether SPF, DKIM and DMARC passed.
The files are hard to read raw. A free or paid DMARC report service turns them into a table. After a week or two you will have a full list of your senders, and the ones failing are your to-do list. Our DMARC record generator builds a record with a report address.
Should you relax the policy?
If a legitimate sender is being rejected right now and you need time to fix it, moving from p=reject to p=quarantine or p=none stops the bounces. It also lets spoofed mail through again, so treat it as a temporary measure with an end date. Fix the sender, check the reports for a few days, then go back.
Moving the other way, from p=none to quarantine and reject, should only happen once the reports show that all your real senders pass.
Frequently asked questions
Can a message pass DMARC with only SPF?
Yes, if SPF passes for a domain aligned with the From domain. In practice DKIM is the more reliable route, because it survives forwarding and most sending tools can sign with your domain.
Why does Gmail show DMARC pass when Outlook shows fail for the same campaign?
Usually because the paths differ. A recipient at Outlook may have their mail forwarded, or go through a company gateway that changes the message. Compare the headers of both copies.
Does a DMARC fail mean my domain is blocklisted?
No. DMARC is checked for each message on its own. Fix the authentication and the next messages pass.
I don't have a DMARC record. Why does my message say dmarc=none, not fail?
none means there was no record to apply. That is not a failure, but Gmail and Yahoo require bulk senders to publish one, and without it anybody can send as your domain with no consequence.