Why Your Legitimate Emails Get Rejected After Setting DMARC to p=reject

You published p=reject to stop spoofing. Within days, a support ticket arrives: the CRM is not delivering order confirmations. The marketing platform's test emails are bouncing. A vendor says their invoices are going to spam.

The common thread: all of these services send email with your domain in the From address but from their own infrastructure. DMARC requires alignment. The domain in the From header must match the domain that SPF authorizes and DKIM signs. When a third party sends from their servers using your domain, alignment fails.

Why alignment fails for third-party senders

SPF checks which server is sending. If a third-party service sends from their own IPs, SPF passes for their domain, not yours. DKIM signs with their private key at their domain, not yours. So when the service sends as you@yourdomain.com from their infrastructure:

• SPF: fail (your SPF record does not include their IPs)
• DKIM: fail (they signed with their key, not yours)
• DMARC alignment: fail

Some services work around this by offering shared IPs in your SPF record or shared DKIM keys. Most do not. Most just put your domain in the From and hope, which works fine at p=none but breaks at p=reject.

Option 1: Subdomain isolation

The cleanest long-term solution is to move third-party senders to a subdomain. They use something like marketing@email.yourdomain.com or noreply@transactional.yourdomain.com. You set up SPF, DKIM, and DMARC for that subdomain independently.

Your main domain stays hardlocked with p=reject. The subdomain has a more permissive policy while remaining under your control.

The tradeoff: your From addresses show a subdomain. Most users do not notice. Some enterprise recipients do.

A tool like DMARCFlow can help manage multiple subdomain policies in one place, keeping each isolated subdomain's authentication configured correctly without manual DNS work for every new vendor.

Option 2: Custom From domain with proper alignment

Some third-party services offer a custom From domain where you host their DKIM key in your own DNS. They give you a CNAME or TXT record to add, and when they send, their DKIM signature uses your domain, so DKIM alignment passes.

For this to work, the service must support it, and you need to actually add the DNS records.

SPF alignment is harder. If the service sends from their IPs with your From domain, SPF still fails. But if DKIM passes with alignment, DMARC passes with one-factor alignment. That is often enough for deliverability.

Option 3: Remove third-party senders from your domain entirely

The most conservative approach is to have third-party services send from their own domain, not yours. They use their own From addresses. Your domain handles only direct outbound mail.

This is the most secure option. The tradeoff is less brand consistency in From addresses.

Before going strict: what your DMARC reports actually say

p=none exists to let you see what is happening before rejecting. Your DMARC aggregate reports show every source sending as your domain, including the ones that would fail at p=reject.

Before moving to p=reject:

1. Check your DMARC reports for all sending sources
2. Identify every third-party service sending as your domain
3. Resolve each one: subdomain, custom From, or remove
4. Only then move to p=reject

Organizations that skip this step are the ones that break their own email while trying to improve security.

Which option fits?

• Many third-party senders needing brand-consistent From addresses: subdomain isolation
• One or two critical services supporting custom DKIM: implement that and test carefully
• Can tolerate different From domains: most secure option

p=reject is a good goal. Breaking your own email in the process is not. The transition takes time, and your DMARC reports are the map.