Why a forwarded email fails DMARC and how to diagnose it

Confirm that forwarding is the changed hop

Compare the first and final receiver's results: forwarding can break SPF while an intact aligned DKIM signature can still pass DMARC.

Forwarding changes the connecting IP and often breaks the original SPF path; an intact aligned DKIM signature can still satisfy DMARC. Compare the first and final receiver’s trusted results for a specific authorised copy. A forwarding failure does not mean every forwarded message fails DMARC.

First separate a real dmarc=fail result from spam placement or a rejection for another reason. Keep the bounce code, recipient provider, time and message identifier. A mailbox rule or forwarder is available only where the purchased service and its permissions provide one; do not assume that Novasean operates every hop in a third-party route.

Compare the original and forwarded copies safely

Send one harmless test message from an authorised sender to a controlled mailbox on the original route. If permitted, forward it through the affected rule to another controlled mailbox. Do not use a live customer conversation as a test.
At each receiving mailbox, open the provider’s full message headers. Record the visible From: domain, Authentication-Results for SPF, DKIM and DMARC, the SPF smtp.mailfrom domain, each passing DKIM header.d domain and any ARC result. A message can contain several Authentication-Results headers: use the final receiving provider’s own trusted verdict for its decision, rather than treating every header as that provider’s result. A sender-side DNS checker cannot prove the final receiver’s decision.
Compare the two hops and the actual delivery or rejection outcome. Redact addresses, content, tokens and message identifiers before sharing evidence outside an authenticated support channel.

If the original copy already fails DMARC, follow the DKIM and DMARC configuration guides before blaming the forwarder. If you cannot obtain both header sets, ask the responsible receiver or forwarding provider for the specific authentication verdict rather than inventing a cause from a generic bounce.

For a controlled forwarded copy, retain the first receiver's aligned DKIM result and the final receiver's result; a signature that fails only after forwarding points to a changed signed message or header path.

Find which aligned method survived forwarding

Final receiver observes	Likely interpretation	Next owner
`spf=fail`, aligned `dkim=pass`, `dmarc=pass`	Forwarding changed the SPF path, but the original signature survived. A later spam decision needs separate diagnosis.	Recipient operator for its actual filtering reason.
SPF passes for the forwarder’s domain, but its domain does not align with the original `From:`; no aligned DKIM passes	SPF success alone does not satisfy the original sender’s DMARC alignment.	Original sender for aligned DKIM; forwarder if it changed signed content.
`spf=fail`, original DKIM signature now fails	The forwarding hop may have altered a signed header or body, or the signature may have been invalid before forwarding.	Compare the first hop, then ask the operator of the hop that changed the message.
`dmarc=pass` but delivery fails	Authentication is not a delivery guarantee; the receiver may apply other policy.	Recipient operator with the exact SMTP response.

Check the domains as well as the labels. A passing DKIM signature from an unrelated forwarding domain is not necessarily aligned with the original visible sender. If a mailing list rewrites From:, diagnose the identity actually shown to the final receiver rather than assuming it is the original one.

Make the fix at the hop that controls it

If you operate the original sending domain, sign each legitimate stream with DKIM using a domain aligned with its visible From: address and confirm that signature at the first receiver. Keep the existing SPF and DMARC rollout under the domain owner’s change control. Do not add every forwarding server to the original domain’s SPF record: those servers are not automatically authorised senders for that domain.

If you operate the forwarding service, avoid modifying signed content or protected headers where the service permits it. Ask its operator whether envelope-sender rewriting, such as SRS, and ARC are supported for this route. SRS can help a forwarded message pass SPF for the forwarder and route bounces correctly, but an SPF pass for the forwarder’s domain does not by itself align with the original visible From: domain. ARC can convey prior authentication results to a receiver; a valid chain is information for its local decision, not a guaranteed DMARC pass or delivery. Do not edit provider-wide mail configuration or disable checks in a customer account to work around one message.

If you control only the recipient mailbox, give the forwarding and receiving providers the redacted two-hop evidence and ask whether they can preserve the signature or offer a supported mailbox-access route that avoids the forwarding hop. Do not weaken a whole domain’s DMARC policy to fix an unverified single-path problem.

Retest the same route and document the outcome

After one authorised change, send a fresh test through the original and forwarded paths. At the final mailbox, compare From:, smtp.mailfrom, valid DKIM header.d, DMARC verdict and actual delivery. Test one representative external sender and destination only if you control both and the service permits it. A pass at one receiver does not prove acceptance at every provider.

If the message still fails, send support the affected route, times with time zones, exact rejection code, redacted header verdicts at each hop and the change made. Name the operator responsible for each hop. Keep any policy rollback tied to the domain owner’s reviewed DMARC plan and preserve the earlier state for comparison.

Common questions

Does forwarding always break DMARC? No. An aligned DKIM signature can survive a simple forward even when SPF fails.

Will SRS alone make the original sender pass DMARC? No. SRS changes the envelope sender; a new SPF pass for the forwarder may not align with the original visible From:.

Does ARC override DMARC? No. ARC supplies a verifiable history that a receiver may consider under its own policy. It is not a promise of acceptance.

Should I change p=reject immediately? Diagnose the failing stream and review aggregate reports with the domain owner before any policy change. A one-message symptom is not a safe basis for changing all mail handling.

Does a DMARC pass at the first mailbox prove the forwarded copy will pass? No. Compare the final receiver's trusted result after every intermediary.

Sources and technical references

Prepared by Team Novasean from the references above. Menus and available features depend on your installed version and service permissions.

Related guides

Was this guide helpful?

If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .

Need help with your service?

Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.