What is the default DMARC policy for subdomains?

By default, subdomains inherit the DMARC policy set for the organizational (parent) domain. If the parent domain's DMARC record specifies p=quarantine , then all subdomains without their own DMARC record will also have a quarantine policy applied.

Can I set a different DMARC policy for my subdomains?

Yes, you can. You have two main ways: using the sp (subdomain policy) tag in your organizational DMARC record to apply a different policy to all subdomains, or publishing a dedicated DMARC record for a specific subdomain, which will override any parent policy.

What happens if a subdomain has its own DMARC record?

If a subdomain publishes its own DMARC record, that specific record's policy will take precedence over the organizational domain's policy, including any sp tag defined in the parent record. This allows for precise control over individual subdomains.

Is DMARC inheritance similar to SPF for subdomains?

No, DMARC's inheritance model is different from SPF. SPF records do not inherently apply to subdomains by default, requiring separate SPF records or specific mechanisms like redirect to extend coverage. DMARC, on the other hand, covers subdomains automatically unless explicitly overridden.

Why is it important to monitor DMARC for subdomains?

Monitoring DMARC reports for subdomains is crucial for identifying unauthorized email sending, potential spoofing attempts, or legitimate sending sources that might not yet be properly authenticated. This ensures that your brand reputation is protected across all your digital assets.

Does a DMARC policy apply to emails from subdomains by default? - DMARC - Email authentication - Knowledge base

DMARC policy inheritance from parent domain to subdomains

When you implement DMARC, a common question arises regarding how it affects your subdomains. Understanding this inheritance is crucial for maintaining consistent email authentication and preventing spoofing across all your email-sending entities. The good news is that DMARC is designed to provide broad protection by default.

By default, a DMARC policy published for your organizational domain automatically applies to all its subdomains. This means that if you set up a DMARC record for yourdomain.com, it will also govern emails sent from mail.yourdomain.com or marketing.yourdomain.com, unless those subdomains have their own specific DMARC records. This hierarchical application is a powerful feature, ensuring that even if you forget to publish a policy for a specific subdomain, it still benefits from your overarching DMARC strategy.

This automatic inheritance is a core principle of DMARC, differentiating it from protocols like SPF, which do not inherently apply to subdomains. The design choice simplifies initial deployment and helps extend protection without requiring a separate record for every single subdomain you might use. For more details on this, you can review the Microsoft documentation on DMARC configuration

The 'sp' tag and default inheritance

While DMARC policies do apply to subdomains by default, this inheritance can be explicitly managed using the sp tag within your primary DMARC record. The sp tag allows you to specify a different policy for subdomains than the one applied to your organizational domain. This provides flexibility, especially for larger organizations with complex email infrastructures.

For example, you might want a more relaxed policy for your subdomains (e.g., p=none) while maintaining a stricter policy (e.g., p=reject) for your main domain. The sp tag facilitates this granular control. However, if the sp tag is not present, the policy defined by the p tag for the organizational domain will be inherited by all subdomains. For more details, consider our guide on how the DMARC sp tag affects subdomain policies.

Example DMARC Record with 'sp' tag

v=DMARC1; p=quarantine; sp=none; rua=mailto:dmarc_reports@example.com;

This flexibility allows you to roll out DMARC gradually, perhaps starting with a p=none for subdomains to gather data, while your main domain is already at p=reject. Understanding DMARC policies for organizational domains and subdomains is key to effective email security.

Subdomain-specific DMARC records override defaults

Despite the default inheritance, any subdomain can publish its own DMARC record. When a subdomain has its own DMARC record, this record will always override the DMARC policy of the organizational domain, including any sp tag settings from the parent. This is a crucial point for managing your DMARC implementation effectively, especially as your email sending infrastructure grows and becomes more complex.

DMARC record overriding parent policy for a subdomain

This override mechanism provides ultimate control. If you have a critical subdomain, like one used for transactional emails, you might want to enforce a very strict p=reject policy directly on that subdomain, even if your main domain uses p=quarantine. It is important to know how DMARC records on subdomains override root domain policies.

Important: subdomain DMARC records

When a subdomain has its own DMARC record, the sp tag in the organizational domain's DMARC record is ignored for that specific subdomain. This ensures that the most explicit policy, the one directly applied to the subdomain, takes precedence.

This also applies to non-existent subdomains, as the DMARC record for the top-level domain will still apply to any subdomain that doesn't have its own explicit record. This provides comprehensive protection, even for subdomains you might not actively use for email sending but could be targeted by phishers. It's important to understand this because it impacts how DMARC policies apply to subdomains.

Managing DMARC policy application for subdomains

The existence of default inheritance and the sp tag means you have a range of options for managing DMARC across your domain and its subdomains. You can rely entirely on the organizational domain's policy, specify a different policy for all subdomains using sp, or set individual DMARC records for specific subdomains to meet unique requirements.

Default DMARC inheritance

Policy application: The organizational domain's DMARC policy applies to subdomains automatically.
Configuration effort: Minimal, set once for the main domain.
Flexibility: Less granular control, broad protection.

Explicit subdomain DMARC policies

Policy application: Specific DMARC record for a subdomain overrides parent policy.
Configuration effort: More effort, set per subdomain.
Flexibility: Highly granular control for specific use cases.

Remember, the primary goal of DMARC is to prevent email impersonation and protect your brand's reputation. Whether you rely on default inheritance or create custom policies, consistent implementation and DMARC monitoring are essential. We provide solutions to help you understand your email authentication landscape quickly.

If you're wondering do subdomains need their own DMARC records, the answer depends on your specific needs. Default inheritance is usually sufficient for many, but explicit records offer fine-tuned control where necessary. How do DMARC policies and RUA/RUF settings inherit between a domain and its subdomains is also an important consideration.

The importance of DMARC monitoring for subdomains

Implementing DMARC is a continuous process that benefits greatly from active monitoring. Regularly reviewing your DMARC reports (RUA and RUF) will give you insight into which emails are passing or failing authentication, whether they are from your main domain or your subdomains.

Suped provides robust DMARC monitoring and reporting features that centralize this data, making it easy to identify issues and understand the authentication status of all your sending sources. Our AI-powered recommendations help you quickly address any misconfigurations, whether they are related to your main domain or a specific subdomain, ensuring continuous protection.

Scenario	DMARC record configuration	Impact on subdomains
Relying on default	No sp tag; no subdomain DMARC record.	Subdomains inherit the parent domain's p policy.
Applying a general subdomain policy	Use sp tag in the organizational domain's DMARC record.	All subdomains (without their own records) follow the sp policy.
Overriding with a specific subdomain policy	Publish a DMARC record directly for a subdomain.	That specific subdomain uses its own DMARC policy, ignoring parent p or sp.

Monitoring helps ensure your policies are working as intended and alerts you to any unauthorized email activity, often a sign of a bad actor using your domain. For further reading, an article on understanding DMARC and subdomains can provide more context.

Final thoughts

A DMARC policy does apply to emails from subdomains by default, offering a baseline level of protection across your entire domain space. However, the flexibility to define specific subdomain policies with the sp tag or by publishing distinct DMARC records for individual subdomains gives you precise control. This allows you to tailor your email authentication strategy to the unique needs of different sending sources within your organization, ultimately bolstering your email security and deliverability.