DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a protocol that tells receiving mail servers how to handle messages that fail authentication. When a message doesn’t pass SPF or DKIM alignment, DMARC can instruct the provider to deliver it to the inbox, send it to spam, quarantine it, or reject it outright.
It means the message didn’t pass the domain’s authentication checks. The receiving server will follow the DMARC policy you set – it might still deliver the mail, drop it into spam, or reject it entirely. This protects your brand from spoofing but can also block legitimate traffic if SPF or DKIM aren’t aligned.
They usually stem from mis‑aligned SPF or DKIM records. If a sending service isn’t listed in your SPF record or its DKIM signature doesn’t match the From domain, the message fails DMARC. Common culprits are third‑party platforms, forwarding services, and outdated DNS entries.
Major providers such as Gmail, Outlook, and Yahoo enforce DMARC policies. Their bounce messages often contain codes like “550‑5.7.26” (Gmail) or “550 5.7.509” (Outlook) indicating a DMARC‑related rejection.
Your policy (p=none, p=quarantine, or p=reject) tells receivers what to do with failing messages. “none” only reports failures, “quarantine” moves them to spam, and “reject” blocks them at the gateway. Gradually tightening the policy helps you catch issues before you go full‑reject.
Typical causes include email forwarding, mis‑configured third‑party senders, subdomain alignment gaps, expired DKIM keys, and multiple SPF records. Each of these breaks the alignment checks that DMARC relies on.
Forwarding often changes the envelope‑from address, breaking SPF alignment. DKIM may survive, but any header tweaks can invalidate the signature. Using relaxed alignment or ARC can mitigate the issue.
Platforms like Mailchimp, Salesforce, or payroll tools send on your behalf but may not be authorized in your SPF record. If they don’t publish a DKIM signature that aligns with your domain, their messages will fail DMARC.
DMARC checks the exact domain in the From address. If you send from mail.example.com
but only have a policy for example.com
, the subdomain can fail unless you publish a separate DMARC record or use the sp=
tag.
DKIM signatures rely on a public key stored in DNS. If the key is removed, rotated incorrectly, or expires, the signature can’t be verified, causing a DMARC fail.
SPF requires a single TXT record per domain. Having two records (e.g., one for Google Workspace and another for a marketing cloud) makes the SPF check invalid, which in turn forces DMARC to fail.
Start by reviewing aggregate reports sent to the RUA address in your DMARC record. Then use online tools like Palisade’s DMARC score checker to validate your DNS records. Finally, send test emails to Gmail, Outlook, and Yahoo and inspect the Authentication-Results
header.
Follow a systematic checklist:
When you’re confident all services are authenticated, move your policy from p=none
→ p=quarantine
→ p=reject
for maximum protection.
p=none
, monitor reports, then tighten to p=quarantine
and finally p=reject
.p=reject
? Not immediately. Begin with p=none
to collect data, then progress to p=quarantine
and finally p=reject
once all senders are authenticated.sp=
tag to apply the same policy to subdomains, or publish separate DMARC records for each subdomain.Ready to get a clear view of your email authentication health? Check your DMARC score now and start fixing failures today.