How to Protect a Domain That Doesn't Send Any Email

Most companies own more domains than they send mail from. Defensive registrations, retired brands, common misspellings bought to stop typosquatting, a domain kept for a project that never shipped — none of them send a single message, and almost none of them are protected. That makes each one useful to an attacker: they can forge the From address on a domain that publishes no email records, and a receiving server has little reason to reject it.

Learning how to protect a domain that doesn't send email is a five-minute job, and it is one of the highest-value security tasks nobody does. You publish a small set of DNS records that say, in effect, this domain sends no mail and accepts none — so any message claiming to come from it should be rejected. This guide covers the three records that do that, in plain terms, with the exact values.

The short answer#

A domain that never sends email should publish three DNS records. Add an SPF record of v=spf1 -all, which declares that no server is authorised to send mail for the domain. Add a DMARC record of v=DMARC1; p=reject;, which tells receiving servers to reject any message that fails authentication. Add a null MX record — an MX record with priority 0 and a single dot as the target — which declares that the domain accepts no incoming mail.

These are the same records a sending domain uses, set to their strictest values. Because the domain never sends legitimate mail, there is nothing to break, so you can go straight to the most restrictive policy without the gradual rollout a live sending domain needs. Publish them wherever the domain's DNS lives — the registrar or DNS host — not in a mail client.

Before you start#

You need one thing: access to the DNS zone for the domain, at the registrar or DNS host where its records live. You do not need a mailbox, a mail provider, or any software on the domain, because the whole point is that the domain has none of those.

• Be certain the domain sends no legitimate mail. If it sends even occasionally — password resets, a contact form, invoices from an app, a server cron job — these strict records will block that mail. Harden a domain only when you are sure nothing sends as it.
• Access to the DNS zone at the registrar or DNS host (Cloudflare, GoDaddy, Route 53, Namecheap, and so on). The records take effect only if the domain uses that host's nameservers.
• A way to check DNS — a public lookup tool, or a dig or nslookup command — to confirm each record resolves after you save it.
• Apply the same three records to every parked domain you own. Attackers target the unprotected ones, and one hardened domain out of twenty does nothing for the other nineteen.

Publish the three records, step by step#

Work through them in order and save each record before starting the next. The values below are literal — type them exactly, with no trailing dots or extra spaces.

1. 1

   Add the SPF record (TXT)

   Add a TXT record on the root of the domain — the name is @ or the bare domain, depending on your host — with the exact value v=spf1 -all. This is a complete SPF record with no authorised sources and a hard fail (-all) for everything else, so it says no server may send mail for this domain. RFC 7505 explicitly recommends this record for domains that send no mail. Publish only one SPF record per domain.

2. 2

   Add the DMARC record (TXT)

   Add a TXT record named exactly _dmarc with the value v=DMARC1; p=reject;. The p=reject policy tells receivers to reject — not just quarantine — any message that fails DMARC, and for a non-sending domain you can start at p=reject because there is no legitimate mail to catch in the crossfire. Microsoft's own parked-domain guidance recommends this exact record. Report addresses (rua and ruf) are optional here and arguably unnecessary, since no valid mail should ever come from the domain.

3. 3

   Add the null MX record (MX)

   Add an MX record on the root of the domain with priority 0 and a target of a single dot, written in a zone file as example.com. IN MX 0 . — the lone dot is the null exchange. This is the null MX record defined by RFC 7505, and it declares that the domain accepts no incoming mail. A sender that sees it stops immediately instead of retrying for days, and returns a bounce; receivers reject a sender whose domain has a null MX with SMTP 550 5.7.27. A domain that publishes a null MX must not publish any other MX record.

4. 4

   Optionally add a null DKIM record (TXT)

   For belt-and-braces cover, add a wildcard TXT record at *._domainkey with the value v=DKIM1; p= — an empty public key, which RFC 6376 defines as a revoked key. SPF -all and DMARC p=reject already stop spoofed mail on their own, since a forged message can neither pass SPF nor produce an aligned DKIM signature, so this step is optional rather than essential. Microsoft does not recommend DKIM CNAME records for parked domains.

5. 5

   Verify each record resolves

   After saving, query each record with a public DNS lookup or dig. TXT on the root should return v=spf1 -all; TXT on _dmarc.yourdomain.com should return your DMARC value; MX on the root should return a single dot with priority 0. Receivers cache old answers until the previous TTL expires, so allow for that if a record existed before.

The three records at a glance#

What these records actually block#

The records work as a set. Without them, a parked domain is a blank cheque: an attacker forges a From address on your unused domain, sends phishing to your customers or staff, and a receiving server has nothing on record telling it the mail is fake. With the records in place, that forged message fails SPF because there is no authorised sender, fails DMARC alignment, and hits a p=reject policy — so a receiver that checks DMARC rejects it before it lands.

The null MX closes the other direction. It tells the world the domain accepts no mail, so misdirected replies and backscatter bounce fast instead of queueing for days against a server that will never answer. None of this touches a domain you actually send from — it is only for the ones that should stay silent.

How this differs by DNS host and registrar#

The three record values are identical everywhere. What differs is how each DNS host wants you to enter them — especially the root name and the null MX target. Registrar interfaces change and word their fields differently, so confirm the exact steps against your host's current DNS documentation.

What to do when it doesn't work#

If a hardened domain is still spoofed, or a record won't validate, work from the symptom. The usual causes are a record that never resolved, a domain that is not on the nameservers you edited, or a leftover MX or SPF record fighting the strict values you just added.

A faster way — and where a mail client fits#

These records are published once at your DNS host and then left alone, so there is no ongoing tool to buy for the hardening itself. Two adjacent jobs do have dedicated tools, and it is worth naming them honestly: publishing the records is your DNS host's job (Cloudflare, Route 53, your registrar), and if you own dozens of domains and want to watch DMARC aggregate reports for spoofing attempts over time, that is the job of a dedicated DMARC monitoring service, not a mail client.

Where AI Emaily fits is the receiving side. SPF, DKIM and DMARC are how a receiving server decides whether a message really came from the domain it claims. AI Emaily reads those same authentication results on the mail arriving in your own inbox, so when a sender fails alignment — including a spoof of a domain that was never hardened — its spam and phishing checks can flag it. It will not publish a DNS record and it is not a DMARC monitor; it is the client that acts on the results downstream. We build AI Emaily, and it comes with a 7-day free trial on the Pro and Autopilot plans.