How to diagnose and fix a DMARC failure

A DMARC failure means that a message claiming to come from your domain failed both SPF alignment and DKIM alignment checks, and your DMARC policy (p=) determined what happened next — delivery to spam, or outright rejection.

DMARC failures split into two categories:

1. Legitimate mail failing — your own email (transactional, marketing, internal) is not passing authentication. Recipients may not receive it, or it lands in spam.
2. Spoofed mail failing — someone else is sending email using your domain's From: address and failing authentication. This is the intended behaviour — DMARC is working.

The steps below help you determine which category applies and fix the first one.

---

Step-by-step diagnosis

1. Confirm DMARC is published correctly

   Look up your DMARC record:

   dig TXT _dmarc.example.com +short

   You should see a record starting with v=DMARC1. Common problems at this step:

   • No record returned — the record is missing. Add a DMARC TXT record at _dmarc.<yourdomain>.
   • Record at the wrong label — the record must be at _dmarc.example.com, not example.com or dmarc.example.com.
   • Multiple records — only one DMARC record is allowed per domain. Remove duplicates.

   DomainCare fires a dmarc_record_missing alert when the record disappears, and a dmarc_record_changed alert when the content changes.

2. Read your DMARC aggregate reports

   Your aggregate reports (rua=) are the primary diagnostic tool. Each daily XML report from a receiving mail server shows:

   • The IP addresses that sent mail claiming to be from your domain.
   • How many messages each IP sent.
   • Whether SPF, DKIM, and DMARC passed or failed for each source.

   If you do not have a rua= address in your DMARC record, add one now:

   v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

   Wait 24–48 hours and review the reports. Use a DMARC report parser (most email security providers offer one) — the raw XML is not human-friendly.

   Look for rows where dmarc disposition is fail. The reason column tells you whether SPF, DKIM, or both failed.

3. Check SPF alignment

   DMARC SPF alignment requires the domain in the Return-Path (envelope sender, MAIL FROM) to match the From: header domain — not just that SPF passes on the envelope domain.

   Verify your SPF record:

   dig TXT example.com +short | grep spf

   Check for these issues:

   • Sending IP not listed — add include:provider.com for every service that sends on your behalf.
   • Too many lookups — if SPF returns permerror, you have exceeded 10 DNS lookups. Flatten your SPF record.
   • Return-Path domain mismatch — some email providers send from a subdomain of their own domain (e.g. bounce.provider.com). With relaxed SPF alignment (aspf=r, the default), bounce.provider.com aligns with provider.com — but it does not align with example.com. Either configure the provider to use your domain in Return-Path, or ensure DKIM alignment passes as the fallback.
4. Check DKIM alignment

   DKIM alignment requires the d= tag in the DKIM signature to match the From: domain. Verify DKIM is set up for the sending service:

   # Replace 'selector' with the actual selector name (ask your email provider)
   dig TXT selector._domainkey.example.com +short

   If this returns nothing, DKIM is not configured. If it returns a record with an empty p= value, the key has been revoked.

   Common DKIM alignment failures:

   • Provider signing with their own domain — the signature d= is provider.com, not example.com. Configure a custom DKIM domain in your provider's settings and add the key to your DNS.
   • Selector not in DNS — the d= tag is correct but the selector TXT record does not exist. Publish the public key your provider gives you.
   • Forwarding broke the signature — email forwarding can modify the body and invalidate the signature. If SPF alignment also fails on forwarded mail, those messages will fail DMARC. This is expected behaviour and not something you can fix on your end.
5. Identify the failing sender and fix it

   Match the failing IP addresses from your aggregate reports to a specific sending service:

   1. Look up the IP in a reverse DNS tool or your mail provider's documentation.
   2. Log in to that service and check its DKIM and SPF configuration.
   3. Either add the service to your SPF record (include:) or configure it to sign with DKIM using your domain.

   Repeat for every source IP that is failing.

6. Advance your DMARC policy

   Once your aggregate reports show only your legitimate senders passing authentication with no unexpected failures, advance your policy:

   1. Move from p=none to p=quarantine; pct=10 — this applies the policy to 10% of failing messages while leaving 90% as none. Monitor for legitimate mail landing in spam.
   2. Increase pct to 50, then 100 over a few weeks.
   3. Move to p=reject once pct=100 shows no legitimate mail failing.

---

Common causes table

Symptom	Likely cause	Fix
SPF fails, DKIM passes	Sending IP not in SPF, but DKIM aligned	Add IP/include to SPF record
DKIM fails, SPF passes	DKIM key missing, wrong selector, or d= mismatch	Configure DKIM with your domain as d=
Both fail	Sender not configured for either	Set up DKIM with your domain; add to SPF
Forwarded mail failing	Forwarding broke DKIM; SPF aligned to forwarder not From: domain	Expected — cannot fix on your end
permerror on SPF	Too many DNS lookups	Flatten your SPF record
dmarc_record_missing alert	Record deleted or DNS change wiped it	Re-publish _dmarc.<domain> TXT record
dmarc_policy_changed alert	Policy downgraded (e.g., reject → none)	Investigate DNS change; restore if unintended

---

Monitoring going forward

Once your DMARC policy is at p=reject, the main ongoing risk is:

• A sending service you add later that is not in your SPF record.
• A DKIM key that is rotated without updating DNS.
• An accidental DMARC record change or deletion.

DomainCare monitors all three and fires alerts for dmarc_record_missing, dmarc_record_changed, dmarc_policy_changed, spf_record_changed, dkim_record_missing, and dkim_selector_changed. See email deliverability for the complete alert list.

---