Protecting parked and no-mail domains

9 June 2026 · 11 min read

Most advice about email authentication assumes you are trying to deliver mail. You have a marketing platform, a billing system, a help desk, and you want all of them to pass DMARC so your invoices and newsletters land in the inbox. That is the hard case, and it deserves the attention it gets.

There is a much easier case that almost everyone neglects: the domain that sends no mail at all. The brand you registered to stop a squatter. The old company name you kept after a rebrand. The marketing campaign domain you bought for a launch three years ago. The "parked" placeholder a registrar set up for you. None of these send a single legitimate message, and yet every one of them is a fully usable From address for a fraudster. If you have not locked it down, an attacker can send mail as accounts@your-old-brand.com and there is nothing in the world's mail systems telling receivers to reject it.

The good news is that no-mail domains are the simplest possible thing to secure correctly. There is no inventory of senders to build, no alignment to chase, no ramp from p=none to p=reject to babysit, because the moment you decide the domain sends nothing you can publish the strictest possible records straight away with zero deliverability risk. This article explains exactly what to publish, why each record matters, and how to confirm it is right. You can check any domain against your own DNS as you read using the free diagnostic tools.

Why a silent domain is still a target

A spoofer does not care whether you use a domain. They care whether receivers will accept mail that claims to come from it. The visible From: address is the part of a message a human reads and trusts, and unless you have published policy that says otherwise, the global default is permissive: an unauthenticated message from an unknown domain is usually delivered, perhaps with a soft warning, often with nothing at all.

That makes an unprotected parked domain genuinely valuable to an attacker for three reasons.

• It carries trust you built and then forgot. A domain that matches your old trading name, a sister brand, or a plausible variant of your main domain lends instant credibility to a phishing email. Recipients recognise the name even if you no longer use the address.
• Nobody is watching it. Because the domain sends no real mail, no one reviews bounces, no one notices reports, and no security team has it on a dashboard. Abuse can run for months undetected.
• It is a clean reputation. Your main domain may be on p=reject and well defended. The parked domain next to it is wide open, and an attacker will always pick the open door.

The attack does not even need to fool a person directly. Spoofed domains feed invoice fraud, where a forged supplier or executive address requests a payment change, and the cost of one successful instance dwarfs the entire effort of locking down a hundred dormant domains. We go deeper into that scenario in how a spoofed domain enables invoice fraud.

The three records every no-mail domain needs

Securing a sending domain is a project. Securing a no-mail domain is three DNS records and ten minutes. The aim is to tell every receiver, in the clearest possible terms, two things: nothing is authorised to send from this domain, and any mail that claims to come from it should be rejected.

You need an SPF record that authorises nothing, a DMARC record at the strictest policy, and a null MX record that declares the domain accepts no mail either. Optionally, a null DKIM record makes the intent explicit. Let us take them in turn.

1. An SPF record that authorises nothing

SPF (Sender Policy Framework) is a TXT record at the root of the domain that lists which servers may send mail using it. For a domain that sends nothing, the list is empty, and the record should explicitly fail everything else.

Publish this as a TXT record on the apex (example.com):

v=spf1 -all

That is the whole record. v=spf1 declares it as SPF. -all is a hard fail: it tells receivers that no IP address is authorised, and any host claiming to send for this domain fails SPF. There are no include:, a, or mx mechanisms because there are no legitimate senders to authorise.

Be deliberate about the qualifier. -all (hard fail) is what you want for a no-mail domain. Avoid ~all (soft fail), which only marks failing mail as suspicious rather than rejecting it, and never publish +all, which authorises the entire internet and is catastrophically wrong. For a silent domain there is no reason to be gentle: nothing legitimate will ever be caught by -all, so use it.

Confirm the record resolves and parses with the SPF checker. On a no-mail domain it should report a single hard-fail mechanism and zero DNS lookups, which is exactly what you want. If you also run a sending domain, our explainer on the ten-lookup limit in how SPF flattening works is worth a read, but a no-mail domain will never come close to that limit.

2. A DMARC record at p=reject

