Playbook: Set Subdomain DMARC (`sp=reject`) Without Breaking Production

An alert fires from your SIEM. A high-priority email from 'urgent-billing@finance.yourcompany.com' to your CFO was just blocked. The sender is legitimate. The mail server is authorized. So why did it get rejected? Because three weeks ago, you successfully moved yourcompany.com to `p=reject`, and its DMARC policy just inherited down and nuked a legacy accounting service you never knew existed.

This scenario is not hypothetical. It’s the predictable outcome of a DMARC project that ignores subdomains. The `p` tag in your DMARC record is a sledgehammer, but effective subdomain email security requires a scalpel. That scalpel is the `sp` tag.

This playbook details the step-by-step process for moving your subdomains to a full `reject` policy *after* your organizational domain is already locked down. It's about surgically applying policy, not swinging blindly.

The Inheritance Trap: How a Parent Policy Creates Blind Spots

DMARC policy, as defined in RFC 7489, is hierarchical by default. When an inbound mail server receives an email, it looks for a DMARC record at the exact `header.from` domain. If it doesn't find one—say, for `notifications.corp.com`—it travels up to the organizational domain, `corp.com`, and applies its policy instead.

This inheritance is incredibly useful when you're starting out. A single `p=none` record on your apex domain instantly starts gathering aggregate reports for your entire email ecosystem. But when you escalate to `p=quarantine` or `p=reject`, that inheritance becomes a liability.

Every forgotten dev server, every shadow IT SaaS trial, every ancient CRM integration sending from a unique subdomain is suddenly subject to a policy it was never prepared for. Their SPF and DKIM configurations, if they even exist, are almost certainly not aligned with the parent domain. The result is total delivery failure. The business blames you, and you're forced to roll back your hard-won security gains.

Deploying the `sp` Tag as a Scaffolding Policy

The `sp` (Subdomain Policy) tag is your primary tool for decoupling your subdomain strategy from your parent domain's policy. It explicitly tells receivers what policy to apply to subdomains of the organizational domain if those subdomains don't have their own DMARC record.

Creating Breathing Room with `sp=none`

If your parent domain is already at `p=reject`, the very first thing you should do is modify the record to include `sp=none`. This is non-negotiable.

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc-rua@yourcompany.com; fo=1;

This record achieves two critical goals. It maintains the strict `reject` policy for your main brand domain (`yourcompany.com`), protecting it from direct spoofing. Simultaneously, it places all subdomains into a non-enforced, monitoring-only mode. Mail from `whatever.yourcompany.com` will be delivered, but it will still be evaluated against DMARC and show up in your aggregate (RUA) reports. This is your safety net. It stops the bleeding and buys you the time to conduct a proper audit.

Triaging RUA Reports for Unaligned Subdomain Senders

With `sp=none` active, your RUA reports become the source of truth for your subdomain audit. You are no longer flying blind. The goal is to systematically identify every legitimate service sending mail from a subdomain and determine why it's failing DMARC.

Reading the Signals in the Noise

Raw RUA XML is dense, but you're hunting for specific patterns. You need to parse these reports and filter for entries where the `header_from` domain is a subdomain of your organizational domain. For each of these, inspect the `policy_evaluated` section. Is SPF failing? Is DKIM failing? More importantly, is the *alignment* failing?

Remember, DMARC requires authentication *and* alignment. An email can have a valid SPF pass but still fail DMARC if the return-path domain doesn't align with the `header.from` domain. This is common with third-party senders. Your job is to distinguish between legitimate but misconfigured services and outright spoofing attempts.

Legitimate Senders vs. Illegitimate Spoofing

If you see IPs belonging to Salesforce sending mail from `updates.yourcompany.com`, that's a legitimate sender that needs to be configured correctly. You'll need to work with the business unit that owns that service to implement proper DKIM signing for that subdomain. But if you see an unknown IP from a residential ISP sending mail from `ceo.yourcompany.com`, that's an attack. The presence of these proves the need for an eventual `sp=reject` policy.

The Incremental Rollout: Moving Subdomains to Enforcement

Once your audit has identified all legitimate subdomain senders, you can begin the process of bringing them into compliance and methodically applying enforcement. This is not a big-bang cutover.

Remediate and Isolate with Subdomain-Specific Records

For each legitimate service—like our `updates.yourcompany.com` example—you must establish DMARC alignment. This usually means configuring DKIM within that third-party platform so it signs with a key associated with `updates.yourcompany.com`.

As soon as a subdomain is fully compliant (all its legitimate mail passes DMARC), give it its *own* DMARC record. Create a TXT record at `_dmarc.updates.yourcompany.com` with the value `v=DMARC1; p=reject;`. This does two things: it immediately protects that specific subdomain, and it removes it from the control of the parent domain's `sp` tag. You are surgically hardening your infrastructure, one piece at a time.

dig TXT _dmarc.transactional.mycorp.com

; <<>> DiG 9.16.1-Ubuntu <<>> TXT _dmarc.transactional.mycorp.com
;; ANSWER SECTION:
_dmarc.transactional.mycorp.com. 300 IN TXT "v=DMARC1; p=reject;"

Flipping the Master Switch to `sp=reject`

Continue this process for every known, legitimate subdomain. When your RUA reports show that all remaining non-compliant subdomain traffic is junk or spoofing, you're ready for the final step. Change the parent domain's DMARC record one last time.

Update the record at `_dmarc.yourcompany.com` to `v=DMARC1; p=reject; sp=reject; rua=...`. Now, any email from any unconfigured or newly created subdomain will be subject to the `reject` policy by default. You have effectively closed the door on subdomain spoofing for your entire domain namespace, present and future.

Postmortem: How a Wildcard DNS Record Broke Our DMARC

Even with a perfect `sp` rollout, DNS itself can throw you a curveball. We once saw a rash of DMARC `temperror` results for a client's subdomains, which threatened to undermine their `sp=reject` policy. `temperror` often causes receivers to accept mail they would otherwise block. The root cause wasn't in the DMARC record at all.

An admin had set up a wildcard MX record (`*.yourcompany.com`) pointing to an old, decommissioned mail server. When a receiving MTA got an email from a non-existent subdomain (a common spammer tactic), its DMARC check triggered an SPF check. The SPF check, in turn, tried to resolve the MX record for this bogus subdomain. The wildcard record responded, but the server it pointed to was unreachable. This led to a DNS lookup timeout.

Many resolvers interpret this timeout as a temporary failure, resulting in an SPF `temperror`. This `temperror` then bubbles up to the DMARC evaluation, which also returns `temperror`. It’s a good reminder that DMARC doesn't exist in a vacuum. It relies on a healthy and precise DNS configuration. Wildcard records, especially for MX or A records, can have dangerous and unforeseen consequences for your email authentication.

The takeaway

Treating subdomains as a secondary concern is the most common failure mode in DMARC projects. Using `sp=none` is the critical intermediate step that turns a high-risk cutover into a controlled audit. You gain visibility into your entire attack surface without breaking legitimate business processes. From there, you can use subdomain-specific DMARC records as instruments to harden each service before finally setting `sp=reject` as a default-deny policy for your domain's future.

This is tedious work. Parsing thousands of XML reports to find that one legacy service is a grind, and tools that can aggregate and attribute this traffic, like MailSleuth.AI, are essential for completing the audit in a reasonable timeframe. But the alternative is worse: explaining to your CISO why a BEC attack succeeded using a subdomain you never knew existed.