Why do forwarded emails fail SPF, DKIM, or DMARC after delivery? – Help Center

What happens when an email is forwarded

Consider this delivery path:

Your sending service sends an email from sender.example to recipient@example.com.
The recipient’s server accepts the message. The email is recorded as delivered.
The recipient’s mailbox automatically forwards the message to recipient@another-domain.com.
The forwarding server sends the message to the next receiving server.
The next server evaluates SPF, DKIM, and DMARC again and may reject the message.

The first delivery and the forwarded delivery are separate server-to-server transactions. A successful first delivery doesn't guarantee that the forwarded copy will pass authentication.

Forwarding is common when a person:

Moves from one mailbox provider to another.
Forwards a work mailbox to a personal mailbox.
Uses an alias or distribution address.
Routes messages through a security gateway or another mail system.
Forwards messages without keeping a copy in the original mailbox.

Why forwarding can break SPF

Sender Policy Framework (SPF) checks whether the server connecting to the recipient is authorized to send email for the envelope sender domain, also known as the Return-Path domain.

For the original delivery, your email service sends the message from an authorized server. SPF can pass because that server is included in your SPF record.

After forwarding, the forwarding server makes a new SMTP connection. Its IP address might not be authorized to send email for the original envelope sender domain. The final receiving server can therefore return an SPF failure, even though the original delivery passed SPF.

Some forwarding services use the Sender Rewriting Scheme (SRS) to rewrite the envelope sender address and preserve SPF during forwarding. Not all forwarding services use SRS, and SPF alignment can still fail depending on the rewritten domain and the receiving server’s checks.

Why forwarding can break DKIM and DMARC

DomainKeys Identified Mail (DKIM) adds a digital signature to selected message headers and the message body. The receiving server checks the signature against the public key in your DNS.

A forwarded message can still pass DKIM if the forwarding service leaves the signed content unchanged. However, a forwarding system may modify the message by adding a footer, rewriting headers, changing the subject, or re-encoding the body. These changes can invalidate the original DKIM signature.

Domain-based Message Authentication, Reporting, and Conformance (DMARC) evaluates whether SPF or DKIM passes and aligns with the domain in the visible From address. DMARC doesn't require both mechanisms to pass. It requires at least one aligned mechanism to pass.

Forwarding can cause DMARC to fail when:

SPF fails because the forwarding server isn't authorized for the original envelope sender domain.
DKIM fails because the forwarding service modified the signed content.
SPF or DKIM passes for a domain that doesn't align with the visible From domain.
The final provider applies stricter checks than the first recipient provider.

If the sender’s DMARC policy is p=reject or p=quarantine, the final provider may reject or quarantine the forwarded message.

For the protocol details, see RFC 7489 and RFC 8617. RFC 8617 describes Authenticated Received Chain (ARC), which allows intermediaries to preserve authentication results through forwarding. ARC can help, but the forwarding path and final provider must support and trust the ARC chain.

Why are only some recipients affected?

Forwarding rules belong to individual mailboxes or mail systems. Most recipients don't forward messages, so their emails follow the normal delivery path and pass authentication.

The failure may also appear to be provider-specific. For example, a message sent to a mailbox at one provider may be automatically forwarded to Microsoft, Yahoo, or another provider. The bounce comes from the final receiving provider, not necessarily from the domain in the original recipient address.

This explains why you may see a Microsoft authentication bounce when the original address belongs to a different provider.

How to confirm that forwarding is the cause

Check the following signals together:

The email has a delivered event followed later by a soft_bounced or hard_bounced event.
The delivery log identifies the failure as delayed. Mailgun uses the is-delayed-bounce indicator for this type of event. See Mailgun metric definitions.
The SMTP response mentions authentication, such as doesn't meet the required authentication level, does not pass DMARC, or SPF check failed.
Only a subset of recipients is affected.
Direct deliveries to other recipients using the same sending domain continue to succeed.
The recipient confirms the use of an auto-forwarding rule, an alias, or another intermediary mail system.

Review the exact SMTP response instead of relying only on the soft_bounced or hard_bounced status. A different error, such as an invalid address or a malformed From header, has a different cause and requires separate troubleshooting.

What you can do

Verify your sending authentication

Confirm that the sending domain has valid and aligned SPF, DKIM, and DMARC records. If direct deliveries work and the failure is limited to recipients forwarded, avoid repeatedly changing DNS records based solely on those bounces.

If authentication fails across many providers, or direct deliveries fail as well, investigate the sending configuration. For general bounce troubleshooting, see Email bounce investigation.

Ask the recipient to review forwarding

The recipient or their mail administrator can:

Turn off the forwarding rule and test delivery again.
Forward the message to a different destination.
Keep a copy in the original mailbox.
Check the forwarding server’s logs for SPF, DKIM, DMARC, SRS, and ARC results.
Send you a direct mailbox address that doesn't use forwarding.

There is usually no sender-side DNS change that can authorize every possible recipient forwarding server to send mail for your domain.

Decide whether to retry or suppress the address

Retry the address once when the failure is isolated, the original delivery succeeded, and forwarding may have changed or stopped. A later successful delivery is consistent with a forwarding rule being removed or corrected.

If the same authentication failure happens again, stop repeatedly retrying the address. Suppress the address from future campaigns or ask the recipient for a mailbox that doesn't use forwarding. Repeated soft bounces can contribute to cumulative bounce suppression. For the current suppression behavior, see Email bounce management.

Don't suppress an entire domain only because a few forwarded addresses fail. First, compare the affected addresses with direct recipients and check the exact bounce message.

When to contact support

Contact support when authentication-related failures affect many direct recipients across multiple providers, or when your direct deliveries also fail. Include:

The sending domain.
The recipient domain and affected mailbox type.
The exact SMTP response.
The event timestamps.
The message ID, if available.
Whether the event sequence shows delivered followed by a delayed bounce.

This information helps distinguish a sender authentication problem from a forwarding-path problem.

Summary

Forwarding changes the delivery path. The final receiving server may see a forwarding server that is not authorized by the original SPF record, or it may receive a message whose DKIM signature no longer verifies. If neither SPF nor DKIM passes with alignment to the visible From domain, DMARC can fail.

The strongest indicators are a delivered event followed by a delayed authentication bounce, a low number of affected recipients, and successful direct deliveries from the same sending domain. In that situation, retry the address once, then suppress it or use a non-forwarded address if the failure repeats.

For the symptom-focused companion article, read Why did my email bounce after it was delivered?