Parked Domains: Locking Down Domains That Send No Mail

Most organizations own more domains than they send mail from. There are the defensive registrations bought next to the brand, the old product names, the country variants, and the domain that only hosts a website. None of them sends mail. Any of them can still appear in the From header of a phishing message.

A receiver cannot tell that a domain is unused unless the DNS says so. A domain with no SPF, no DMARC and no MX record does not look abandoned. It looks unauthenticated, and unauthenticated mail is filtered on content and reputation, not rejected on policy.

The M3AAWG Protecting Parked Domains Best Common Practices and the UK government guidance Protect domains that do not send email describe the same set of records. Here is each one, the mechanism behind it, and the details that catch people out.

The four records

For a parked example.net that sends and receives nothing:

example.net.                  TXT  "v=spf1 -all"
_dmarc.example.net.           TXT  "v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.com"
example.net.                  MX   0 .
*._domainkey.example.net.     TXT  "v=DKIM1; p="

SPF: a bare -all

RFC 7208 calls this "a well-established best practice" and gives the record for a domain that sends no mail as v=spf1 -all. The only mechanism is -all, so every sending IP gets fail.

SPF is not inherited. v=spf1 -all on example.net says nothing about billing.example.net. M3AAWG suggests a wildcard, *.example.net TXT "v=spf1 -all", for the subdomains. A wildcard only answers for names that have no records of their own, so a subdomain with an A record still needs its own SPF record.

DMARC: p=reject, and sp= next to np=

DMARC is the record that turns those failures into a rejection. With no aligned SPF and no DKIM signature, every message fails DMARC, and p=reject asks receivers to refuse it. Unlike SPF, DMARC covers subdomains: a receiver that finds no record at _dmarc.billing.example.net uses the one at the organizational domain.

Which policy it then applies depends on whether the subdomain exists. RFC 9989 takes the policy from sp= for subdomains that exist and from np= for subdomains that do not. "Do not exist" has a narrow meaning: section 3.2.13 defines it as a query that returns NXDOMAIN.

That definition is why np=reject alone is not enough:

• Wildcards create names. Once *.example.net has a TXT record, every invented subdomain exists, and receivers apply sp=.
• Some zones do not return NXDOMAIN. Zones signed with compact denial of existence (RFC 9824) answer NOERROR with an empty answer for names that do not exist. On October 20, 2026, a query for a made-up name under example.com, sent to Cloudflare's public resolver, came back NOERROR with no records. The same query under iana.org came back NXDOMAIN.

So publish both. sp=reject covers every subdomain a receiver believes exists, and np=reject covers the ones it does not. The GOV.UK record and the record published for example.com both set sp=reject.

adkim=s; aspf=s is optional on a parked domain, because nothing on it should pass at all. GOV.UK includes it. For more on the subdomain tags, see why the sp= tag matters and what RFC 9989 changed.

Null MX: MX 0 .

A null MX is a single MX record with preference 0 and a host of .. RFC 7505 says what it does on both sides of a conversation:

• A server sending to anyone@example.net stops at the first attempt and does not queue the message for retries. The suggested reply is 556 5.1.10.
• A server receiving mail from example.net may reject it because no reply can come back. The suggested reply is 550 5.7.27, "Sender address has null MX".

That second point is a check that has nothing to do with DMARC. A domain that publishes a null MX "MUST NOT advertise any other MX RR". Without any MX, senders fall back to the A or AAAA record (RFC 5321, section 5.1), so a domain that hosts only a website would otherwise invite delivery attempts to its web server. GOV.UK notes that some DNS hosts do not accept a null MX. If yours does not, publish the other records anyway.

DKIM: an empty key on every selector

RFC 6376 says that an empty p= means "this public key has been revoked". A wildcard at *._domainkey answers that for any selector an attacker names. A receiver treats a signature that does not verify as no signature, so this record adds little to DMARC. M3AAWG and GOV.UK both list it, and it costs one line. GOV.UK also asks you to remove every real selector the domain used to have, including CNAMEs that point at a provider.

Live example: example.com

example.com is reserved for documentation by RFC 2606 and sends nothing. On October 20, 2026, its public records were:

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

It publishes no rua= tag, so nobody receives reports about mail that forges it. For a domain you own, you want those reports.

Where the reports go

A parked domain with a null MX cannot receive its own aggregate reports, so rua= has to point at a domain that takes mail. When that address sits outside the domain being reported on, RFC 9990, section 4 requires receivers to confirm that the report domain agrees to accept them. RFC 9989 names this exact case: reports about "domains that cannot actually receive mail". The report domain publishes the authorization:

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

A DMARC reporting service publishes this record on its side. If you send reports to your own mailbox on example.com, you publish it, or a wildcard *._report._dmarc.example.com for a whole portfolio.

The reports are the point of the exercise. A parked domain should have no legitimate traffic, so every source in its reports is either a forgery or a system someone forgot. Both are worth knowing about.

Many domains, one record

Editing forty DMARC records to change one reporting address is how parked domains drift out of date. M3AAWG suggests a CNAME:

_dmarc.example.net.     CNAME  _dmarc.parked.example.com.
_dmarc.example.org.     CNAME  _dmarc.parked.example.com.
_dmarc.parked.example.com.  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc-reports@example.com"

Each domain points at one record, and a change there reaches all of them. On DDMARC's Professional plan the hosted DMARC record works the same way, through one CNAME per domain.

The exceptions

Receive-only domains. A domain that accepts mail but never sends it, such as an inbound alias domain, keeps its real MX records. Skip the null MX, which would bounce its inbound mail, and still publish v=spf1 -all and p=reject.

Subdomains that do send. If alerts.example.net sends mail while the rest of the domain does not, give it its own SPF and DKIM records and its own DMARC record. GOV.UK suggests sp=none on the parent in that case. A dedicated _dmarc.alerts.example.net record lets the parent keep sp=reject.

Domains you are about to use. The day a parked domain starts sending, the records above make every message fail. Replace them before the first send, not after the first bounce report.

DNS TTLs. Changes take effect as caches expire. A TTL of a day on the old records means a day of mixed answers, which matters for the last exception and not much for the others.

To confirm the records are in place, run the domain through the domain checker. It reports a null MX as a deliberate "receives no mail" result, not as a missing record.