Mail we forward is rejected by recipients on DMARC
On forwarding SPF breaks (envelope-from changes) and DKIM sometimes breaks (body tweaks). ARC (RFC 8617) solves this: the forwarder signs the original authentication result so the end recipient can trust it. Google and Microsoft seal ARC by default.
Try this first
- 1Identify which forwarder is breaking. In Microsoft 365 see Message Trace, in Google use Email Log Search. Forwards from mailing lists or old rules are classic causes.
- 2On M365 or Google Workspace ARC is signed for you. Verify a forwarded message contains ARC-Authentication-Results, ARC-Message-Signature and ARC-Seal headers.
- 3If you have an own relay or list server (Mailman, Sympa), check ARC support and that it's enabled. Mailman 3 supports ARC, older versions don't.
- 4For mailing lists From-rewriting (Sender, Reply-To, From: list@..) is also an option. Not always elegant but reliable.
- 5Test a forwarded message with a DMARC validator like Mailhardener or dmarcian. They show whether ARC is trusted by major receivers.
When to bring us in
A legacy MTA in the chain without ARC support can't be fixed without replacement. Either redesign the mail flow or upgrade the MTA.
See also
- Our emails land in spam for some recipientsAlmost always an SPF, DKIM, or DMARC setting that is wrong or missing, or a sender name that mimics a well-known brand.
- Someone reports receiving phishing emails "from us"Read: spoofing. Someone is abusing your sender name, not necessarily your actual mailbox.
- An email bounces (NDR): delivery failedThe NDR text usually states the exact reason. Reading it is step one.
None of the above fits?
Describe your situation below. We pass your input plus the steps you already saw to our AI and return tailored next-step advice. If it's too risky to DIY, we'll say so.
Or skip the DIY entirely
Our Managed IT clients do not look these things up. One point of contact, a fixed monthly price, resolved within working hours.