Why Mail Still Fails After You Set DMARC to p=reject (And How to Find the Subdomain SPF Gaps First)

A person who writes DMARC guides for a living recently posted their own DMARC monitoring data to Reddit. Their domain was at p=reject. Legitimate mail was failing. Their own tool caught it.

This is not a beginner mistake. It is a specific, reproducible failure mode that hits people who understand DMARC well enough to deploy it, but who have not audited every subdomain that might be sending mail on their behalf.

The failure mode: SPF passes, DMARC fails

Here is what is happening.

SPF authenticates the MAIL FROM domain - the server that actually handed the message to your receiving MTA. DMARC authenticates the From domain - the address your users see in their email client. These are not always the same domain.

At p=reject, DMARC requires alignment. The authenticated MAIL FROM domain has to match the From domain, or the message is rejected.

If your apex domain (example.com) has a correct SPF record but a subdomain (marketing.example.com) is sending mail without its own SPF record, then:

• The MAIL FROM for that subdomain likely resolves to the subdomain itself or to an ESP
• SPF passes for that MAIL FROM
• But the From domain is still example.com
• DMARC checks alignment between From and MAIL FROM
• Alignment fails
• p=reject drops the mail

The mail technically passed SPF. But DMARC is not just checking SPF. It is checking alignment. A subdomain without SPF has no authenticated identity that aligns with your From domain.

Why p=none hides this and p=reject does not

At p=none, DMARC alignment failures are recorded but the mail is delivered. The failure is invisible unless you are reading your aggregate reports.

At p=quarantine, some receivers accept mail with alignment failures, some do not. Delivery becomes unreliable but not fully broken.

At p=reject, every alignment failure is a rejection. If a subdomain is sending mail with no SPF record of its own, that subdomain cannot produce a message that passes DMARC alignment. Every message from that subdomain gets rejected, silently.

The shift from p=none to p=reject does not change how SPF or DKIM work. It changes how strictly alignment is enforced. That is why the migration breaks mail that "was working fine" at p=none.

Subdomains that commonly lack SPF

Most SPF gaps come from a small number of predictable sources.

Marketing subdomains delegated to an ESP. The marketing team sets up send.example.com and routes it through a vendor. Nobody adds SPF for send.example.com because the main domain has SPF and that "should cover it." It does not.

Legacy mail systems that were migrated but not decommissioned. A subsidiary ran its own mail server on mail.oldcompany.com. The company was acquired, the server was shut down, the subdomain was pointed at a new provider. SPF was never added.

SaaS tooling subdomains. Applications that send email on your behalf often use their own subdomain for the return path. If your SaaS vendor uses a subdomain they control (e.g., sendgrid.com sending from subdomain.yourdomain.com), and that subdomain has no SPF record, any mail sent that way fails DMARC alignment at p=reject.

Departed employee campaign subdomains. Someone set up a campaign subdomain for a product launch. The campaign ended, the employee left, the subdomain was not cleaned up. It still accepts mail. Nobody notices until a DMARC report surfaces it.

Internal-only subdomains that still receive external mail. A vendor or partner replies to a known address at internal.example.com, which was never intended for external use but still accepts mail. No SPF means no DMARC alignment.

How to find subdomain senders in your aggregate reports

DMARC aggregate reports arrive as XML from your receivers. They tell you which sources are sending mail for your domain and what the authentication results were.

Look specifically for:

• Rows where the source IP is not your known mail server IP range
• Rows where the "envelope from" domain is a subdomain you do not recognize
• Rows where SPF and DKIM both fail but the mail appears legitimate

If you have never read your aggregate reports, or if you are relying only on p=none delivery feedback, you likely have subdomain senders you do not know about.

Manually parsing XML aggregate reports is painful. Most practitioners who run their own DMARC at scale use a tool that normalizes this data into a readable format.

DMARCFlow is designed for exactly this workflow. It parses aggregate reports and surfaces unknown subdomain senders automatically, flags which ones have SPF gaps, and shows which alignment failures are coming from those gaps. Running the pre-migration audit inside DMARCFlow means you see the audit results grouped by subdomain severity rather than staring at raw XML. For domains with a non-trivial number of subdomains, this is the practical difference between an audit that takes an afternoon and one that takes twenty minutes.

The pre-migration audit checklist

Before you move any domain to p=reject, run this:

1. Get your latest aggregate reports for the past 30 days.

2. List every unique subdomain that appears as a sending source.

3. For each subdomain, confirm it has an SPF record.

4. For each subdomain that sends mail, confirm it has DKIM configured if your policy requires it.

5. Identify any subdomain where the sending infrastructure is unknown or unmanaged.

6. For unknown subdomains, either add SPF and DKIM, or remove the subdomain from your DMARC scope by adjusting your alignment mode.

If you find subdomains sending mail that should not be, do not just delete the subdomain or disable the record. Understand who is using it first. Removing a subdomain that a business process depends on is a good way to create an urgent support ticket.

What to do if you find a subdomain SPF gap

The fix depends on whether the subdomain should be sending mail.

If the subdomain is legitimate and should send mail: Add an SPF record that covers the sending infrastructure. If a vendor controls the sending, they should provide the include statement or mechanism. If you run your own mail, add the appropriate mechanisms for those servers.

If the subdomain is legitimate but the infrastructure is changing: Set p=quarantine temporarily while you audit and migrate. Do not jump to p=reject until the new infrastructure is verified.

If the subdomain is not needed: Point it at a null MX and do not accept mail for it. Alternatively, add a strict SPF record that matches nothing (v=spf1 -all) so it cannot be exploited for spoofing either.

If you cannot determine ownership: Set the subdomain to p=none in your DMARC record so mail continues to flow while you investigate. Do not ignore it.

Do not use this as an excuse to stay at p=none

p=none is a monitoring phase, not a resting place. The purpose of p=none is to find problems like subdomain SPF gaps before they cause an outage. If your aggregate reports show zero failures and zero unknown senders, that is when you move to p=reject, not when you hope nobody notices.

The DMARC expert who posted their own failure was doing the right thing by monitoring. They found the problem before it became a business-critical mail outage. That is exactly what p=none is for. The lesson is not that p=reject is dangerous. It is that skipping the audit before the migration is what causes the failure.

FAQ

Why does SPF pass but DMARC fail at p=reject?

SPF validates the server that delivered the message. DMARC validates that the From domain in the message header aligns with that server. At p=reject, DMARC enforces alignment strictly. A subdomain with no SPF record cannot produce an aligned authentication result for your From domain, regardless of whether SPF passes at the server level.

Which subdomains most commonly lack SPF records?

Marketing subdomains delegated to ESPs, legacy mail infrastructure, SaaS applications that send on your behalf, and subdomains created for specific campaigns or initiatives that were later abandoned or repurposed without proper DNS hygiene.

How do I audit subdomain SPF before moving to p=reject?

Pull 30 days of DMARC aggregate reports, identify every subdomain appearing as a sending source, and verify each one has a current SPF record. Use a DMARC monitoring tool to automate this if your domain has more than a handful of subdomains. For each subdomain with a gap, decide whether it should be sending mail and either add SPF or remove the subdomain from your mail-accepting scope.