Subdomains and DMARC.

Your DMARC record sits on your organizational domain and, most of the time, quietly protects every subdomain too. But subdomains are also where enforcement quietly leaks: a forgotten sender that breaks the day you reach p=reject, or a made-up subdomain a spoofer uses precisely because nobody locked it down. Here's how subdomain coverage actually works, and what to check when you run more than one.

One record usually covers them all

When a receiver checks a message from news.example.com, it first looks for a DMARC record at _dmarc.news.example.com. If there isn't one, it walks up the DNS tree to your organizational domain's record at _dmarc.example.com and applies your sp= value (the subdomain policy). If you didn't set sp=, your main p= applies to subdomains instead. So a single record with sp=reject already covers every subdomain that doesn't publish its own. You don't need a record per subdomain unless you want one to behave differently.

Alignment, and why subdomains usually "just work"

DMARC passes when SPF or DKIM lines up with the domain in your From address. With relaxed alignment (the default, adkim=r / aspf=r), "lines up" means shares the same organizational domain. So mail From news.example.com, signed with DKIM d=example.com (or d=news.example.com), aligns fine. With strict alignment (adkim=s / aspf=s), the domains have to match exactly, and a subdomain From with an org-domain signature would not align. Keep relaxed unless you have a specific reason not to; it's what makes subdomain mail work without ceremony.

When to give a subdomain its own record

Publish a record at _dmarc.sub.example.com when that subdomain needs to differ from the rest: a slower rollout (hold news.example.com at quarantine while everything else is at reject), its own reporting address, or different alignment. A subdomain's own record fully overrides sp= and p= for that subdomain only. No record means it keeps inheriting the parent.

The non-existent subdomain trap (np)

Here's the one people miss. sp= governs subdomains that exist. But spoofers love to forge addresses on subdomains that don't exist, like account-security.example.com, precisely because they were historically uncovered. DMARCbis (RFC 9989) added the np= tag for exactly this: it sets the policy for subdomains that don't resolve in DNS at all (an NXDOMAIN). Setting np=reject slams that door shut even while sp= is still relaxed during a rollout.

Running several subdomains: the checklist

• Discover before you enforce. Your DMARC reports (right here in dmarcula) show every subdomain mail is actually flowing from. Tighten sp= only once you've seen the full list, or you'll bounce a sender you forgot about.
• Each sending subdomain needs its own SPF and DKIM. A subdomain isn't covered by the parent's SPF or DKIM automatically; SPF is checked per exact domain, and DKIM is per signing domain. Set both up, aligned, on every subdomain that sends.
• sp= is all-or-nothing. It applies to every subdomain the same way. If nine subdomains can go to reject but one needs none, you can't say that with sp= alone; give the exception its own record.
• Deep subdomains walk up too. a.b.example.com inherits example.com's policy unless b.example.com or a.b.example.com publishes its own.
• Reporting stays consolidated. Subdomains without their own record report into your main rua, so you keep one view. Leave it that way unless a team genuinely needs a separate feed.
• Set sp= and np= before you celebrate reject. A green p=reject on the apex isn't the finish line if subdomains are still wide open.

Keep reading

• The enforcement journey: subdomains are the last mile of reaching p=reject.
• DMARC, SPF & DKIM in plain English: what alignment really means.
• DMARC record generator: build the record, including sp and np.
• Glossary: sp, np, alignment, and the rest.

Not sure which subdomains are sending as you? Open your dashboard, or email support@dmarcula.com and we'll help you read the list.