DMARC Fail but Delivered: Understanding ARC Overrides

A DMARC aggregate report can show a message that failed SPF and DKIM, yet the receiver reports a disposition of none even though the domain publishes p=quarantine or p=reject.

That is not automatically evidence that the report is wrong or that the receiver ignored authentication. Forwarding and mailing-list paths can break SPF or DKIM after the message was authenticated earlier. The receiver may use ARC or another local-policy signal when deciding how to handle the message.

DMARC result and delivery decision are different

DMARC evaluates whether SPF or DKIM passes with alignment to the visible From domain. The result is a pass or fail.

The receiver then makes a handling decision. A published DMARC policy expresses the domain owner’s requested treatment for failures, but receivers can apply local policy. RFC 9989 makes that distinction explicit.

This means both of these statements can be true:

• the message failed DMARC; and
• the receiver still delivered it.

Do not change a failed authentication result into a pass merely because delivery succeeded.

Why forwarding breaks authentication

SPF follows the connecting path

SPF checks the IP address connecting to the receiver against the envelope-sender domain’s authorised record. When a message is forwarded, the final connection comes from the forwarder rather than the original sender. Unless the forwarding system rewrites the envelope sender appropriately, SPF can fail.

DKIM can survive forwarding, but not every modification

DKIM can survive simple forwarding because the signature travels with the message. It can fail when an intermediary modifies signed content, for example by:

• adding a footer;
• rewriting the subject;
• changing MIME structure or encoding; or
• modifying signed headers.

If forwarding breaks SPF and message modification breaks DKIM, the final receiver sees a DMARC failure even if the original message was authenticated before it entered the forwarding path.

What ARC contributes

ARC stands for Authenticated Received Chain. RFC 8617 defines a way for participating intermediaries to record authentication results and seal a chain of custody as a message passes through them.

An ARC set contains:

• an ARC-Authentication-Results header recording results observed at that hop;
• an ARC-Message-Signature; and
• an ARC-Seal linking the set to the earlier chain.

At the final receiver, a valid ARC chain can provide evidence that the message passed authentication before forwarding changed it. The receiver decides whether it trusts the ARC sealer and how much weight to give that evidence.

ARC does not turn the final DMARC evaluation into a pass. It gives the receiver additional context for its local handling decision.

What local-policy data means in reports

Aggregate-report formats can include a reason indicating local policy. The exact data presented by reporting systems varies, but the operational question is the same: did the receiver make a different handling decision because it had trusted context outside the final DMARC pass/fail result?

Useful evidence includes:

• the source IP and volume pattern;
• the reported disposition;
• SPF and DKIM results;
• any reported override reason;
• whether the path is associated with a known forwarder or mailing list; and
• whether the pattern is stable or has changed.

An aggregate report does not contain enough evidence to prove that a particular delivered message was benign. It is a summary that guides investigation.

Expected patterns versus patterns to investigate

Often explainable

A pattern may be consistent with ordinary forwarding when:

• the source belongs to a known forwarding or mailing-list path;
• the volume is low and stable relative to normal reporting;
• the same path repeatedly shows the same reason; and
• customer mail-flow documentation supports the explanation.

Record the explanation and continue monitoring. Do not invent a universal percentage threshold for “normal”; domains and forwarding patterns differ.

Worth investigating

Investigate when:

• a new source appears without a known forwarding explanation;
• volume changes materially;
• failures are associated with a business-critical flow;
• the expected DKIM signature is missing or invalid;
• report data shows an unfamiliar or inconsistent override reason; or
• customer reports and aggregate evidence do not agree.

The goal is to distinguish a known forwarding side effect from an unauthorised or broken sending path.

How this affects policy progression

ARC evidence can explain why a receiver delivered a forwarded message that failed DMARC, but it does not convert that message into a DMARC pass. Review the path, confirm whether it is legitimate, and use the domain’s broader report evidence when deciding whether a policy change is safe.

Do not postpone enforcement solely because a small, understood forwarding pattern exists. Equally, do not dismiss a large or unexplained failure pattern because some rows mention local policy.

Before progressing policy:

1. identify the source and forwarding path;
2. confirm whether the original service signs with aligned DKIM where possible;
3. check whether content modification is expected;
4. document receiver-local outcomes separately from authentication pass rates; and
5. include the pattern in customer communication and ongoing monitoring.

Read the policy-progression guide for the wider decision process.

Reporting the result to a customer

Use precise language:

This mail failed DMARC at the final receiver. The receiver reported a local handling decision that may be consistent with a known forwarding path. We are confirming the source and monitoring the pattern; delivery does not change the authentication result.

Avoid saying that ARC “fixed” DMARC, that a delivered message was automatically safe, or that the domain achieved a perfect authentication result.

What ARC does not solve

• ARC does not guarantee that a receiver trusts the chain.
• ARC does not repair the domain’s SPF or DKIM configuration.
• ARC does not protect lookalike domains or compromised accounts.
• ARC does not inspect message intent or content.
• ARC does not force a receiver to deliver or reject a message.
• ARC does not make every forwarding failure harmless.

Frequently asked questions

Why can p=reject mail still be delivered?

p=reject is the domain owner’s requested handling for DMARC failures. A receiver can apply local policy, including trusted forwarding evidence, when making its final delivery decision.

Does ARC override DMARC?

ARC does not rewrite the DMARC result. A receiver may use a valid, trusted ARC chain as additional evidence and choose a different handling outcome.

Do ARC-related messages count as DMARC passes?

No. If the final evaluation failed, report it as a failure. Track the receiver’s handling decision separately.

Can I prevent every ARC override?

No. The final receiver controls its local policy. You can improve the original flow by using aligned DKIM and avoiding unnecessary content modification, but you cannot dictate receiver trust decisions.

When should an MSP escalate an override pattern?

Escalate when the source or path is unknown, the pattern changes, a business-critical flow is affected, or the evidence is inconsistent. A known, stable forwarding pattern can be documented and monitored.

If you do not recognise override data, start with the DMARC report guide and check the current public records with the free DMARC checker.