Why forwarded email gets rejected or junked, and what to use instead of a forward

What a forward does to the message

A forwarding rule takes a message that arrived at your server and sends it on to another address. The receiving server sees a message from your server, not from the original sender's. SPF checks whether the sending server is allowed for the envelope sender's domain, so the check can fail simply because the forwarder is not on that list. DKIM, which signs parts of the message, can survive, but Google lists what breaks it: changing the subject, the To, Cc, Date or Message-ID headers, altering MIME boundaries or re-encoding the body.

Why DMARC makes it visible

DMARC passes if either SPF or DKIM passes on a domain that matches the visible From address. A forward that breaks SPF can still pass DMARC if DKIM stays intact. If the sender publishes a strict policy and both fail, the receiver may reject the message. Microsoft's documentation notes that its sender rewriting scheme, which rewrites the envelope sender so SPF can pass, does not by itself fix DMARC, because the rewritten sender does not match the From domain. Authenticated Received Chain was developed to deal with the limits of DKIM across forwards, and Microsoft 365 implements it, but it only helps where the final receiver trusts the sealer.

• SPF can fail on a forward and still leave DKIM to pass.
• Rewriting the envelope sender helps SPF, not DMARC alignment.
• The final receiver decides what to do with a failure.

Policy blocks that look like authentication failures

Microsoft 365 can block automatic forwarding to outside addresses. Its outbound spam policy has three settings: on, off and a system-controlled default, whose behaviour Microsoft says differs between organisations and recommends replacing with an explicit choice. When forwarding is off, the sender receives a non-delivery report with 5.7.520 and the words access denied. Mail flow rules and remote domain settings can also block forwards, and when one allows and another blocks, the block typically wins. This is the cause when forwarding "worked for years and stopped": a policy changed, not the DNS.

A safe first investigation

Open one forwarded message that did arrive and read the Authentication-Results header for spf, dkim and dmarc. Read the bounce for any that did not. Find out where the forward is set: the provider's admin settings, a person's inbox rule or the web host's panel, because each fails differently and is fixed in a different place. Check the destination's junk and quarantine areas before concluding anything is lost.

• Write down: forwarding type, source address, destination, sender examples.
• Keep the header lines and bounce text with personal details removed.

Alternatives to forwarding, and the paid outcome

If everyone who should read the mail is inside the same email account, an alias, a group or a shared mailbox delivers the original message and avoids re-sending it. Google's documentation draws the same line: forwarding alters the original content, while redirecting leaves it untouched. Where forwarding must stay, the sender's authentication, your provider's forwarding policy and the destination's filters all matter, and nobody can guarantee a junk-free result.

The fixed-price job for this is a published test price of £165, not yet tested with buyers, payable after sign-off. It covers up to five rules. For each, a test from two outside providers must reach the final destination without a bounce, with the cause of the original failure recorded from the headers, and any replacement alias or shared mailbox must deliver the original message to every named recipient. It does not recover mail already lost, and it leaves any decision about blocking outside forwarding with you.