How to protect subdomains with DMARC?

Understanding DMARC and Subdomains

Many organizations send email from subdomains (newsletters.example.com, noreply.example.com, alerts.example.com) as well as the primary domain. Each subdomain needs DMARC protection, but configuration varies depending on whether you want centralized or distributed policies.

Attackers often target less-protected subdomains for spoofing because they're less monitored than the primary domain. Comprehensive DMARC coverage, including all subdomains, is essential for complete email protection.

Subdomain DMARC Configuration Approaches

Approach 1: Standalone Subdomain Policies

Each subdomain has its own DMARC record:

Primary domain:

example.com TXT: v=DMARC1; p=reject; rua=mailto:[email protected]

Mail subdomain:

_dmarc.mail.example.com TXT: v=DMARC1; p=reject; rua=mailto:[email protected]

Newsletter subdomain:

_dmarc.newsletters.example.com TXT: v=DMARC1; p=reject; rua=mailto:[email protected]

Advantages:

• Fine-grained control per subdomain
• Separate reporting for each subdomain
• Different policies for different purposes
• Easier troubleshooting per subdomain

Disadvantages:

• More records to manage
• Duplicate configuration
• More reporting addresses to monitor

Approach 2: Subdomain Policy Inheritance

Subdomains inherit parent policy (if no specific subdomain record exists):

Primary domain:

_dmarc.example.com TXT: v=DMARC1; p=reject; rua=mailto:[email protected]; sp=quarantine

• sp=quarantine: Subdomain policy (quarantine instead of reject)
• All subdomains without their own record inherit this

No records for subdomains (they use parent policy)

Advantages:

• Single policy for organization
• Less configuration
• Simpler to manage
• Centralized reporting

Disadvantages:

• Less granularity
• Can't customize per subdomain
• All subdomains follow parent policy
• May not match all use cases

Discovering All Subdomains

Before implementing DMARC, identify all email-sending subdomains:

# Find all subdomains sending mail
# Check MX records
for subdomain in $(cat subdomains.txt); do
  dig ${subdomain}.example.com MX +short
done

# Check mail logs for From: domains
grep "^From: " maillog | cut -d'@' -f2 | sort -u

# Passive DNS records
./passive-dns-lookup example.com | grep mail

# Email header analysis
# Look at Received-from headers to find all sending domains

Common email subdomains to check:

• mail.example.com
• newsletters.example.com
• noreply.example.com
• support.example.com
• alerts.example.com
• billing.example.com
• sales.example.com
• marketing.example.com

Configuring DMARC for Each Subdomain

Step 1: Add Subdomain DMARC Record

# For newsletters.example.com
dig _dmarc.newsletters.example.com TXT

# If no record exists, create one:
_dmarc.newsletters.example.com TXT: v=DMARC1; p=reject; rua=mailto:[email protected]

Step 2: Configure Subdomain SPF

Subdomains need their own SPF records:

newsletters.example.com TXT: v=spf1 include:sendgrid.net ~all

Or inherit from parent:

newsletters.example.com TXT: v=spf1 include:example.com ~all

Step 3: Configure Subdomain DKIM

Each subdomain needs DKIM configuration:

selector._domainkey.newsletters.example.com TXT: v=DKIM1; k=rsa; p=[PUBLIC KEY]

Or configure mail service to use parent domain DKIM.

Step 4: Test Subdomain Authentication

# Check DMARC record
dig _dmarc.newsletters.example.com TXT

# Check SPF
dig newsletters.example.com TXT

# Check DKIM
dig selector._domainkey.newsletters.example.com TXT

# Send test email and check headers

Subdomain Policy Strategies

Strategy 1: Strict on Primary, Lenient on Subdomains

Primary domain - strict enforcement:

_dmarc.example.com: v=DMARC1; p=reject; sp=quarantine

Subdomains - more lenient during testing:

_dmarc.mail.example.com: v=DMARC1; p=quarantine; pct=50
_dmarc.newsletters.example.com: v=DMARC1; p=quarantine

Gradually enforce on subdomains after testing.

Strategy 2: Unified Policy Across Domain

Single policy for all:

_dmarc.example.com: v=DMARC1; p=reject; sp=reject

• Primary domain: p=reject
• All subdomains: sp=reject

Simple and consistent.

Strategy 3: Subdomain-Specific Policies

Different policies for different use cases:

_dmarc.example.com: v=DMARC1; p=reject
_dmarc.transactional.example.com: v=DMARC1; p=reject; pct=100
_dmarc.marketing.example.com: v=DMARC1; p=quarantine; pct=50
_dmarc.alerts.example.com: v=DMARC1; p=none; rua=mailto:[email protected]

Matches different security requirements.

Protecting Unintended Subdomains from Spoofing

The Wildcard DMARC Approach

Some domains support wildcard DMARC records:

_dmarc.*.example.com TXT: v=DMARC1; p=quarantine

This provides basic protection for any subdomain without its own record.

Not all receivers support this - verify with your domain registrar/DNS provider.

Alternative: Explicit Catch-All

If wildcard isn't supported, create records for all known subdomains:

