How do DMARC policies and RUA/RUF settings inherit or override each other between a domain and its subdomains?
Published 8 May 2025
Updated 11 Jun 2026
10 min read
Summarize with
Updated on June 11, 2026: We updated this guide for the DMARCbis RFCs published in May 2026, including DNS Tree Walk policy discovery, RFC 9990 aggregate reporting, RFC 9991 failure reporting, and the current status of tags such as np, psd, t, pct, rf, and ri.
In a simple parent and child setup, a subdomain inherits the organizational domain's DMARC record only when the subdomain does not have its own valid DMARC record. Under RFC 9989, DNS Tree Walk policy discovery can also find DMARC Policy Records at intermediate ancestors, so deeper namespaces use the selected ancestor record rather than always jumping straight to the organizational domain. If a valid DMARC record exists at the subdomain, that subdomain record overrides the organizational domain record as a complete record. The override is not tag by tag. A subdomain record with its own p, rua, or ruf settings does not inherit the missing pieces from the parent.
The practical result is simple: if I add a DMARC record to mail.example.com, that record must contain the policy and every report destination I still want for that subdomain. If the team needs central DMARC monitoring, I keep the central RUA address on the subdomain record too, even when an email platform asks for its own RUA address.
Quick rule
DMARC inheritance selects one record. Under RFC 9989, that selected record can be found by the DNS Tree Walk, not only by a two-query parent lookup. It does not combine the parent record with the child record. Once the child record is selected, the parent record's RUA and RUF settings stop applying to that child.
The short answer
I use this mental model: DMARC first decides which DNS record applies, then it reads only that record. RFC 9989 does this with policy discovery and, when needed, a DNS Tree Walk. It does not read the organizational domain for policy and then read the subdomain for reports. It does not let a subdomain record act as a small override file. A DMARC TXT record is a full instruction set.
- No exact subdomain record: the receiver uses the policy record selected by DNS Tree Walk. For an existing subdomain, it uses sp when present, otherwise p. For a non-existent subdomain, it uses np when present, otherwise sp or p.
- Subdomain record exists: the receiver uses the subdomain record and ignores the parent record for that message.
- Report addresses: RUA and RUF destinations come only from the selected record. Missing report tags are not inherited.
- Partial records: a record intended to set policy should include a valid p tag. Under RFC 9989, a syntactically valid record with valid rua and no valid p is treated as p=none; RUF alone does not create that fallback.
- Current tag status: RFC 9989 keeps np, psd, and t active. It marks pct, rf, and ri historic, so they should not be used in new records.
Flowchart showing DMARC choosing a subdomain record before the parent record.
How inheritance works
For an email with a visible From domain of mail.example.com, the receiver looks for a DMARC TXT record at _dmarc.mail.example.com. If that record exists and is valid, that is the record. If it does not exist, RFC 9989 policy discovery uses a DNS Tree Walk to look upward for the applicable DMARC Policy Record, which might be the organizational domain, usually _dmarc.example.com, or another ancestor in deeper namespaces. This is the behavior behind most subdomain override rules.
|
|
|
|---|---|---|
Parent or ancestor only | sp, np, or p | selected record |
Child valid | child p | child |
No rua | selected | none |
No ruf | selected | none |
Compact view of which DMARC setting applies.
The sp tag only matters when the organizational domain or selected ancestor record is being used for a subdomain. It lets the parent domain say, for example, "use p=quarantine for the parent, but use sp=none for subdomains." For non-existent subdomains, RFC 9989 adds np, which takes precedence over sp when present. If the subdomain has its own DMARC record, the parent sp value is no longer part of the decision.
This also explains why I still include p in a dedicated subdomain record. Under RFC 9989, an otherwise syntactically valid record with a valid rua but no valid p is processed as p=none, but that fallback is monitoring behavior, not a clear policy statement. If you want a dedicated record for a subdomain, follow a full subdomain setup pattern and include every tag you need there.
RUA and RUF do not merge
RUA and RUF behave like the policy tags because they belong to the selected record. If a subdomain has no exact DMARC record, aggregate reports for that subdomain are sent to the RUA addresses on the DMARC Policy Record selected by policy discovery. In a simple setup this is the organizational domain record; with DNS Tree Walk it can be another ancestor record. If the subdomain has its own record, aggregate reports for that subdomain are sent only to the RUA addresses in the subdomain record.
Inherited parent record
- Lookup: no valid exact subdomain record exists, so policy discovery selects an ancestor record.
- Policy: the selected ancestor record's sp tag applies for existing subdomains, np can apply to non-existent subdomains, or p applies if neither is present.
- Reports: RUA and RUF use the selected ancestor record's destinations.
Explicit subdomain record
- Lookup: a valid subdomain record exists.
- Policy: the subdomain's own p tag applies.
- Reports: RUA and RUF use only the subdomain record's destinations.
This matters when a sending platform asks to receive RUA reports. A RUA address on the organizational domain can receive reports for all mail covered by that organizational record, including other senders. If the sender only needs visibility for a marketing subdomain, I prefer a dedicated subdomain record. Then I put the platform's RUA address and the central reporting address in that one subdomain record. DMARC allows multiple RUA URIs in the same record.
Subdomain record with two aggregate report destinationsDNS
Host: _dmarc.mail.example.com Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com,mailto:reports@example.net
RUF deserves extra care. RUA reports are aggregate XML summaries defined by RFC 9990, usually counts by source IP, authentication result, and disposition. RUF reports are message-specific failure reports defined by RFC 9991. Many receivers do not send them, and when they are sent they can include sensitive headers or message fragments. I keep RUF off unless there is a clear investigation need and a controlled mailbox for those reports.
Practical DNS examples
Start with the organizational domain. This record covers example.com and, when no more specific policy record exists, it also covers subdomains. In this example, the parent is stricter for the main domain but keeps subdomains at monitoring only through sp=none.
Organizational domain recordDNS
Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=quarantine; sp=none; rua=mailto:dmarc@example.com
Now add a record at mail.example.com. This record overrides the parent for that exact subdomain. The parent RUA address no longer receives reports for this subdomain unless it is also listed here.
Explicit subdomain recordDNS
Host: _dmarc.mail.example.com Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com,mailto:reports@example.net
If a RUA or RUF address is on a different domain, the reporting destination domain needs to authorize that use. Otherwise, receivers can reject the external report destination. The authorization record sits under the destination domain, not under the sending domain.
External report destination authorizationDNS
Host: example.com._report._dmarc.reports.example.net Type: TXT Value: v=DMARC1
Do not send broad reports by accident
If a third party asks for a RUA address at the organizational domain, that address can receive aggregate data for more than the traffic it sends. Use a dedicated subdomain record when the third party only needs visibility into that subdomain.
How I validate the final record
Before I publish a subdomain DMARC record, I check three things: the DNS host is correct, the record has a complete policy, and every RUA or RUF destination that should receive reports is present on that exact record. A DMARC checker catches the common syntax mistakes before mailbox providers have to interpret them.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped's product makes this workflow less manual by showing the DMARC record, SPF and DKIM diagnostics, DNS records, and source-level authentication results in one place. The useful part here is the source context around the TXT value, especially which senders are affected before tightening a subdomain policy.
For most teams, Suped is the best overall DMARC platform because it turns reports into actionable issues, sends real-time alerts, and keeps DMARC, SPF, DKIM, hosted policy controls, and deliverability signals together. When DNS ownership is split across teams, Suped's Hosted DMARC helps manage policy staging without repeatedly editing TXT records by hand.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
If I am starting from scratch, I use a record generator to create a valid baseline, then adjust the RUA and RUF destinations for the exact domain or subdomain that will own the reports.
Common mistakes
Most DMARC inheritance mistakes come from assuming parent and child records merge. They do not. When I review a setup, I look for these specific errors first.
- Missing central RUA: a subdomain record lists the email platform only, so the main reporting mailbox loses visibility.
- Unclear child policy: the subdomain record omits p and either falls back to p=none because rua is valid, or does not produce DMARC processing if only ruf is present.
- Wrong host: the record is published at _dmarc.example.com when the intended scope is _dmarc.mail.example.com.
- External report failure: the RUA destination is off-domain, but the destination domain has not authorized reports.
- Unexpected RUF exposure: failure reports are enabled without confirming who can read them and what data they contain.
- Old discovery model: treating DMARC as only an exact-domain and organizational-domain lookup misses DNS Tree Walk records in deeper namespaces.
Clean operating pattern
Use the organizational domain record for broad coverage. Add subdomain records only when a subdomain needs a different policy, different report destinations, or both. When you add the child record, copy the central report destination into it.
Views from the trenches
Best practices
Treat each subdomain DMARC record as complete; copy every reporting tag you still need.
Use a dedicated sending subdomain when a vendor asks for its own aggregate reports.
Keep central RUA reporting on explicit child records so monitoring does not lose scope.
Common pitfalls
Teams add a vendor RUA on the parent record and expose aggregate data beyond one sender.
A child record omits p and depends on p=none fallback instead of a clear policy.
RUF gets enabled for troubleshooting without a clear mailbox owner or retention rule.
Expert tips
Publish the strictest safe parent policy, then stage exceptions on named subdomains.
Document which team owns each report address before adding it to production DNS.
Test inherited and explicit cases separately because the receiver chooses only one record.
Marketer from Email Geeks says a subdomain can have its own DMARC record, which is useful when a sending platform needs separate reporting.
2024-01-18 - Email Geeks
Marketer from Email Geeks says a subdomain record overrides the organizational record, so parent RUA addresses need to be copied if they should keep receiving reports.
2024-02-07 - Email Geeks
The rule I use
For DMARC inheritance, I treat the selected record as the only record. If no exact subdomain record exists, the record selected by DNS Tree Walk controls the policy and reporting, commonly the organizational domain record in simple setups. If a valid subdomain record exists, that record controls the policy and reporting for the subdomain. Nothing is merged.
That makes the operational answer clear. Use parent records for default coverage. Use explicit subdomain records for exceptions. Put every required RUA and RUF destination on the exact record that will be selected by receivers.
