Forgotten SPF Record Breaks DMARC p=reject Subdomains

Why Your Subdomain Mail Fails Silently Under DMARC p=reject

Your domain has DMARC set to p=reject. You are doing everything right. Then a specific subdomain stops delivering mail and nobody gets a bounce message. The reason is almost always the same: a forgotten SPF record on a sending subdomain.

When you add a new sending subdomain for transactional mail, a marketing platform, or an internal application, you need SPF to cover that subdomain's sending infrastructure. If you skip that step, DMARC alignment fails silently for that subdomain. The mail does not bounce back to your server -- it simply disappears into the recipient's filtering layer. You find out when a user complains or your delivery rates drop.

This is one of the most common silent failures under DMARC p=reject. It catches experienced operators as often as newcomers, partly because the failure is not visible from your sending systems -- only from your DMARC reports.

How DMARC Alignment Decides Pass or Fail

DMARC does not simply verify that SPF or DKIM passes. It verifies that the domain in the message's From header (RFC5322.From) aligns with the domain that passed SPF or DKIM.

There are two alignment modes:

Relaxed mode (the default): the organizational domain must match. A message from notifications.example.com passes if SPF or DKIM passes for example.com (the organizational domain).

Strict mode: the RFC5322.From domain must exactly match the domain that passed SPF or DKIM. A message from notifications.example.com requires an exact match -- no subdomain forgiveness.

In relaxed mode, a subdomain can inherit alignment from the organizational domain -- but only if SPF or DKIM actually covers that subdomain. If the subdomain has no SPF record at all, SPF returns "none" and the SPF alignment path offers no help. If the subdomain is also not DKIM-signing for its own domain, both alignment paths fail and DMARC fails.

The Forgotten SPF Include: Step by Step

Step 1: Your root domain (example.com) has p=reject with working SPF and DKIM.

Step 2: You add a new sending subdomain (notifications.example.com) for a transactional service, CRM, or internal tool. The vendor gives you an SPF include string (for example, `include:sendgrid.net`).

Step 3: You add the include to the root domain's SPF record -- but the subdomain either does not inherit it, or you intended to add it to the subdomain's own SPF record and forgot. Subdomains do not automatically inherit their parent domain's SPF record.

Step 4: The subdomain sends mail. The RFC5322.From shows notifications.example.com. The sending service's server uses its own HELO domain (sendgrid.net), which passes SPF for sendgrid.net. But the From domain is notifications.example.com, which has no matching SPF record and no DKIM signature from that domain.

Step 5: DMARC checks alignment. SPF alignment fails because the RFC5321.MailFrom domain (sendgrid.net) does not match notifications.example.com. DKIM alignment also fails if the subdomain is not DKIM-signing for its own domain. DMARC fails. The message is rejected or filtered silently.

Result: Legitimate mail from your own subdomain is blocked. No bounce reaches your inbox. The failure only surfaces in your DMARC aggregate reports -- if you are monitoring them.

How to Diagnose the Failure

Your DMARC aggregate reports (XML files sent to the RUA destination in your DMARC record) tell you exactly which subdomain is failing and why. Here is what to look for.

In the aggregate report, find entries where:

The RFC5322.From domain is your subdomain (notifications.example.com)
SPF shows "fail" or "softfail" for that subdomain
DKIM shows "fail" or "none" for that subdomain

The critical comparison is `envelopefrom` (the RFC5321.MailFrom domain, e.g. sendgrid.net) versus `headerfrom` (the RFC5322.From domain, e.g. notifications.example.com). If the envelope is a third-party ESP domain but the header is your subdomain, and SPF fails for that subdomain, you have an alignment failure caused by a missing SPF include.

A concrete signal: if your aggregate report shows a subdomain sending mail for the first time and immediately failing DMARC with SPF fail, that subdomain almost certainly has no SPF record covering its sending infrastructure. That is your diagnostic shortcut.

If you are not actively monitoring aggregate reports -- or if your RUA destination is misconfigured -- you will not see this signal. DMARCFlow's reporting dashboard parses these reports automatically and flags new subdomain failures as they appear, so you catch the forgotten SPF problem within hours rather than days.

