Parked Domains: How to Lock Down Domains That Never Send Email

A domain that never sends email should say so in DNS. Publish v=spf1 -all so no server is authorised to send, a DMARC record at p=reject with sp=reject so receivers refuse anything claiming to be from it, and, where the domain receives no mail either, a null MX record. Then keep monitoring it.

Why parked domains are attractive targets

Most South African businesses own more domains than they actively use. A typical pattern: yourcompany.co.za runs email and the website, while yourcompany.com, an old brand name, a product name and a couple of misspellings were registered defensively and point nowhere, or redirect to the main website. Nobody thinks about their email security because nobody sends email from them.

That is precisely the problem. A domain with no SPF record and no DMARC record gives receiving servers no instruction at all. A criminal can send mail claiming to be from accounts@yourcompany.com and the receiver has no published policy telling it to refuse that mail. Because the domain carries your brand, recipients find it believable. A defensive registration bought to protect your name can end up being the easiest way to abuse it.

Parked domains are also invisible in a way active domains are not. If someone spoofs your main domain, there is a chance a bounce or a confused reply lands in a real mailbox. If someone spoofs a domain that has no mailbox at all, nobody inside the business ever sees a trace of it.

Classify every domain before you lock it down

“Parked” means different things, and the right records depend on what the domain actually does. Before publishing anything, put each domain in one of these categories.

The receive-only category is the one that catches people out. An old domain may still have mailboxes or forwarders that staff, clients or legacy systems rely on, even if nobody has sent from it in years. Check MX records, mail platform configuration and, ideally, a few weeks of DMARC aggregate data before deciding a domain receives nothing. If you are unsure what a domain is doing, our free DMARC checker shows its current SPF, DMARC and MX position.

The lockdown record set

For a domain that sends no email, these are the records to publish. Replace yourcompany.com with the domain and supply your own reporting address.

1. SPF: authorise nobody

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

This says no server is permitted to send mail using this domain in the envelope sender. It costs zero DNS lookups and leaves nothing to drift. For a non-sending domain, -all is the right qualifier: there are no legitimate forwarding cases to protect.

2. DMARC: reject everything that claims to be you

_dmarc.yourcompany.com. TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:reports@yourcompany.co.za"

Because nothing legitimate sends from the domain, there is no need for the staged rollout an active domain requires; you can go straight to p=reject. The sp=reject tag makes the subdomain policy explicit. Without an sp tag, subdomains inherit p anyway, but stating it removes any doubt. Strict alignment is optional here, since no mail should pass at all. The rua address keeps aggregate reports flowing so you can see abuse attempts. If the reporting mailbox is on a different domain, that domain must publish an authorisation record for external reporting, which most DMARC services handle for you.

3. Null MX: where the domain receives no mail

yourcompany.com. MX 0 .

RFC 7505 defines this “null MX” record, a single MX with preference 0 and a target of a lone dot. It tells sending servers the domain does not accept email, so mail addressed to it fails immediately rather than being queued and retried. It also signals clearly that addresses at the domain are not real, which some receivers take into account when assessing mail claiming to come from it. Only use it for website-only and fully parked domains. Publishing a null MX on a receive-only domain will break its inbound mail.

What about subdomains?

SPF records apply only to the exact name they are published on, so mail.yourcompany.com has no SPF record of its own. DMARC covers this gap: the organisational domain’s policy, including sp=reject, applies to subdomains that do not publish their own DMARC record. This is one reason the DMARC record does more of the heavy lifting than SPF on a parked domain. Our article on subdomains and the sp= tag covers inheritance in detail.

The DKIM question: do you need a revocation record?

Some guidance suggests publishing a wildcard DKIM record with an empty key, for example *._domainkey.yourcompany.com TXT "v=DKIM1; p=", to declare that no key is valid. It is not harmful, but for most parked domains it is not needed.

The logic is straightforward. A DKIM signature can only verify if the receiver finds a public key at the selector named in the signature. A domain that has never had DKIM keys published has nothing to find, so any signature claiming to be from that domain fails. With SPF set to -all and DMARC at p=reject, a message with no valid aligned SPF and no valid aligned DKIM fails DMARC and is rejected by receivers that honour the policy. The DMARC record already does the job.

Where a revocation record does earn its place is on a domain that previously sent mail and still has old DKIM keys in DNS. In that case the cleaner fix is to remove the old selector records, so there is no valid key left for anyone to misuse. For a refresher on selectors, see DKIM explained.

A portfolio approach for businesses with many domains

Once a business holds more than a handful of domains, the problem stops being technical and becomes administrative. Domains are registered by different people, at different registrars, with DNS hosted in different places. The practical framework is simple to describe and harder to maintain:

1. Inventory. List every domain the organisation owns: .co.za, .com, other TLDs, brand names, product names and defensive typo registrations. Include where DNS is hosted and who controls it.
2. Classify. Assign each domain to one of the four categories above, with evidence rather than memory.
3. Apply the standard set. Every non-sending domain gets SPF -all and DMARC p=reject; null MX is added where the domain receives nothing.
4. Monitor. Point aggregate reports from every domain to one place, so abuse of an obscure variant is visible alongside your main domain.
5. Govern changes. When a parked domain is brought into use, for a campaign or a new product, it moves to the active category and goes through a proper rollout. When a domain is retired, it is locked down before mailboxes are removed, not years afterwards.

Agencies and IT providers managing domains for many clients face this at scale; our article on DMARC for agencies and MSPs covers the operational side.

Mistakes to avoid

• Null MX on a domain that still receives mail. Confirm forwarders and mailboxes first.
• Locking down a domain a forgotten system still sends from. Old website contact forms, printers and legacy applications sometimes use an old domain. A short monitoring period at p=none is cheap insurance if there is doubt.
• Letting a defensive domain lapse. An expired domain with your brand can be re-registered by someone else, and then no record you published protects you.
• Leaving +all or an old permissive SPF record in place. Replace it, do not append to it.
• Assuming a website redirect means no email risk. Web and email are separate in DNS; a redirect says nothing about mail.

Every MailMarq package includes parked domain lockdown alongside your active domains, with the same monitoring all year, so a defensive registration stays defensive. See the annual packages, or ask for a free assessment of your full domain portfolio through our contact page.

Frequently asked questions

MailMarq
MailMarq is a managed DMARC service run from Johannesburg. Our team has built and managed business websites, hosting and email infrastructure for South African companies since 2016, and writes these guides from work on real domains.