Why Your DMARC Monitor Caught a Problem You Did Not Know

Why Your DMARC Monitor Already Caught a Problem You Did Not Know You Had

Here is a scenario that plays out regularly in DMARC adoption threads: a person who writes DMARC guides for a living sets up DMARC monitoring for their own domain, and within 24 hours their tool flags a failure. On a domain they thought was fully configured. The irony is sharp enough that it got 64 upvotes on a technical subreddit. The root domain SPF was correct. DKIM was signing the right domain. DMARC policy was set to reject.

The cause was not a misconfiguration. It was an SPF scope problem.

A subdomain on that domain was sending automated mail. That subdomain was not covered by the SPF record. When it sent mail, the MAIL FROM address used the subdomain hostname. SPF checked against the subdomain, found no authorized mail server, returned none. DMARC alignment failed.

This is the gap that breaks most DMARC setups at least once. And the reason it keeps breaking is that most monitoring tools only watch the root domain.

The Subdomain SPF Gap: What Actually Happens

SPF records are evaluated against the domain in the MAIL FROM address, also called the Return-Path. This is the envelope domain, not the From: address that shows in email clients.

When you send from hello@mydomain.com, SPF checks mydomain.com. When a ticketing system sends from support@mydomain.com, SPF checks support.mydomain.com. These are separate DNS lookups. A valid SPF record on mydomain.com says nothing about whether support.mydomain.com is authorized to send mail.

This is by design in the SMTP specification. SPF scope is explicit and narrow. But it catches most people off guard because they assume subdomains are automatically covered by the root domain's SPF record.

They are not.

Subdomains That Are Almost Always Forgotten

Every organization has subdomain senders set up years ago and never audited. Common examples:

Marketing automation platforms: Brevo, HubSpot, and Marketo often send from subdomains like mail.mydomain.com or em.mydomain.com when configured for custom tracking domains. If those subdomains use the vendor's infrastructure and that infrastructure is not in your SPF record, SPF fails.

Support and ticketing platforms: Zendesk, Freshdesk, and Intercom frequently send from support.mydomain.com or help.mydomain.com using the vendor's sending servers. Those IPs are not yours unless you add them.

CRM systems: Salesforce and Microsoft Dynamics can send from subdomains tied to your domain when custom sending domains are configured. The Salesforce sending infrastructure must be explicitly authorized in your SPF record.

CI/CD and monitoring tools: Alerting systems, runbooks, and deployment pipelines often send from subdomains like alerts.mydomain.com or ci.mydomain.com, using SendGrid, Mailgun, or AWS SES under the hood.

Legacy internal mail relays: Older systems that relay automated mail through a specific subdomain, often undocumented and unmanaged.

In each case, the subdomain is a separate DNS zone for SPF purposes. If the subdomain's sending infrastructure is not explicitly authorized, SPF returns neutral or none, and DMARC alignment fails.

How to Find Subdomains Sending Mail You Did Not Know About

Read your DMARC aggregate reports. Look for the aligned_domain field in failure reports. Any aligned_domain that is a subdomain of your root domain is sending mail. If you see support.mydomain.com in those reports, that subdomain is a gap.

Audit your DNS records. Any subdomain with an MX record, an A record pointing to a mail server, or its own SPF record is a candidate sender.

Inventory your vendors. Every SaaS platform that sends email on your behalf using your domain is a subdomain sender. Search your inbox for support@, noreply@, alerts@, and notify@ patterns combined with your domain.

Use an SPF discovery tool. A checker that shows all include mechanisms in your SPF record reveals which third-party services are authorized. Any service that sends from your domain but is not in that list is a gap.

Use DMARCFlow to monitor subdomain-level alignment automatically. Most DMARC monitoring only covers your root domain. DMARCFlow tracks every subdomain that appears in your aggregate reports and alerts you when a subdomain starts sending and is not yet SPF-aligned. Without subdomain-level monitoring, you find out about new senders from the failure report, not before they cause problems.

How to Fix Subdomain SPF Gaps

For each subdomain sender you find:

Option A: Add a dedicated SPF record for the subdomain. Create an SPF record at subdomain.mydomain.com that authorizes the correct sending infrastructure. This is the cleanest approach when the subdomain has its own sending service.

Option B: Add the subdomain's infrastructure to the root SPF record. Use an include mechanism or ip4/ip6 directive to extend your root SPF record to cover the subdomain sender. This works when the subdomain uses infrastructure already used elsewhere.

Option C: Consolidate subdomain senders under a single covered relay. Route all subdomain mail through a relay that is already covered by your SPF record. This reduces maintenance over time.

One common mistake: SPF does not support wildcards the way most people expect. Writing v=spf1 include:*.mydomain.com ~all does not authorize all subdomains to use your SPF record. Wildcards in SPF work only at the level of individual labels, not entire subdomain trees.

After making any SPF change, validate using an external SPF checker before publishing. SPF changes propagate slowly and a mistake can cause mail delivery failures.

The Only Fix That Works Permanently

Patching today's gap is not the hard part. The hard part is catching the next subdomain sender before it causes alignment failures.

New subdomain senders get added constantly. A new SaaS tool, a new internal script, a department that spins up its own mail relay. Each one is a potential SPF gap until proven otherwise.

Root-domain-only DMARC monitoring misses these gaps entirely. DMARCFlow monitors every subdomain that appears in your aggregate reports and alerts you when a subdomain is not yet covered by your SPF record. You find out when the subdomain first starts sending, not after it has already broken alignment for a week.

FAQ

Does a subdomain automatically inherit the root domain SPF record?
No. SPF records are evaluated against the exact domain in the MAIL FROM envelope. Subdomains are separate DNS names. A subdomain must have its own SPF record or be explicitly included in the root domain's SPF record.

If my root domain SPF is correct, why does DMARC still fail?
DMARC alignment requires SPF or DKIM to pass with alignment. If a subdomain sends mail and SPF fails for that subdomain, alignment fails even if the root domain SPF is correct. Alignment is checked per-domain.

Can I use the same SPF record for subdomains as for my root domain?
Only if the subdomain sends from the same infrastructure. In most cases, subdomain senders use different services, so a shared SPF record would not be correct.

How do I know if a subdomain is sending mail?
Check your DMARC aggregate reports for aligned_domain values that are subdomains. Also audit DNS for MX records on subdomains and search your inbox for subdomain senders from your vendor list.

What is the fastest way to fix a subdomain SPF gap?
Create a separate SPF record for the subdomain that authorizes its actual sending infrastructure, then validate with an SPF checker before publishing.