A null SPF record is the first line of defence for domains that never send email. Most organisations own more domains than they use: parked names, misspellings bought to stop typosquatters, brands that were retired years ago, and campaign domains that outlived the campaign. Because nobody reads their mail logs, they are the easiest names for an attacker to forge. This guide shows us how to lock them down with SPF, DMARC, a null MX, and a tidy DNS zone.
Why attackers spoof domains you do not use
A phishing message needs a sender address that looks trustworthy. A domain that closely resembles a real brand, or that is a real brand you retired, does that job. The attacker does not need access to your servers. In the SMTP protocol the sender address is just text, and anyone can write your domain into it. What stops this is whether the receiving server finds your authentication records and believes them.
A domain with no records at all gives receivers nothing to check. Depending on the mailbox provider, that can mean the forged message is delivered with no warning. A domain with no live users also means nobody notices the abuse: there is no support inbox, no complaint, no spike in a dashboard. The domain is quietly lent out to whoever wants it.
| Domain type | Why it gets targeted | Typical gap |
|---|---|---|
| Parked domain | Looks official and has no mail system to flag abuse | No SPF, no DMARC |
| Defensive registration (other TLDs) | Same name under another extension; recipients rarely check the ending | Bought and forgotten |
| Old brand or merged company | Past customers and partners still trust it | Records left from the old mail host |
| Typo or lookalike domain | One letter off; hard to spot on a phone | Often unregistered, or registered but unconfigured |
| Retired campaign domain | Was used in links and emails that still sit in inboxes | DNS pointing at a vendor that has closed the account |
This is general information about DNS and email authentication, not a guarantee against every kind of fraud. Records protect the exact names you publish them on. They do not stop someone from registering a lookalike name that you do not own, which is why the inventory step below matters.
The null SPF record
SPF (Sender Policy Framework, RFC 7208) lets a domain list which servers may send mail using that domain in the envelope sender. A null SPF record publishes an empty list and ends it with a hard fail. The value is short.
example-parked.test. 3600 IN TXT "v=spf1 -all"Read it left to right: v=spf1 declares the version, and -all matches every sender and returns a fail. There are no ip4, include or a mechanisms, so nothing is allowed. Two details are worth knowing.
- Publish exactly one SPF record per name. Two TXT records that both begin with v=spf1 cause a permanent error. If an old record exists, replace it rather than adding a second one.
- SPF is checked on two identities. Receivers evaluate the domain in the envelope sender (MAIL FROM) and, for some checks, the HELO name. The visible From header is not an SPF identity, which is why DMARC is needed as well.
- SPF does not inherit to subdomains. A record on the apex covers the apex only. Names such as mail.example-parked.test need their own record, or a wildcard (see the next point).
- Wildcards can help. A record at the name *.example-parked.test with the same value covers subdomains that have no records of their own. Wildcards only answer for names that do not already exist in the zone, so test with a lookup tool after publishing.
If you want a refresher on what each SPF mechanism does, our guide to authenticating a sending domain covers the three standards together, and our SPF lookup-limit guidance explains why a record this small never runs into the 10-lookup limit.
DMARC p=reject with rua reporting
DMARC (RFC 7489) tells receivers what to do when a message claiming to be from your domain fails SPF and DKIM alignment, and where to send reports. For a sending domain we advise a gradual rollout, because a strict policy can block your own legitimate mail if a source was forgotten. For a domain that sends nothing, there is no such risk. Every message is forged, so we go straight to reject.
_dmarc.example-parked.test. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@reports.example.net"| Tag | Value | Purpose |
|---|---|---|
| v | DMARC1 | Version; must come first |
| p | reject | Policy for the domain itself |
| sp | reject | Policy for subdomains; if left out, subdomains follow p |
| adkim and aspf | s | Strict alignment; harmless here and states intent clearly |
| rua | mailto: address | Where aggregate reports are sent |
The rua tag is what turns a lock into a lock with a camera. Large mailbox providers send daily aggregate reports that list which IP addresses tried to send mail for your domain and how many messages they sent. On a non-sending domain these reports should show nothing but forgery, so a quiet report is good news and a report with a passing result is a flag that something is configured wrongly or an old system still uses the name.
Reports to a different domain: If the rua address is on another domain, the reporting domain must publish an authorisation record at the name example-parked.test._report._dmarc.reports.example.net with the value v=DMARC1. Without it, many receivers will not send the reports. RFC 7489 describes this check.
Reading those reports is covered in how to read DMARC aggregate reports, and the meaning of strict and relaxed alignment is explained in our DMARC alignment guide. For non-sending domains the details barely matter, because nothing can align.
Null MX: telling the world the domain receives nothing
SPF and DMARC cover mail that claims to come from your domain. A null MX covers mail addressed to it. When a sender looks up a domain with no MX record, the rules in RFC 5321 let it fall back to the address records of the name and try to deliver there. For a parked domain that points at a web server, that can mean connection attempts to a machine that was never meant to take mail, delays, and confusing bounce messages.
RFC 7505 defines the null MX to say plainly that the domain does not accept email. It is a single MX record with preference 0 and a root dot as target.
example-parked.test. 3600 IN MX 0 .Sending servers that understand it stop at once and report a permanent failure instead of retrying for days. Two notes: publish only one MX record when you use the null form, and do not add it to a domain that should actually receive mail, such as one whose address you still print on letterheads or give to customers. Check which addresses people still use before you publish. If a domain forwards to your main mailbox, it is a receiving domain and belongs in a different category in your inventory.
Optional: a revoked DKIM wildcard
DKIM (RFC 6376) signs messages with a key published in DNS under a selector name. A DKIM record with an empty p= tag is defined as a revoked key. Some teams publish one at the wildcard name *._domainkey so that every selector an attacker tries resolves to a revoked key instead of to nothing.
*._domainkey.example-parked.test. 3600 IN TXT "v=DKIM1; p="We treat this as a belt-and-braces extra. A forged message cannot pass DMARC without an aligned SPF or DKIM pass, and a null SPF record already blocks the SPF side. With no key published, DKIM already cannot pass, so the wildcard adds clarity more than protection. It also behaves differently across DNS providers and lookup tools. If you use it, publish it, query a few random selector names, and confirm the answers before you roll it out to many domains. If you cannot verify it, skip it. The three core records do the real work. For legitimate keys, plan regular rotation.
Dangling DNS and subdomain takeover
Email records are only part of a domain posture. A common web-side risk is the dangling record: a DNS entry that still points at something you no longer own. Picture a CNAME for promo.example-old.test pointing to a hostname at a hosting or marketing vendor. The campaign ends, the vendor account is closed, and the DNS entry stays. If the vendor lets anyone claim that hostname again, a stranger can now publish a page that appears under your domain.
The consequences go beyond email. A page on a trusted subdomain is ideal for credential phishing, can set cookies that your main site reads, and can look legitimate in a security tool because the domain is yours. Email-related variants exist too: MX or SPF include records that name a mail provider you stopped using can let a new tenant of that provider send as you.
| Record type | Dangling when | What to do |
|---|---|---|
| CNAME | Target hostname belongs to a vendor service you cancelled | Delete the record, or re-claim the target before anything else |
| A or AAAA | Address was released back to a cloud pool | Delete the record or point it at a controlled address |
| MX | Names a mail host you no longer use | Replace with a null MX or remove |
| NS (delegation) | Subdomain delegated to a DNS service whose zone is gone | Remove the delegation or recreate the zone |
| SPF include | Includes a vendor you stopped using | Remove the include; see the multi-vendor guide |
The rule is simple: when you end a service, delete the DNS record first or on the same day. When you audit, resolve every CNAME and every delegation and check that the target still answers and still belongs to you. Our multi-vendor domain management guide covers the same discipline for email vendors.
Build and keep an inventory
You cannot protect a domain you have forgotten. The inventory is a simple table, kept in a spreadsheet or a configuration repository, and it does more good than any tool. Gather the list from every registrar account, from your DNS providers, from certificates, from old invoices and from mail logs, then record the following for each name.
| Field | Why it matters |
|---|---|
| Domain and registrar | Where to log in, and who holds the account |
| Purpose and owner | A named person who decides whether it stays |
| Class: sending, receiving-only, non-sending | Decides which records it gets |
| Expiry and auto-renew status | A lapsed domain can be bought by anyone and inherits your old reputation |
| Current records: SPF, DMARC, MX | What the zone says today |
| Registrar lock and DNS access | Protects against unauthorised transfer |
| Last reviewed date | Proves the review happens |
Review it every quarter, and also after an acquisition, a rebrand, a vendor cancellation or a staff change. Each review is short: read the latest reports, confirm the records, check renewal dates, resolve a sample of CNAMEs. If you plan a new sending subdomain later, the guidance in sending subdomain strategy explains how to separate it cleanly from the protected apex.
Managing many domains in bulk
The standard set is identical across every non-sending domain, so it should be applied the same way every time. Treat it as a template with one variable, the domain name, and push it through whatever tooling you already use.
- Template the records. Keep the SPF, DMARC and null MX values in one place and generate the zone entries from the domain list.
- Use your DNS provider API or infrastructure as code. A scripted change is repeatable and reviewable, and it leaves a history. Check your provider documentation for the supported record types and rate limits.
- Centralise reporting. Send every rua to one address on a reporting domain, publish the authorisation records once per protected domain, and tag reports by domain when you read them.
- Verify after publishing. Query each record from outside your network and compare it to the template. Our domain verification guide lists useful DNS checks and propagation tips.
- Lock the registrar side. Enable transfer lock, two-step sign-in and auto-renew where your registrar offers them.
For accounts that hold a large portfolio, check your MigoSMTP account or API documentation for exact details on what the platform offers for domain management. The records in this guide are standard DNS and work with any provider.
A worked example with invented numbers
A business reviews its registrar accounts and finds 24 domains. After sorting, 6 are active sending domains, 2 are receiving-only domains that forward to a main mailbox, and 16 are non-sending: 7 parked names, 4 old-brand domains, 3 typo and lookalike registrations and 2 expired campaign domains. Of the 16, none has an SPF record, 3 have a stale DMARC record at p=none, and 5 have MX records that still point at a former mail host.
The team applies the standard set to all 16: a null SPF record, a DMARC record at p=reject with sp=reject and a shared rua address, and a null MX. It also removes the 5 stale MX records. A scan of CNAME and NS records finds 4 entries that point at cancelled vendor services, on 3 domains. Two are deleted at once, and the remaining two belong to a vendor account that still exists, so the team confirms ownership first and then deletes them.
| Item | Before | After |
|---|---|---|
| Non-sending domains with null SPF | 0 of 16 | 16 of 16 |
| Non-sending domains at DMARC reject | 0 of 16 | 16 of 16 |
| Domains with null MX | 0 of 16 | 16 of 16 |
| Stale MX records | 5 | 0 |
| Dangling CNAME or NS entries | 4 | 0 |
| Domains with auto-renew confirmed | 11 of 24 | 24 of 24 |
Over the next month the shared reporting mailbox receives aggregate reports. Most show a handful of failed messages from unknown addresses against the typo domains, which is the expected pattern for forged traffic. One report, for an old-brand domain, shows 40 messages from a server the team does recognise: a billing tool that still sends invoice copies with the old domain as sender. The team moves that tool to a current authenticated domain, then leaves the old domain locked down. Without the reports, those invoices would simply have been rejected without anyone knowing why.
A short checklist
- Every domain you own is listed with an owner, a class and an expiry date.
- Non-sending domains publish v=spf1 -all, with one SPF record per name.
- DMARC is p=reject with sp=reject and a working rua address; external report authorisation is in place.
- Domains that should receive no mail publish a null MX (0 followed by a dot).
- Optional revoked DKIM wildcard is tested before wide use.
- No CNAME, A, MX, NS or SPF include points at a retired service.
- Registrar lock, two-step sign-in and auto-renew are enabled.
- Reports are read on a schedule, and any passing result on a non-sending domain is investigated.
- The inventory is reviewed quarterly and after every acquisition, rebrand or vendor change.
Need help locking down your domain portfolio? Tell us how many domains you hold and which of them send mail, and we will help you plan a safe record set and review routine.
Further reading and sources
- RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email
- RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
- RFC 7505: A "Null MX" No Service Resource Record for Domains That Accept No Mail
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
- RFC 5321: Simple Mail Transfer Protocol
Frequently asked questions
Why would anyone spoof a domain that I do not even use?
Because a spoofed message from a plausible but unused domain is cheap to send and hard for recipients to judge. Attackers like old brand names, misspellings and defensive registrations precisely because they look official while having no live mail system that could notice or complain. A strict policy turns those domains from convenient disguises into dead ends.
What does the SPF record v=spf1 -all actually say?
It says that the set of servers allowed to send for this domain is empty. The all mechanism matches every sender, and the minus qualifier turns that match into a fail. Receivers that check SPF therefore see a hard fail for every message that uses the domain in the envelope sender or HELO name.
Is SPF enough on its own to protect a parked domain?
No. SPF only checks the envelope sender, while people see the From header. DMARC with p=reject is what tells receivers to act on the result for the visible From domain. We publish both, and add a null MX where the domain should receive nothing.
What is a null MX record?
It is an MX record with preference 0 and a target of a single dot, defined in RFC 7505. It states that the domain accepts no email. Without it, senders that find no MX record may fall back to the address records of the domain and try to deliver there anyway, which wastes time and can produce confusing bounces.
Should I use p=reject or p=quarantine on non-sending domains?
Use p=reject. Because the domain never sends legitimate mail, there is no risk of blocking something wanted, and reject gives the strongest instruction to receivers. The usual staged rollout is for domains that already send mail and need time to find all their sources.
Do I need DKIM records on a domain that sends nothing?
No, there is nothing to sign. Some teams add a wildcard record with an empty p= value under _domainkey to state that any key is revoked. It is an optional extra and not a replacement for SPF and DMARC. Test it with your DNS provider before relying on it, because wildcard handling differs between tools.
How is a dangling DNS record dangerous?
If a CNAME points at a vendor hostname that you no longer control, someone else may be able to claim that hostname and serve content under your domain. That can be used for phishing pages, cookie theft or fake login forms on a name that looks like yours. Removing the record when you cancel the service closes the gap.
How often should I review my non-sending domains?
A quarterly review is a sensible rhythm for most organisations, with extra checks after acquisitions, rebrands, vendor cancellations and registrar changes. The review is short once the inventory exists: confirm the records are still in place, read the reports, and check the renewal dates.
Can I manage dozens of domains without editing each one by hand?
Yes. Keep the standard record set as a template, apply it through your DNS provider API or infrastructure as code, and send all aggregate reports to one reporting mailbox or service. Remember that a rua address on a different domain needs an authorisation record on the receiving side, as RFC 7489 describes.