Domain Without Email: Parked Domain Protection Guide

A domain that never sends email is still a perfectly good sender address for anyone who wants to impersonate you, unless its DNS tells every receiver that no legitimate mail can come from it. Most organisations own far more domains than they mail from: defensive registrations, old brands, product names, country variants, acquisitions and campaign sites. Each one without email authentication records can be used in the From address of a phishing message, and receivers have nothing to judge it against. This guide gives the exact DNS records for a non-sending domain (null MX, SPF "-all", a revoked DKIM wildcard and DMARC "reject", including the new np tag in RFC 9989), how to roll them out across a portfolio, how to keep reports flowing, and how to check the protection stays in place. It is for DNS, email and brand protection teams. For the underlying mechanisms on sending domains, see the DMARC, SPF and DKIM Guide.

Key takeaways

• Four records close the gap. A null MX ("MX 0 ."), an SPF record of "v=spf1 -all", an empty DKIM key at "*._domainkey" and a DMARC record with p=reject together say: this domain sends no mail, has no valid signing keys and receives no mail.
• DMARC does the enforcing. SPF and DKIM records alone only fail authentication; it is DMARC p=reject that asks receivers to refuse the message, and the other records cover receivers that do not apply DMARC.
• Subdomains need explicit cover. RFC 9989 adds the np tag for non-existent subdomains; set sp and np to reject unless a subdomain genuinely sends, and use wildcards where your DNS allows.
• Reports must go somewhere that can receive mail. A parked domain cannot receive its own DMARC aggregate reports, so point rua at a mailbox or reporting service on another domain and publish the authorisation record that the external domain needs.
• The real failure is lifecycle, not syntax. Domains drop out of inventory, expire, get re-registered by others or are moved to a new DNS host without their records; inventory and monitoring matter as much as the records.

Why non-sending domains are attractive to attackers

Phishing (ATT&CK T1566) depends on a sender address the recipient trusts. A brand's own domain is the most convincing choice, and a domain with no SPF, DKIM or DMARC gives receivers no published policy to reject spoofed mail. M3AAWG's best practice on parked domains notes that attackers favour domains resembling well-known brands that have no established sending reputation, which is exactly what a defensive registration is.

Three situations come up repeatedly:

• Exact-domain spoofing: a parked domain such as "examplebank.co.uk" alongside the real "examplebank.com" is used directly in the From header. Without DMARC, many receivers deliver it.
• Subdomain spoofing: a domain with DMARC on the apex but no subdomain policy lets "invoices.example.com" be forged even where nothing exists at that name.
• Lapsed domains: a domain allowed to expire can be registered by anyone (ATT&CK T1583.001 Acquire Infrastructure: Domains), who then controls its DNS, email and web content, and inherits any trust still pointing at it. The ForcedLeak Salesforce Agentforce incident shows the pattern: an expired domain still on a content security policy allowlist was bought for about five dollars and became a trusted exfiltration channel.

The records below deal with the first two. Only portfolio management deals with the third.

The four records for a domain that sends no email

The UK government's guidance for domains that do not send email and the M3AAWG Protecting Parked Domains Best Common Practices agree on the core set. Replace example.com with the parked domain and reports.example.net with a domain that receives mail.

Null MX

RFC 7505 (Standards Track) defines a null MX as a single MX record with preference 0 and a zero-length exchange label, written as "." in zone files, and says a domain that publishes it must not publish any other MX record. Without an MX, sending servers fall back to the domain's A or AAAA record and may retry for days; the null MX makes delivery to the domain fail at once. A server that refuses to relay to such a domain should answer 556 with enhanced status 5.1.10, and a receiver that refuses mail from a sender domain with a null MX uses 550 with 5.7.27. That last point matters for defence: some receivers reject mail whose envelope sender domain cannot receive bounces. The UK guidance notes that some DNS providers do not support null MX records; check yours before relying on it.

SPF

"v=spf1 -all" has no mechanisms that match any host, so every SPF check returns fail. Do not add "include:" or "a" mechanisms "just in case": every mechanism is a way for mail to pass.

DKIM

