Parked domains need email security too: SPF -all, DMARC reject, and null MX

A parked domain feels harmless because nobody uses it. That is exactly why it becomes useful to an attacker. It is not in the marketing calendar, not monitored by the product team, and often missing from the email-security rollout because it does not send legitimate mail.

The right posture for a non-sending domain is not silence. The right posture is an explicit DNS statement: this domain sends no mail, accepts no mail, and any message claiming to use it should fail authentication.

The compact record set

For a domain that should never send or receive email, the baseline record set is small. M3AAWG's parked-domain guidance points to the same pattern: SPF with no authorized hosts, DMARC at reject, no DKIM keys, and null MX for inbound mail.

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

# Do not publish DKIM public keys for a domain that never sends mail.

Each record says a different thing. SPF says no IP address may use the domain in the SMTP envelope identity. DMARC says unauthenticated mail using the visible From domain should be rejected. Null MX says the domain does not accept inbound mail. The absence of DKIM keys means an attacker cannot create a validating signature for that domain.

Why null MX matters

Without MX records, SMTP has old fallback behavior: a sender can try the domain's A or AAAA record as a mail destination. That is useful for compatibility, but awkward for modern domain portfolios where many domains exist only as websites, redirects, defensive registrations, or old campaign names.

RFC 7505 defines null MX so a domain can explicitly say it accepts no mail. The record is deliberately simple:

example.com. MX 0 .

That final dot is the important part. It is not a host. It is the DNS root, used here as the no-service value. A domain publishing null MX should not publish any other MX record. If the domain later needs to receive mail, remove the null MX before adding real mail exchangers.

The outgoing side is still DMARC

Null MX does not stop somebody from putting the parked domain in a visible From header. It only describes inbound delivery. Outbound spoofing needs SPF and DMARC.

The SPF record for a non-sending domain should be a naked fail-all policy:

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

That record authorizes no sending hosts. Then DMARC turns that authentication failure into a receiver-facing policy decision:

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

The rua address is optional for a truly inactive domain, but useful. Aggregate reports show which parked domains attackers are testing, which lookalikes are being used, and which receivers are still accepting mail that should have been rejected.

Subdomains are where portfolios leak

Most organizations protect the apex and forget the long tail: mail.example.comfrom a retired migration, events.example.com from a campaign, or go.example.com from a vendor that was removed years ago.

RFC 9989 keeps the familiar subdomain policy model and adds clearer handling for non-existent subdomains. If a parent domain publishes no sp or np override, subdomains inherit the parent policy. For locked-down portfolios, make the intent explicit:

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

Use sp=reject for existing subdomains that do not publish their own policy. Use np=reject for names that do not exist at all. That closes the easy attack path where a phisher invents security-alerts.example.com and relies on the parent domain being ambiguous.

When not to use this pattern

Do not publish null MX or v=spf1 -all on a domain that is used in a real From, Return-Path, bounce, reply, or notification workflow. If a product team has quietly reused the domain, these records can cause legitimate mail to be rejected.

The safe workflow is inventory first, lock second. For acquired companies, campaign domains, and old regional brands, start with reporting so the organization can prove that the domain is truly non-sending.

What DMARCify should surface

Parked-domain protection is not a one-time DNS cleanup. Domain portfolios change whenever a team buys a new brand, launches a campaign, enters a region, or acquires a company. The useful dashboard view is a portfolio table:

That last row matters most. If an inactive domain suddenly appears in aggregate reports, it is either a legitimate business process that escaped inventory or a spoof attempt. Both deserve attention before the domain is trusted by recipients.

The operating rule

Every owned domain should be in one of two states. If it sends mail, it has authorized senders, aligned DKIM or SPF, monitored reports, and a path to enforcement. If it does not send mail, it has SPF -all, DMARC p=reject, no DKIM keys, and null MX.

The dangerous state is the middle: owned, resolving, forgotten, and silent. That is the state attackers prefer.