DMARC record missing sp= tag (subdomain policy)
The DMARC record at the organizational domain omits the `sp=` tag, so subdomains fall back to the `p=` policy instead of a dedicated subdomain policy.
When sp= is missing, every subdomain under the organizational domain inherits the main p= value. If p=none, attackers can spoof invoices.example.com, hr.example.com, or any made-up subdomain with no DMARC enforcement at receivers, and the attempts will not surface in aggregate reports as rejections. Even at p=reject, you lose the ability to enforce a stricter stance on unused subdomains while keeping a lenient policy on the main domain during rollout.
What causes it
- The record was generated by a wizard or template that only prompts for
p=andrua=, omittingsp=entirely. - An operator deliberately removed
sp=to simplify the record, not realizing receivers fall back top=rather than treating subdomains as unprotected. - The domain is still in a
p=nonemonitoring phase and the admin never revisited the record to lock down subdomains separately. - A copy-paste from a vendor onboarding doc that targets a flat domain with no subdomain mail flow.
- Multiple TXT strings at
_dmarcwere merged or truncated by the DNS provider's UI, dropping thesp=tag.
How to fix it
Decide the subdomain policy independently of the parent
If no subdomains send mail, set sp=reject immediately — this is safe even while the parent sits at p=none during rollout. If subdomains send mail through separate ESPs, align SPF/DKIM for each sending subdomain first, then set sp=quarantine or sp=reject.
Publish an updated DMARC record with sp= set explicitly
Edit the TXT record at _dmarc.example.com and add an explicit sp= tag. Keep the record on a single logical TXT string and verify the full value after your DNS provider saves it.
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; sp=reject; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1; adkim=s; aspf=s" Verify the published record and subdomain lookup behavior
Confirm the record resolves and that a receiver will apply sp= by querying both the organizational domain and a non-existent subdomain. Receivers walk up to the organizational domain's _dmarc and use sp= for the subdomain.
dig +short TXT _dmarc.example.com
dig +short TXT _dmarc.anything.example.com Watch aggregate reports before tightening the parent policy
Leave the record in place for 1-2 reporting cycles and review rua XML for unexpected sources under subdomains. Only move the parent p= to quarantine or reject once subdomain sources are either authenticated or confirmed illegitimate.
Fixed it? Run a fresh test to confirm.
Test my inbox →