DMARC for subdomains: sp=, np= and domains you forgot

The subdomains you forgot#

When you audit, look beyond the obvious sending subdomains:

• Legacy names like mail.example.com, smtp.example.com or old.example.com that once had servers.
• Marketing subdomains like news.example.com or go.example.com used by campaign tools.
• Product subdomains like app.example.com that might send notifications directly from application servers.
• Regional or acquired brands living under your domain.
• Wildcard DNS. If your zone has a wildcard record (*.example.com), every subdomain "exists" as far as DNS is concerned, so np never applies. Attackers can use any name, and sp is what governs them.

Aggregate reports list the From domain for each record in the header_from field. Filter for anything other than your root domain to see which subdomains appear in mail, legitimate or not.

Subdomains that should never send#

For subdomains that exist for web or API use but should never send email, publish explicit records that make abuse easy to reject:

api.example.com.         TXT "v=spf1 -all"
_dmarc.api.example.com.  TXT "v=DMARC1; p=reject"

The inherited sp=reject would already cover DMARC, but an explicit -all SPF record also helps receivers that evaluate SPF independently.

Testing subdomain policies#

Use dig to see what a receiver would find:

dig +short TXT _dmarc.invoices.example.com   # empty: falls back to the parent
dig +short TXT _dmarc.example.com            # the governing record
dig +short A invoices.example.com            # NXDOMAIN means np applies, if supported

Then send a test message from a subdomain you control and read the Authentication-Results header. Many receivers include the applied policy, for example dmarc=pass (p=reject sp=reject).

Subdomains in aggregate reports#

Aggregate reports are organized by the From domain the receiver saw, so a single report for your organizational domain may contain rows for several subdomains. Each row's identifiers section names the header_from domain, and policy_published shows the policy the receiver applied. When you review reports, group rows by header_from first. That makes it obvious which subdomains carry real traffic, which ones only appear in spoofing attempts, and which ones you did not know were sending at all.

A subdomain that suddenly appears in reports with failing results, especially one that does not exist in your DNS, is a strong sign someone is trying it as a spoofing target. That is exactly the traffic np=reject is designed to stop, and it is useful evidence when you decide whether to tighten sp as well.

Delegated subdomains need special care#

If you delegate a subdomain to another DNS provider or to a partner, with NS records pointing elsewhere, the _dmarc record for that subdomain lives in their zone, not yours. They can publish a weaker policy that overrides your inherited one. Keep a list of delegated subdomains and check their DMARC records periodically, or agree contractually on the policy they must publish.

Checklist#

• Know that sp defaults to p; set it explicitly if you want something different.
• Add np=reject once your organizational policy is at enforcement.
• Give subdomains that are still being cleaned up their own _dmarc record.
• Check for wildcard DNS, which defeats np.
• Publish v=spf1 -all on subdomains that never send.
• Filter aggregate reports by header_from to find subdomains in use.

Key takeaways#

• Subdomains without their own DMARC record inherit the organizational domain's record.
• sp sets policy for existing subdomains and defaults to p; np sets policy for non-existent ones.
• np=reject cheaply blocks spoofing of made-up subdomains, where receivers support it.
• Per-subdomain records let you enforce the root while some subdomains are still in progress.
• Wildcard DNS and forgotten legacy names are the most common gaps.