How to Protect Parked and Unused Domains from Email Abuse

Short answer: A domain that never sends or receives e-mail should say so in DNS, or criminals can use it for convincing spoofed messages. Publish three records on every parked or unused domain: an SPF record of v=spf1 -all, a DMARC record of v=DMARC1; p=reject; at _dmarc, and a null MX record (MX 0 .). Together they tell receivers that no server may send as the domain, that anything claiming to be from it should be rejected, and that it accepts no mail.

Why unused domains are attractive to criminals

Most businesses own more domains than they use: old brand names after a rename, country versions bought for protection, typo variants, domains registered for a campaign or product that never launched, and domains kept after an acquisition. They often have a website redirect and nothing else.

To a criminal, these domains are useful. They carry your brand, they look legitimate and, crucially, nobody is watching them. If a domain publishes no SPF and no DMARC record, receiving servers have no instruction from the owner, and spoofed mail from it is judged only on other signals. A message from [email protected] announcing new bank details can look entirely plausible to a long-standing customer.

Brand protection domains bought specifically to keep them out of criminals’ hands are a particular irony: without e-mail records, the very domains meant to protect the brand can be used against it, because owning a domain does not stop others from writing it in a From address.

Locking these domains down costs a few minutes per domain and no money. It is one of the best security returns available in e-mail.

Record 1: SPF that authorises nobody

Publish a TXT record at the root of the domain:

v=spf1 -all

This says that no server is allowed to send mail using this domain in the envelope sender. Any message claiming to come from it fails SPF immediately. There is no reason to use the softer ~all here, because there is no legitimate mail that could be affected by forwarding or forgotten senders.

For extra coverage, some administrators also publish v=spf1 -all on commonly abused subdomain names, but the DMARC record below already covers subdomains for the visible From address.

Record 2: DMARC that rejects everything

Publish a TXT record at _dmarc.yourparkeddomain.com:

v=DMARC1; p=reject;

Because nothing legitimate can pass SPF or DKIM for the domain, every message using it in the From address fails DMARC, and the policy tells receivers to reject it. Subdomains inherit the policy, so invented names such as billing.yourparkeddomain.com are covered too. You may add sp=reject to make that explicit.

Optionally add a rua report address. Reports for a parked domain show whether anyone is trying to abuse it, which can be useful intelligence. If the report address is on a different domain, remember that the receiving domain must authorise it with a special DNS record, or reports will not be sent.

Record 3: null MX

A null MX record, defined in RFC 7505, is a single MX record with priority 0 and a host of just a dot:

yourparkeddomain.com. MX 0 .

It tells sending servers that the domain accepts no mail at all. They bounce messages immediately instead of trying the domain’s A record or retrying for days. It also signals to receivers that the domain is not a legitimate sender, since a domain that cannot receive mail cannot receive replies or bounces.

The null MX is the least known of the three records, and for many parked domains it is optional: SPF and DMARC already stop the domain being used convincingly as a sender. It is still worth adding, because it makes the domain’s status unambiguous for every system that looks at it.

Some DNS panels do not accept a lone dot as an MX target. If yours does not, ask the provider how to publish a null MX, or at least make sure no MX records point anywhere unintended.

The three records together

All three records are ordinary DNS entries that any DNS panel can hold, and they do not affect the website or its redirect in any way. They can be added in a single session for a whole portfolio of domains.

If the domain does forward mail to your main mailboxes, for example because customers still write to an old address, do not publish a null MX. Keep working MX records for receiving, and publish only the SPF and DMARC records if the domain never sends mail.

Building an inventory of your domains

The hardest part is usually knowing which domains you own. Sources to check:

• your registrar accounts, including old accounts opened by former staff or agencies;
• renewal invoices from accounting;
• redirects configured on your web server or CDN;
• domains used in old marketing campaigns, apps or product launches;
• domains brought in through acquisitions or mergers.

Also look at domains registered in personal names. Founders, former marketing staff and agencies sometimes registered a company domain in their own account years ago. Those domains are part of your brand but outside your control, and moving them into a company-owned account should come before, or together with, the e-mail lockdown.

For each domain, note whether it sends mail, receives mail, or neither, and apply the right combination of records. Consolidating domains in one registrar account with two-factor authentication also protects them against hijacking.

Common mistakes with unused domains

• Protecting only the main domain. The most visible domain gets SPF, DKIM and DMARC, while a dozen related domains have nothing. Attackers pick the unprotected ones.
• Inherited default records. Some registrars and hosting companies publish default MX or SPF records on new domains, for example pointing to their own mail service. A parked domain may therefore accept mail into a mailbox nobody reads, or authorise a shared server to send as it. Replace defaults with the lockdown records.
• A p=none DMARC record. Better than nothing for monitoring, but it does not stop spoofing. Parked domains can go straight to p=reject.
• Letting domains expire unnoticed. An expired brand domain can be registered by someone else, who can then send fully authenticated mail from it. Renew domains you want to protect, and decide deliberately which ones to let go.
• Forgetting DNS after a hosting change. When a redirect is moved to a new host or CDN, the lockdown records may be lost with the old zone. Include them in every migration checklist.

An annual review of all domains, with a quick lookup of the three records on each, catches almost all of these.

Domains that might send mail again

Sometimes a parked domain comes back to life: a new product launches on it, or a regional office starts using it. Before any mail is sent from the domain, replace the lockdown records with a proper setup: SPF listing the new senders, DKIM for each sending service, DMARC starting at p=none with reports, and working MX records. If you forget, the first real messages will be rejected by your own policy, which is at least an obvious and quickly fixed failure rather than a silent one.

Warm up the domain gradually once it starts sending. A domain that has never sent mail has no reputation, and a sudden burst of messages looks suspicious to mailbox providers.

Checking your domains

You can verify each domain with three lookups: dig TXT domain, dig TXT _dmarc.domain and dig MX domain. For a quicker overview, Site AI Audit checks SPF (including validity and the lookup limit), DKIM, DMARC and MX records for a domain and explains each finding in plain words. Run a free check on each domain you own; paid plans on the pricing page cover several websites and alert you when records change, which is useful for spotting a lockdown record removed by accident.

Related reading

• Email Spoofing: How to Stop People Sending Mail as Your Domain
• DMARC for Subdomains: How the sp Tag Protects Your Domain
• MX Records Explained: How Email Finds Your Mail Server
• Domain Hijacking: How to Protect Your Domain Name and DNS

The bottom line

Every domain you own can be used to impersonate you unless it says otherwise. For domains that never handle e-mail, publish v=spf1 -all, a DMARC record with p=reject and a null MX. Keep an inventory of all your domains, apply the records consistently, and replace them with a full setup if a domain ever starts sending mail.

FAQ

Do parked domains need SPF and DMARC?

Yes. Without them, criminals can spoof the domain more easily. v=spf1 -all and a DMARC record with p=reject tell receivers to reject any mail claiming to be from it.

What is a null MX record?

A single MX record with priority 0 and a target of “.” that declares the domain accepts no e-mail. Senders then bounce messages immediately.

Should I use -all or ~all on a parked domain?

Use -all. There is no legitimate mail to protect, so a hard fail has no downside.

Does a redirect-only domain need these records?

Yes. A web redirect has nothing to do with e-mail. The domain can still be used in spoofed From addresses unless SPF and DMARC say otherwise.

What if my parked domain still receives some mail?

Keep working MX records for receiving and publish only the SPF and DMARC records if the domain never sends mail.

Do I need DMARC reports for a parked domain?

They are optional. Reports can show abuse attempts, which is useful information, but the reject policy protects the domain either way.