Fix ‘DMARC Policy Rejects This Message’ Bounces When Forwarding

Someone forwards your email, or a customer forwards theirs, and instead of arriving quietly the message bounces with a blunt error: DMARC policy rejects this message. It sounds like a serious failure, and senders often panic that their domain is broken. In most cases the domain is doing exactly what its owner told it to do, and forwarding is what collided with that instruction.

Understanding that collision is the key to fixing it. This guide explains why forwarding breaks DMARC, how to tell whether your settings or the forwarder are responsible, and what changes actually solve the problem without weakening your domain’s protection.

Quick Answer

This bounce happens when a forwarded message fails DMARC alignment and your published policy tells receivers to reject failing mail. Forwarding usually breaks SPF, and if the message also lacks a valid aligned DKIM signature, DMARC fails completely. Fix it by making sure your outgoing mail is DKIM-signed by your own domain, keeping your policy realistic, and, for services that forward mail for you, using a forwarder that rewrites the envelope or preserves authentication, such as one that supports ARC.

What the Error Really Means

DMARC checks two things and asks whether at least one of them passes and matches the domain in the visible From address. That match is called alignment. When a receiver applies DMARC and both checks fail alignment, it follows the policy you published. If that policy is p=reject, the receiver refuses the message and the sender receives the bounce you are reading.

So the error is not random. It is a chain: forwarding changed the message’s path, the original checks stopped aligning, and your own policy ordered the rejection. Any fix has to break that chain at a sensible point.

Why Forwarding Breaks Authentication

SPF almost always fails after forwarding

SPF checks whether the server sending the message is authorised for the domain in the return path. A forwarding server is usually not on the original sender’s list, so SPF fails. This has been true since long before DMARC existed, and on its own it is not fatal, because DMARC needs only one aligned pass.

DKIM survives forwarding, unless the message changes

DKIM signs parts of the message itself, so a simple forward that leaves the content untouched keeps a valid signature. Trouble starts when the forwarder modifies the message: adding a footer, inserting a subject prefix, rewriting links, or converting the format. Any change to signed parts invalidates the signature, leaving neither SPF nor DKIM aligned.

Then DMARC has nothing left to accept

With SPF failed and DKIM broken or missing, DMARC fails. If the From domain publishes p=reject, the receiving server must refuse the message. Mailing lists and old-style forwarding services cause this most often, because they routinely alter messages as part of what they do.

Work Out Which Side You Control

The right fix depends on your role in the failed delivery, so identify it first:

• You own the From domain and your users complain their mail bounces when forwarded. Your policy and signing setup are the levers you control.
• You run a service, group, or mailbox that forwards mail for others. Your forwarding method is the lever, and modernising it solves the problem for many senders at once.
• You simply received the bounce for one message. You may only be able to resend directly to the final address instead of through the forwarding path.

Reading the bounce carefully helps. It usually names the rejecting server, the policy it applied, and sometimes the authentication results. Save the full bounce text before changing anything; it is your best evidence of which check failed.

Fixes for Domain Owners

1. Confirm every legitimate service that sends your mail applies a DKIM signature with your own domain. DKIM is the check that survives forwarding, so it must be present and aligned on all mail.
2. Review audit tools and DMARC reports to find senders that still send unsigned mail for your domain, and fix or retire them.
3. Check your DMARC policy honestly. If you moved to p=reject before all legitimate mail was signed, step back to p=quarantine or p=none temporarily while you finish the signing work, then return to reject.
4. Make sure your DKIM setup itself is healthy, because a rotated or deleted key makes forwarded mail fail exactly like this bounce describes.
5. Re-test by sending to an address that forwards to another provider, and confirm the forwarded copy now passes on DKIM.

The background on how alignment and reporting work is explained clearly in the DMARC overview at dmarc.org, which is the reference most administrators use when setting policy strength.

Fixes for Forwarders and Mailing Lists

If you operate the forwarding step, you carry much of the responsibility for these bounces, and the fixes are well established:

• Do not modify the message. Forwarding content untouched preserves DKIM and prevents most DMARC forwarding failures.
• Use envelope rewriting, often called SRS. Rewriting the return path lets SPF pass for the forwarding domain, instead of failing against the original sender’s record.
• Add ARC headers. Authenticated Received Chain lets a forwarder record the authentication results it saw on arrival, so the final receiver can trust a message that passed when it first arrived.
• For mailing lists, consider rewriting the From address to the list’s own domain when you must add footers or subject tags, so the message aligns with a domain you control.

Google’s guidance for forwarded and bulk mail, including its authentication expectations, is summarised in the Google email sender guidelines, which forwarders should treat as a baseline.

When the Real Problem Is a Strict Policy Set Too Early

Many of these bounces trace back to a well-meant decision: publishing p=reject quickly for security, before signing and sender inventories were complete. DMARC reports exist precisely to prevent this. Spend time at p=none collecting reports, fix every legitimate sender they reveal, move to quarantine, and only then use reject. Domains that follow that order rarely generate forwarding bounce complaints. Domains that skip it generate them immediately.

The same discipline applies to other services connected to your domain. When you review your mail setup as a whole, including personal mailboxes and store or website services, work through the related issues in our guide about fixing domain emails landing in spam so one strict policy does not expose weak spots elsewhere.

Common Mistakes to Avoid

• Removing your DMARC record entirely. That stops the bounce by removing your protection, and invites spoofing of your domain. Adjust policy in stages instead.
• Assuming one bounce means your whole setup is broken. Check whether direct mail still passes. A forwarding-only failure points at the path, not your core records.
• Asking the receiving service to whitelist you. Large providers apply published policy automatically. The durable fix is aligned authentication, not exceptions.
• Signing mail with a service’s domain instead of yours. An unaligned DKIM pass does not satisfy DMARC, so forwarded mail still fails.
• Modifying forwarded messages and blaming senders. If your service adds footers, it breaks signatures. Own that behaviour and adopt ARC or From rewriting.

Conclusion

A DMARC policy rejects this message bounce means forwarding destroyed both aligned checks and your published policy ordered a refusal. The lasting fixes are boring but effective: sign all mail with your own domain’s DKIM, set policy strength only as fast as your reports justify, and forward messages without changing them, using SRS or ARC where you run the forwarding. Do that, and forwarded mail starts arriving again without giving up the protection DMARC was meant to provide.

Frequently Asked Questions

Is this bounce the fault of the sender or the receiver?

Neither side is usually at fault alone. The receiver is following the policy the From domain published, and the forwarding step broke the checks. Responsibility is shared between the domain owner’s policy choices and the forwarder’s handling of the message.

Will lowering my policy to p=none stop these bounces?

Yes, in most cases, because receivers will no longer reject failing mail. Treat it as a temporary diagnostic step while you fix signing, not as the final state, because p=none offers no protection against spoofing.

Why do mailing list messages fail more than simple forwards?

Lists commonly add subject prefixes, footers, and unsubscribe links, all of which can break DKIM signatures. A plain forward that changes nothing usually survives on DKIM, while a decorated list message often does not.

What is ARC and do small senders need it?

ARC is a way for forwarding services to pass along the authentication results they observed. Small senders do not implement ARC themselves; they benefit when the services forwarding their mail support it, and should prefer providers that do.

Can I stop a specific person from getting these bounces?

Usually by changing the path: send directly to their final mailbox instead of the forwarding address, or ask them to use a modern mailbox provider whose forwarding preserves authentication. The domain-wide fixes in this guide solve it for everyone at once.