How to Fix the Broken SPF Record

Step 1: Audit your sending subdomains. List every subdomain that sends mail -- transactional services, marketing platforms, internal applications, notification systems. If you do not have this list, build it first.

Step 2: Check the current SPF record for each subdomain. Use an SPF checker (such as the SPF Checker at dmarcflow.com) to see what each subdomain's SPF record contains. If it returns "no SPF record found," that subdomain is not covered and cannot pass SPF alignment.

Step 3: Add the missing SPF include or mechanism. For each subdomain that sends mail, add the appropriate `include:`, `a:`, or `mx:` mechanism to that subdomain's DNS. Do not assume the subdomain inherits SPF from its parent -- it does not.

Step 4: Flatten if your include chain is too long. If adding the new service pushes your SPF record over the 10-lookup DNS limit (RFC 7208), flatten the record by replacing include chains with their resolved IP addresses.

Step 5: Verify with a test send. Send a test message from the subdomain to a known-good inbox. Check the `Authentication-Results` header -- both SPF and DKIM should show "pass" and alignment should be confirmed.

How to Stop This From Happening Again

Maintain a subdomain sending inventory. Every time you add a new sending subdomain, add it to a tracked list and verify SPF and DKIM before going live.

Set up DMARC monitoring with alerts. Most operators discover the forgotten SPF problem through DMARC reports -- but passive monitoring (reports you download but never open) does not help. You need active monitoring that surfaces new subdomain failures quickly.

DMARCFlow monitors your aggregate reports and alerts you when a subdomain that was previously passing DMARC alignment suddenly starts failing. The alert fires before users start reporting missing mail, which is the difference between a five-minute DNS fix and a two-day incident investigation. The DMARCFlow dashboard also shows per-subdomain breakdown across all your monitored domains, which makes auditing a large sending infrastructure faster than manually parsing XML reports.

Add SPF and DKIM to your go-live checklist. Before launching a new sending subdomain or switching email providers, run an SPF lookup and DKIM check for that subdomain as part of your standard change process.

FAQ

Can DKIM fix a forgotten SPF record?

Only if the subdomain is DKIM-signing using the same domain as the RFC5322.From. If the subdomain has no DKIM key published, or if DKIM is signed for a different domain, DKIM alignment also fails. The forgotten SPF problem is not automatically solved by DKIM -- and if the subdomain is doing neither SPF nor DKIM for its own domain, you get double failure.

Does this affect relaxed mode only?

No. Relaxed mode makes the organizational domain the alignment target, but the subdomain still needs at least one of these to pass DMARC: SPF passing for the subdomain, or DKIM signing for the subdomain. If both return fail or none, DMARC fails in relaxed mode just as it does in strict mode. The practical difference is that strict mode requires exact domain matching, while relaxed mode accepts any subdomain of the organizational domain -- as long as authentication passes for something in the chain.

How do I know which subdomain is failing?

Your DMARC aggregate reports show every subdomain that attempted to send mail and whether it passed or failed DMARC. Look for entries where both SPF and DKIM show fail or none for the subdomain in question. If you are not receiving aggregate reports, configure an RUA destination in your DMARC record first -- without aggregate reports, you are diagnosing this problem blind.

Does rolling back to p=none fix this?

No. Changing your policy to p=none removes enforcement but does not fix the authentication problem. Your mail will deliver again, but your domain is unprotected against spoofing from that subdomain. Fix the SPF record, verify DMARC alignment passes, then return to p=reject if that was your target.

Why does the mail not bounce?

When a recipient server rejects a message under DMARC p=reject, it refuses the message at the SMTP level with a 550 5.7.1 or similar code. Your sending server may receive this rejection, but three things can make it invisible: the rejection happens at a downstream filtering layer your server does not see directly; your sending system does not log or forward those rejections; or the rejection message itself gets filtered as spam. This is why aggregate reports are often the only reliable signal -- they are sent to you by the recipient server before the message is rejected.