An empty p= value in a DKIM key record means the key has been revoked, so a signature claiming any selector on the domain cannot verify. The UK guidance also says to remove any existing DKIM selector records, both TXT and CNAME, when a domain stops sending; a CNAME pointing at an email provider's key can still validate mail sent through that provider.

DMARC

p=reject is the instruction that matters. Strict alignment (adkim=s, aspf=s) is harmless on a domain that sends nothing and removes any leeway. The UK guidance adds fo=1 to request failure reports where supported; M3AAWG notes that ruf failure reports can produce a large volume on an actively abused domain, so they are optional.

Subdomains, wildcards and the RFC 9989 np tag

RFC 9989, published in May 2026 on the IETF Standards Track, is the revised DMARC specification and obsoletes RFC 7489 and RFC 9091. Three tags control subdomains:

With p=reject and no sp or np, subdomains inherit reject anyway, so the explicit tags are belt and braces. They earn their place when you later relax sp for a sending subdomain: np=reject keeps invented names such as "payroll.example.com" protected. RFC 9989 also drops the pct tag that RFC 7489 used for partial rollout, and adds a psd tag that only public suffix operators set; a parked domain record leaves psd out. Some receivers will still implement the older RFC 7489 behaviour for a while, which is another reason to publish explicit values. The DMARCbis Changes Guide covers the full set of changes.

Wildcards for receivers that skip DMARC. M3AAWG recommends wildcard SPF ("*.example.com TXT v=spf1 -all") and wildcard null MX ("*.example.com MX 0 .") so that names under the domain also fail SPF and refuse mail. Be aware of the side effect: a DNS wildcard makes every subdomain name resolve for that record type, so a wildcard TXT will answer for any name. Do not add wildcards to a zone that also hosts real services without testing what they shadow.

A sending subdomain under a parked apex. If "alerts.example.com" must send, give it its own SPF, DKIM selector and DMARC record (a DMARC record at "_dmarc.alerts.example.com" overrides the apex policy for that name), and keep sp=reject on the apex for every other subdomain. The UK guidance offers sp=none on the apex as the simpler choice; it weakens protection for every other existing subdomain, so prefer per-subdomain records.

Keeping DMARC reports flowing

A parked domain cannot receive mail, so its rua address must be on a domain that can. The DMARC reporting rules require the receiving domain to agree to accept reports for another domain: publish a TXT record "example.com._report._dmarc.reports.example.net" with the value "v=DMARC1" in the reports domain, as M3AAWG shows. Without it, many receivers drop the reports.

• Why reports matter on a domain that sends nothing: any aggregate report row for a parked domain is either abuse or a forgotten sender. Both need action.
• Scale with CNAMEs: for a large portfolio, M3AAWG suggests pointing each parked domain's _dmarc name at one shared DMARC record by CNAME, so a single change updates every domain. The same trick works for SPF via a shared TXT where your DNS host supports CNAME at that name; it does not work at the zone apex for SPF itself, where a CNAME cannot sit beside SOA and NS records.
• Contacts: M3AAWG also recommends putting a responsible contact on another domain in the SOA record and an abuse contact in registration data, because abuse@ on the parked domain cannot receive mail.

Rolling it out across a domain portfolio

1. Build the inventory. Export every domain from every registrar account, including those held by marketing, regional offices, agencies and acquired companies. Record registrar, DNS host, owner, renewal date and whether the domain sends, receives or hosts a website. This is NIST SP 800-53 CM-8 System Component Inventory applied to domains.
2. Prove each domain is really silent. For two to four weeks, publish DMARC p=none with a rua address on each candidate domain and read the reports. Anything that passes SPF or DKIM is a real sender someone forgot, often a ticketing or marketing platform.
3. Remove leftover records. Delete old SPF includes, DKIM selector CNAMEs and MX records pointing at former mail services.
4. Publish the four records. Use a template in your DNS automation so every parked domain gets identical values, and change the DMARC policy straight to reject: on a domain with no legitimate mail there is no reason for a staged quarantine phase.
5. Verify from outside. Query each record from a public resolver, send a test message from an external account using the parked domain as the sender and confirm it is rejected or flagged.
6. Roll back if needed. If a forgotten sender breaks, publish a DMARC record for that one subdomain or temporarily set the apex to p=quarantine, fix the sender's authentication, then return to reject. Never remove the DMARC record entirely.
7. Add the domain lifecycle steps: auto-renew with a registrar lock, a new-domain checklist that applies the template on day one, and an exit step that keeps defensive domains registered and protected rather than letting them lapse.

