Switched DMARC to p=reject and Forwarded Mail Started Bouncing? Check the Headers

You moved your DMARC record from p=none to p=reject. Direct mail to the big providers still lands fine, but some senders now get bounces for messages to a few specific recipients. When you look closer, those recipients don't actually read mail at the address you sent to. Their mailbox forwards everything to a different provider, and the rejection happens on that second hop. The bounce makes it look like your authentication is broken. Usually it isn't, at least not in the way people first assume. The headers on the forwarded copy tell you exactly which check failed and why, and once you can read them the fix is usually narrow.

What the bounce is really telling you

With forwarding there are three parties: your server sends to the recipient's first mailbox (call it the forwarder), and the forwarder relays the message to the final mailbox provider. When that final provider rejects the message because of your DMARC policy, the forwarder receives the rejection and generates a bounce back to the envelope sender, which is you. So the bounce in your inbox often mentions a server you never talked to. That's the first clue. If the rejecting host is not the domain you addressed, you're looking at a forwarding path, not a direct delivery problem. The bounce text itself varies a lot between providers. Some mention DMARC explicitly, some just say the message failed authentication or policy checks. Don't spend too long decoding it. The useful evidence is in the message headers.

Find the Authentication-Results header on the forwarded copy

The header you want is Authentication-Results. The receiving server adds it after running SPF, DKIM, and DMARC checks, and it records the result of each one. The catch is that a rejected message never reaches the final mailbox, so you can't read its headers there. Two practical ways around that:

Temporarily send a test message to the forwarding address while the DMARC policy is relaxed, or forward to a mailbox you control on another provider. Then open the copy at the final destination and view the raw source. Most webmail clients have an option along the lines of show original or view source.
Check whether the bounce includes the original message or its headers as an attachment. Many do, though those are usually the headers as they left your server, not the final receiver's verdict.

Once you have the raw source of a forwarded copy, look for the Authentication-Results line added by the final provider (it's typically near the top, because headers are prepended as mail moves). On a forwarded message that would fail under p=reject, it tends to look something like this:

TEXT

Illustrative output format (layout varies by receiver):

Authentication-Results: mx.final-provider.example;
  spf=fail (domain of example.com does not designate 203.0.113.25 as permitted sender) smtp.mailfrom=example.com;
  dkim=none;
  dmarc=fail (p=REJECT) header.from=example.com

Read it field by field. smtp.mailfrom is the envelope sender, the Return-Path domain that SPF checks. The IP in the SPF result is the forwarder's server, not yours. dkim=none means no DKIM signature was found at all, and header.from is the visible From domain that DMARC cares about. If you want a deeper walkthrough of every field and what alignment means for each one, see Reading Authentication-Results Headers to Fix DMARC Alignment.

Why SPF fails after forwarding, and why that's expected

SPF answers one question: is this connecting IP allowed to send mail for the envelope sender's domain? When your server delivers directly, the connecting IP is yours, it's in your SPF record, and SPF passes. After forwarding, the connecting IP is the forwarder's. Traditional forwarding keeps your original envelope sender, so the final receiver checks your SPF record against the forwarder's IP. It isn't listed, so SPF fails. Nothing on your side changed. Forwarding simply breaks SPF by design. Some forwarders rewrite the envelope sender to their own domain, a technique called SRS (Sender Rewriting Scheme). In that case SPF may show pass, but for the forwarder's domain. DMARC requires the SPF-authenticated domain to align with the From domain, so a pass for someone else's domain still doesn't help you. Either way, SPF alignment is gone after the first hop. That leaves DKIM. DMARC passes if either SPF or DKIM passes and aligns with the From domain. DKIM is a cryptographic signature over the message headers and body, and it doesn't care which IP delivers the message. As long as the forwarder doesn't modify the signed parts, the signature verifies at the final receiver just as it did at the first one. That's why forwarded mail kept arriving under p=none: nothing was being enforced. Under p=reject, any message that relied only on SPF has no aligned pass left once it's forwarded.

Red herrings worth ruling out

A few things tend to send troubleshooting in the wrong direction. Your SPF record is probably fine. If direct deliveries pass SPF, rewriting the record won't change anything for forwarded mail. Adding the forwarder's IPs to your SPF record is sometimes suggested, but it's a poor trade: you don't control those IPs, they change, you'd need to do it for every forwarder your recipients use, and it pushes you toward SPF's DNS lookup limit. It also does nothing if the forwarder uses SRS. The forwarder isn't necessarily misconfigured. Forwarding that breaks SPF is normal behavior, not a fault on their end. Blocklists are unlikely to be the cause. A blocklisted IP produces a different rejection, and it would affect direct mail too. Finally, p=reject itself isn't the bug. It exposed a gap that was already there. Rolling back to p=none stops the bounces, but it also stops the protection you set out to get.

Confirm DKIM is signing with your own domain

In the forwarded headers, the DKIM result is the one that decides things. There are three common outcomes:

dkim=none: your mail isn't being DKIM-signed at all.
dkim=pass with a header.d= value that isn't your domain: the message is signed, but with a hosting hostname or a third-party service's domain, so it doesn't align.
dkim=fail: a signature exists but broke in transit, often because something in the path modified the body or signed headers.

For the first two, the fix is on the sending side. Enable DKIM signing for the domain on whatever sends the mail. On a cPanel server that's typically handled per domain in the panel's email deliverability tools; on other stacks it lives in the MTA config or the sending service's dashboard. It depends on the setup. Then confirm the public key is published and resolvable:

BASH

# Replace 'default' with your selector (the s= value in the DKIM-Signature header)
# and example.com with your domain
dig +short TXT default._domainkey.example.com

You should get a TXT record containing v=DKIM1 and a p= public key. An empty result means the record is missing or published under the wrong name. For dkim=fail on forwarded copies only, the forwarder or a mailing list is probably changing the message. That's outside your control, though some receivers consider ARC (Authenticated Received Chain) headers added by trusted forwarders. Whether they do is up to each receiver, so treat it as a bonus rather than a fix. The same pattern applies to every service that sends as your domain. If one tool relies only on SPF, its mail will fail DMARC the moment it's forwarded. What to Audit Before Switching DMARC Policy from None to Reject covers how to catch those senders.

Verifying the fix

Once DKIM is signing with your domain, repeat the test: send a message through the forwarding path to a mailbox you can read, and open the raw source at the final destination. You want to see dkim=pass with header.d= set to your domain, and dmarc=pass. SPF will most likely still say fail or pass for a different domain. That's fine, and expected. Your DMARC aggregate reports are a good second check. Forwarded mail shows up as rows from IPs you don't recognize with SPF failing. If DKIM passes and aligns on those rows, DMARC passes and the mail is delivered. If DKIM is missing on them, those are the messages that bounce under p=reject. If you're on a support desk and a customer reports bounces right after a DMARC change, ask for a forwarded test copy's raw headers before touching DNS. In most cases the answer is already there: SPF failed because of the extra hop, and DKIM either wasn't present or wasn't signed with the customer's own domain. Make sure every sender signs DKIM with the From domain, and forwarding stops being a problem for DMARC.