How does DMARC policy application work with subdomains and CNAME records?
Matthew Whittaker
Co-founder & CTO, Suped
Published 4 Jun 2025
Updated 19 Aug 2025
8 min read
Understanding how DMARC policies interact with subdomains and CNAME records is critical for maintaining email deliverability and security. While the core concept of DMARC is straightforward, its application across complex domain structures can lead to confusion. Many organizations use subdomains for various sending purposes, and sometimes, CNAME records are involved in their DNS setup.
A common point of confusion arises when attempting to delegate DMARC management or when unexpected policy application occurs on subdomains. This often involves the sp (subdomain policy) tag and the sometimes misunderstood role of CNAMEs. Getting these configurations right ensures that your emails are properly authenticated and that your DMARC reports provide accurate insights without unintended side effects.
Navigating these interactions is essential to prevent legitimate emails from being flagged as suspicious or blocked altogether. A clear understanding helps in diagnosing issues, maintaining brand reputation, and effectively combating phishing and spoofing attempts that could lead to your domain being put on a blocklist (or blacklist).
By default, a DMARC policy published for an organizational domain will apply to all of its subdomains. This means if your primary domain, say example.com, has a DMARC record, its policy (p= tag) will automatically extend to marketing.example.com or news.example.com, unless explicitly overridden. This is a crucial aspect of DMARC policy inheritance.
However, you can specify a different DMARC policy for subdomains using the sp tag within your main DMARC record. For instance, you might set a p=reject policy for your primary domain while having an sp=none for subdomains if you're still monitoring their email traffic. It is also possible to create a separate DMARC record for a specific subdomain, which will then override the organizational domain's policy for that particular subdomain.
The interaction of the sp tag can sometimes be counter-intuitive. For example, some tools might flag an empty sp tag or its absence as a potential issue, even when it's functioning as intended, by simply applying the primary domain's p policy. This behavior is outlined in the DMARC specification, which states that if the sp tag is missing, the policy of the organizational domain applies to its subdomains. To dive deeper into these specifics, consider exploring DMARC's official FAQ.
The role of CNAME records in DMARC policy application
CNAME records (Canonical Name) are a type of DNS record that maps an alias name to a canonical domain name. They are commonly used to point subdomains to other domains. However, for DMARC, the DMARC record must be a TXT record located at the _dmarc subdomain (e.g., _dmarc.yourdomain.com). This specific subdomain naming convention is a critical requirement.
The challenge with CNAMEs comes from a fundamental DNS rule: a domain or subdomain cannot have both a CNAME record and other record types (like TXT, MX, or A records) simultaneously. If you set a CNAME for _dmarc.yourdomain.com to point to another domain, say _dmarc.otherservice.com, the DMARC lookup will follow that CNAME. Consequently, your domain's DMARC policy will be determined by the TXT record found at _dmarc.otherservice.com, not directly by a TXT record on your own _dmarc.yourdomain.com. This is how many email service providers (ESPs) and DMARC management platforms facilitate DMARC setup for their users.
This CNAME redirection method can be useful for centralizing DMARC policy management across many domains, allowing changes to a single DMARC record to propagate to all aliased domains. However, it's essential that the target of the CNAME is indeed configured to serve a DMARC TXT record for this purpose. If the CNAME points to a domain that doesn't have a DMARC record, or if it points to a general hostname not designed for DMARC, it can lead to DMARC validation failures or unexpected policy application from the root organizational domain of the CNAME target.
Direct DMARC TXT record
Simplicity: Direct control over your domain's DMARC policy. No third-party dependencies.
Transparency: Policy is clearly defined within your own DNS zone file.
Local management: Requires manual updates for each domain and subdomain.
Common pitfalls and troubleshooting DMARC with CNAMEs
One common issue I've seen is incorrectly setting a CNAME record for the _dmarc subdomain to a non-DMARC-specific hostname. For example, pointing _dmarc.yourdomain.com to se-broo.seravo.com (as seen in a recent discussion). Unless se-broo.seravo.com is explicitly designed to host DMARC records for external domains, this setup likely means your DMARC policy will effectively default to whatever policy seravo.com has (or no policy at all if it's missing), rather than your intended one.
Another pitfall is assuming that a wildcard CNAME (*.example.com) will handle DMARC records. While wildcards can work for certain DNS records, they typically do not apply to the _dmarc subdomain specifically. DMARC requires a direct TXT record lookup at the _dmarc prefix of the domain or subdomain in question. Wildcard CNAMEs are seldom a good idea generally speaking, and can cause unexpected DNS resolution issues, including dangling DNS records.
CNAME on _DMARC warning
Be cautious when using CNAME records for your _dmarc subdomain. If the CNAME points to a domain that doesn't have a DMARC record, your domain will effectively have no DMARC policy, leaving it vulnerable. Always verify the DMARC record at the CNAME's destination.
Tools like MXToolbox or other DNS checkers can sometimes provide misleading warnings or interpretations if your DMARC setup involves CNAMEs in a non-standard way. It's crucial to understand the underlying DNS resolution process and DMARC specification to accurately diagnose such messages. If a checker implies an sp tag is empty or suspicious, it might simply be misinterpreting the inheritance behavior or a CNAME redirection.
Best practices for DMARC with subdomains and CNAMEs
When establishing DMARC policies for your domains, aim for clarity and directness. For subdomains, you have a few options to consider. You can rely on the default inheritance from your organizational domain, define a specific subdomain policy using the sp tag in your primary DMARC record, or create a unique DMARC record directly on the subdomain, for example, _dmarc.sub.yourdomain.com. Each approach has its merits depending on your specific email sending architecture and desired level of control. If you have questions about subdomain DMARC records, explore more.
If you need to centralize DMARC management, using CNAME records to point your _dmarc records to a dedicated DMARC service or an ESP's provided hostname is a valid strategy. However, always ensure that the target hostname is indeed set up to serve the correct DMARC TXT record. Verify this by performing a DNS lookup on the CNAME target. For a comprehensive guide on DMARC setup, including organizational and subdomain policies, take a look at DMARC best practices.
Avoid using CNAME records where a direct TXT record is expected, especially for the core _dmarc record unless you're explicitly using a DMARC delegation service. Also, refrain from using wildcard CNAMEs for _dmarc or DMARC reporting subdomains, as they can lead to unpredictable behavior and security risks. Always conduct thorough tests with a deliverability tester after making DNS changes to confirm that your DMARC policy is being applied correctly for both your primary domain and its subdomains.
Scenario
DMARC Record Example
Subdomain Policy Application
Organizational Domain Only
_dmarc.yourdomain.com IN TXT "v=DMARC1; p=quarantine"
Default policy (p=quarantine) applies to all subdomains if no specific sp tag is present, nor a subdomain DMARC record.
Organizational Domain with sp Tag
_dmarc.yourdomain.com IN TXT "v=DMARC1; p=reject; sp=none"
Primary domain policy (p=reject) for main domain. Subdomain policy (sp=none) for all subdomains, unless a specific subdomain has its own record.
Specific Subdomain DMARC Record
_dmarc.sub.yourdomain.com IN TXT "v=DMARC1; p=quarantine"
This specific subdomain's policy (p=quarantine) overrides any organizational or sp policy for that subdomain.
DMARC via CNAME Delegation
_dmarc.yourdomain.com IN CNAME _dmarc.providerservice.com
The policy defined at providerservice.com (or its organizational domain) applies. This policy can include its own sp tag if applicable.
Views from the trenches
Best practices
Always explicitly define DMARC policies for critical subdomains, especially those used for transactional emails or marketing.
Use the 'sp' tag in your organizational domain's DMARC record to manage subdomain policies centrally when appropriate.
If delegating DMARC via CNAME, confirm that the CNAME target is a legitimate DMARC service and correctly configured.
Common pitfalls
Assuming DMARC policies on the organizational domain will always behave as expected for all subdomains without verification.
Creating a CNAME record for '_dmarc' that points to a non-DMARC-specific hostname, leading to unexpected policy application.
Using wildcard CNAMEs for DMARC records, which can cause DNS resolution issues and policy misinterpretations.
Expert tips
Use a DMARC record generator to ensure correct syntax for both primary and subdomain policies.
Segment your email sending by subdomain, assigning specific policies based on the type and sensitivity of mail sent.
Automate DMARC report analysis to quickly identify any policy failures or authentication problems across your domain ecosystem.
Expert view
Expert from Email Geeks says DMARC policy applies to all subdomains by default if not explicitly stated otherwise at the organizational level or if no separate subdomain policy exists.
2020-01-30 - Email Geeks
Expert view
Expert from Email Geeks says DMARC does not inherently care about CNAMEs, it primarily looks for a TXT record. The DNS resolver handles the CNAME redirection before DMARC evaluates the resulting TXT record.
2020-01-30 - Email Geeks
Ensuring DMARC success across your domain portfolio
Effectively managing DMARC policies for both primary domains and subdomains, especially when CNAME records are involved, is fundamental to robust email security and deliverability. Understanding the default inheritance behavior, the nuances of the sp tag, and the proper use of CNAMEs for DMARC delegation can prevent significant headaches. While CNAMEs offer flexibility for centralized management, their incorrect application for _dmarc records can lead to policy failures or misinterpretations.
Prioritize clear, explicit DMARC records and regular monitoring of your DMARC reports. This proactive approach ensures that your email ecosystem is secure, that your legitimate messages reach their intended recipients, and that you maintain a strong sending reputation across all your domains and subdomains.
providerservice.com (or its organizational domain) applies. This policy can include its own sp tag if applicable.
