Subdomain Spoofing: Why You Need DMARC on Every Subdomain

The Subdomain Blind Spot

Most organizations focus their DMARC enforcement on their primary domain. They work through the process of getting example.com to p=reject and consider the job done. But attackers know this and shift to spoofing subdomains instead.

An email from billing@payments.example.com looks just as legitimate as one from billing@example.com to most recipients. If payments.example.com doesn't have DMARC enforcement, that spoofed email sails right through.

How DMARC Handles Subdomains

DMARC has two tags that control subdomain behavior:

sp (Subdomain Policy)

The sp tag in your organizational domain's DMARC record sets the default policy for all subdomains that don't have their own DMARC record.

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

If you don't include sp, subdomains inherit the p policy. But this behavior isn't guaranteed — RFC 7489 says subdomains "should" inherit the organizational domain policy, but some receivers don't implement this consistently.

Individual Subdomain Records

You can publish a DMARC record on any subdomain to override the parent policy:

_dmarc.marketing.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

This is useful when a subdomain has different authentication needs than the parent domain.

The Attack Surface

Consider a typical organization with these subdomains:

• www.example.com — Website (doesn't send email)
• mail.example.com — Mail server
• app.example.com — Application
• staging.example.com — Staging environment
• blog.example.com — Blog

None of these subdomains (except possibly mail) send email. But without DMARC protection, an attacker can send email "from" any of them:

• invoice@billing.example.com
• alert@security.example.com
• no-reply@update.example.com

These subdomains might not even exist in your DNS — DMARC alignment checks the From header domain, not whether the subdomain has DNS records.

Protecting Non-Sending Subdomains

For subdomains that should never send email, publish a "null" configuration:

DMARC Record

_dmarc.staging.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Null SPF Record

staging.example.com. IN TXT "v=spf1 -all"

This SPF record says "no servers are authorized to send email for this subdomain." Combined with p=reject, any email claiming to be from this subdomain will be rejected.

No DKIM Needed

If a subdomain never sends email, there are no DKIM keys to publish. The combination of null SPF + DMARC reject is sufficient.

The sp=reject Strategy

The simplest approach for most organizations:

1. Set sp=reject on your organizational domain
2. For subdomains that DO send email, publish individual DMARC records with appropriate policies
3. Don't publish DMARC records for non-sending subdomains — they inherit sp=reject from the parent

; Organizational domain — covers everything by default
_dmarc.example.com.     IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"

; Marketing subdomain — needs its own policy during enforcement ramp-up
_dmarc.marketing.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

All other subdomains (existing or not) inherit sp=reject from the parent.

Inventory Your Subdomains

Before implementing subdomain DMARC policies, inventory which subdomains actually send email:

1. Check DMARC aggregate reports: Reports show the From domain of every message — look for subdomain usage you may not be aware of
2. Audit DNS records: List all subdomains with MX or A records
3. Check with teams: Marketing, engineering, support, and IT may all use subdomains for different email purposes
4. Review third-party services: Some services send from a subdomain of your domain

Common Subdomain Senders

Subdomain	Typical Use
marketing. or mail.	Marketing campaigns
notifications. or notify.	Application notifications
support. or help.	Helpdesk responses
bounce. or return.	Bounce handling
transactional.	Transactional email

The Wildcard Problem

Attackers can create subdomains you've never heard of:

• payroll.example.com
• hr-update.example.com
• security-alert.example.com

These subdomains don't need to exist in your DNS. The attacker just puts them in the From header. If your DMARC setup doesn't cover arbitrary subdomains (via sp=reject), these spoofed emails pass through.

Implementation Checklist

1. Audit existing subdomains that send email
2. Configure SPF and DKIM for every sending subdomain
3. Set sp=reject on your organizational domain's DMARC record
4. Publish individual DMARC records for sending subdomains that need different policies (e.g., p=quarantine while ramping up a new subdomain)
5. Add null SPF records (v=spf1 -all) on known non-sending subdomains for defense in depth
6. Monitor DMARC reports — filter by subdomain to catch unexpected senders

Common Mistakes

Setting sp=none While p=reject

This creates a false sense of security. Your main domain is protected but every subdomain is wide open for spoofing. Always match sp to your desired security level.

Forgetting About Subdomain Email Services

Moving to sp=reject breaks email from subdomains that haven't been properly authenticated. Always inventory and configure before tightening the policy.

Not Monitoring Subdomain Reports

DMARC reports include the header From domain. If you're only looking at example.com results, you'll miss authentication failures on subdomains. Filter your reports by domain to get the full picture.

Summary

Your main domain is only half the battle. Attackers exploit unprotected subdomains — including subdomains that don't even exist — to send convincing phishing emails. The fix is straightforward: set sp=reject on your organizational domain, properly authenticate the subdomains that do send email, and monitor DMARC reports for subdomain activity.

A complete DMARC deployment protects your entire domain namespace, not just the apex.