Why Enforcing DMARC on Your Parent Domain Is Not Enough

Does DMARC on your main domain protect your subdomains?

No. Setting a DMARC policy on example.com does not automatically govern mail.example.com, admin.example.com, or any other subdomain.

DMARC records do not cascade down the domain tree. A policy on the parent domain covers only that exact domain, not its subdomains. This is a common misconception that leaves organizations with a real security gap.

An October 2026 analysis of Australia's ten largest banks illustrates the problem. All ten enforce DMARC at p=reject on their primary domains. Seven of those banks leave their .au domain variant unprotected, meaning attackers can send spoofed email from commbank.au even when commbank.com is fully locked down.

If you manage email authentication for an organization with multiple domains or subdomains, auditing each one for DMARC coverage is not optional.

Why the parent domain policy does not cover subdomains

DMARC alignment checks whether the From header domain matches the domain that passed SPF or DKIM. When a message is sent from a subdomain, the From header shows that subdomain. The parent domain DMARC policy does not apply to it because it is a different domain from DMARC's perspective.

The From header must match the organizational domain that passed authentication for DMARC to pass. Subdomains are separate organizational domains. A DMARC record on the parent cannot govern mail sent from a subdomain because the From header domains are different.

This is by design in the RFC 7489 specification, not an oversight or a gap that vendors will patch.

How attackers exploit the subdomain gap

The attack path is straightforward. An attacker identifies that your primary sending domain has a strict DMARC policy. They then check whether your subsidiary domains and subdomains have their own DMARC records. If they do not, the attacker sends email from an unprotected subdomain using your brand name in the From header.

A realistic scenario: your IT department sends password-reset notifications from it.example.com. That subdomain has no DMARC record. An attacker sends a convincing password-reset email from it.example.com to your employees. The email passes SPF because it.example.com has its own SPF record. It may pass DKIM if the attacker controls a mail server that can sign for that subdomain. DMARC on example.com does not block it because the From header domain is it.example.com, not example.com.

Your employees see your actual domain in the email address and trust it.

How to find unprotected domains and subdomains

The fastest way to find gaps is to use a DNS lookup tool or a DMARC checker to query DMARC records across your full domain portfolio. Look for domains that return nothing or NXDOMAIN for a DMARC lookup.

Key questions to answer:

• How many domains does your organization own that can receive email?
• Which of those domains are used for sending email?
• Which sending domains have a DMARC record?
• Which sending domains have a p=none policy versus an enforced policy?
• Are any subdomains used for sending that are not covered by a parent DMARC record?

Many organizations discover they have more sending domains than they realized. Marketing platforms, SaaS tools, cloud services, and legacy systems often send from domains that were set up years ago and never assessed for DMARC coverage.

What your DMARC aggregate reports reveal about subdomain abuse

Aggregate DMARC reports (RUA reports) show authentication results for all domains that receive mail from your sending infrastructure. These reports include results for subdomains if they are sending to receivers that participate in DMARC reporting.

If you receive DMARC reports, look for entries where the result shows pass on DKIM or SPF but the aligned domain is a subdomain you did not authorize. Unrecognized subdomain senders in your DMARC reports are worth investigating. They could be legitimate services you forgot about, or they could be spoofing attempts that happened to pass authentication.

The practical challenge is that most organizations get DMARC reports in separate digest emails per domain, if at all. Collecting and correlating reports across a domain portfolio requires tooling. DMARCFlow aggregates reports for all your domains and subdomains into a single view, making it practical to spot subdomain spoofing without manually processing XML reports from each receiver.

Monitoring aggregate reports across your entire domain portfolio, rather than checking domains manually, is the practical path for organizations with more than a handful of domains.

How to fix the subdomain gap

Each domain and subdomain that sends email needs its own DMARC record. The options for coverage:

Option 1: Explicit DMARC record on each sending domain

Set a p=quarantine or p=reject policy on every domain and subdomain that sends mail. Before enforcing, monitor aggregate reports to confirm all legitimate sending sources are aligned.

Option 2: Use the sp tag on the parent domain

The sp tag in a DMARC record sets a policy for subdomains specifically. Adding sp=quarantine or sp=reject to your parent domain DMARC record applies that policy to all subdomains of the organizational domain, while leaving the parent domain's own policy under the p tag.

Example:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:reports@example.com

This sets p=reject for example.com and sp=quarantine for all subdomains. Use this only when you are confident all legitimate subdomain senders are covered by explicit subdomain records or can accept quarantine treatment.

Option 3: Use a subdomain-specific record to override the parent

A DMARC record on a subdomain takes precedence over the parent policy for that subdomain. Set explicit subdomain records where you need different treatment than the parent provides.

Practical next step

Before adding new DMARC records, pull aggregate reports for every domain you know sends mail. Identify which subdomains are actually used for sending and which appear in reports unexpectedly.

A DMARC monitoring service that aggregates reports across your full domain portfolio makes this practical without building custom tooling. DMARCFlow collects aggregate reports for all your domains and subdomains in one place, surfaces subdomain senders you did not authorize, and alerts when new sending sources appear.

FAQ

Does a wildcard SPF record cover all subdomains?
A wildcard SPF record like *.example.com covering include mechanisms does apply to subdomains, but it only satisfies the SPF check, not the DMARC alignment check. The From header domain still needs to align with the organizational domain in the SPF result for DMARC to pass. A wildcard SPF record on its own does not protect subdomains from spoofing.

Does DMARC p=none on the parent protect subdomains?
No. p=none means the domain is in monitoring mode and no action is taken on failed messages. It does not provide any protection for subdomains, and it does not cause subdomains to inherit the monitoring behavior.

Can a subdomain DMARC record override a parent policy?
Yes. A DMARC record at the subdomain level takes precedence over any policy set on the parent domain for that specific subdomain. This is intentional under RFC 7489.

What happens to email from subdomains that have no DMARC record?
Receiving mail servers apply their own handling rules. Some treat unprotected domains as more likely to be spoofed. Some apply their own heuristics. There is no standardized behavior, which is exactly why leaving subdomains without DMARC records is a gap, not a safe default.