DMARC subdomain policy explained: the sp tag and why it matters

Most people who set up DMARC focus on one thing: the p tag, which sets the policy for their main domain. That is the right place to start. But there is a second policy tag that decides what happens to email claiming to come from your subdomains, and it is routinely overlooked. It is called sp, short for subdomain policy.

Get it wrong and you can publish a DMARC record that says p=reject, feel protected, and still leave every subdomain of your domain open to spoofing. This post explains how subdomain policy works, why attackers care about it, and how to set it without breaking legitimate mail.

How DMARC policy inheritance works

When a receiving mail server evaluates a message, it looks up the DMARC record on the domain in the visible From address. The rules are set out in RFC 7489, the DMARC specification, and they behave differently depending on whether the sending domain is your organisational domain or a subdomain of it.

• Mail from your main domain (for example [email protected]) is governed by the p tag in the DMARC record at _dmarc.example.co.uk.
• Mail from a subdomain (for example [email protected]) is governed by the sp tag in that same top-level record, unless the subdomain publishes its own DMARC record.

The key point is inheritance. If a subdomain has no DMARC record of its own, receivers fall back to the parent domain's record and apply the sp value. And here is the trap: if you do not specify sp at all, it defaults to the value of p.

That default sounds safe, and often it is. But it means the moment you deliberately set a different policy, or a receiver interprets your record in an unexpected way, subdomain behaviour can diverge from what you intended. Making the tag explicit removes the ambiguity.

Why attackers target subdomains

Domain spoofing does not have to use your exact domain. If your main domain is locked down with p=reject but your subdomains are not, an attacker can send from a subdomain that has never sent legitimate mail and never will.

Common examples look convincing to a recipient:

• [email protected]
• [email protected]
• [email protected]

These are subdomains you probably never created. That does not stop an attacker putting them in a From address. Because the subdomain does not exist in your DNS as a mail sender, it has no SPF or DKIM, so it fails authentication. Whether that failed message is rejected or delivered comes down entirely to your subdomain policy. If sp is effectively none, the spoofed message sails through.

This is the same logic that makes protecting parked and unused domains important. Anything that carries your brand and can appear in a From address needs a policy, whether or not you use it.

The three values sp can take

The subdomain policy tag accepts the same three values as the main policy tag:

• sp=none - monitor only. Failing subdomain mail is still delivered. Useful during rollout, but not protection.
• sp=quarantine - failing subdomain mail is sent to spam or held.
• sp=reject - failing subdomain mail is refused outright.

As with the main policy, why p=none is not protection applies equally to sp. A subdomain policy of none tells the world you are watching, but it blocks nothing.

A worked example

Consider this record on _dmarc.example.co.uk:

v=DMARC1; p=reject; sp=none; rua=mailto:[email protected]

This looks strong at a glance. The main domain is at reject. But sp=none means every subdomain, including ones that do not exist, is unprotected. An attacker sending from [email protected] would fail authentication and still be delivered. The record gives a false sense of security.

Compare it to:

v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]

Now both the main domain and every subdomain without its own record are protected. Spoofed subdomain mail is rejected.

When you might want sp to differ from p

Most organisations should end up with sp matching p at reject. But there are legitimate reasons to set them differently, at least temporarily.

A common one is a large organisation where the main domain is well understood and locked down, but various departments or business units send from subdomains through systems that have not yet been brought into the DMARC programme. In that situation you might run the main domain at p=reject while keeping sp=quarantine or sp=none so you can gather reports on subdomain senders before tightening.

The important discipline is that this is a staging position, not an end state. Leaving sp permanently weaker than p leaves a permanent gap. The route to closing it is the same as the main domain: monitor, identify legitimate senders, authenticate them, then tighten. That is the process described in getting safely to p=reject.

Subdomains with their own DMARC record

If a specific subdomain publishes its own DMARC record, that record takes precedence over the parent's sp tag for that subdomain. This is useful when one subdomain has genuinely different sending behaviour, for example a marketing platform that lives on news.example.co.uk.

You might keep the parent at sp=reject to protect all the subdomains you never use, while publishing a dedicated record on news.example.co.uk that reflects that subdomain's own senders and reporting address. This gives you tight default protection with a controlled exception, rather than weakening the policy for everything.

How to set your subdomain policy safely

• Make sp explicit. Do not rely on the default. State the value you intend, even if it matches p.
• Enumerate your real subdomain senders first. Use aggregate reports to see which subdomains actually send legitimate mail before you tighten. Many organisations are surprised by what they find.
• Tighten in stages. If you have unknown subdomain traffic, move sp from none to quarantine to reject as you gain confidence, exactly as you would for the main domain.
• Publish dedicated records only where needed. A subdomain that sends genuinely distinct mail can have its own record; everything else should inherit a strong parent policy.
• Aim for sp=reject as the end state. Unused subdomains should never be a delivery route for spoofed mail.

For the full breakdown of how sp sits alongside p, adkim, aspf and the rest, see every DMARC tag explained.

The subdomain policy tag is small, easily missed, and quietly decisive. A DMARC record that protects your main domain but leaves sp at none is only doing half the job, and the half it leaves undone is exactly where a careful attacker will aim. Setting sp explicitly, and working it towards reject, closes a gap that most organisations do not even know they have.