SPF on its own is not enough, for a subtle but important reason: SPF validates the envelope sender (the return-path), not the visible From: header that a human actually reads. A spoofer can pass or sidestep SPF using their own domain in the envelope while still forging your domain in the From: line. The mechanism that ties protection to the visible address is DMARC, and it is the record that does the real work.

Publish this TXT record at _dmarc.example.com:

v=DMARC1; p=reject; rua=mailto:dmarc@yourmonitoringdomain.com; aspf=s; adkim=s

Each part earns its place.

• v=DMARC1 declares the record version.
• p=reject is the policy, and for a no-mail domain you go straight to it. There is no monitoring ramp, no p=none first, no p=quarantine step, because there is no legitimate mail that reject could possibly harm. This is the one situation in all of DMARC where jumping straight to the strictest policy is not only safe but correct.
• rua=mailto:... is the address that receives aggregate reports. Even a silent domain benefits from reports, because they show you the spoofing attempts that are now being rejected, which is useful evidence that the lockdown is doing its job. Point it at a mailbox or service you actually monitor, ideally on a different domain that does receive mail.
• aspf=s and adkim=s set strict alignment. On a sending domain relaxed alignment is usually right, but on a no-mail domain strict is a clean, defensible choice: there is no subdomain mail to accommodate, so demanding exact-match alignment costs nothing and tightens the policy.

If you would rather not hand-write the syntax, the DMARC generator will build a correct record from a few choices, and you can verify the published result with the DMARC checker. For a no-mail domain the checker should show p=reject and a valid rua, and that is the headline result you are looking for.

3. A null MX record so the domain receives nothing either

Spoofing is about outbound mail, but a forgotten domain often has a stale MX record pointing at a mail server that no longer belongs to you, or no MX record at all, which lets opportunistic senders attempt delivery. Declaring that the domain accepts no inbound mail closes that gap and removes any ambiguity.

The standard way to say "this domain receives no mail" is a null MX record, defined in RFC 7505. Publish a single MX record with priority 0 and a target of . (a literal dot):

example.com.   IN   MX   0   .

A receiving server that looks up your MX and finds the null record knows immediately that the domain has no mail service, and stops trying to deliver. This is cleaner than leaving the MX blank, and far safer than leaving an old MX pointing at infrastructure you no longer control, which is itself a hijacking risk.

4. A DKIM wildcard that revokes all keys (optional but tidy)

DMARC passes if either SPF or DKIM aligns, and you have already neutralised SPF and set p=reject. So a DKIM lockdown is not strictly required. But if you want to leave no DKIM selector usable and make your intent explicit, you can publish a wildcard DKIM record with an empty public key, which signals that any DKIM signature for this domain should be treated as revoked:

*._domainkey.example.com.   IN   TXT   "v=DKIM1; p="

An empty p= means "this key is revoked". It is belt-and-braces, useful mainly for domains that once sent mail and may have selectors floating around, and it does no harm to add. If you are curious how DKIM keys and selectors work in the first place, the DKIM checker lets you inspect any selector on any domain.

Do not forget the subdomains

A common and dangerous oversight is to lock down the apex and leave subdomains exposed. DMARC has a separate subdomain policy tag, sp, that controls what happens to mail from anything.example.com as opposed to example.com itself. If you omit sp, subdomains inherit the main p value, which on a no-mail domain is fine because p=reject then covers everything. But it is worth being explicit so the intent survives anyone later editing the record:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourmonitoringdomain.com; aspf=s; adkim=s

Setting sp=reject alongside p=reject states plainly that no subdomain sends mail either. This matters because attackers love subdomains of dormant domains: login.your-old-brand.com looks even more convincing than the bare domain, and unless your policy explicitly covers it, a spoofer can pick a subdomain you never registered DNS for and there is nothing to stop them. We cover the mechanics and the gotchas in the subdomain DMARC record explained.

One subtlety to be aware of: a child organisation that wants different handling can publish its own _dmarc record on a subdomain, which overrides the parent sp. For a no-mail domain you almost never want this, so leave the subdomains without their own records and let sp=reject govern them all.

A complete worked example

