If your company sends order confirmations from mail.example.com and newsletters from marketing.example.com, those addresses are subdomains of your main domain. When you turn on DMARC to protect your main domain from email spoofing, your subdomains are usually protected too, because they follow the main domain's policy automatically. But about 1 in 13 domains with DMARC fully turned on in DMARCeye's Q1 2026 dataset have a small misconfiguration that locks the main domain while leaving subdomains exposed.
This article unpacks the subdomain-policy finding from DMARCeye's Q1 2026 industry report. The full report and methodology are below.
A DMARC record is a small line of text in your DNS that tells email receivers what to do with messages claiming to be from your domain. The main setting is the p= tag, which sets the policy for your main domain. There are three policy levels:
p=none means receivers monitor and report, but deliver everything (no protection yet).p=quarantine means failed messages are sent to spam.p=reject means failed messages are blocked entirely.The sp= tag is the same idea, applied to subdomains. It takes the same three values. If you don't set sp= at all, your subdomains follow whatever p= is. So if your main domain is at p=reject and you don't set sp=, every subdomain (mail.example.com, support.example.com, anything else you have) is also at p=reject. That is the spec working as intended (per RFC 7489 ยง6.3).
You would set sp= explicitly only if you want subdomains treated differently from the main domain. The most common reasons are: a subdomain sends mail through a different vendor than the main domain, or you want to enforce on subdomains faster (or slower) than the main domain.
Among the several thousand domains in the DMARCeye Q1 2026 monitored sample, the sp= distribution depends heavily on the main p= policy:
Three patterns stand out:
sp= at all. 86.67% of domains at p=none, 78.59% at p=quarantine, and 65.15% at p=reject leave sp= out of their record entirely. As we covered above, that is the default behavior, and subdomains automatically follow the main domain's policy.p=reject domains set sp=none, and another 0.94% set sp=quarantine. Combined, that is 7.56% of fully-enforced domains with strict protection on the main domain but loose or no protection on subdomains.sp= to stage protection on subdomains first. Only 0.42% of p=none domains have set sp=reject. This is a clever pattern (keep the main domain in monitor-only mode while you collect data, but immediately block fake messages on subdomains) and it is underused.There are two situations where setting sp= explicitly is the right move.
Your subdomains use different email providers. If marketing.example.com sends through one tool (your newsletter platform, for example) and your main domain sends through another (your transactional email provider), each one has different authentication settings. You might want a stricter DMARC policy on one than the other, especially while you are rolling out a new provider. Setting sp= lets you give subdomains their own policy without touching the main domain.
You want subdomains protected before the main domain. When a domain sends a lot of mail (or is a high-risk target for spoofing), it can be tempting to wait on full enforcement until you have watched the reports for weeks. In this case, it could make sense to keep the main domain at p=none (monitor only) while setting sp=reject to fully protect subdomains right away. Subdomains usually have fewer legitimate senders and clearer setups, so they are often safer to enforce on first. The Q1 data shows 0.42% of p=none domains use this pattern.
The mistake to watch for is the opposite: strict policy on the main domain (p=reject) but loose or none on subdomains (sp=none or sp=quarantine). The reason is usually one of these:
sp= to stop the failures instead of fixing the actual authentication problem on that subdomain.sp=none during initial rollout to avoid surprises and never came back to tighten it.sp= to match p=, and somebody later weakened it manually for whatever reason.In all cases, the result is the same. The main domain is fully protected, but every subdomain accepts spoofed messages with no enforcement. Anyone scanning your DMARC record sees the gap immediately.
7.56% of fully-enforced domains in our Q1 dataset have this configuration. If you are at full enforcement, this is the first thing to check on your DMARC record.
Here are three short questions to work through:
p=reject over time. Leaving sp= out of your record is the default, and it works for most companies. Subdomains follow the main policy automatically.sp= so each one can have its own policy.sp= explicitly. If you want subdomains looser than the main domain, you almost never want that, so set sp= to match p= instead, or leave it out.If your DNS already has sp= declared, double-check that it is not weaker than p=. The p=reject with sp=none combination is the misconfiguration to watch for. If you do not have DMARC monitoring set up yet, DMARCeye's free plan covers one domain and shows you exactly what your record looks like, including your sp= value if you have set one. To check what your domain has right now:
DMARCbis is the upcoming update to the DMARC standard, expected to publish in 2026. It does not change anything about how sp= works. When you do not set it, subdomains still inherit the main policy.
It does add a new tag called np=, which controls policy for subdomains that do not exist at all. Today, if a spammer sends mail claiming to be from madeup.example.com (a subdomain you never created), receivers fall back to your main domain's policy. With np=, you will be able to apply a stricter policy specifically to those fake subdomains. If you want stronger subdomain coverage once DMARCbis is final, this is the tag to watch.
For most domains, leaving sp= out of the record is the right move. The default behavior protects subdomains automatically.
The exceptions are real but specific: when subdomains use different email providers than the main domain, or when you want to protect subdomains faster than the main domain. In both cases, set sp= deliberately and set it correctly.
If your DMARC record is at p=reject and your sp= is anything weaker, this is the misconfiguration. Fix it before fixing anything else. DMARCeye tracks sp= settings across all your monitored domains, with a free plan covering one.