How do DMARC policies and RUA/RUF settings inherit or override each other between a domain and its subdomains?
Matthew Whittaker
Co-founder & CTO, Suped
Published 8 May 2025
Updated 19 Aug 2025
8 min read
Understanding how DMARC (Domain-based Message Authentication, Reporting, and Conformance) policies interact with subdomains is crucial for maintaining effective email security and deliverability. Many organizations operate with complex domain structures, often utilizing numerous subdomains for various purposes like marketing, transactional emails, or internal communications. If these are not correctly configured, it can lead to emails failing authentication checks and landing in spam folders or being rejected entirely.
The core of DMARC's design includes a mechanism for policy inheritance, which can simplify management, but also introduces complexities if not fully understood. This inheritance governs not only the disposition policy (e.g., p=none, p=quarantine, or p=reject) but also the reporting mechanisms, specifically the RUA (Aggregate Report URI) and RUF (Forensic Report URI) settings.
Navigating these interactions ensures that your DMARC implementation provides comprehensive protection without unintentionally blocking legitimate email flows. Let's delve into how these policies and reporting settings behave across your domain structure, ensuring you maintain a strong email security posture.
At its core, DMARC is designed to simplify management by allowing a single record on your organizational domain to cover all its subdomains by default. This means if you publish a DMARC record for yourdomain.com, subdomains like mail.yourdomain.com or app.yourdomain.com will automatically inherit that policy unless a specific DMARC record is found on the subdomain itself.
This default inheritance applies to the policy (the p tag) and implicitly to the reporting URIs (the rua and ruf tags) if no separate DMARC record exists for the subdomain. So, if your root domain has a p=quarantine policy, all emails originating from unconfigured subdomains will also be subjected to quarantine if they fail DMARC authentication. This behavior is outlined in the DMARC specification (RFC 7489).
This mechanism is a double-edged sword. It offers convenience for organizations with many subdomains, as it prevents the need to create individual DMARC records for each one. However, it also means that a lax policy on your main domain (e.g., p=none) will apply to all subdomains, potentially leaving them vulnerable to spoofing. Conversely, a strict policy like p=reject could inadvertently block legitimate email from subdomains that aren't yet properly authenticated with SPF and DKIM.
Default DMARC inheritance
Simplifies management: A single DMARC record for the organizational domain applies to all subdomains without explicit records.
Risk of over-blocking: Strict parent policies can block legitimate subdomain email if not properly configured.
The 'sp' tag and explicit subdomain overrides
To gain granular control over how DMARC policies apply to subdomains, the sp (subdomain policy) tag comes into play. This tag is added to your organizational domain's DMARC record and allows you to specify a different policy for subdomains than the one set by the p tag, without needing to create individual DMARC records for each subdomain. For example, your main domain might have p=reject, but you could set sp=quarantine for its subdomains while you're still working on their authentication.
When a DMARC record is explicitly published for a subdomain, that specific record overrides any policy inherited from the organizational domain, including the sp tag. This is a critical point: an explicit subdomain DMARC record takes precedence. For example, if yourdomain.com has sp=quarantine, but mail.yourdomain.com has its own DMARC record with p=reject, then mail.yourdomain.com's policy will be reject, not quarantine.
This override capability is essential for managing diverse sending practices within a single organizational domain. For instance, you might want a very strict DMARC policy for your primary transactional email subdomain but a more relaxed p=none policy for a newly deployed marketing subdomain while you monitor its DMARC reports. This flexibility allows for a phased rollout of DMARC and tailored security levels.
In this example, the main domain will reject unauthenticated emails, while its subdomains will quarantine them. For more details on the sp tag, you can refer to how the DMARC sp tag affects subdomain policies.
RUA/RUF reporting inheritance and overrides
Just as the DMARC policy itself, the RUA (Aggregate Report URI) and RUF (Forensic Report URI) settings also adhere to the inheritance and override rules. If a subdomain does not have its own DMARC record, it will send its aggregate and forensic reports to the RUA and RUF addresses specified in the parent organizational domain's DMARC record.
However, if you create a dedicated DMARC record for a subdomain, and this record includes rua or ruf tags, these local settings will override the RUA/RUF addresses from the parent domain. This means that reports for that specific subdomain will go only to the addresses listed in its own DMARC record.
This is a key consideration for report management. You might want all DMARC reports to flow to a central system for monitoring, or you might prefer specific teams (e.g., marketing for marketing.yourdomain.com) to receive reports relevant to their sending practices. Explicitly defining RUA/RUF on subdomains allows for this distributed reporting. For a deeper understanding of reporting, you can check what information is contained in DMARC RUA and RUF reports.
Subdomain (no explicit record): Inherits RUA from maindomain.com, reports go to reports@maindomain.com.
Subdomain (explicit record):host._dmarc.sub.maindomain.com TXT v=DMARC1; p=none; rua=mailto:reports@subdomain.com; Reports for this subdomain go to reports@subdomain.com, overriding the parent's RUA.
Practical implications and best practices
The flexibility of DMARC inheritance and overrides allows for robust email security implementation, but requires careful planning. It's generally recommended to start with a p=none policy on your organizational domain, with RUA configured, to gather data. This allows you to identify all legitimate sending sources, including those from subdomains, before moving to stricter policies.
For subdomains with well-defined sending patterns and established SPF/DKIM, implementing an explicit DMARC record with a p=reject policy and its own RUA/RUF addresses (or additional RUA addresses pointing to a DMARC monitoring service) is a best practice. This compartmentalizes risk and makes troubleshooting easier if an issue arises with a specific subdomain's email flow. You can find out more about best practices for DMARC setup.
Always remember that the most specific record wins. A DMARC record on a subdomain will always take precedence over a parent domain's policy, including any sp tag. Regularly review your DMARC aggregate reports to ensure that both your organizational domain and its subdomains are behaving as expected and that no legitimate emails are being blocked.
Views from the trenches
Best practices
Always start DMARC implementation with a p=none policy and aggregate reporting to gather data from all sending sources, including subdomains.
Common pitfalls
Assuming all subdomains are covered by the main domain's DMARC without verifying if an explicit subdomain record exists.
Expert tips
Use the 'sp' tag on your organizational domain's DMARC record to apply a more lenient policy (e.g., p=quarantine or p=none) to subdomains while maintaining a stricter policy (e.g., p=reject) for the root domain.
Marketer view
A marketer was surprised when a client's email marketing tool insisted on receiving DMARC aggregate reports, expressing concern that the reports would contain data beyond just their ESP's emails.
2024-01-18 - Email Geeks
Marketer view
A marketer noted that ESPs requiring an RUA address might simply be providing examples for DMARC setup, suggesting it's not always a strict mandate.
2024-01-18 - Email Geeks
Key takeaways
The way DMARC policies and RUA/RUF settings inherit or override each other between a domain and its subdomains is fundamental to effective email authentication. By default, subdomains without their own DMARC records will inherit the policy and reporting addresses of their parent organizational domain. This simplifies initial setup but can lead to unexpected behavior if not managed properly.
The sp tag provides an intermediate layer of control, allowing a specific policy for unconfigured subdomains from the parent record. Crucially, an explicit DMARC record published on a subdomain will always override any inherited or sp-defined policy, and its RUA/RUF settings will take precedence for that subdomain's reports.
Mastering these inheritance and override rules is key to a robust DMARC deployment, ensuring both comprehensive brand protection and seamless email delivery across your entire domain ecosystem. Continuous monitoring of your DMARC reports from Google and Yahoo remains essential for validating your configuration.
Organizational domain has DMARC, but subdomain doesn't.
