How to protect domains that do not send email

Why are domains that do not send email spoofed?

Most organisations own more domains than they use for email: old brand names, country variants, misspellings registered to stop typosquatting, and domains bought for a campaign that ended. Many of them have a website or a redirect, but no SPF, DMARC or MX records at all.

To a receiving mail system, a domain with no DMARC record has given no instruction about forged mail. Someone who sends a message with that domain in the From address is judged only by the receiver's own filters. A domain that looks like yours and has no policy is an attractive tool for phishing, precisely because nobody watches it.

Which records does a domain that never sends email need?

A domain that neither sends nor receives email needs three records. Together they say that no server may send for the domain, that receivers should reject mail that claims to come from it, and that it accepts no mail.

example.net. TXT "v=spf1 -all"
_dmarc.example.net. TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com"
example.net. MX 0 .

v=spf1 -all lists no senders and fails everything else. -all is the goal for every SPF record; ~all is only a soft signal, and ?all or +all give receivers nothing to act on. p=reject asks receivers to reject mail that fails DMARC, and sp=reject states the same for subdomains instead of leaving them to inherit it. There is no need to step up from p=none here, because a domain that sends nothing has no legitimate mail to lose.

Keep the policy at full strength. A pct value below 100, or sp=none, lets part of the forged mail through.

What does a null MX record do, and why not just leave MX out?

A null MX record (RFC 7505) is an MX record with preference 0 and a single dot as the host. It states that the domain accepts no email. Sending servers that see it give up at once and return the message to its sender, instead of queueing it and retrying for days.

Leaving MX out does not mean the same thing. When a domain has no MX record, the mail standard tells senders to try the domain's A or AAAA address instead, so mail can end up at the web server or wherever that address points. A null MX closes that path and makes the intention explicit.

A null MX must stand alone. Publishing it next to ordinary MX records contradicts it, and senders resolve the conflict differently, so some deliver and some do not. If the domain receives mail, remove the null MX; if it does not, remove the other MX records.

How should a domain that only sends email be set up?

A send-only domain, such as one used for notifications or newsletters, needs the same strong DMARC policy, but its SPF record and DKIM keys list the services that really send for it. Whether it should have a null MX depends on one question: does any mail need to arrive at this domain?

• If nothing should arrive, publish a null MX. Replies to the From address will then bounce at once, which is the right result for a no-reply address.
• If replies, bounces or other mail must reach an address at the domain, publish ordinary MX records that point to a mailbox service you control.
• Bounces go to the Return-Path address, not to the From address. Many services use their own bounce domain, or a subdomain of yours with its own MX record, which a null MX on the parent domain does not affect.

notify.example.com. TXT "v=spf1 include:mail-provider.example -all"
_dmarc.notify.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
notify.example.com. MX 0 .

Unlike a parked domain, a send-only domain does have legitimate mail, so confirm in the reports that every sending service passes with alignment before you move to p=reject.

Does a domain that does not send email need DKIM?

No. DKIM keys exist so that a sender can sign its mail, and a domain that sends nothing has nothing to sign. The SPF and DMARC records are enough: with no valid signature and no SPF pass, every message fails DMARC and the reject policy applies.

If the domain used to send mail, check for old DKIM records left behind, for example under the selectors of a service you no longer use. A valid old key means that anyone who still holds the private key can sign mail that passes. Delete the record, or publish it with an empty p= tag, which marks the key as revoked so that signatures made with it no longer verify.

old-selector._domainkey.example.net. TXT "v=DKIM1; p="

How do I protect the subdomains of a parked domain?

When a receiver finds no DMARC record for a subdomain, it uses the record of the organisational domain and applies its sp= policy. That is why sp=reject on the parked domain covers mail from names such as billing.example.net, whether or not the name exists in DNS. Set it explicitly rather than relying on inheritance from p=, so the intention is clear to anyone who reads the record later.

The updated DMARC specification (DMARCbis) adds an np= tag for subdomains that do not exist at all. It only matters when it should differ from sp=. With sp=reject, non-existent subdomains are already covered, so you do not need np= for a parked domain.

SPF and MX do not inherit in the same way; each name has its own records. Some owners publish wildcard SPF and null MX records for the subdomains as well. A wildcard only answers for names that have no records of their own, so it is a supplement to the DMARC policy, not a replacement for it.

Should a parked domain send DMARC reports?

Yes. Keep a rua address in the record. For a domain that sends nothing, the aggregate reports are simple to read: every message in them is either forged or a forgotten legitimate sender. A sudden volume of failing mail shows that someone is using the domain in a campaign, and a source that passes shows that something still has permission to send.

Send the reports to a mailbox on a domain that receives mail, not to the parked domain itself, which has a null MX. When the reporting address is on another domain, that domain must publish an authorisation record, or receivers will not send the reports there.

example.net._report._dmarc.example.com. TXT "v=DMARC1;"

Parked and defensive domains can be monitored in DMARC Vision alongside the domains you send from. The site's free DMARC record checker reviews a record before you publish it.

What are the most common mistakes?

• Deleting every DNS record when a domain is retired. With no DMARC record nothing tells receivers to stop forged mail, and with no MX record, senders fall back to the domain's address.
• Leaving an old SPF include for a service that is no longer used. Anyone who can send through that service, possibly including its other customers, can then pass SPF for the domain.
• An MX record that points to a decommissioned server. Mail queues and bounces slowly, and if the hostname or IP address is later reused by someone else, they may receive mail addressed to the domain.
• Publishing a null MX next to ordinary MX records, which contradicts it.
• Putting the rua address on the parked domain itself, where a null MX means no report can arrive.
• Stopping at p=none, ~all or a pct below 100 on a domain that has no legitimate mail to protect.
• Forgetting that a registrar's parking service may publish its own MX or SPF records. Check the live DNS, not only your own zone file.