Decision guidance

Small versus large organisations. A business with a handful of domains can apply the records by hand in an afternoon. A group with hundreds of domains across registrars needs DNS as code, a shared DMARC record by CNAME, and a DMARC reporting service that groups reports by domain so unexpected sources stand out.

Detection and measurement

• DMARC aggregate reports: alert on any message volume reported for a parked domain, split by source IP and by pass or fail.
• DNS drift checks: a daily job that resolves the four records for every inventoried domain and alerts on change or absence, particularly after DNS host migrations.
• Registration monitoring: renewal dates and registrar lock status for every domain; certificate transparency logs and new registrations for lookalikes of your brands.
• Mail gateway logs: inbound messages to staff claiming to come from your parked domains should be rejected; any that arrive indicate a receiver-side gap.

Metrics that show it is working:

1. Percentage of inventoried domains with all four records correct (target 100 per cent of non-sending domains).
2. Number of domains discovered outside the inventory each quarter (should fall to near zero).
3. Days of drift: time between a record changing and the alert being resolved.
4. Domains within 30 days of expiry without auto-renew (target zero).
5. Aggregate report sources seen per parked domain per month, each one investigated.

Framework mapping

Common failure patterns

• DMARC on the main domain only: the brand's primary domain is at reject while dozens of defensive and country domains have nothing, so attackers simply use those.
• Leftover DKIM CNAMEs: a selector CNAME to a former email platform still resolves, so anyone with an account on that platform may be able to send DKIM-passing mail as the domain.
• Reports addressed to the parked domain itself: rua points at dmarc@ on a domain with a null MX, so no report ever arrives and abuse goes unnoticed.
• Records lost in a DNS migration: a portfolio moved to a new DNS host or registrar arrives with only A and NS records, because email records were not in the export.
• Letting defensive domains lapse: renewal is cut to save cost and the domain is re-registered by someone else, who now controls it entirely, as the ForcedLeak case showed for a domain still trusted by an allowlist.
• Using p=quarantine indefinitely: a domain that sends nothing has no reason to sit at quarantine, and some messages still land in junk folders where users find them.

Lessons from incidents

The ForcedLeak research on Salesforce Agentforce is not an email spoofing case, but it shows why parked and retired domains need ownership: a domain that once belonged to the organisation, still referenced by a security control, was allowed to expire and was bought cheaply by the researcher. The same logic applies to email: a lapsed domain that staff, partners or allowlists still trust is an impersonation asset. Keep defensive domains registered, locked and protected for as long as anything might still trust them. For broader email threats, see Top 10 Phishing Techniques.

Practitioner checklist

• Inventory every domain across all registrar accounts, with owner, DNS host and renewal date.
• Confirm with two to four weeks of DMARC p=none reports that each candidate domain really sends no mail.
• Remove stale MX, SPF includes and DKIM selector TXT and CNAME records.
• Publish null MX "0 .", SPF "v=spf1 -all", "*._domainkey" "v=DKIM1; p=" and DMARC p=reject with sp=reject and np=reject.
• Point rua at a mail-receiving domain and publish the external report authorisation record there.
• Add wildcard SPF and null MX where the zone hosts no other services.
• Template the records in DNS automation and apply them to every new domain on registration.
• Run a daily drift check and alert on missing or changed records.
• Enable auto-renew and registrar lock, and keep retired brand domains registered.
• Review aggregate reports for parked domains monthly and investigate every source.

Standards and references

• IETF: RFC 9989 Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• IETF: RFC 7505 A "Null MX" No Service Resource Record for Domains That Accept No Mail
• UK Government: Protect domains that do not send email
• M3AAWG: Protecting Parked Domains Best Common Practices
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Acquire Infrastructure: Domains

Related NHI Mgmt Group resources: DMARC, SPF and DKIM Guide · DMARCbis Changes Guide · Authoritative DNS and Registrar Account Security Guide · DNS Security Guide