Summary
Understanding how DMARC policies and RUA/RUF settings interact between parent domains and their subdomains is crucial for effective email authentication. While DMARC policies generally propagate down to subdomains by default, explicit records at the subdomain level can override this inheritance, providing granular control over how different parts of your domain infrastructure handle email authentication failures and report generation. This flexibility allows organizations to tailor their DMARC implementation to specific sending needs, such as using different policies or report destinations for marketing versus transactional email subdomains.
Key findings
- Default inheritance: By default, if a subdomain does not have its own DMARC record, it will inherit the DMARC policy (p=none, p=quarantine, or p=reject) from its parent or organizational domain.
- Explicit override: Publishing a DMARC record directly on a subdomain will override any inherited policy from the parent domain for that specific subdomain. This allows for tailored policies.
- Subdomain policy tag (sp): The DMARC 'sp' tag (subdomain policy) in a parent domain's DMARC record can explicitly define the policy for all subdomains that do not have their own DMARC record. This is a powerful way to manage subdomain policies centrally. DuoCircle notes that this tag specifies how DMARC handles illegitimate emails from subdomains.
- RUA/RUF inheritance: Similar to policies, RUA (aggregate report) and RUF (forensic report) addresses also inherit. If a subdomain has its own DMARC record, any RUA/RUF specified in that record will be used, overriding the parent's RUA/RUF for reports concerning that subdomain. If the subdomain record omits RUA/RUF, no reports will be sent for that subdomain unless the parent's 'sp' tag is configured for reporting.
Key considerations
- Strategic deployment: Plan your DMARC deployment, especially for subdomains, considering different sending purposes. For example, marketing emails from a subdomain might need a different policy than internal communications.
- Comprehensive monitoring: Ensure you receive DMARC aggregate reports (RUA) for all domains and subdomains. This may require setting up multiple RUA addresses if you manage subdomains with individual DMARC records. For more details on DMARC records, consult our guide.
- Consistency vs. flexibility: Decide whether to rely on default inheritance (perhaps using the 'sp' tag for blanket subdomain policies) or to explicitly define DMARC records for specific subdomains that require unique policies or reporting.
- Avoiding conflicts: Mismanagement of DMARC records across parent and subdomains can lead to unintended email blocking or missed reports. Always verify your DNS settings carefully after making changes.
What email marketers say
Email marketers often face practical challenges when implementing DMARC across complex domain structures, particularly involving subdomains and third-party sending services. There's a common initial confusion regarding whether subdomains automatically inherit policies or require explicit configuration. Many marketers encounter requests from their Email Service Providers (ESPs) to add RUA addresses, raising questions about data sharing and the scope of these reports. Balancing the need for robust email authentication with the complexities of managing multiple sending sources is a recurring theme.
Key opinions
- Subdomain policy management: There's a shared realization that subdomains can and often should have their own DMARC records to achieve specific policy goals, overriding the parent domain's settings.
- ESPs and RUA requests: It's becoming more common for ESPs to request or provide default RUA addresses for their customers' domains, primarily to meet mailbox provider requirements and monitor for spoofing, rather than always providing detailed reports back to the customer directly.
- Scope of RUA reports: Marketers are concerned that RUA reports shared with third parties will contain data on all emails from the domain, not just those sent via the specific ESP, raising privacy and data sharing questions.
- Overriding RUA/RUF: If a subdomain has its own DMARC record, including RUA/RUF addresses, these will supersede any RUA/RUF addresses defined on the parent domain, meaning the parent domain's RUA won't receive reports for that subdomain. Understanding DMARC report requirements is key.
Key considerations
- Verify ESP requirements: When an ESP requests an RUA address, clarify whether it is a strict requirement or an option for their own monitoring. This impacts your DMARC setup strategy. For general DMARC setup, eSecurity Planet provides a guide.
- Custom subdomain policies: Recognize that creating a specific DMARC record for a subdomain gives you full control over its policy and reporting, overriding any inherited settings from the parent domain.
- Reporting transparency: If sharing RUA access with a third party, understand what data they will receive and how they will use it. Consider setting up your own DMARC reporting solution to maintain full control and visibility over all your domain and subdomain policies.
- Testing and validation: Always test DMARC record changes, especially those impacting subdomains or RUA/RUF settings, to ensure the desired outcome and avoid unintended impacts on email deliverability.
Marketer view
Marketer from Email Geeks notes a client's unusual request to add an RUA for their email marketing tool (Kajabi) to their DMARC record. This is a first encounter with a third party insisting on receiving customer domain RUA reports, leading to questions about the implications. While the information is likely benign, concerns exist that it will include more than just Kajabi emails, prompting a cautious approach.
Marketer view
Marketer from Email Geeks finds the RUA request strange, suggesting that the provided RUA addresses might just be examples of what to add. They speculate that it's theoretically possible to add multiple mailto options in a subdomain policy, allowing both DMARC tools and ESPs to receive copies of the reports. This highlights the flexibility, but also the potential for complexity, in DMARC reporting.
What the experts say
Email deliverability experts highlight the nuances of DMARC policy application, particularly concerning domain and subdomain interactions. They underscore that while subdomains without explicit DMARC records will inherit the parent's policy, any DMARC record set on a subdomain will take precedence, functioning independently. This independent behavior extends to RUA/RUF reporting, meaning separate reporting destinations can be configured for subdomains, or reports for those subdomains might be missed by the parent's RUA if not explicitly added. Their advice centers on strategic configuration to maintain both security and deliverability.
Key opinions
- Policy precedence: An explicit DMARC record on a subdomain will always override the policy of the organizational domain. This provides fine-grained control for specific subdomains.
- Default inheritance: If a subdomain does not have its own DMARC record, it will indeed inherit the policy from its parent domain. This is the default behavior as outlined by VerifyDMARC documentation.
- RUA/RUF independence: If a subdomain has its own DMARC record with specified RUA/RUF addresses, these report destinations will be used for that subdomain's reports, effectively stopping those reports from being sent to the parent domain's RUA/RUF.
- Independent records: Each DMARC record, whether on the main domain or a subdomain, acts independently. This means specific configurations on subdomains (policy, reporting, percentage) do not impact other parts of the domain hierarchy.
Key considerations
- Tailored policies: Leverage explicit subdomain DMARC records to implement different policies for various sending purposes, such as a more relaxed 'p=none' for new subdomains under testing, or a stricter 'p=reject' for established, secure transactional subdomains. This is part of general DMARC best practices.
- Comprehensive reporting: To ensure full visibility, if you set individual DMARC records for subdomains, make sure each includes its own RUA address. Otherwise, you might lose valuable aggregate reports for those subdomains.
- Avoiding confusion: Clearly document your DMARC setup across all domains and subdomains to prevent confusion about which policy or reporting destination applies, especially within larger organizations. This impacts DMARC policy application.
- Consistent monitoring: While subdomains can have unique policies, it's often beneficial to monitor their DMARC reports alongside the main domain's to gain a holistic view of your email ecosystem and detect any unauthorized sending from your brand.
Expert view
Expert from Email Geeks clarifies that a policy appearing on the subdomain will override the organizational domain policy. This means that once a DMARC record is explicitly set for a subdomain, its directives take precedence over any inherited rules, providing independent control over how that specific subdomain handles email authentication failures.
Expert view
Expert from Email Geeks confirms that subdomains without an explicit DMARC policy will indeed inherit it from the organizational domain. This default behavior ensures that even subdomains not specifically configured for DMARC will still be covered by the parent domain's authentication policy, maintaining a baseline level of protection across the entire domain space.
What the documentation says
The foundational DMARC specification (RFC 7489) and subsequent guidance clearly define the hierarchy and inheritance rules for DMARC policies and reporting. Documentation typically highlights the default behavior where subdomains inherit the parent domain's policy and reporting destinations. However, it also emphasizes the overriding power of an explicit DMARC record published at the subdomain level, which allows for precise, independent control over that subdomain's email authentication posture and where its aggregate (RUA) and forensic (RUF) reports are sent.
Key findings
- RFC 7489 guidance: The DMARC standard (RFC 7489) defines the 'sp' (subdomain policy) tag, which allows the organizational domain's DMARC record to specify a policy for all subdomains that do not have their own explicit DMARC record.
- Implicit inheritance: Absent an explicit DMARC record or 'sp' tag on a subdomain, the subdomain implicitly inherits the DMARC policy from its parent domain. This ensures continuous coverage across your domain space. The IETF Datatracker mentions key concepts of DMARC policies being published and retrieved.
- Explicit override: If a DMARC record is published directly on a subdomain, that record's policy and reporting settings will take precedence and override any inherited or 'sp' tag policies from the parent domain.
- RUA/RUF tag specificity: The 'rua' and 'ruf' tags in a DMARC record explicitly define the email addresses where aggregate and forensic reports should be sent. If a subdomain's DMARC record contains these tags, reports for that subdomain will go to the specified addresses, ignoring the parent's reporting addresses.
Key considerations
- Adherence to standards: Ensure that your DMARC records, for both parent and subdomains, conform to the official DMARC RFC standards to guarantee proper interpretation by mail receivers. A list of DMARC tags can help.
- Interaction of tags: Understand the precise interaction between the 'p' (policy) and 'sp' (subdomain policy) tags in your main DMARC record to ensure subdomains behave as intended, whether explicitly or by inheritance.
- DNS publication: Accurate DNS record publication is paramount. Incorrectly published DMARC records for parent domains or subdomains can lead to policy misapplication or report delivery failures. Refer to DMARC record examples for guidance.
- Reporting mechanisms: Implement robust DMARC reporting mechanisms to collect and analyze RUA/RUF data from all relevant domains and subdomains. This comprehensive visibility is essential for identifying and mitigating unauthorized email sending and ensuring proper authentication.
Technical article
Documentation from DuoCircle states that the 'sp' tag allows domain owners to specify how DMARC should manage illegitimate emails sent from their subdomains. This tag provides a centralized mechanism for applying a DMARC policy to all subdomains that do not have their own, explicit DMARC record, enhancing control and simplifying management.
Technical article
IETF Datatracker documentation indicates that DMARC policies are published by the Domain Owner or Policy Signer Organization (PSO) and retrieved by the Mail Receiver during the SMTP session, via the DNS. This highlights the fundamental role of DNS in DMARC's operation, serving as the lookup mechanism for policy and reporting instructions.
Related resources
6 resources
Related pages
When should you use DMARC p=none, p=quarantine, or p=reject policies?
DMARC Policies for Organizational Domains and Subdomains Explained
What is the best practice for DMARC record placement for subdomains?
What are the best practices for DMARC setup, including organizational and subdomain policies and reporting?
How does DMARC policy application work with subdomains and CNAME records?
Can DMARC reports be sent without RUA or RUF addresses?
Should I add an explicit DMARC record for subdomains?
What are the requirements for RUA and RUF in DMARC policies?
Do subdomains need their own DMARC records if the main domain has one?
Simple DMARC examples: how to start with a p=none policy
