dmarc.subdomain_policy Reviewed July 2026

Quick fix

Inventory subdomains that legitimately send email and configure aligned SPF or DKIM for them.

What this finding means

SecuTest compares the explicit `sp` policy with the root `p` policy. If `sp` is omitted, subdomains inherit `p`. It warns when an enforcing root policy is weakened to `sp=none`.

Interpretation boundary Use the exact evidence in your report. SecuTest reports externally observable conditions; it does not assume ownership, exploitability, compromise, or business intent when those cannot be proven remotely.

Associated attack or threat scenario

Threat type Subdomain email spoofing and phishing

How the attack or failure scenario works

An attacker forges a visible From address at a subdomain such as `billing.example.com`. A weak subdomain policy may request no enforcement even though the parent domain rejects failures. This can exploit user trust in the organization's namespace.

Conditions and limitations

  • The attacker uses a subdomain of the protected organizational domain.
  • The subdomain does not publish a more specific DMARC record that overrides inheritance.
  • The effective `sp` policy is weaker and the message fails aligned SPF and DKIM.

Why it matters

Security and business impact A weaker `sp` policy can leave unused or forgotten subdomains available for spoofing even when the organizational domain enforces DMARC.

Step-by-step fix

Where to make the change

  • The authoritative DNS zone for the registrable domain.
  • The outbound or inbound mail platform when sender authorization, signing, or routing is involved.
  • The DMARC reporting mailbox or reporting service when aggregate reports are required.

Remediation procedure

  1. Inventory subdomains that legitimately send email and configure aligned SPF or DKIM for them.
  2. Use inheritance by omitting `sp` when the root policy should apply uniformly.
  3. Otherwise set `sp=quarantine` or `sp=reject` explicitly.
  4. Create documented exceptions only at specific subdomains that genuinely require a separate migration.

Commands and configuration examples

Replace example values with the hostname, selector, IP address, port, provider, or policy values shown in your SecuTest evidence. Review every example before production use.

Uniform enforcement
v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc-reports@example.com

Inherited enforcement
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@example.com

Verify the fix

  1. Query `_dmarc.example.com` and any subdomain-specific `_dmarc` records.
  2. Send test messages from authorized subdomain senders and confirm DMARC alignment.
  3. Test an unauthorized subdomain sender and confirm enforcement.
  4. Review aggregate reports grouped by header From domain.
Confirm the externally visible result

After DNS, CDN, certificate, mail, or application propagation completes, run a fresh SecuTest scan and compare the new evidence with the original finding.

Re-scan your domain

Common mistakes

  • Setting `sp=none` to accommodate one sender instead of fixing that sender.
  • Forgetting that a subdomain-specific DMARC record overrides parent inheritance.
  • Assuming unused subdomains cannot be abused in a visible From address.

Authoritative references