# Create records for all subdomains
for sub in mail alerts billing sales support noreply newsletters; do
  # Add DMARC record via DNS provider API
  dns_add "_dmarc.${sub}.example.com" "v=DMARC1; p=quarantine"
done

Monitoring Unmapped Subdomains

# Monitor DMARC aggregate reports for unknown subdomains
# Check "From" domains in failing messages
# If unknown subdomain is spoofed, add DMARC record

# Example from forensic reports:
# - Attacker spoofed: phishing.example.com
# - Add immediately: _dmarc.phishing.example.com with p=reject

Subdomain-Specific Challenges

Challenge 1: Different Mail Services per Subdomain

Scenario:

• Primary domain: Google Workspace
• Marketing subdomain: HubSpot
• Transactional: SendGrid

Solution: Each subdomain has own SPF/DKIM configuration:

example.com: v=spf1 include:_spf.google.com ~all
marketing.example.com: v=spf1 include:hubspot.com ~all
transactional.example.com: v=spf1 include:sendgrid.net ~all

Challenge 2: Third-Party Services Sending As Subdomain

Scenario: Service needs to send as [email protected] but service provider isn't properly configured.

Solution:

1. Contact service provider about DMARC alignment
2. If not available, configure service to include SPF/DKIM headers
3. Use p=quarantine temporarily while fixing
4. Move to p=reject once provider is compliant

Challenge 3: Legacy Systems on Subdomains

Scenario: Old system on legacy.example.com can't support proper SPF/DKIM configuration.

Solutions:

1. Preferred: Migrate system off subdomain
2. Short-term: Use weaker DMARC policy (p=quarantine, p=none)
3. Interim: Add IP to SPF allowlist from multiple sources
4. Document: Create plan to modernize system

DNS Configuration Best Practices

SPF for Subdomains

# Parent domain SPF
example.com TXT: v=spf1 include:example.com.spf ~all

# Subdomain SPF (option 1 - independent)
mail.example.com TXT: v=spf1 include:sendgrid.net ~all

# Subdomain SPF (option 2 - inherits parent)
mail.example.com TXT: v=spf1 include:example.com ~all

# Subdomain SPF (option 3 - combination)
mail.example.com TXT: v=spf1 include:sendgrid.net include:example.com ~all

DKIM for Subdomains

# Option 1: Subdomain-specific DKIM
selector1._domainkey.mail.example.com TXT: v=DKIM1; k=rsa; p=[KEY]

# Option 2: Use parent domain DKIM
# Configure mail service to use selector1._domainkey.example.com

DMARC for Subdomains

# Subdomain DMARC record
_dmarc.mail.example.com TXT: v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]

Monitoring Subdomain Authentication

Aggregate Reports Per Subdomain

Configure different report addresses:

_dmarc.example.com: rua=mailto:[email protected]
_dmarc.mail.example.com: rua=mailto:[email protected]
_dmarc.newsletters.example.com: rua=mailto:[email protected]

Allows tracking authentication separately.

Consolidated Reporting

Or consolidate all subdomain reports:

_dmarc.example.com: rua=mailto:[email protected]
_dmarc.mail.example.com: rua=mailto:[email protected]
_dmarc.newsletters.example.com: rua=mailto:[email protected]

Easier to manage, analyze from central location.

Common Subdomain DMARC Mistakes

Mistake 1: Forgetting Subdomains Exist

Problem: Only implementing DMARC on primary domain

Result:

• Subdomains unprotected
• Attackers spoof subdomains freely
• False sense of security

Solution: Audit all email-sending subdomains

Mistake 2: Different Policies Causing Confusion

Problem:

example.com: p=reject
mail.example.com: p=quarantine

Result:

• Inconsistent protection
• Reporting confusion
• Difficult troubleshooting

Solution: Use consistent policies or document reasoning

Mistake 3: Subdomain Without Authentication Setup

Problem:

_dmarc.subdomain.example.com: v=DMARC1; p=reject

But no SPF/DKIM records for subdomain!

Result:

• All mail from subdomain fails
• Legitimate mail rejected
• Service disruption

Solution: Set up SPF/DKIM before enabling DMARC

Mistake 4: Not Testing Authentication

Problem:

• Add subdomain DMARC without testing mail sources
• Assume everything will pass authentication

Result:

• Legitimate mail gets rejected
• Customers can't receive notifications

Solution: Monitor with p=none or low pct before enforcement

Conclusion

Protecting subdomains with DMARC requires discovering all email-sending subdomains and configuring DMARC, SPF, and DKIM appropriately for each. Whether using centralized policies (inherited from parent) or subdomain-specific policies (individual records), comprehensive coverage prevents attackers from spoofing your domain hierarchy.

Key takeaways:

• Discover all email-sending subdomains
• Configure DMARC for each subdomain
• Use SPF/DKIM with proper alignment
• Test before enforcement (p=none → p=quarantine → p=reject)
• Monitor with aggregate and forensic reports
• Document policies and maintain inventory

Complete subdomain protection is the final step in deploying comprehensive email authentication and spoofing prevention across your organization.