Why Your Subdomain Email Gets Rejected by DMARC (And How to Fix It)

Your subdomain is sending legitimate email. You never published a DMARC record for it. Yet receivers are silently rejecting its mail.

The reason is DMARC inheritance. Your subdomain is not exempt just because it does not have its own DMARC record. It is subject to the policy published on your organizational domain, and if that policy is p=reject, your subdomain's mail fails unless it meets the alignment requirements.

This is not a bug. It is how DMARC is designed to work. But it catches many operators off guard, especially when rolling out DMARC enforcement across an organization with multiple sending subdomains.

The only way to know this is happening is through DMARC aggregate reports. If you are not monitoring those reports, you will not see the failures -- receivers that enforce DMARC often silently discard failing mail without sending bounces. DMARCFlow monitors aggregate reports across all your domains and subdomains, alerts you when new subdomains appear in reports without their own explicit policy, and flags authentication failures before they become production incidents.

How DMARC Subdomain Inheritance Works

RFC 7489, Section 6.6.3 defines how DMARC policies apply to subdomains. The rule is straightforward: a DMARC policy published on example.com applies to every subdomain of example.com, unless that subdomain publishes its own DMARC record that overrides the inherited policy.

This means:

• example.com with p=reject means all subdomains -- including mail.example.com, notifications.example.com, and alerts.example.com -- are also subject to p=reject


• The inheritance covers second-level subdomains and everything below them


• Only a DMARC record explicitly published in the subdomain's DNS breaks the inheritance


• Nothing in the email headers or SMTP transaction changes this

The practical implication: if you move your organizational domain to p=reject without auditing your sending subdomains, you may start seeing silent rejections for subdomain mail you did not realize was being sent.

The Real-World Failure Scenario

Here is the pattern that plays out repeatedly in practice:

1. The IT team publishes v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com on example.com. DKIM is aligned for example.com.
2. A separate team sets up an application that sends transactional email from noreply@notifications.example.com using a third-party MTA like SendGrid, Amazon SES, or Mailgun.
3. The MTA signs outbound mail with its own DKIM key, which is aligned to the MTA's domain (e.g., sendgrid.net), not to example.com.
4. The MTA's IPs are not listed in example.com's SPF record.
5. Both SPF and DKIM alignment fail for the From: address at notifications.example.com.
6. Receiving mail servers that enforce DMARC silently reject or quarantine the mail.
7. The sender application logs show no error. No bounce message arrives. The only evidence is in the DMARC aggregate report.

This is exactly what happened to someone who writes DMARC guides for a living. They set up a new sending subdomain, confirmed it worked in testing, then discovered months later -- through their own aggregate reports -- that production mail had been silently failing for some receivers.

The failure is silent because many receivers drop DMARC failures without sending a bounce. The sender has no indication anything went wrong until they check aggregate reports.

How to Tell If Your Subdomain Is Failing DMARC

The first step is checking what policy your subdomain actually inherits. Use a DMARC lookup tool and enter your subdomain, not just your root domain.

The second step is reviewing your DMARC aggregate reports. These are XML files sent to the rua address in your DMARC record. They show authentication results for your domain, including subdomains. If you are manually downloading and parsing these files, you are already behind. DMARCFlow automates this across all your domains and flags subdomains that appear in reports without their own policy.

Look for:

• DKIM failures on subdomain-aligned From addresses


• SPF failures where the sending infrastructure is not covered by the organizational domain's SPF record


• High failure rates on subdomains that have no explicit DMARC record


• Subdomains appearing in reports for the first time after you moved the organizational domain to p=reject

If you do not have access to aggregate reports, check your MTA logs for rejection codes. A 550 5.7.1 response citing DMARC policy is a direct signal.

How to Fix DMARC Subdomain Rejections

There are four practical paths.

Option A: Publish a DMARC record on the subdomain

This is the cleanest fix for most teams. Start with a permissive record to validate the setup:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100

This tells receivers to apply no policy yet but to send aggregate reports to you.

While running at p=none, verify that:

• Your MTA's sending IPs are listed in the subdomain's SPF record, or that you use a subdomain-aligned DKIM selector


• Your DKIM selector is published in the subdomain's DNS (e.g., selector._domainkey.notifications.example.com)


• Aggregate reports show DKIM or SPF passing for legitimate mail streams

