DMARC Override Reason Explained

An override is a clue, not a pass

A DMARC row can say both SPF and DKIM failed, then show disposition=none with a reason like forwarded or local_policy. That looks wrong until you know what the receiver is telling you.

A DMARC override reason means the receiving mailbox provider did something different from the domain policy, or from the simple result you expected, because it saw extra context. The reason appears inside policy_evaluated in a DMARC aggregate report. It does not prove the message reached the inbox. It does not mean your DNS is perfect. It means the receiver made its own handling choice and gave you a short label for why.

DMARC itself is simple at the core. SPF checks whether the sending server is allowed by the SPF record for the SPF-authenticated domain. DKIM checks whether the message has a valid signature, tied to a selector and public key in DNS. DMARC passes when SPF passes and aligns with the visible From domain, or DKIM passes and aligns with that From domain. If both aligned checks fail, your DMARC policy says what you ask receivers to do.

• p=none: monitor and receive reports, without asking receivers to quarantine or reject DMARC failures.
• p=quarantine: ask receivers to treat DMARC failures as suspicious, often by routing them to spam or junk.
• p=reject: ask receivers to reject DMARC failures before delivery when they honor the policy.

The word "ask" matters. Receivers can apply local policy. That is why override reasons exist.

Where override reasons appear

Look in the aggregate report row, inside policy_evaluated. The row gives the source IP, count, DMARC-aligned SPF result, DMARC-aligned DKIM result, disposition, and sometimes one or more reasons.

A common row tells this story: a source IP sent a batch of messages, aligned SPF failed, aligned DKIM failed, your published policy was p=reject, but the receiver recorded disposition=none and reason=mailing_list. That means the receiver accepted or exempted those messages because it believed a mailing list changed the mail in a way that can break authentication.

RFC 7489 defined these common policy override types: forwarded, sampled_out, trusted_forwarder, mailing_list, local_policy, and other. Current DMARC aggregate reporting in RFC 9990 keeps local_policy, mailing_list, trusted_forwarder, and other, and uses policy_test_mode for testing mode. You may still see the older names in reports and DMARC tools because many systems still speak in RFC 7489 terms.

If raw XML is hard to read, put the file into the free DMARC report reader. It turns RUA reports into source IPs, counts, authentication results, and override reasons so you can focus on the sender that needs work.

What each reason usually means

Treat every reason as the receiver's short note. It explains its handling choice, but it rarely gives enough detail to close the case by itself.

• forwarded: the receiver believes the message came through forwarding, or its own checks made forwarding likely. SPF often breaks during forwarding because the final forwarder sends from a new IP. DKIM may survive if the message was not changed after signing. If forwarded mail matters, make sure your real senders use aligned DKIM.
• trusted_forwarder: the receiver expected authentication trouble because the message came through a forwarder it trusts locally. This is a receiver-side trust decision. You normally cannot add yourself to that list. Your best fix is still aligned DKIM on the original message.
• mailing_list: the receiver believes a mailing list handled the mail. Lists often add footers, rewrite subjects, or resend messages. Those changes can break DKIM. The list may also change the sending path, which breaks SPF. Do not weaken your domain policy just because list traffic shows up. Check whether the list is a real place where your mail should travel.
• local_policy: the receiver exempted the message under its own rules. This can cover allow lists, internal routing rules, security product decisions, or provider policy that is not shown in the report. It is a broad label, so avoid over-reading it.
• sampled_out: older RFC 7489 reports used this when the domain's pct tag asked receivers to apply policy to only part of failing mail. Current RFC 9990 aggregate reporting no longer lists sampled_out as an override type, but old reports and tools may still show it.
• policy_test_mode: current aggregate reports can use this when the domain is in a declared test mode, so the receiver reports the policy result without normal enforcement.
• other: the receiver had another reason. Look for a comment field, but expect it to be missing or vague.

The pattern matters more than one label. A few forwarded messages from consumer mailboxes may be normal. Many local_policy rows from a CRM IP might mean that a real sender is unauthenticated and a big receiver is being lenient.

How to decide what to fix

Start with your own senders. Override reasons are helpful, but they should not become an excuse to leave known mail broken.

