Domains that do not send mail
A parked or non-sending domain still needs locking down. Why SPF -all and DMARC reject matter even when you never send email.
Your www subdomain has never sent an email. Neither has that parked domain you registered to protect the brand. So why would they need SPF and DMARC? Because email spoofing happens on someone else's mail server, and if your domain publishes nothing, that server has no way to tell a forgery from the real thing.
The attack needs nothing from you
Forging a From address is trivial: an attacker sends mail from their own server with From: accounts@www.yourbrand.com. Your domain is never contacted. No mailbox, no MX record, no mail server on your side is involved at any point.
When that message arrives, the receiving server asks DNS two questions about the domain in the From address:
- Does it publish an SPF record saying which servers may send for it?
- Does it publish a DMARC policy saying what to do with mail that fails?
If both answers come back empty, the receiver has no grounds to reject the forgery. It gets delivered, wearing your name.
The details
This is why domains that send no mail are the most spoofable, not the least: active mail domains usually get SPF/DKIM/DMARC set up as part of onboarding a mail provider, while www hosts, parked domains and service subdomains are forgotten. Attackers know this and pick the unprotected name under a trusted brand. UK NCSC and M3AAWG both publish guidance specifically on locking down non-sending domains.
The fix: two records that say "nobody speaks for this name"
For a domain with no email, the correct posture is not "no records": it is records that authorise zero senders and tell receivers to reject everything. Set once, never maintained.
SPF: a TXT at the name itself — v=spf1 -all ("no server may ever send as this name").
DMARC: a TXT at _dmarc.<name> — v=DMARC1; p=reject ("reject anything that fails").
The details
There is no rollout risk on a non-mail domain: since no legitimate mail exists, nothing legitimate can be caught by the policy, so you can go straight to p=reject instead of staging through p=none and p=quarantine. Optionally add a Null MX record (MX 0 ., RFC 7505) to declare the domain accepts no inbound mail either, and add rua=mailto:… to the DMARC record if you want reports showing who is attempting to spoof the name.
DMARC inherits down, SPF does not
DMARC has a shortcut: if www.yourbrand.com has no policy of its own, receivers fall back to the policy of the organisational domain, yourbrand.com. Publish p=reject there and every subdomain is covered automatically.
SPF has no such fallback. Each hostname that could plausibly appear in a From address needs its own v=spf1 -all record: the apex always, plus any high-value subdomains.
The details
The parent record's sp= tag controls what subdomains inherit: p=reject; sp=none protects the apex but leaves every subdomain open, which is a common and easy-to-miss gap. If sp= is absent, subdomains inherit p=. Per RFC 7489 the fallback goes to the organisational domain (the registrable name), not each intermediate label.
The lockdown checklist for a non-mail domain
TXT→v=spf1 -all(exactly this, nothing else)TXTat_dmarc→v=DMARC1; p=reject(or rely on the parent domain's reject policy)- Optional:
MX 0 .(Null MX) to decline inbound mail explicitly - Nothing else: no DKIM, no MTA-STS, no senders to list
Exit Tools grades every monitored domain against the right rubric automatically: domains with MX records are held to the full mail standard (SPF senders, DKIM, DMARC, MX redundancy), while domains without email routing are graded on this lockdown posture instead, including DMARC inherited from the parent domain. You can override the auto-detection per domain.