Once you have confirmed passing authentication for two to four weeks, move the policy toward enforcement:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=100

Then, once you are confident:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; pct=100

The progression from p=none to p=quarantine to p=reject is not optional. Skipping steps is how you get the silent failure problem again, just at a stricter policy level.

During this progression, DMARCFlow tracks your pass rates across all subdomains and sends alerts when failure rates change -- which is the fastest way to catch a misconfigured subdomain before it becomes a production incident.

Option B: Align DKIM for the subdomain

If your current MTA signs mail with a DKIM key that is aligned to its own domain rather than your subdomain, you have two choices:

• Reconfigure the MTA to use a DKIM selector published in your subdomain's DNS


• Switch to an MTA that supports custom subdomain DKIM selectors

Most major transactional email providers support custom DKIM selectors. The configuration steps vary by provider, but the goal is the same: the DKIM signature must include d=notifications.example.com, not d=sendgrid.net.

Option C: Add the subdomain to your SPF record

If your MTA uses IP addresses or includes that are not currently in your organizational domain's SPF record, you have two options:

• Add the sending IPs or includes to your organizational domain's SPF record


• Publish a separate SPF record on the subdomain that covers its own sending infrastructure

Publishing a separate SPF record on the subdomain is valid but adds DNS complexity. If you do it, make sure the subdomain's SPF record does not conflict with or duplicate the organizational domain's SPF logic in a way that causes lookup failures.

Option D: Isolate subdomain sending on a separate registered domain

Some organizations choose to send all transactional and notification mail from a completely separate registered domain (e.g., examplemail.com) that is isolated from their corporate domain (example.com). This prevents inheritance issues entirely because the DMARC policy on example.com has no effect on examplemail.com.

This approach is common for SaaS products and high-volume senders. It adds domain management overhead but eliminates the inheritance trap.

How to Prevent This in the Future

The failure pattern here is predictable. Before moving your organizational domain to p=reject, audit every subdomain that sends mail. For each one, confirm:

• Does it have its own DMARC record?


• If not, what policy does it inherit?


• Does the subdomain have SPF coverage for all its sending infrastructure?


• Is DKIM aligned to the subdomain or to a third-party domain?

Use a DMARC monitoring tool that flags new subdomains appearing in aggregate reports without their own policy. This is the fastest way to catch the problem before it causes a production outage. DMARCFlow does this automatically, alerting you when a subdomain you did not expect to see in reports starts generating authentication failures.

When you add a new sending subdomain to your infrastructure, the checklist is:
1. Check what DMARC policy it inherits
2. Publish an explicit p=none record on the subdomain
3. Configure SPF and DKIM for the subdomain's sending infrastructure
4. Monitor aggregate reports for two weeks
5. Move toward enforcement as you confirm authentication passing

Frequently Asked Questions

Does a DMARC record on example.com apply to sub.example.com?

Yes. Unless sub.example.com publishes its own DMARC record, it inherits the policy from example.com.

Can a subdomain have a different DMARC policy than the root domain?

Yes. A subdomain can publish its own DMARC record with any policy (p=none, p=quarantine, or p=reject). The subdomain policy overrides inheritance.

What happens if a subdomain has p=none but the root domain has p=reject?

The subdomain's own policy applies. The subdomain is not affected by the root domain's p=reject because it has its own record.

Does DMARC inheritance apply to every level of subdomain?

Yes. DMARC inheritance applies to all levels below the policy publishing domain. A record on example.com applies to mail.example.com, alerts.mail.example.com, and any other subdomain at any depth.

Can I use a wildcard DMARC record?

RFC 7489 does not define wildcard DMARC records. Inheritance is based on the organizational domain's published policy applying to all subdomains unless explicitly overridden.

Summary

DMARC policies inherit to subdomains by default. If your organizational domain uses p=reject, your subdomains do too unless they publish their own explicit record. The fix is either subdomain-level DMARC configuration with proper SPF and aligned DKIM, or isolation of sending infrastructure onto a separate registered domain. Monitor aggregate reports to catch subdomain failures before they become production incidents.

DMARCFlow monitors DMARC aggregate reports across all your domains and subdomains, alerts you when new subdomains appear in reports without their own policy, and tracks authentication pass rates as you move toward enforcement. If you are managing DMARC across multiple subdomains and sending infrastructure, it is the tool built for exactly this problem.