Lock down a domain that sends no mail

Many domains never send or receive email: parked domains, brand and typo domains you hold to keep them from others, and names used only for a website. They can still be spoofed. Anyone can put [email protected] in the From address of a message. Three DNS records tell receivers that the domain has no mail at all, so they can reject such messages.

This guide uses example.com. Replace it with your domain, or let the free lockdown tool check your domain for MX records and build the records for it.

The three records

example.com.         MX   0 .
example.com.         TXT  "v=spf1 -all"
_dmarc.example.com.  TXT  "v=DMARC1; p=reject"

Each record is explained below. Publish all three at the same time. None of them affects a website on the same name.

Null MX: the domain accepts no mail

RFC 7505 section 3 says that "to indicate that a domain does not accept email, it advertises a single MX RR" with preference 0 and the root . as exchange. Senders that follow it fail at once instead of retrying for days.

Without any MX record, senders fall back to the domain's own A or AAAA record as an implicit MX (RFC 5321 section 5.1). A web server would then get mail connections. The null MX stops that.

The null MX must stand alone. RFC 7505 section 3 says: "A domain that advertises a null MX MUST NOT advertise any other MX RR." See Null MX in the MX guide.

Section 4.2 explains why a null MX is only for domains that also send no mail: mail systems "SHOULD NOT publish a null MX record for domains that they use in RFC5321.MailFrom or RFC5322.From addresses". It then points to SPF for the sending side: operators "can publish Sender Policy Framework (SPF) "-all" policies [RFC7208] to make an explicit declaration that the domains send no mail."

SPF that allows nothing

example.com.  TXT  "v=spf1 -all"

The record has no mechanisms that authorise a server, so every sender fails. RFC 7208 section 10.1.2 gives this exact record: "The record for a domain that sends no mail is" v=spf1 -all, and calls publishing it "a well-established best practice".

On a domain that does send, ~all is often used while you are not yet sure every sender is listed, because a missed sender then gets a softfail instead of a fail. A domain that sends nothing has no senders to miss, so the hard fail is the point. See SPF explained.

SPF checks the envelope sender, not the From address that people see. That is why DMARC is needed as well.

DMARC reject

_dmarc.example.com.  TXT  "v=DMARC1; p=reject"

DMARC (RFC 9989) checks the domain in the visible From address. A message passes only when SPF or DKIM passes for an aligned domain. A domain with SPF -all and no DKIM keys can never pass, so with p=reject every message that uses it fails, and the policy asks receivers to reject it. On a sending domain you would start with p=none and read reports first. With no legitimate mail, there is nothing to wait for.

The record also covers subdomains. RFC 9989 section 4.7 defines sp for existing subdomains: "If both the "sp" tag is absent and the "np" tag is either absent or not applicable, the policy specified by the "p" tag MUST be applied for subdomains." The np tag covers names that do not exist at all. Section 4.7 says: "If the "np" tag is absent, the policy specified by the "sp" tag (if the "sp" tag is present) or the policy specified by the "p" tag (if the "sp" tag is not present) MUST be applied for non-existent subdomains." So p=reject alone also covers anything.example.com. You can write sp=reject; np=reject to make it explicit, but it changes nothing here.

A rua address is optional:

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]"

It buys you aggregate reports, which show whether someone tries to send mail as the domain and from where. The cost is a mailbox that receives XML files, and someone who reads them. A report address in another organisational domain also needs an authorisation record there (RFC 9990 section 4). Because example.com has a null MX, the address must be on a domain that receives mail. The DMARC record generator builds either variant.

Optional: revoke every DKIM key

*._domainkey.example.com.  TXT  "v=DKIM1; p="

This wildcard answers every DKIM selector with an empty key. RFC 6376 section 3.6.1 says of the p= tag: "An empty value means that this public key has been revoked." A signature that claims to come from the domain fails without the wildcard too, because there is no key to check it against. The wildcard turns that into an explicit revoked key.

It is optional. DMARC p=reject already rejects mail that is not aligned, and without real keys no DKIM signature for the domain can pass. Some receivers look at DKIM without DMARC, and for them the wildcard is a clear signal. A DKIM check of the domain reports the empty key as DKIM_KEY_REVOKED, which is expected here. Do not publish the wildcard if any part of the domain signs mail.

Subdomains

The records do not all reach subdomains in the same way:

• Null MX and SPF are per name. They apply only to the exact name they are published on. A subdomain that exists, for example www.example.com, needs its own MX 0 . and v=spf1 -all if you want the same statement there. A name with an A record and no MX is open to the implicit MX rule.
• DMARC at the organisational domain covers subdomains. Receivers that find no _dmarc record at a subdomain walk up the DNS tree to _dmarc.example.com and apply its sp or np policy, which is p here. You do not need a _dmarc record on each subdomain.

If one subdomain does send mail, for example news.example.com through a mailing service, give it its own SPF, DKIM and _dmarc record, and leave the null MX and -all records off that name.

How to check it

The free email security check reads MX, SPF, DMARC, DKIM and MTA-STS for a domain. For a domain with the three records, expect:

• MX_NULL as information: the domain accepts no mail.
• No SPF findings. A missing record shows as SPF_NOT_FOUND, and ~all as SPF_SOFTFAIL_ALL.
• A DMARC policy of reject. Without rua you see DMARC_NO_RUA, which you can accept if you chose to go without reports.
• DKIM: without the wildcard, DKIM_NO_COMMON_SELECTORS as information. With it, the check lists each common selector it tries as revoked under DKIM_KEY_REVOKED, a warning that is expected here.

The lockdown tool runs the same mail check and marks each of the three records as in place, to add or to replace. The MX lookup shows the MX records alone. Use it on each subdomain that exists. The SPF lookup counter shows that v=spf1 -all needs no DNS lookups. The checks read published records only. They do not see mail that is sent.

Common mistakes

• A null MX next to other MX records (MX_NULL_WITH_OTHERS). Remove the old records.
• -all or a null MX on a domain that does send mail, often an old domain still used by one system. Check before you publish.
• p=none left in place for good (DMARC_POLICY_NONE). It asks receivers to take no action, so it gives no protection.
• No DMARC record at all (DMARC_NOT_FOUND).
• Forgetting a subdomain that does send. The parent's p=reject then rejects its mail too, unless its mail passes DMARC (its own SPF or DKIM, aligned).
• Two SPF records on the same name (SPF_MULTIPLE_RECORDS), for example an old one left beside the new -all record.