Why International Mail Gets Rejected After You Set DMARC to Reject

You set DMARC to p=reject - the recommended policy for blocking domain spoofing. Then a partner in another country tells you they can no longer receive email from you.

Your domain passes every authentication check. SPF aligns. DKIM is signed. DMARC passes on your sending server. But their mail server is rejecting your messages.

The issue is not your DMARC record. It is how your legitimate mail interacts with receiving servers that apply their own inbound DMARC policies.

How DMARC p=reject actually works

DMARC p=reject does not block mail from leaving your server. It tells receiving servers to reject mail that fails your domain's authentication checks.

When you set p=reject, you are publishing this instruction:

"If mail claiming to be from @yourdomain.com fails SPF or DKIM alignment, reject it."

That instruction is evaluated by the receiving server - not by your server. And the receiving server's evaluation depends on which mail server actually sent the message, not which domain is in the From header.

Why international mail fails

International delivery failures under DMARC p=reject typically involve one of these patterns:

Forwarding chains break DKIM

When mail is forwarded through a mailing list, relay, or third-party aggregator, the DKIM signature is often signed by the original sending infrastructure, not the From domain. If the forwarding server modifies headers or content, the DKIM signature invalidates.

A forwarded message passes SPF (the forwarder's IP is authorized) but fails DKIM alignment (the From domain does not align with the signing domain). That is a DMARC fail at the receiving server, which may apply its own inbound p=reject policy.

Tertiary forwarding compounds the problem

Sender → Your MTA → Forwarding relay → Recipient's server

Each hop adds complexity. The original DKIM signature may break at the first forward. The SPF check may pass at the first forward but fail at the second if the forwarding path is not properly authenticated.

Some international mail providers apply strict inbound enforcement

German providers like GMX and WEB.DE apply strict inbound DMARC enforcement - they reject mail that fails alignment rather than soft-failing or passing it. This catches forwarded mail that has lost DKIM integrity, even when the original sender is legitimate. WEB.DE and GMX have been known to apply this behavior to forwarding chains that cannot pass DKIM alignment.

This is not a bug - it is the intended behavior of DMARC enforcement. But it catches legitimate forwarded mail that has lost DKIM integrity.

How to diagnose the failure

Check your DMARC aggregate reports for these patterns:

• from-first-party + fail-dkim: your domain is in the From header, but DKIM is broken. This usually means forwarding.
• High volume of auth failures from specific receiving domains: those domains may be applying strict inbound policies to forwarded mail.

Authentication-Results headers in delivery failure messages also show which check failed and at which point.

How to fix it

Use a forwarding-aware sending service

Some email services preserve DKIM headers and maintain alignment through forwarding chains. If your mail goes through forwarding-heavy paths, a forwarding-aware service reduces DKIM breakage.

Configure subdomains for different sending contexts

Use separate subdomains for:

• Direct MTA sends (marketing, transactional)
• Third-party forwarding (newsletter lists, external partners)

This isolates forwarding risk so a forwarding failure on one subdomain does not affect direct-sent mail on your primary domain.

Monitor aggregate reports before deployment

Before setting p=reject, run in monitoring mode (p=none) for two to four weeks. Identify any legitimate sending sources that rely on forwarding chains. Address those before switching to reject.

Consider ADSP for specific sending contexts

Author Domain Signing Practices (ADSP) lets you declare which subdomains are expected to sign. If your primary domain is used for direct mail only, ADSP on a designated sending subdomain helps receiving servers distinguish legitimate forwarded mail from spoofing. Note: ADSP support is limited and not widely honored by major receivers - check whether your target domains honor it before relying on it.

What DMARCFlow detects in aggregate reports

Forwarding failures show up in aggregate reports as a specific pattern: your domain in the From header, DKIM signature present but fail result, and the source IP in your own range or a known forwarding service. That combination - from-first-party + fail-dkim + own-IP - is the signature of a structural forwarding problem, not a spoofing attack.

DMARCFlow parses this pattern automatically and flags it separately from external spoofing attempts. When forwarding is the cause, you get an actionable alert (fix the forwarding chain) rather than a security incident (investigate spoofing source). For operators managing p=reject across international partner networks, that distinction saves time and prevents unnecessary incident response.

FAQ

Can I set p=reject and still forward mail?

Only if DKIM alignment is preserved through the forwarding chain. If the forwarding service breaks DKIM, the mail will fail DMARC at the receiving server regardless of your policy setting.

Does SPF help with forwarded mail?

SPF verifies the sending IP, not the From domain. Forwarded mail may pass SPF at the receiving server but still fail DMARC if DKIM is broken. SPF alone does not guarantee DMARC pass.

Should I lower my DMARC policy to fix international delivery?

Lowering enforcement (p=reject → p=quarantine or p=none) removes the protection that p=reject provides against domain spoofing. The better solution is to identify which forwarding paths are breaking DKIM and address those structurally.

Do all international mail providers apply strict inbound DMARC?

No. Enforcement varies. Some providers pass or soft-fail mail that fails DMARC alignment. German providers (GMX, WEB.DE, mail.com) are known for strict inbound enforcement. Check aggregate reports for specific receiving domains that are rejecting your mail.