Email Security (DMARC+)

Troubleshooting DMARC Failures

Troubleshooting DMARC Failures

Overview

DMARC failures are almost always caused by misconfiguration rather than a fundamental problem. This guide covers the most common failure patterns and how to diagnose and fix each one.

Diagnostic approach

When you see DMARC failures in the dashboard:

  1. Identify the source IP — which sending service is failing?
  2. Check which authentication method failed — SPF, DKIM, or both?
  3. Check alignment — did the authenticated domain match the From: header?
  4. Fix the root cause — based on what failed

SPF failures

"I added the SPF include but it's still failing"

Check:

  • Did you add the include to the correct domain's SPF record? (not a subdomain)
  • Is there a propagation delay? DNS changes can take up to 48 hours
  • Do you have two SPF records? Only one SPF record is allowed per domain — two records cause PermError
  • Is the SPF include correct for that service?

Verify: dig TXT yourdomain.com — you should see one SPF record with the include

SPF PermError (too many lookups)

The 10 DNS lookup limit has been exceeded. Every include:, a:, mx:, and redirect= costs one lookup.

Fix:

  1. Use the SPF Explorer in DMARC+ to count current lookups
  2. Remove includes for services you no longer use
  3. Move some senders to subdomains (each subdomain has its own 10-lookup budget)
  4. Replace include: chains with direct ip4: ranges for services that have stable IPs

SPF alignment failure (SPF passes but DMARC fails)

SPF is passing but failing alignment — the Return-Path domain doesn't match the From: domain.

Common cause: A third-party service is sending from its own domain in the envelope (e.g., bounces.mailchimp.com) even though the From: header shows your domain.

Fix:

  • Configure the service to use a custom MAIL FROM domain that you own (most major services support this)
  • Set up DKIM instead — DKIM alignment is more robust for third-party senders and doesn't break on forwarding
  • Use a subdomain of your own domain as the MAIL FROM: bounces.yourdomain.com → add it to your SPF record

Forwarded email failing SPF

This is expected and not a misconfiguration. When email is forwarded (by an email forwarding rule or a mailing list), the Return-Path changes to the forwarder's domain, breaking SPF alignment.

Fix: Ensure DKIM is set up for the original sending domain. DKIM signatures survive forwarding (as long as the message isn't modified), so forwarded email can still pass DMARC via DKIM.

DKIM failures

"I published the DKIM DNS record but emails aren't signing"

Check:

  • Did you activate DKIM in the service settings after publishing the DNS record? Most services require you to click "Enable" or "Verify" after you publish the record
  • Is the DNS record fully propagated? Use dig TXT selector._domainkey.yourdomain.com to verify
  • Is the selector name correct? The DNS record name must exactly match the s= value in the email header

DKIM signature verification failed

The signature exists but doesn't verify — meaning the message was modified after signing.

Common causes:

  • Email security gateways that add headers, footers, or disclaimers to messages after signing (this is very common with on-premises mail security appliances)
  • Mailing list software that modifies the subject line (e.g., adding [List Name] prefix)
  • Email clients that reformat the message body

Fix:

  • Configure your mail security gateway to sign after any modifications, or to preserve the DKIM signature
  • For mailing lists: configure the list to strip and re-sign, or to use a list-specific DMARC record
  • Some services support l= tag in DKIM signatures (body length limit) — this can help with gateway modification but has security tradeoffs

DKIM key not found (no public key in DNS)

The email references a selector (s=value) but no DNS TXT record exists for it.

Fix: Publish the missing DNS TXT record, or update the service to use an active selector.

DMARC policy issues

"I set p=reject but legitimate emails are being blocked"

Symptoms: Users report delivery failures or missing emails after you advanced to p=reject.

Diagnostic steps:

  1. Check DMARC+ for the sources that are failing — which service/IP is it?
  2. Check if this service was in your reports before you advanced (did you miss a source?)
  3. Check if the service recently changed its sending infrastructure (new IPs)

Immediate fix: Temporarily roll back to p=quarantine to restore delivery while you investigate. Permanent fix: Configure authentication for the newly discovered source, then re-advance.

pct= not behaving as expected

If you set pct=50, only 50% of failing emails should be affected by the policy. But you're seeing 100% rejection.

Note: pct= is optional for receiving servers to implement. Not all mail providers respect it — some apply the full policy regardless. Don't rely on pct= as a safety net; use it as a gradual rollout tool while monitoring, but verify with real report data.

Common false positives

Automated email scanners

Security tools (SEGs, antivirus, sandboxes) often follow links and scan URLs in emails. They may also trigger tracking pixels or other elements that can interact with email authentication checks. This doesn't typically affect DMARC pass/fail rates but can affect other campaign metrics.

Internal email relay

If your organisation uses an internal relay server (on-premises mail gateway, email archiving appliance, DLP scanner) between your mail server and the internet, that relay must also pass SPF checks. Add its IP to your SPF record.

Cloud fax and unified communications services

Services like eFax, RingCentral, or similar that send email notifications may send from your domain. Check DMARC+ for unfamiliar IPs and investigate before blocking.

Getting help

If you've worked through this guide and still can't identify the cause of a failure:

  1. Export the raw DMARC report data from DMARC+
  2. Identify the specific IP, message count, and failure mode
  3. Look up the IP owner using an IP lookup tool or WHOIS
  4. Contact that service's support with your DMARC data showing their IP failing authentication