/Guides/Subdomain DMARC Policies
DMARC Implementation

Subdomain DMARC Policies

Your organization domain is protected, but what about marketing.yourdomain.com and app.yourdomain.com? Learn how to configure DMARC policies for subdomains to prevent attackers from spoofing them.

7 min read
Updated January 2025

The Subdomain Problem

Most organizations focus DMARC protection on their primary domain (yourdomain.com) but forget about subdomains:

marketing.yourdomain.com (unprotected)

Used by SendGrid, Mailchimp, Salesforce Marketing Cloud

app.yourdomain.com (unprotected)

Transactional emails, password resets, notifications

support.yourdomain.com (unprotected)

Zendesk, Freshdesk, customer support emails

Security Risk
Attackers can send phishing emails from your unprotected subdomains even if your main domain has DMARC p=reject. Recipients will see "From: noreply@marketing.yourdomain.com" and trust it.

How DMARC Inheritance Works

When a receiving server checks DMARC for a subdomain, it follows this lookup order:

1

Check Subdomain DMARC Record

First, look for _dmarc.marketing.yourdomain.com TXT record. If found, use this policy for the subdomain.

2

Check sp= Tag in Organization Domain

If no subdomain DMARC record exists, check _dmarc.yourdomain.com for sp= tag (subdomain policy):

v=DMARC1; p=reject;

sp=quarantine; (← policy for ALL subdomains)

rua=mailto:dmarc@yourdomain.com

3

Inherit p= Policy

If no sp= tag exists, subdomains inherit the main policy (p= tag). If p=reject, subdomains also get p=reject.

3 Subdomain Configuration Strategies

Strategy 1: Use sp= Tag (Recommended)

Set a subdomain policy in your organization domain DMARC record. This applies to ALL subdomains that don't have their own DMARC record.

# _dmarc.yourdomain.com TXT

v=DMARC1;

p=reject; (main domain policy)

sp=quarantine; (subdomain policy)

rua=mailto:dmarc@yourdomain.com;

pct=100

Why This Works
Main domain protected with p=reject, but subdomains start with sp=quarantine while you test. Centralizes subdomain protection in one record.

Strategy 2: Individual Subdomain Records

Create separate DMARC records for each subdomain that sends email. Gives you granular control per subdomain.

# _dmarc.marketing.yourdomain.com TXT

v=DMARC1; p=quarantine;

rua=mailto:marketing-dmarc@yourdomain.com

# _dmarc.app.yourdomain.com TXT

v=DMARC1; p=reject;

rua=mailto:app-dmarc@yourdomain.com

# _dmarc.support.yourdomain.com TXT

v=DMARC1; p=none;

rua=mailto:support-dmarc@yourdomain.com

When to Use
When different subdomains have different deployment timelines or you want separate DMARC reports per subdomain team.

Strategy 3: Inherit Main Policy

Don't use sp= tag and don't create subdomain records. All subdomains inherit the main p= policy.

# _dmarc.yourdomain.com TXT

v=DMARC1;

p=reject; (applies to main domain AND all subdomains)

rua=mailto:dmarc@yourdomain.com

Caution
Only use this after ALL subdomains have proper SPF/DKIM configured. If even one subdomain has bad auth, it will immediately fail with p=reject.

Real-World Enterprise Example

A typical enterprise setup with multiple subdomains:

yourdomain.com

Main organization domain - Google Workspace

p=reject (fully enforced)

marketing.yourdomain.com

Marketing campaigns - SendGrid + Mailchimp

sp=quarantine (testing phase, inherits from main domain sp= tag)

app.yourdomain.com

Transactional emails - Postmark + AWS SES

Individual record: p=reject (fully configured SPF/DKIM)

support.yourdomain.com

Customer support - Zendesk

sp=quarantine (inherits from main domain sp= tag)

staging.yourdomain.com

Staging environment - testing only

Individual record: p=none (monitor only, no enforcement)

# Main domain record (_dmarc.yourdomain.com):

v=DMARC1; p=reject; sp=quarantine;

rua=mailto:dmarc@yourdomain.com; pct=100

# Subdomain record for app (_dmarc.app.yourdomain.com):

v=DMARC1; p=reject;

rua=mailto:app-dmarc@yourdomain.com

# Subdomain record for staging (_dmarc.staging.yourdomain.com):

v=DMARC1; p=none;

rua=mailto:staging-dmarc@yourdomain.com

Step-by-Step Implementation

1

Inventory All Subdomains

List every subdomain that sends email: marketing, app, support, staging, etc. Check with IT, marketing, and product teams.

2

Check Current SPF/DKIM Status

For each subdomain, verify SPF and DKIM are configured. Send test emails and check authentication results.

3

Add sp=none to Main Domain

Start monitoring subdomain email without enforcement:

v=DMARC1; p=reject; sp=none;

rua=mailto:dmarc@yourdomain.com

4

Review Reports for 2 Weeks

Check DMARC aggregate reports for subdomain email sources. Identify any legitimate senders failing SPF/DKIM.

5

Fix Subdomain Authentication

Configure SPF and DKIM for each subdomain. Update ESP settings (SendGrid, Mailchimp, etc.) to use subdomain.

6

Move to sp=quarantine

Once all legitimate subdomain email passes authentication:

v=DMARC1; p=reject; sp=quarantine;

rua=mailto:dmarc@yourdomain.com

7

Monitor for 4 Weeks, Then sp=reject

After 4 weeks with no failures at sp=quarantine:

v=DMARC1; p=reject; sp=reject;

rua=mailto:dmarc@yourdomain.com

All subdomains now fully protected!

Common Mistakes
  • • Forgetting about subdomains when setting p=reject on main domain
  • • Not configuring SPF/DKIM for ESP subdomains (marketing, support)
  • • Setting sp=reject too quickly without monitoring reports
  • • Assuming subdomains that don't send email are safe (they can still be spoofed)
  • • Using same DKIM selector for main domain and subdomains (use separate selectors)
  • • Not testing subdomain emails before changing sp= policy

Subdomain Protection Made Simple

TrustYourInbox automatically discovers all your subdomains and monitors their DMARC compliance. No manual tracking needed.