InboxGrade

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.

Impact — Medium impact

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

  1. The record was generated by a wizard or template that only prompts for p= and rua=, omitting sp= entirely.
  2. An operator deliberately removed sp= to simplify the record, not realizing receivers fall back to p= rather than treating subdomains as unprotected.
  3. The domain is still in a p=none monitoring phase and the admin never revisited the record to lock down subdomains separately.
  4. A copy-paste from a vendor onboarding doc that targets a flat domain with no subdomain mail flow.
  5. Multiple TXT strings at _dmarc were merged or truncated by the DNS provider's UI, dropping the sp= 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 →

Related errors