DMARC fail: what it means and how to fix it

“DMARC fail” means the receiving server could not find a reason to believe the message came from the domain in its From line. DMARC passes when at least one of two checks passes and is aligned:

• SPF passes for the envelope domain (the hidden return path), and that domain matches the From domain;
• DKIM verifies a signature made with the From domain (the d= in the signature), or one of its subdomains in the default relaxed mode.

So a message can pass SPF, pass DKIM, and still fail DMARC, because both passed for somebody else’s domain.

Read the verdict first

Ask for a copy of a failing message as an attachment and open its headers, or paste them into the e-mail header analyzer. Look for the line added by the receiver:

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=bounces.mailtool.example;
  dkim=pass header.d=mailtool.example;
  dmarc=fail header.from=yourdomain.com

Here both checks passed, for mailtool.example. Nothing was signed or sent for yourdomain.com: the service is not authenticated for your domain.

Gateways word it differently. Mimecast reports DNS Authentication: DMARC Fail; Microsoft returns 550 5.7.509; Gmail returns 550-5.7.26. They all mean the same thing, and the fix is on the sending side.

The six usual causes

1. A service sends in your name without DKIM for your domain. The most common one: a newsletter tool, a CRM, an invoicing app. Set up its domain authentication so that it signs with d=yourdomain.com. Adding its include: to SPF is often not enough, because many services use their own return path.

2. Forwarding. A message forwarded by an intermediate server arrives from that server’s address, so SPF fails. DKIM survives forwarding when the message is not changed. This is why every service should sign with DKIM, not rely on SPF.

3. dkim=fail (body hash did not verify). The message was changed after it was signed: a footer or disclaimer added by a gateway, links rewritten by a security filter, a mailing list adding its own text. Sign after the last system that changes the message, or have that system sign itself.

4. SPF permerror. More than ten DNS lookups, two SPF records, or a syntax error: SPF fails for every message. The SPF checker shows it, and Too many DNS lookups explains how to fix it.

5. Strict alignment. adkim=s or aspf=s in your DMARC record demand an exact domain match. Mail signed by news.yourdomain.com then fails for yourdomain.com. Remove the two tags unless you have a reason for them.

6. Two DMARC records, or none readable. Receivers ignore a domain with several _dmarc records. The DMARC checker flags it.

What not to do

Do not go back to p=none to make a failure disappear. It re-opens your domain to every forger in order to fix one sender. Find the sender in your DMARC reports (the DMARC report reader lists sources by result), authenticate it, and the failures stop.

Your mail fails at one recipient only

If a single company rejects you while others accept the same message, their gateway is often stricter than your policy: some reject DMARC failures even with p=none. The fix is still the same, make the message pass, but it explains why “it works for everyone else”.

For the path from monitoring to enforcement once everything passes, see From p=none to p=reject.