All posts

DMARC for subdomains and domains that do not send email

The sp and np tags, and why a domain that sends no mail still needs DMARC. How to lock down subdomains and parked domains so nobody can spoof them.

A domain does not have to send email to be spoofed. Scammers happily forge the address of a parked domain you never use, or invent a subdomain like billing.yourbusiness.com that you never created. The fix is the same in both cases: publish a DMARC record that says “refuse everything”, because a domain nobody sends legitimate mail from has nothing to lose by rejecting all of it. Here is how the sp and np tags work, and what to publish on a domain that sends nothing at all.

Your main policy does not automatically cover subdomains

Your DMARC record sits on your organisational domain and carries a p= tag setting the policy there. What is easy to miss is that this policy does not, on its own, dictate what happens for every subdomain in the way you might expect.

DMARC gives you a separate lever for that: the sp tag, short for subdomain policy. If you set sp, it defines the policy for subdomains that do not have their own DMARC record. If you leave sp out, subdomains inherit your main p value. Setting it explicitly removes all doubt.

So a record like v=DMARC1; p=reject; sp=reject; rua=mailto:reports@yourbusiness.com says two things clearly: refuse forgeries of the main domain, and refuse forgeries of any subdomain that has not published its own policy. If a particular subdomain genuinely sends mail through a different system, give it its own record instead of relying on the inherited policy, as we explain in the DNS tree walk in DMARCbis.

The gap np closes: subdomains that do not exist

There is a subtler hole. What about a subdomain that has no DNS records at all, one you never created? A scammer can put billing.yourbusiness.com in the From line even though that name exists nowhere in your DNS. Historically the policy applied to those invented names was not always what people expected.

DMARCbis, the 2026 update to the standard, adds the np tag to close this precisely. np sets the policy for non-existent subdomains, meaning names that resolve to nothing. With np=reject, mail claiming to come from a subdomain that does not exist is refused outright. Since you never send from names you have not created, there is no downside to rejecting all of it.

A modern, locked-down record therefore reads: v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:reports@yourbusiness.com. That covers the main domain, real subdomains without their own record, and invented subdomains, all in one line. The np tag arrived with DMARCbis, so it is worth confirming your record includes it, which we cover alongside the other changes in what RFC 9989 changes.

The domain that sends no email at all

Plenty of businesses own domains they do not send from: an old brand, a redirect domain, a name bought to protect a trademark, a country-code version, such as .co.uk or .de, alongside the .com they actually use. It is tempting to ignore these, because there is no mail to protect.

That is the mistake. A domain with no protection is an open invitation. A scammer can forge its address freely, and to a recipient the message looks like it came from a name your business owns. The absence of legitimate mail actually makes this easier to lock down, not harder, because you can refuse everything without any risk of blocking your own messages.

For a domain that sends nothing, publish three things:

  • A DMARC record that rejects everything: v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:reports@yourbusiness.com. You still want the rua reporting address so you can see who is trying to forge it.
  • An SPF record that authorizes no senders: v=spf1 -all. This says plainly that no server is allowed to send mail for this domain, so every attempt fails SPF.
  • An empty DKIM stance. Since the domain signs nothing, you are not publishing signing keys, and the combination of a hard SPF fail and no aligned signature means nothing can pass DMARC. There is nothing legitimate to sign, so there is nothing to break.

Together these turn a parked domain from a free spoofing target into a dead end. Any forgery fails every check and is refused wherever your policy is honored.

Why this is worth doing

The value is quiet but real. A forged message from a domain you own, even one you never send from, still damages you when a customer or partner receives it and believes it. Locking down the domains you are not using costs a few DNS records and removes a whole category of impersonation you would otherwise never see coming, precisely because you are not watching a domain you do not send from.

It also tidies your reporting. With rua set on a parked domain, you get aggregate reports showing exactly who is attempting to forge it, which is often an early signal that someone is targeting your brand.

A checklist

  • On your sending domain, set p, sp and np deliberately rather than leaving them to inheritance.
  • Give any subdomain that sends through its own system a dedicated DMARC record.
  • On every domain you own but do not send from, publish p=reject, sp=reject, np=reject, an SPF record of v=spf1 -all, and no DKIM keys.
  • Keep a reporting address on all of them so you can see the forgery attempts.

If you are not sure what your domains publish today, or which of them are currently exposed, run the free DMARC checker against each name. It analyzes the live records and tells you in plain terms whether a given domain could be spoofed right now. Protecting the domains you do use is the headline job. Locking the ones you do not is the easy win most businesses forget.