• Sort by count. Fix high-volume legitimate sources before low-volume noise. One broken billing sender matters more than a stray forwarded message.
• Identify the source. Map the source IP, DKIM domain, envelope sender, and dates to Google Workspace, Microsoft 365, SendGrid, Mailchimp, HubSpot, Shopify, Zendesk, your app server, or an unknown source.
• Check SPF. Publish one SPF record for the domain being checked. Include only real senders. Stay under the SPF 10 DNS lookup limit from RFC 7208. The lookup-counted mechanisms include include, a, mx, ptr, exists, and redirect. Use ~all while auditing. Use -all only when every real sender is covered.
• Check DKIM. Each sender should sign mail with a key under a selector such as selector1._domainkey.example.com. For DMARC, the DKIM d= domain must align with the visible From domain. Fix missing selectors, stale keys, disabled signing, and vendor default signatures that use the vendor domain.
• Check alignment. A raw SPF pass or DKIM pass is not enough. DMARC needs the passing domain to align with the From domain. Relaxed alignment allows the same organizational domain. Strict alignment requires an exact domain match.
• Check MX and replies. MX records do not make outbound mail pass DMARC, but bad MX records can break replies, bounces, and sender checks while you debug delivery.
• Check reputation and blocklists. Gmail and Outlook can still route authenticated mail to spam because of complaints, bounces, bad lists, strange volume jumps, risky links, suspicious content, user behavior, blocklists, and their own local policy.

Run the domain through the free InboxRadar scorecard after DNS changes. It checks SPF, DKIM, DMARC, MX, and common delivery risks in one place. Then watch later RUA reports to confirm that the fixed sender now passes with alignment.

How to read the common cases

A good DMARC review is part sender inventory and part incident triage. The same reason can mean normal mail, broken setup, or abuse.

If a known provider shows forwarded or trusted_forwarder at low volume, the issue may be a recipient forwarding mail to another mailbox. You usually cannot make SPF survive that path. Aligned DKIM is the practical defense because a valid DKIM signature can survive forwarding when the message body and signed headers stay intact.

If a known marketing or support tool shows local_policy at high volume, treat it as a setup problem until proven otherwise. The receiver may have accepted the messages today, but another receiver may reject them. Enable branded DKIM, configure a custom return-path when the vendor supports it, and remove old SPF includes before adding new ones.

If a mailing list shows failures, decide whether that traffic is part of your real mail flow. Some list managers rewrite From headers to avoid breaking DMARC for list members. Some alter the message and break DKIM. If the list is business-critical, use the list provider's current guidance rather than relaxing your whole domain policy.

If unknown IPs fail with no useful override reason, leave enforcement in place. That may be spoofing. With p=none, use the data to find real senders before moving to p=quarantine or p=reject. With p=reject, watch for normal mail failures before assuming every unknown source is harmless.

Do not mix this up with AI crawler access

DMARC reports explain email authentication. Robots.txt explains web crawler policy. They live in different systems, but both affect whether people can find and trust you.

If your website needs to appear in AI answers, allow the crawlers that decide live AI-search visibility: OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews through the normal Search index, and Applebot for Apple Intelligence. Disallowing these in robots.txt removes you from that engine.

Training and opt-out controls are separate. 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 do not claim what a bot did without logs and vendor docs. Only Googlebot documents JavaScript rendering. If your main content appears only after client-side JavaScript runs, other AI crawlers may miss it. Treat that as an undocumented risk and put important text in the first HTML response. Use the free AI visibility checker for that web-side check.

Use the report without over-reading it

DMARC aggregate reports are summary data. They are good for patterns. They are poor for proving exactly where one message landed.

A report row usually groups messages by source IP and result. It can show header_from, SPF domains, DKIM selectors, counts, disposition, and reason. It usually does not show the subject, body, full recipient list, or the spam folder decision. A message can pass DMARC and still land in spam. A message can fail DMARC and still be accepted because of local policy.

Use official sources when a vendor's advice sounds loose: RFC 7208 for SPF, RFC 6376 for DKIM, RFC 7489 for the original DMARC reporting vocabulary, and RFC 9990 for current aggregate reporting. For provider behavior, use the current Google and Microsoft sender guidelines. For AI crawlers, use the vendor docs from OpenAI, Anthropic, Perplexity, Google, Apple, and Common Crawl.

The right output from a DMARC review is a short sender list: source IP, provider, count, SPF result, DKIM result, alignment result, override reason, and next action. That gives your DNS owner or vendor support team enough to fix the mail stream without guessing.