Domains that send no email

A domain that does not use email is not safe from email abuse. Anyone can send a message that claims to come from it, and the receiving server never checks whether the domain has mail servers of its own. Attackers like unused and parked domains for exactly this reason. Nobody is watching them, and a convincing lookalike sender address costs nothing. Publishing three small records makes the intent explicit and tells receivers to throw the abuse away.

The three records

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

• •Null MX (0 .) — RFC 7505. States that the domain accepts no mail, so senders fail immediately instead of retrying for days.
• •SPF -all — authorises no server to send as the domain. With no sending services, there is nothing to list.
• •DMARC p=reject — tells receivers to refuse anything that fails. With no legitimate mail, there is nothing to monitor first, so skip the usual p=none stage. sp=reject applies the same rule to subdomains.

Because nothing legitimate is ever sent, there is no reason to collect aggregate reports: those arrive at a mailbox on the domain, and a domain with no mail has none. DKIM is not needed either, since there is nothing to sign.

Why a missing MX does not prove there is no mail

It is tempting to treat a domain with no MX record as a domain without mail. The mail standards say otherwise: when there is no MX, a sender falls back to the domain's address record (A or AAAA) and tries to deliver there. If the domain has a website, mail may still be accepted by the web server. Only a published null MX is an explicit statement, and only a domain with no MX and no address record at all has nowhere to deliver to. Surface treats those two as certain no-mail cases and anything else as uncertain.

How the report changes

• •MTA-STS and TLS-RPT are shown as not applicable, since they only matter for inbound mail.
• •Missing SPF or DMARC is still a failure, because spoofing never depended on receiving mail.
• •The fix text is the short version above, rather than the setup advice meant for domains that send.

Common failure modes

• •Publishing SPF -all but no DMARC. Many receivers weigh DMARC more heavily than SPF alone, so publish both.
• •Forgetting subdomains. Without sp=reject, or a policy on each subdomain, an attacker can use mail.example.com or anything else under the domain.
• •Applying these records to a domain that does send mail somewhere. Check before you publish -all and p=reject. Marketing tools, invoicing systems and forms that send as the domain count as sending.