How does email forwarding affect SPF, DKIM, and DMARC validation?
Published 2 Jul 2025
Updated 20 Oct 2026
13 min read
Summarize with
Updated on 20 Oct 2026: We clarified forwarding types and corrected how to diagnose SPF, DKIM, and DMARC failures.
Automatic email forwarding changes the connecting sender IP, so SPF for the original Return-Path domain commonly fails. If the forwarder uses Sender Rewriting Scheme (SRS), SPF can pass for the rewritten Return-Path, but that domain normally is not aligned with the original visible From domain. DKIM can still pass with DMARC alignment if the signed body and headers stay intact. Automatic forwarding therefore removes the SPF path to DMARC in most cases and leaves aligned DKIM as the deciding check.
Unknown IPs in aggregate reports are not proof of forwarding. First compare the traffic with customer bounces, identify whether the source follows a stable receiver pattern, and check whether aligned DKIM survived. If both SPF and DKIM fail, DMARC monitoring helps identify the failing sources, but missing bounces alone do not prove spoofing.
The short rule
DMARC needs one aligned authentication pass, not both. Forwarding often breaks SPF or its alignment, but a valid DKIM signature with an aligned signing domain can carry the message through DMARC.
- SPF: Checks the IP that connects to the final receiver against the Return-Path domain.
- DKIM: Checks the cryptographic signature and survives when the signed content stays intact.
- DMARC: Passes when SPF or DKIM passes and its authenticated domain aligns with the visible From domain.
- Reports: Unknown IPs are evidence to investigate, not proof of forwarding.
Manual forwarding versus automatic forwarding
The authentication effect depends on whether forwarding creates a new message or redirects the original message.
- Manual forwarding normally creates a new message with the forwarding person's address in the visible From header. The final receiver evaluates that domain's SPF, DKIM, and DMARC configuration. Quoted original headers are body text, not the new message's authentication identity.
- Automatic forwarding through a mailbox rule, alias, or email redirection normally retains the original visible From header. The final receiver still evaluates the original domain's DMARC policy, but SPF sees the forwarder's IP. A redirect or resend command that preserves the original From has the same risk, even when triggered manually.
Forwarding as an attachment also creates an outer message with its own authentication. The attached original message does not authenticate that outer message. The distinction between resending and changing the visible From domain is described in RFC 7960.
What automatic email forwarding changes
Forwarding creates another SMTP delivery hop. The first receiver accepts the message, then sends it to a second mailbox. The final receiver sees the forwarder as the connecting system. That is why the source IP in a DMARC aggregate report often looks unfamiliar. It is the IP used by the forwarder, not the original email platform.
The envelope sender is the SMTP MAIL FROM address, usually recorded as Return-Path after delivery. SRS rewrites this address without changing the visible From header. Without SRS, SPF normally tests the original envelope sender domain against the forwarder's IP and fails. With SRS, SPF can pass for the forwarder's domain when that domain's SPF record authorizes the forwarding server, but that result normally lacks DMARC alignment with the original visible From domain. SPF evaluates the current SMTP hop, not the original sender's earlier connection.
|
|
|
|
|---|---|---|---|
SPF | Usually passes and aligns | Often fails or loses alignment | Usually cannot pass DMARC alone |
DKIM | Usually passes | Can pass if signed content stays intact | Passes DMARC when the signing domain aligns |
DMARC | Needs one aligned pass | Usually depends on aligned DKIM | Fails if neither path passes and aligns |
ARC | Usually unnecessary | Can preserve prior authentication evidence | Receiver decides whether to use it |
Common authentication results after forwarding
Email forwarding flowchart showing SPF failure and DKIM-based DMARC validation
Authentication pass versus DMARC alignment
SPF and DKIM produce their own authentication results. DMARC then asks whether a passing SPF Return-Path domain or passing DKIM signing domain aligns with the domain in the visible From header. Under relaxed alignment, the domains can share the same organizational domain. Under strict alignment, they must match exactly.
This distinction explains why SRS solves an SPF transport problem without usually solving DMARC. The rewritten address can authenticate under the forwarder's domain, while the visible From header still contains the original sender's domain. The SPF result is pass, the SPF alignment result is fail, and DMARC still needs aligned DKIM.
|
|
|
|
|---|---|---|---|
Original Return-Path retained | SPF usually fails | No SPF alignment pass | Needs aligned DKIM |
SRS rewrites Return-Path | SPF can pass | Usually not aligned with original From | Needs aligned DKIM |
Aligned DKIM survives | DKIM passes | DKIM domain aligns | Pass |
Trusted ARC chain present | Prior results are recorded | Current DMARC can still fail | Receiver can apply a local override |
Authentication and alignment outcomes
Alignment defaults
DMARC uses relaxed SPF and DKIM alignment unless the record sets aspf=s or adkim=s. Strict alignment requires an exact domain match; a subdomain and its parent no longer count as aligned. This is separate from the p=quarantine or p=reject enforcement policy and from DKIM canonicalization.
Why SPF fails but DKIM can survive
SPF asks whether the connecting IP is allowed to send for the envelope sender domain. That works for direct mail because the authorized sending platform connects to the receiver. After forwarding, the last system is the forwarder, so the original sender's SPF authorization no longer describes the connection.
DKIM is bound to the message rather than the latest SMTP connection. The sender signs selected headers and a body hash, and the final receiver checks the signature against the public key in DNS. DKIM survives when the signed data is unchanged after the selected canonicalization is applied. Relaxed canonicalization tolerates defined whitespace changes and header folding, not arbitrary edits that leave the meaning unchanged. Subject tags, added footers, MIME re-encoding, body wrapping, and changes to signed headers can invalidate it. These rules are defined in RFC 6376.
SPF after forwarding
- IP check: The final receiver checks the forwarder's IP against the current Return-Path domain.
- SRS: A forwarder can rewrite the Return-Path so SPF passes for its own domain.
- Limit: That SRS domain normally is not aligned with the original visible From domain.
DKIM after forwarding
- Signature: The signature remains valid when the signed headers and body still verify.
- Breakage: Footers, header rewrites, and MIME changes can invalidate the signature.
- Alignment: The passing d= domain must be aligned with the visible From domain for DMARC.
Simplified forwarded pathtext
Original delivery: example.com -> recipient mailbox SPF checks example.com against original sending IP: pass and aligned DKIM signature d=example.com: pass and aligned Forwarded delivery: recipient mailbox -> second mailbox SPF checks example.com against forwarding IP: fail DKIM signature d=example.com: pass if signed content is unchanged DMARC: pass because aligned DKIM survives
When forwarding makes DMARC fail
Forwarding makes DMARC fail when the message loses both aligned paths. SPF usually fails when the original envelope sender is retained, or usually loses alignment when SRS substitutes the forwarder's domain. DKIM fails because the forwarded message no longer matches the signed version, or it passes under a domain that is not aligned. With a p=reject policy, the sender requests rejection of DMARC failures, while the final receiver decides how to handle them. A p=quarantine policy requests suspicious treatment, often delivery to spam. A DMARC pass does not guarantee inbox placement.
Do not fix forwarding by trusting random IPs
Adding a forwarder's IP to your SPF record is usually the wrong fix. SPF authorizes systems to send with your domain in the envelope sender. If that address is retained, the addition can produce an aligned SPF pass, but it grants that infrastructure permission to use your domain. If SRS uses the forwarder's domain instead, your SPF record is not the record being checked. Changing -all to ~all also does not create the SPF pass that DMARC requires.
- Body edits: Footers and link rewrites can break DKIM.
- Header edits: Subject tags and changes to signed headers can break DKIM.
- Mailing lists: List footers and subject prefixes can break a signature that simple alias forwarding would preserve.
- ARC use: A trusted ARC chain can support a receiver's local handling decision after DMARC fails.
Authenticated Received Chain (ARC) lets an intermediary record the authentication results it observed before forwarding and seal that history. ARC does not convert the final DMARC result into a pass. The final receiver validates the chain, decides whether it trusts the intermediary, and can use that evidence when applying local policy. An arc=pass result alone does not establish trust or guarantee acceptance. This distinction is defined in RFC 8617. Read more about ARC in forwarded mail.
How to tell forwarding from spoofing
Start with delivery impact. Compare aggregate rejection counts with customer complaints and bounce volume, but do not classify traffic as spoofing just because those signals remain flat. A forwarder can accept the first delivery and then fail on the next hop, so the original sender's logs alone do not establish final delivery.
If customer complaints or bounce messages rise at the same time, investigate a forwarding failure. Check the Authentication-Results header added by the final receiver on a delivered sample, confirm whether aligned DKIM passed, identify which receiver reported the failure, and compare the source with known forwarding routes. Earlier Authentication-Results headers require a trusted path or validated ARC evidence. A focused domain health check verifies the public DNS setup before report analysis begins.
- Bounces: Match rejected report volume against actual bounce messages and support tickets.
- Sources: Group unknown IPs by receiver, reported source, geography, and daily pattern.
- Alignment: A raw DKIM pass does not help DMARC unless its d= domain aligns with From.
- Headers: Authentication-Results, ARC headers, and Received hops can confirm an indirect route.
- History: A stable source and receiver pattern supports investigation; confirm the recipient route with message headers or forwarding logs.
Aggregate reports group traffic by source IP and authentication outcomes. They do not contain individual recipient addresses; the optional envelope_to field is a recipient domain. In the XML, auth_results contains raw SPF and DKIM results, while policy_evaluated.spf and policy_evaluated.dkim include DMARC alignment. A trusted_forwarder override, when present, is the receiver's explanation for local handling, not proof that every message from that IP is legitimate. These fields are specified in RFC 9990.
DMARC records drawer showing filters, record rows, authentication results, and CSV export
Suped's DMARC record table supports this investigation by filtering reports by source, receiver, authentication result, and domain alignment. That narrows an unknown-IP pattern into sources to confirm, dismiss as unauthorized, or repair.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
What senders and forwarders should do
Senders cannot control every recipient forwarding rule. The sender-side response is to apply aligned DKIM to every legitimate stream, monitor real failures, and avoid weakening DMARC because one indirect route is noisy. Forwarders should preserve signed content, use SRS for bounce handling, and add ARC when they authenticate mail before forwarding it.
Sender actions
- Sign mail: DKIM-sign every stream with a d= domain aligned to its visible From domain.
- Use relaxed: Prefer c=relaxed/relaxed for DKIM to tolerate defined formatting changes; it does not preserve signatures through content edits.
- Stage policy: Move through monitored policy changes only after legitimate sources pass authentication with DMARC alignment.
- Watch impact: Compare aggregate failures with bounces and support cases before changing authentication.
Forwarder actions
- Preserve content: Avoid adding footers or changing MIME structure after authentication.
- Use SRS: Rewrite MAIL FROM with SRS, authorize the forwarding IP in that domain's SPF record, and test reverse routing of bounces.
- Seal ARC: Authenticate inbound mail and validate any existing ARC chain before changes; seal the outgoing message after all modifications.
- Limit rewrites: Avoid subject tags, disclaimers, and link changes on forwarded messages.
Example quarantine DMARC recorddns
_dmarc.example.com TXT ( "v=DMARC1; p=quarantine;" "rua=mailto:dmarc@example.com" )
Example reject DMARC recorddns
_dmarc.example.com TXT ( "v=DMARC1; p=reject;" "rua=mailto:dmarc@example.com" )
Stage policy without pct
RFC 9989 marks the pct tag as historic. Collect aggregate reports at p=none, correct legitimate sources, then publish quarantine or reject as a deliberate policy change. Do not depend on pct for partial enforcement.
This is where Hosted DMARC helps operationally. Suped's product lets teams manage reporting addresses, review authentication data, and publish deliberate policy changes without repeated manual DNS edits during a forwarding investigation.
For recipient-side failures, the repair is usually at the forwarding system rather than in the original sender's SPF record. Keep those cases separate from direct-source authentication work because the evidence and owner differ. The operational steps for forwarding failures cover that split. This same process applies to other legitimate failures caused by indirect mail flows.
How Suped fits into this workflow
Suped's product turns aggregate DMARC data into a working queue for forwarding investigations. Filter by source, receiver, SPF result, DKIM result, and alignment, then compare a suspected route with bounce and support data before changing DNS or policy.
Suped workflow for forwarding noise
- Filter: Isolate SPF failures, surviving DKIM signatures, and alignment results by receiver.
- Classify: Separate known forwarding routes from direct senders and unauthorized traffic.
- Compare: Match report changes with bounce logs and customer reports before treating them as delivery loss.
- Alert: Notify the responsible team when an authentication pattern crosses a configured threshold.
If the immediate question is whether a domain's DMARC DNS record is valid, run a DMARC checker first. If the record is valid and reports still show failures, move to source classification, alignment analysis, and impact checks.
How to investigate forwarding failures
Use the same decision path for each suspected forwarding source. Send comparable test messages directly to a destination mailbox and through the affected forwarding rule, then compare the final receiver's headers. Inspect smtp.mailfrom for the SPF domain, header.d for the DKIM signing domain, and header.from for the DMARC domain. If SRS is present, verify its domain's SPF authorization. If DKIM fails, compare signed headers and body content; a plain-text test helps isolate formatting changes.
Evidence for a forwarding investigation
Use report patterns as clues and confirm routes with headers or forwarding logs.
Unconfirmed source
Investigate
An unfamiliar IP and failed authentication do not establish a route or sender intent.
Possible forwarding
Check route
Aligned DKIM survives despite SPF failure; headers or logs are still needed to confirm forwarding.
Confirmed forwarding failure
Fix route
Headers or forwarding logs confirm the route, and a repeatable test fails on the forwarded hop.
Confirmed unauthorized source
Keep policy
The source owner or logs confirm use of your domain without authorization.
A rejection count in a DMARC aggregate report is not the same as a customer delivery failure. Reports describe how receivers evaluated traffic that used your domain in the visible From header. That traffic includes authorized direct mail, indirect mail, misconfigured senders, and unauthorized use.
- Confirm impact: Check bounce logs, support tickets, and sender logs for the same period.
- Check alignment: Confirm whether a passing DKIM d= domain aligns with the visible From domain.
- Inspect the route: Use message headers and report patterns to distinguish forwarding from a direct sender.
- Avoid SPF fixes: Do not authorize a forwarder's IP unless it legitimately sends mail for your domain.
- Escalate the path: Ask the forwarder to preserve DKIM, use SRS, and seal ARC when supported.
Views from the trenches
Best practices
Preserve DKIM-signed content in forwarding rules and use headers to confirm what changed.
Compare rejection counts with bounces before treating aggregate report spikes as delivery loss.
Group unknown IPs by source and receiver patterns, then confirm routes with headers or logs.
Common pitfalls
Adding random forwarding IPs to SPF gives those systems permission they should not have.
Treating every large-provider source as forwarding can hide abuse and tenant routing errors.
Lowering DMARC policy for all mail to save one forward path weakens domain protection.
Expert tips
Use relaxed DKIM canonicalization and aligned signing domains on every legitimate mail stream.
Ask partners to use SRS and ARC when they forward mail that keeps the original visible From.
Flat bounce volume does not establish whether a rejection spike is forwarding or unauthorized mail.
Marketer view
A marketer says DMARC only needs one aligned authentication path, so a forwarded message can still pass when aligned DKIM survives.
2023-06-14 - Email Geeks
Marketer view
A marketer says SPF failure in forwarded mail can be normal, but both aligned paths failing requires review of message changes and source patterns.
2023-06-14 - Email Geeks
Frequently asked questions
Forwarded email usually fails SPF for the original Return-Path domain because the final receiver checks the forwarder's IP. SRS can produce an SPF pass for the forwarder's rewritten Return-Path, but that domain normally is not aligned with the original visible From domain for DMARC.
Yes. Forwarded email passes DMARC when a DKIM signature survives and its d= domain aligns with the visible From domain. DMARC needs one aligned authentication pass, so SPF failure alone does not cause DMARC failure.
DKIM fails when a forwarder changes signed headers or the signed body. Common causes include added footers, subject tags, MIME re-encoding, body wrapping, and link rewriting. Mailing lists make these changes more often than simple alias forwarding.
No. ARC preserves signed evidence of authentication results observed earlier in the route. A final receiver can validate and trust that chain when applying local policy, but ARC does not change the message's current DMARC result into a pass.
No. Unknown IPs can belong to forwarders, shared tenant systems, or unauthorized senders. Compare receiver names, alignment results, route headers, source patterns, bounces, and customer reports before classifying the traffic.
Do not reduce DMARC enforcement across the domain solely because forwarded mail appears in reports. Improve aligned DKIM coverage, confirm real delivery impact, and work with forwarders to preserve signed content, use SRS, and add ARC when supported.
