DMARC Report Shows Failures: What to Do

A DMARC failure report gives you leads

One unknown source in a DMARC report can be harmless forwarding, a forgotten app, or someone trying to spoof your domain. Treat it like evidence before you touch policy.

Keep your current DMARC policy in place while you investigate. If you already use p=quarantine or p=reject, that policy may be protecting your domain from mail you did not authorize. The right move is to sort each source into one of three buckets: real mail you own, mail forwarded by someone else, or mail you did not authorize.

DMARC passes when either SPF passes with an aligned SPF-authenticated domain, or DKIM passes with an aligned signing domain. In both cases, alignment is checked against the visible From domain. A DMARC failure means neither aligned path passed for that message. The report may still look familiar because aggregate XML usually shows IPs, envelope domains, DKIM domains, and counts rather than a clean vendor name. If the XML is hard to read, use the DMARC report reader to turn the aggregate report into sources, pass rates, and alignment results.

• Find the failing source IP, envelope sender, DKIM domain, and message count.
• Check whether the source matches a real tool you use, such as a CRM, billing app, support desk, newsletter tool, or website form.
• If you own the source, fix SPF or DKIM alignment for that sender.
• If you do not own it, leave quarantine or reject in place and keep watching reports.
• Record the owner of each approved sender so the same source is easy to recognize later.

Start with the source, count, and pattern

A single failed message from a random IP means something different from thousands of failures from a known email platform.

Look at the source IP and reverse DNS when it is available. Then compare the report date, volume, and sending pattern to your own mail. A steady stream from a marketing platform may be a tool you forgot to authenticate. A burst from many unrelated networks may be spoofing. A small number from consumer mailbox providers can be forwarding, mailing lists, or people sending copies through another system.

DMARC aggregate reports sent to a rua address are summary reports. They show counts and authentication results. They usually do not include full message bodies or enough detail to identify every recipient. Use them to find patterns, then confirm with your sending platform logs.

• Match high-volume failures to campaign dates, invoices, alerts, password resets, and support replies.
• Ask each vendor which bounce domain and DKIM selector should appear in mail from your domain.
• Compare the report's SPF domain and DKIM d= domain with the visible From domain.
• Do not add a sender to SPF until you know it is real and current.
• Remove sources from your approved list when a vendor or mail stream is retired.

Fix real senders without weakening DMARC

If the failure is a tool you use, the fix is usually SPF alignment, DKIM signing, or both. Changing DMARC policy is the last resort.

SPF is the DNS record that lists which hosts may send for a domain. Publish only one SPF TXT record for the domain being checked, use only active senders, and stay within the SPF 10 DNS lookup limit in RFC 7208. The lookup-counted terms include include, a, mx, ptr, exists, and redirect, including nested lookups. While you are still cleaning up, ~all is common. After the sender list is complete and tested, -all is stricter.

SPF only helps DMARC when the SPF-authenticated domain aligns with the visible From domain. Many tools send with their own bounce domain unless you configure a custom return-path. If SPF passes for the vendor domain, DMARC can still fail for your domain.

DKIM is often the better fix for third-party tools. The tool signs mail with a private key, and you publish the public key at a selector such as selector1._domainkey.example.com. DKIM helps DMARC when the signing d= domain aligns with your From domain. It also tends to survive forwarding better than SPF because forwarding often changes the sending IP.

• Turn on DKIM for every platform that sends as your domain.
• Publish each vendor's DKIM selector exactly as they provide it.
• Set up a custom return-path only when the vendor supports it and you can keep DNS correct.
• Remove old SPF includes before adding new ones.
• Use the free domain scorecard after DNS changes to check SPF, DKIM, DMARC, MX, and blocklist signals together.

When the source is spoofing

If the source is not yours, a DMARC failure is the system doing its job. Your next step is monitoring, not panic.

With p=none, receivers can send reports while you monitor. With p=quarantine, you ask receivers to treat failing mail as suspicious, often by placing it in spam. With p=reject, you ask receivers to reject failing mail. Receivers still make the final delivery decision under their own local policy, but enforcement gives them a clear instruction from the domain owner.

If you already have p=quarantine or p=reject and real mail is passing, keep it. Spoofers often test domains to see which ones are easy to abuse. Dropping back to p=none tells receivers to monitor instead of applying your enforcement request.

If you are still at p=none, do not jump blind. First fix legitimate sources. Then move to p=quarantine, watch reports and bounces, and move to p=reject once normal mail passes through aligned SPF or DKIM.

• Leave failed unauthenticated sources covered by your current policy.
• Watch whether spoofing volume rises, shifts IPs, or uses lookalike subdomains.
• Check account security if the failures resemble real internal mail.
• Keep the rua report address active after enforcement.
• Use a separate subdomain for risky or high-volume mail streams when needed.

Why failures can still affect delivery

Mailbox providers look at authentication, reputation, and behavior. DMARC failures are a strong warning, but they are not the whole delivery story.

Google and Microsoft publish sender guidelines that require or recommend SPF, DKIM, and DMARC depending on the sender type, volume, and destination service. Their filtering also considers domain reputation, IP reputation, complaint rates, spam traps, blocklists, URL reputation, message content, volume spikes, and recipient behavior. A passing DMARC result proves the message is tied to an authorized domain identity. It does not erase a poor sending history.

Check MX records so replies and bounces work. Check public blocklists if a known sender suddenly drops in delivery, while remembering that large mailbox providers also use private reputation systems. If a sender is listed, compromised, or sending to stale contacts, SPF and DKIM repair will not fix the whole problem.

For official rules, use RFC 7208 for SPF, RFC 6376 for DKIM, RFC 7489 for DMARC, plus the current Google and Microsoft sender guidelines. If a vendor tells you to publish a record that conflicts with those rules, ask for the exact hostname, selector, and alignment path before changing DNS.

Do not mix this up with AI crawler access

DMARC protects who can send email as your domain. Robots.txt states crawler access rules for your website. These are separate systems.

If your site needs to appear in AI answers, allow the crawlers that power live AI search: OAI-SearchBot (ChatGPT search), Claude-SearchBot (Claude), PerplexityBot (Perplexity), Googlebot (Google AI Overviews ride the normal Search index, and there is no separate opt-out crawler), and Applebot (Apple Intelligence). Disallowing these in robots.txt removes you from that engine.

Training controls are different. GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not affect live AI search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent. Robots.txt is a site's stated policy, not proof of behavior. Perplexity-User and Bytespider have been reported to ignore it, so use logs and edge controls when behavior matters.

Only Googlebot documents JavaScript rendering. If important content exists only after client-side JavaScript runs, other AI crawlers may miss it. Treat that as an undocumented risk, not a proven rule about a named bot. For that separate website issue, use the AI visibility checker and the vendor docs from OpenAI, Anthropic, Perplexity, Google, Apple, and Common Crawl.