How to troubleshoot DMARC failures caused by forwarding
Updated on 29 Sep 2026: We updated this guide for RFC 9989 and added clearer alignment, SRS, ARC, and paired-header troubleshooting.
Forwarding often breaks SPF because the forwarder's server sends with the original envelope sender, but its IP address is absent from that sender's SPF record. DMARC still passes when an intact DKIM signature uses a signing domain that matches the visible From domain. It fails when SPF loses that domain match and DKIM is missing, invalid, or signed with another domain.
Treat this as a message-path problem, not as an instruction to weaken the client's DMARC policy. For an MSP, the practical job is to identify the forwarder, prove which authentication path changed, decide who can fix it, and document the residual risk for the client.
Why forwarding changes the DMARC result
DMARC evaluates the visible From domain against an authenticated domain. SPF authenticates the envelope sender domain for the connecting IP. DKIM authenticates a signed copy of the message. A normal direct delivery can pass through either route. A forwarder inserts a new sending IP, so the original SPF authorization no longer describes the last SMTP hop.
Flow of SPF and DKIM checks after email forwarding
DKIM can survive forwarding because the signature travels with the message. It breaks when the forwarder changes signed content, such as the subject line, message body, MIME structure, or signed headers. Mailing lists commonly add a footer or subject tag. Security gateways can rewrite links. Either change can invalidate the original signature.
Do not authorize the forwarder's IP in client SPF
The forwarder is sending mail for many unrelated domains. Adding its IP to the client's SPF record expands authorization without restoring the original route correctly. Fix DKIM preservation, use sender rewriting where the forwarder controls the envelope, or use receiver-side forwarding controls instead.
Check authentication and domain alignment separately
An SPF or DKIM pass does not guarantee a DMARC pass. The passing identity must also match the visible From domain under the domain's alignment mode. Read the raw result as two checks: did authentication pass, and did the authenticated domain match?
|
|
|
|---|---|---|
header.from | Visible From domain | DMARC reference identity |
smtp.mailfrom | Visible From domain | SPF alignment |
header.d | Visible From domain | DKIM alignment |
Domain comparisons that determine DMARC alignment
Relaxed alignment, the default, accepts domains that share the same Organizational Domain. Strict alignment requires an exact domain match. SRS normally rewrites the envelope sender into the forwarder's domain, so SPF can pass for the new hop while SPF alignment with the original visible From domain still fails.
Use the current DMARC standard
RFC 9989 became the DMARC standard in 2026 and replaced RFCs 7489 and 9091. It keeps the core pass rule: at least one authenticated identifier must have domain alignment with the visible From domain.
Find the failing route in DMARC data
Start with aggregate reports and group failures by source IP, reporting provider, header From domain, and authentication result. A forwarding pattern usually has low or irregular volume, SPF failure, and either DKIM pass or DKIM failure. The same original sender often appears through several destination networks because users set forwarding independently.
Separate mailbox forwarding from a service that sends on the client's behalf. A forwarder relays a message that already passed through an initial receiver. A third-party sender originates a new message and often uses its own envelope sender or DKIM domain. The source may look unfamiliar in both cases, but only the forwarding route calls for SRS or ARC analysis.
For recurring client operations, DMARC monitoring should retain source history so the MSP can separate a new sender from an established forwarding route. Compare the first-seen date with mailbox migrations, routing-rule changes, acquisitions, and new helpdesk aliases. Do not classify an unfamiliar IP as malicious until the message path is confirmed.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
Suped's Issues view helps an MSP separate verified and unverified sources, inspect pass rates, and prioritize the routes affecting the most client mail. That workflow creates an evidence trail: source, volume, affected domain, first observation, authentication outcome, client owner, and next action.
- Source pattern: Look for a receiving or routing network sending mail that originated elsewhere.
- SPF evidence: Use paired raw headers to confirm that SPF passed at the first receiver and failed at the final receiver.
- DKIM evidence: Record the selector, signing domain, result, and any body-hash failure.
- Scope evidence: Measure affected recipients, message types, and client business processes.
Prove whether the forwarder or sender broke authentication
Obtain one direct-delivery copy and one forwarded copy of the same test message. Preserve full headers. Compare the Authentication-Results fields added by each receiver, the Return-Path, DKIM-Signature fields, and body-hash status. Read Received headers from the bottom upward to reconstruct the hops, then check the ARC instance sequence when it exists. This comparison shows where the result changed without relying on assumptions about the provider.
Sender-side fault
The sender gave forwarded mail no durable authentication path.
- Missing DKIM: The direct message has no valid signature.
- Wrong domain: The signing domain does not match the visible From domain under the configured mode.
- Weak coverage: Only some sending services apply the expected signature.
- Old key: The selector is missing or publishes the wrong public key.
Forwarder-side fault
The direct message passes, then the forwarding system changes it.
- Body change: A footer or MIME rewrite breaks the signature.
- Header change: A signed subject or address header changes.
- No SRS: The original envelope sender remains, so SPF fails.
- Local policy: The final receiver does not use trustworthy forwarding evidence.
Forwarded message authentication resulttext
Authentication-Results: mx.example.net; spf=fail smtp.mailfrom=bounces.sender.example; dkim=pass header.d=client.example; dmarc=pass header.from=client.example
This sample still passes DMARC through DKIM. If the last line says fail, verify whether DKIM failed cryptographically or passed with a different domain. When several DKIM signatures are present, inspect every result because one valid domain-matched signature is enough for DMARC. ARC headers can preserve earlier authentication observations, but ARC does not force a receiver to accept the message. Treat ARC as supporting evidence, not as a replacement for DMARC.
Apply the fix at the right control point
The fix depends on who controls the failing hop. Assign each incident to the sender, forwarder, receiver, or client mailbox owner. That prevents the MSP team from making unrelated DNS changes while the actual fault sits in a mail-routing rule.
|
|
|
|---|---|---|
No DKIM | Sender | Enable matching DKIM |
Body changed | Forwarder | Stop content edits |
Plain forwarding | Forwarder | Use SRS for SPF |
ARC ignored | Receiver | Review local policy |
Compact routing diagnosis and ownership map
Sender Rewriting Scheme, usually called SRS, replaces the envelope sender during forwarding so SPF evaluates a domain controlled by the forwarder and bounces can return through the forwarder. It makes SPF technically correct for the new hop, but it does not normally make that rewritten domain match the original visible From domain. Preserved, domain-matched DKIM remains the reliable DMARC path.
- Enable DKIM: Sign every client-authorized stream with the visible From domain, or the same Organizational Domain when relaxed alignment applies.
- Preserve content: Disable footers, subject tags, and rewrites on forwarding paths where possible.
- Configure SRS: Use it on the forwarding service to make SPF correct for the new hop and preserve bounce handling.
- Review ARC: Confirm the forwarder seals results and the receiver has a reason to trust that chain.
- Retest policy: Keep enforcement staged until known forwarding routes have stable DKIM outcomes.
Retest without weakening client protection
Send a controlled message to a mailbox that forwards to a second provider, then collect the final raw headers. Test direct delivery at the same time. Use the same From domain, sending service, and DKIM selector so the forwarding hop is the only meaningful variable. A broad domain health check can confirm the published DMARC, SPF, and DKIM configuration before you investigate the live route.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
The email tester gives the MSP a repeatable message-level result that can be attached to the ticket. Run it before the change and after the change. Save both outputs with the aggregate-report evidence, because forwarding incidents often reappear when a client creates another mailbox rule or a gateway starts modifying content again.
Do not weaken policy to hide one route
Changing DMARC to monitoring-only stops enforcement for every failing message, including spoofed mail. RFC 9989 removed pct and introduced t=y for testing: quarantine is treated as none, while reject is treated as quarantine. The tag does not stop reports. If a client needs staged enforcement, record the affected route, owner, review date, and exit condition. Use hosted DMARC policy controls to manage a deliberate rollout, not to hide an unresolved route.
Turn the fix into an MSP service workflow
Forwarding failures are easier to manage when every client follows one operating procedure. The ticket should include the affected domain, forwarding source, message sample time, raw headers, report volume, business impact, technical owner, and retest date. For broader service design, the DMARC for MSPs collection connects this troubleshooting work with onboarding, monitoring, and client reporting.
Suped's DMARC monitoring product gives MSPs one operational view across multiple client domains. Its multi-tenant dashboard groups authentication failures by source and domain, adds issue alerts and fix steps, and tracks DMARC policy changes. SPF, DKIM, blocklist (blacklist), and deliverability context help a technician rule out unrelated reputation problems while keeping the incident record in one workflow.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Close the incident only after the direct and forwarded tests pass through the intended authentication route, aggregate data stays stable for the agreed observation window, and the client understands any receiver-controlled exception. Suped's steps-to-fix view gives the service desk a consistent place to record that work and verify the change.
A durable fix protects the forwarding path
A forwarding-related DMARC failure is resolved when the message keeps one valid domain-matched authentication route after the extra SMTP hop. In practice, that usually means reliable DKIM signing plus a forwarder that does not alter signed content. SRS makes the forwarding hop's SPF behavior correct, while ARC can give the final receiver useful history. Neither one excuses missing DKIM on client-authorized mail.
For an MSP, the durable outcome is a documented route, a named owner, a preserved test message, and monitoring that detects recurrence. Keep the client's enforcement goal intact, fix the component that changed authentication, and stage policy changes against measured evidence.
