auth.dmarc.sp_none

DMARC Subdomain Policy Is 'none'

What we check

We read the sp= tag of the DMARC record. It sets the policy receivers apply to mail from subdomains of the organizational domain (mail.example.com, newsletter.example.com, …). When the tag is absent, subdomains inherit p=. This finding means the record carries an explicit sp=none while p= is quarantine or reject.

What this finding means

The organizational domain is enforced, but every subdomain is not. RFC 7489 §6.3 lets sp= override p= for subdomains, and none requests no action against failing mail — receivers deliver it and merely report. A forged From: anything@support.example.com therefore lands in the inbox even though @example.com itself would be rejected.

sp=none is sometimes left over from a staged rollout: subdomains were monitored first and the tag was never tightened.

Why it matters

• The enforcement has a hole the size of your subdomain space. Attackers do not need @example.com; any label under it will do, and receivers treat it as legitimately unprotected.
• Subdomains that never send mail are the easiest to spoof. A non-sending subdomain has no SPF or DKIM to align with, so every message fails DMARC — and sp=none says to deliver it anyway.
• Reports already cover subdomains. Aggregate reports under p=reject include subdomain traffic, so there is rarely a reason to keep subdomains in monitoring once the apex is enforced.

How to fix

1. Confirm which subdomains send mail using the aggregate reports (rua=) and make sure each aligns via SPF or DKIM.

2. Remove the sp= tag so subdomains inherit the organizational policy:

   copy

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

   or set it explicitly to an enforcing value:

   copy

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

3. Re-scan. The finding clears once sp= is absent or enforcing.