What does the DMARC sp= tag actually do?

The sp= tag sets a DMARC enforcement policy that applies only to subdomains, separately from the p= tag that governs the root domain. It accepts the same three values as p= — none, quarantine, or reject. When sp= is left out of the record, subdomains automatically inherit whatever the p= tag specifies, so most domains never need to set it explicitly.

What happens if I never add an sp= tag to my DMARC record?

Nothing changes for you — subdomains simply inherit the root domain's p= policy. If your root is at p=reject, every subdomain, including ones you have not created yet, is protected the same way. The gap only appears if someone later adds an sp= tag set to a weaker value than p=.

Can an attacker spoof a subdomain that doesn't exist in my DNS?

Yes. RFC 7489 requires receiving mail servers to apply your DMARC subdomain policy even to hostnames that were never provisioned. A subdomain policy of none leaves every possible subdomain of your domain open to spoofing, not just the ones you actively use for mail.

Should a marketing subdomain use a weaker DMARC policy than the main domain?

Only temporarily, while you finish setting up SPF and DKIM for that subdomain. A weaker sp= value should have a fixed end date, not sit indefinitely. Once the subdomain's own authentication passes consistently, tighten sp= to match the root domain's policy or remove it so inheritance takes over.

How do I check my current DMARC subdomain policy?

Run a TXT lookup against _dmarc.yourdomain.com with a tool like dig or an online DNS checker, then read the p= and sp= values in the returned record. If sp= is absent, your subdomains already match the root policy. If it is present and weaker than p=, that is the gap to close.

Does EmailControl monitor DMARC record changes automatically?

Yes. EmailControl checks your domain's SPF, DKIM, and DMARC records on a schedule — weekly on the free plan, daily or hourly on paid plans — and emails you when the DMARC record changes, so a weakened or added sp= tag gets caught instead of sitting unnoticed.

DMARC Subdomain Policy: How sp= Overrides Your Main Record

Your root domain can sit at p=reject while every subdomain underneath it stays wide open.

Your DMARC record enforces p=reject on the root domain, so spoofed mail from yourdomain.com bounces cleanly. Then a phishing email arrives from noreply.mail.yourdomain.com, passes right through, and lands in a customer's inbox with your logo on it. The root domain was never touched — the subdomain was the opening. DMARC is a DNS record that tells receiving mail servers what to do when a message claiming to be from your domain fails SPF or DKIM: do nothing, quarantine it, or reject it outright. What most operators miss is that a second tag, sp=, controls whether subdomains follow that same rule or a weaker one of their own.

What Is a DMARC Subdomain Policy, and Why Does It Exist?

The subdomain policy tag, written sp=, sets an enforcement level that applies to every subdomain of your organizational domain, separate from the p= tag that governs the root. It exists because companies often run mail through subdomains they did not think of as "the domain" — a help desk at support.yourdomain.com, a marketing platform sending from mail.yourdomain.com, a job board at careers.yourdomain.com. Each of those is a distinct hostname that an attacker can spoof independently of your main domain.

How the sp= Tag Interacts With Your Main p= Policy

If your DMARC record has no sp= tag at all, subdomains inherit whatever p= says. A record of v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com protects the root and every subdomain identically, with no extra tag required. The gap opens when someone adds sp=none on purpose — usually to stop a legacy subdomain's unauthenticated mail from bouncing — and never revisits it. From that point on, the root stays locked while subdomains accept spoofed mail with no enforcement at all.

Record	Root domain effect	Subdomain effect
p=reject (no sp=)	Reject on failure	Reject — inherits p=
p=reject; sp=reject	Reject on failure	Reject — explicit, same as inherited
p=reject; sp=none	Reject on failure	No action — spoofable
p=reject; sp=quarantine	Reject on failure	Sent to spam, not blocked

Why Would You Set a Different Policy for Subdomains?

There is one legitimate reason: you are rolling out authentication gradually. A newly acquired brand or an unaudited subdomain that has never had SPF or DKIM set up will fail every check, so setting it to sp=quarantine while you fix the underlying records avoids losing that mail outright during the transition. That is a temporary, deliberate choice with an end date — not a permanent setting copied from a tutorial and forgotten. If you cannot name the date you plan to tighten it back to match the root policy, it is not a rollout plan, it is a gap.

How Do You Check and Fix Your Current Subdomain Policy?

You can read your live policy in under a minute with a DNS lookup. Here is the sequence:

Query the TXT record at _dmarc.yourdomain.com using dig txt _dmarc.yourdomain.com or an online DNS lookup tool.
Find the p= tag and note its value — none, quarantine, or reject.
Look for an sp= tag in the same record. If it is missing, subdomains already match the root policy and you are done.
If sp= is present and weaker than p=, decide whether that gap is intentional and time-boxed, or leftover from an old fix.
To close the gap, republish the record with sp= removed, or set it equal to p=, at your DNS provider.
Re-query the record after the change to confirm the new value has propagated before you consider it fixed.

What About Subdomains That Don't Send Mail at All?

DMARC's subdomain policy applies even to subdomains that do not exist in your DNS zone at all. The DMARC specification, RFC 7489, defines this as "non-existent subdomain" handling: a receiving server checks the policy for nonexistent.yourdomain.com the same way it checks a real one, because attackers routinely invent subdomains that were never provisioned. This is exactly why leaving sp= at none is riskier than it looks — you are not just exposing the subdomains you know about, you are exposing every subdomain an attacker can invent.

Checking this by hand works the first time. It stops working the moment your DNS has more than one domain in it, or the record changes without anyone on the team noticing — a DNS provider migration, a new marketing tool that asks for an SPF include and gets a policy edit along with it, a junior admin copying a record from a blog post that includes sp=none as an example. EmailControl's FAQ page walks through how SPF, DKIM, and DMARC work together if you want the fuller picture before you touch a live record.

The honest objection here is "our root domain is already at p=reject, isn't that enough?" Most of the time, yes — if no one has ever added an sp= tag, you already have full subdomain coverage for free, inherited automatically. The risk is that you cannot see a silent edit to that record without checking it, and DNS changes rarely come with a notification. A record that read p=reject with no sp= tag last quarter can read p=reject; sp=none today because someone needed a quick fix for a broken subdomain and never followed up.

EmailControl checks your domain's SPF, DKIM, and DMARC records on a schedule and emails you the moment the DMARC record itself changes, so a new sp=none tag does not sit unnoticed for months. Start free monitoring and add your domain — it takes about a minute, and the first check runs immediately so you see your current policy today instead of guessing.

Does sp= Replace the Need for SPF and DKIM on the Subdomain?

No, and this is where the fix gets misapplied. The sp= tag only controls what a receiving server does after authentication has already failed — reject, quarantine, or do nothing. It does not make a subdomain pass authentication in the first place. A subdomain that sends real mail, such as invoices.yourdomain.com through a billing platform or updates.yourdomain.com through a status-page tool, still needs its own valid SPF include or a DKIM selector configured for that exact sending service. Tightening sp= to reject without first confirming the subdomain's own SPF and DKIM pass will start bouncing your own legitimate mail, not just an attacker's.

This is the scenario that usually explains why an sp=none tag got added in the first place: a team turned on strict enforcement, a real subdomain failed authentication because its SPF record was never updated for a new sending tool, and the fastest fix under pressure was to loosen the subdomain policy rather than fix the underlying SPF include. The policy tag treated a symptom. The SPF record was the actual cause, and it was still broken after the "fix" shipped.