A defensive domain that does not send email should say so in DNS. Three records do the job: a null MX record, an SPF record that rejects everything, and a DMARC policy set to reject. Together they make it much harder for someone to send mail that pretends to come from the domain.
Most advice about defensive domains stops at "redirect it to the main site". That is fine for visitors. It does nothing for email.
The sign on the door
Picture a shop that has closed for good. If the door has a sign that says "No deliveries, no post, nobody here", nothing happens. If the door has no sign, you get parcels, and sooner or later somebody uses the address to order things in your name.
A defensive domain without email records is the shop without the sign. Nobody reads the mail, but anybody can send mail that looks like it came from there.
The three records
I will use example.com as the domain. Replace it with yours.
1. Null MX. This tells other mail servers that the domain does not accept mail. It is defined in RFC 7505: an MX record with preference 0 and a single dot as the target.
example.com. IN MX 0 .
Without it, a server that tries to send mail to the domain will keep trying, and the sender waits. With it, the sender gets an immediate answer.
2. SPF that rejects everything. SPF (RFC 7208) lists which servers may send mail for a domain. For a domain that sends nothing, the list is empty and the policy is to fail.
example.com. IN TXT "v=spf1 -all"
3. DMARC set to reject. DMARC (RFC 7489) tells receivers what to do with mail that fails the checks.
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=reject"
The p tag covers the domain itself, and sp covers its subdomains.
One thing about subdomains
SPF does not inherit. A record at the top of the domain does not cover mail that claims to come from mail.example.com. If you want to cover subdomains, add a wildcard record as well:
*.example.com. IN TXT "v=spf1 -all"
Do this only on domains that send nothing at all.
The most important warning
Never put these records on a domain that sends or receives real mail. A null MX stops incoming mail, and a reject policy stops outgoing mail that fails the checks. If the domain is used for anything, even something small like a contact form, stop and check first.
What about the website?
Redirecting a defensive domain to your main site is still a good idea. Browsers and visitors do not care about the mail records, and the redirect shows that you own the name. If you redirect with HTTPS, make sure the domain has a valid certificate, or leave the redirect to plain HTTP and accept the limits. Whichever you choose, keep the choice consistent across your defensive names.
How to test it
You do not need special tools:
- Look up the three records with a DNS lookup tool, and check that each one is there exactly once. Two SPF records at the same name break SPF.
- Send a message to an address at the domain from a mailbox you control. With the null MX in place, the message should bounce right away.
- Use a DMARC checker, many of which are free, and check that the policy is read as reject.
- Write the date and the result down in your domain records.
How to add the records in AiVikings.ai
The MCP server has DNS tools that can list, add, change and delete the records on a domain. Check the documentation for the record types and limits that apply to you, and the MCP tools reference for the exact tools. If your DNS panel does not accept a single dot as the MX target, ask your DNS provider how it handles null MX.
Where this fits
Registering the name is only half of the job. The other half is deciding what the name should do. The post on turning an approved list into registrations covers the first half, and the guide to defensive domain administration shows where a registrar sits. If you have many defensive names, the post on changing nameservers across a portfolio helps you apply the same records everywhere. For a look at how many names large companies actually hold, read the summary of the NDSS study. The page for brand protection teams has the rest.
A registrar administers domains. It does not monitor for infringement and it does not give legal advice.
Questions people ask
Do I need these records if the domain has no website?
Yes. Spoofing uses the name in the email address, and the website is irrelevant to that.
Will a null MX break my redirect?
No. Web traffic and mail use different records.
Can I use these records on my main domain?
No. They stop mail. Use them only on domains that send and receive nothing.
Is DMARC enough on its own?
It works together with SPF and DKIM. For a domain that sends nothing, the three records above are the usual set.
Sources
- RFC 7505, A "Null MX" No Service Resource Record for Domains That Accept No Mail
- RFC 7208, Sender Policy Framework
- RFC 7489, Domain-based Message Authentication, Reporting, and Conformance
If one of these records caused you trouble, I would like to hear about it. Write to me in the chat on the website.
/Thomas