A subdomain inherits the organizational domain's DMARC record only when the subdomain does not have its own valid DMARC record. 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. 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. 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 subdomain record: the receiver uses the organizational domain record. For policy, it uses sp when present, otherwise 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 subdomain record still needs a valid p tag. A record with only RUA or RUF is not a valid DMARC policy.
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, the receiver checks the organizational domain, usually _dmarc.example.com. This is the behavior behind most subdomain override rules.
|
|
|
|---|---|---|
Parent only | sp or p | parent |
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 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." If the subdomain has its own DMARC record, the parent sp value is no longer part of the decision.
This also explains why a subdomain record cannot be only v=DMARC1 plus a report address. DMARC requires a policy. 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 DMARC record, aggregate reports for that subdomain are sent to the RUA addresses on the organizational domain 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 subdomain record exists.
- Policy: the parent sp tag applies, or p if sp is absent.
- Reports: RUA and RUF use the parent 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, usually counts by source IP, authentication result, and disposition. RUF reports are failure samples. 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 child 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.
- Invalid child record: the subdomain record contains RUA or RUF but no required p policy tag.
- 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.
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 gets created with RUA only, leaving the required policy tag missing.
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 subdomain record exists, the organizational record controls the policy and reporting. 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.
