DMARC for Subdomains: How the sp Tag and Subdomain Policies Work

If your organization uses subdomains for email -- things like mail.example.com, newsletter.example.com, or app.example.com -- you need to understand how DMARC policies apply to them. The rules are not always obvious, and getting them wrong can either leave subdomains unprotected or break legitimate email.

This guide explains how DMARC inheritance works, how the sp tag gives you separate control over subdomains, and when you should publish DMARC records directly on subdomains instead.

How DMARC Inheritance Works by Default

When a receiving mail server gets an email from newsletter.example.com, it first looks for a DMARC record at _dmarc.newsletter.example.com. If no record exists there, it falls back to the organizational domain and checks _dmarc.example.com.

This fallback behavior means that if you publish a DMARC record on your main domain, all subdomains are covered automatically. A record at _dmarc.example.com with p=reject will apply to example.com, mail.example.com, app.example.com, and every other subdomain -- unless you specify otherwise.

This is important for two reasons. First, you do not need a separate DMARC record for every subdomain. Second, if your main domain is at p=reject, all your subdomains are also at p=reject by default. That can be a problem if some of those subdomains are not ready for enforcement.

The sp Tag: Separate Subdomain Policies

The sp tag in your DMARC record lets you set a different policy for subdomains without publishing separate records on each one. It works exactly like the p tag but applies only to subdomains.

Here is a DMARC record that uses sp:

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@example.com;

This record says: reject failing messages for example.com, but take no action on failing messages for subdomains like mail.example.com or app.example.com. You get the full protection of p=reject on your main domain while keeping subdomains in monitoring mode.

The sp tag accepts the same three values as p:

• sp=none -- Monitor subdomains only. No enforcement.
• sp=quarantine -- Send failing subdomain messages to spam.
• sp=reject -- Block failing subdomain messages entirely.

If you do not include the sp tag at all, subdomains inherit the p policy. So p=reject without an sp tag means subdomains also get p=reject.

When to Use the sp Tag

The sp tag is useful in several common scenarios:

Different Sending Services on Subdomains

Many organizations route different types of email through different subdomains. Your corporate email goes through example.com, your marketing newsletters go through newsletter.example.com, and your application sends transactional email from app.example.com. Each of these might use different email providers with different authentication setups. Agencies managing multiple client domains deal with this complexity constantly, often juggling dozens of subdomains across different accounts.

If your main domain is fully authenticated and ready for p=reject, but your marketing subdomain still has SPF or DKIM issues, the sp tag lets you enforce on the main domain without breaking subdomain email:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com;

This protects the main domain fully while applying a softer policy to subdomains as you work through their authentication.

Gradual Enforcement Across Subdomains

Just as you phase in enforcement on your main domain, you can use the sp tag to phase in enforcement on subdomains. Start with sp=none, move to sp=quarantine, and eventually reach sp=reject. This follows the same gradual approach recommended for the p tag. For more on choosing between quarantine and reject for your subdomains, see DMARC quarantine vs reject.

Protecting Non-Sending Subdomains

If your organization only sends email from the main domain and a few specific subdomains, all the other subdomains are potential spoofing targets. Attackers can spoof payments.example.com or support.example.com even if those subdomains do not exist in your DNS.

Setting sp=reject protects all of these non-sending subdomains at once:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com;

This is the ideal end state for most domains. Both the main domain and all subdomains reject unauthenticated messages.

Publishing DMARC Records Directly on Subdomains

Instead of using the sp tag, you can publish a DMARC record directly on a specific subdomain. A record at _dmarc.newsletter.example.com will override whatever the parent domain's record says for that subdomain.

This approach makes sense when:

A subdomain needs a completely different reporting address. Maybe your marketing team manages newsletter.example.com and wants DMARC reports sent to their own inbox instead of the main domain's reporting address.

A subdomain needs a stricter policy than the parent. If your main domain is still at p=none but a specific subdomain is fully authenticated and needs enforcement, you can publish a p=reject record on that subdomain directly.

Different teams manage different subdomains. In larger organizations, different teams may own different subdomains. Giving each team their own DMARC record lets them manage their own enforcement timeline independently.

Here is an example of a subdomain-specific DMARC record:

; Published at _dmarc.newsletter.example.com
v=DMARC1; p=reject; rua=mailto:marketing-dmarc@example.com;

This subdomain will follow its own policy regardless of what the parent domain's record says.

Common Subdomain Scenarios

Here are practical configurations for the most common subdomain setups:

Marketing Subdomain with Separate Provider

Your main domain uses Google Workspace. Your marketing team sends newsletters through Mailchimp using newsletter.example.com. Both need to pass DMARC, but they have different authentication paths.

Set up SPF and DKIM for both the main domain and the subdomain. Then use a parent DMARC record that covers both:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com;

Once both domains are fully authenticated, sp=reject protects everything.

Application Subdomain Sending Transactional Email

Your application sends from app.example.com using a service like SendGrid or Postmark. Configure SPF and DKIM for the subdomain through that service. Developers integrating transactional email should make sure the DKIM signing domain is either app.example.com or shares the organizational domain example.com so DMARC alignment passes.

If the application subdomain needs time to get authentication right, use:

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@example.com;

This protects the main domain while giving the application team time to fix their setup.

Multiple Subdomains, Only Some Send Email

You have mail.example.com, app.example.com, and docs.example.com. Only the first two send email. The third should never send any email at all.

The simplest approach is to set sp=reject on the parent domain and make sure the sending subdomains are properly authenticated. The non-sending subdomain docs.example.com is automatically protected by the reject policy.

If the sending subdomains are not ready for rejection yet, use sp=quarantine or sp=none on the parent and optionally publish a separate p=reject record on docs.example.com to protect it immediately.

Checking Subdomain DMARC Records

You can check DMARC records for both your main domain and subdomains at dmarcrecordchecker.com. Enter the subdomain to see whether it has its own DMARC record or falls back to the parent domain's policy. This helps you verify that your inheritance and sp tag settings are working as expected.

Choosing the Right Approach

For most small to medium businesses, the sp tag on the parent domain is sufficient. You do not need to publish separate DMARC records on each subdomain unless you have specific requirements like different reporting addresses or independent team management.

The recommended end state is p=reject; sp=reject; on your organizational domain. This protects the main domain and all subdomains from spoofing. Get there by starting with sp=none, authenticating all legitimate subdomain senders, and gradually increasing enforcement.

Monitor Your DMARC Record

You've created your DMARC record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.