Suppose you rebranded from acme-legacy.com to acme.com two years ago. The legacy domain still resolves, still appears on old letterheads and email signatures, and sends nothing. Here is the full set of records to publish, all on acme-legacy.com.

The apex SPF record, as a TXT record on acme-legacy.com:

v=spf1 -all

The DMARC record, as a TXT record on _dmarc.acme-legacy.com:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@acme.com; aspf=s; adkim=s

Note the rua points at the live domain acme.com, which does receive mail and is monitored, so the reports actually reach someone.

The null MX record on acme-legacy.com:

acme-legacy.com.   IN   MX   0   .

And, optionally, the revoking DKIM wildcard on *._domainkey.acme-legacy.com:

v=DKIM1; p=

That is the entire job. No alignment chasing, no enforcement ramp, no risk of breaking mail, because there is no mail to break. From the moment these propagate, a forged message from billing@acme-legacy.com fails SPF, fails DMARC, and is rejected by every major receiver that honours the policy, which today includes Gmail, Yahoo, and Microsoft.

How to verify it actually works

Publishing is not the same as protecting. DNS edits can be typo'd, applied to the wrong zone, or silently overridden by a registrar's default parking records. Always confirm.

1. Check DMARC. Run the DMARC checker against the domain and confirm it reports p=reject, a valid rua, and no syntax warnings.
2. Check SPF. Run the SPF checker and confirm a single -all mechanism with no authorised senders.
3. Check the MX. Confirm the null MX (priority 0, target .) is in place and no stale MX survives.
4. Watch the reports. Once aggregate reports start arriving at your rua address, you will see rejected spoofing attempts. This is the proof your lockdown is live and working. If your reports are empty, that usually means the policy is so effective nobody is bothering, or that the rua is misconfigured, which we troubleshoot in why your DMARC reports are empty.

If you manage a portfolio of dormant domains, checking each by hand once and never again is a trap, because registrar migrations, DNS provider changes, and well-meaning colleagues all silently undo records over time. The whole point of continuous monitoring is to catch the day a record disappears and alert you before a spoofer notices the gap. A parked domain that was locked down in 2024 and quietly reverted in 2026 is back to being an open door, and nobody will know until it is used.

Common mistakes specific to no-mail domains

Even this simple task has a few recurring failure modes worth naming.

• Using ~all instead of -all. Soft fail leaves a crack open. On a no-mail domain there is no legitimate sender to protect, so commit to the hard fail.
• Stopping at SPF. SPF alone does not protect the visible From: header. Without p=reject, a spoofer can forge your domain in the header while passing SPF on their own envelope domain. DMARC is the record that closes this, as we explain in DMARC alignment explained.
• Leaving a p=none policy in place "to be safe". p=none does nothing to block spoofing; it only requests reports. For a sending domain it is a sensible first step, but for a no-mail domain it is a missed opportunity. There is no reason to monitor before enforcing when nothing legitimate can break. Go straight to reject.
• Forgetting the subdomains. Without sp=reject made explicit, a future edit could weaken subdomain handling. State it.
• Leaving a stale MX. An old MX pointing at infrastructure you no longer own is both a delivery target and a takeover risk. Replace it with a null MX.
• Setting it and forgetting it. Records get reverted. Monitor them.

If you want a fuller catalogue of what goes wrong across all kinds of domains, the ten most common DMARC mistakes is a useful companion, and the glossary defines any term here you want to nail down.

The practical takeaway

A domain that sends no mail is the easiest thing in your entire estate to secure, and the most commonly left wide open. Three records do the job: v=spf1 -all to authorise nothing, a DMARC record at p=reject with sp=reject to reject any forged mail, and a null MX to refuse inbound delivery. There is no ramp, no risk, and no reason to wait, because there is no legitimate mail that strict enforcement could ever harm.

Start by checking what your dormant domains actually publish today using the free DMARC checker and SPF checker; you may be surprised how many are completely unprotected. If you have a portfolio of parked, legacy, or campaign domains and would rather have the records published, verified, and continuously watched for you, the done-for-you DMARC service locks each one down to p=reject and alerts you the moment a record changes, so a domain you secured once stays secured for good.