How to remove MX records from a parked domain

Q: Do I still need SPF and DKIM if the domain never sends mail?

Yes for SPF: publish v=spf1 -all so a receiver sees no sender is authorised. DKIM has no equivalent "never sign" record; revoke old selectors with an empty p= value if the domain used to sign mail. None of SPF, DKIM or the null MX replaces the others, each closing a different part of the same gap.

Removing MX from a parked domain means publishing a null MX record (priority 0, target a single dot), not deleting every MX record outright. This guide covers why the record matters, how to confirm you have this fault, the exact DNS records for each likely cause, and how to verify the fix. The mistake to avoid: zero MX records, which lets mail fall back to the domain's website.

Key points

A parked domain with zero MX records is not protected: mail falls back to its A or AAAA record instead, per RFC 7505.
The fix is a null MX record: priority 0, target a single dot, for example example.com. MX 0 .
NCSC's guidance for parked domains pairs the null MX with SPF v=spf1 -all and DMARC at p=reject (refuse fakes) with a rua= address, but the address in its example was NCSC Mail Check's, which stopped DMARC aggregate reporting on 24 March 2025, so use a working one instead.
ShieldMarc's free DMARC generator leaves sp= out by default, so a parked domain's unused subdomains follow its p=reject policy; adding sp=reject only makes that explicit.
Registrar shortcuts can undo the fix, such as Porkbun's "Fix DNS" email button, which points MX back at Porkbun's own mail servers, so the records need checking again later, not just once.

Contents

What removing MX from a parked domain actually means
How to confirm this is actually your problem
A live MX record is still pointing at an old mail service
There's no MX record at all, so mail falls back to the website
SPF and DMARC were never published
Old DKIM selectors are still live
Verifying the fix
Preventing it coming back
Start today
Frequently asked questions

What removing MX from a parked domain actually means

A parked domain, such as one registered defensively, sends and receives no legitimate mail, per NCSC's guidance on parked domains. The goal is not an empty MX field but a null MX record, priority 0, target a single dot, which RFC 7505 formalises.

DMARC at enforcement (p=reject, refuse fakes), defined by RFC 9989, the current standard, asks receivers to refuse mail using the domain in the From address that fails authentication, though RFC 9989 has them quarantine it unless other analysis supports rejecting; it does not cover lookalike domains or display-name spoofing, which need separate handling. Null MX, SPF and DMARC are three of four related fixes, alongside DKIM cleanup; this article covers MX, and the fuller setup guide for parked domains covers the rest.

How to confirm this is actually your problem

Run a DNS lookup for MX with the free DNS Lookup tool, which checks A, AAAA, MX, TXT, NS, SOA and SRV: a real mail host, nothing, or already a null MX. If MX is empty but an A or AAAA record exists, mail is still deliverable by fallback, the exact fault RFC 7505 exists to close.

Check SPF and DMARC at the same time with the free SPF, DKIM & DMARC Checker, since a missing MX record alone does not stop a forged From: address. For a fast overall read, run Domain Trust Check; MX or null-MX status is not one of its 16 checks, so a good grade does not confirm this fix.

A live MX record is still pointing at an old mail service

It happens where an MX record from a former Microsoft 365 or Google Workspace tenant, a previous host or a registrar's default mail forwarding was never removed.

The fix:

Look up the current MX record for the domain.
Remove it from the DNS zone.
Add a null MX record, priority 0, target a single dot:

example.com. MX 0 .

The target is the single character ".", not a hostname (RFC 7505; NCSC uses the same form). Some panels reject a bare "." as typed input; use whichever syntax the panel accepts, still at priority 0, and confirm the published target is the single dot itself, not a hostname.

Fixing MX on a parked domain

Check current records
Look up MX, SPF and DMARC before changing anything.
Publish a null MX
Priority 0, target a single dot: example.com. MX 0 .
Add SPF and DMARC
v=spf1 -all, then p=reject with a working rua= address.
Revoke old DKIM
Set any known selector's key to empty (p=) if the domain used to send mail.
Verify and monitor
Recheck DNS, then add a monitor so a later reset doesn't go unnoticed.

There's no MX record at all, so mail falls back to the website

RFC 7505's own abstract names this trap: with no MX record, sending servers fall back to the domain's A or AAAA record, usually a website's, not a mailbox. If MX is empty but A or AAAA resolves, the domain is exposed to whatever answers on port 25 there.

Publish the same null MX record as above so sending servers are told not to attempt delivery, rather than leaving the field blank. With no A or AAAA record either, the fallback risk does not apply, but the null MX record still removes ambiguity for later. Parking pages usually keep an A record live regardless: Porkbun's, for example, points the root back at its own servers, so check A and AAAA even on a domain believed empty.

SPF and DMARC were never published

A missing MX record does not stop a forged From: address; NCSC pairs SPF and DMARC with the null MX so that receivers know no mail should come from the domain (NCSC).

Publish an SPF record authorising no senders:

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

Publish a DMARC record at enforcement with a working rua= address, using the free DMARC generator. It leaves sp= out by default, so subdomains follow p=reject; the record below adds sp=reject only to make that explicit:

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

Pro Tip: Publish the null MX record in the same DNS change as the SPF and DMARC records, not on its own: a spoofer never needed your MX record to forge the From address in the first place.

If the domain cannot receive mail at all, point rua= at a monitored mailbox and add an authorisation record there, a pattern the Dutch Internet Standards Platform shows:

Name:  example.com._report._dmarc.reports.example.net
Type:  TXT
Value: v=DMARC1

To have ShieldMarc read the reports, add the domain to its free Starter plan once live and make sure rua= sends them to ShieldMarc: receivers send aggregate reports only to the addresses in rua=.

Old DKIM selectors are still live

Relevant only if the domain used to send mail: a closed provider's DKIM selector records often stay published indefinitely. Replacing an old selector's key with an empty one marks it revoked, so any mail still signed with that key fails DKIM (RFC 6376).

Replace each known selector's record with an empty key:

selector._domainkey.example.com. TXT "v=DKIM1; p="

A wildcard *._domainkey record with an empty key only answers for selector names that have no record of their own, so it does not revoke an old selector that is still published. ShieldMarc's free DKIM checker probes 18 common selectors plus up to 10 typed in, finding what is still published before writing the revocation records.

Verifying the fix

Query the MX record again, by dig, nslookup, or the free DNS Lookup tool: confirm exactly one record, priority 0, target a single dot. Re-run the SPF, DKIM & DMARC Checker to confirm SPF resolves to -all and DMARC sits at p=reject with a rua= address; it checks the record, not whether reports reach that mailbox.

DNS answers can stay cached for up to the old answer's TTL, which dig shows but ShieldMarc's DNS Lookup does not, so allow that period to pass before treating a cached answer as a failed fix. ShieldMarc runs no live SMTP test, so it cannot confirm a server refuses real delivery; RFC 7505 specifies a DNS record, not a connection test.

Preventing it coming back

Registrar shortcuts can undo the fix: Porkbun's "Park Domain" feature, for example, changes only web records, but its "Fix DNS" email button configures Porkbun's own MX and SPF records, undoing both the null MX and the v=spf1 -all record just configured, so whoever inherits the domain must not click it.

Protect your parked domains first. They are easier to deal with, and once protected, require no maintenance.

Source: NCSC

A DNS monitor (Professional, MSP or Trial) checks A, MX, TXT and NS every five minutes and emails "DNS Change Detected" with no diff, so pair it with a DNS Lookup check; a DMARC health monitor emails only when the policy changes, catching a p=reject that quietly reverts to p=none (monitoring only). MSPs with many client domains can group them in one organisation: Professional covers 25 domains, MSP 100 slots.

I think a parked domain is one of the cheapest fixes here: three DNS records, no infrastructure, and nothing that should need to change once correct. The only task afterwards is noticing if someone else's reset undoes it.

Start today

Pull the current MX, SPF and DMARC records with the free DNS Lookup and SPF, DKIM & DMARC Checker tools, no account needed, then build the DMARC record with the free DMARC generator and publish it together with the null MX and SPF records shown above.

Add the domain to ShieldMarc's free Starter plan so its DMARC reports are monitored from day one. For more than one parked domain, compare Professional and MSP pricing for DNS and DMARC-health monitors, and read the fuller setup guide for parked domains for the complete SPF, DMARC and DKIM walkthrough beyond MX alone.

Frequently asked questions

Do I need an MX record if my domain doesn't send or receive email?

Yes, but not a working one: publish a null MX record, priority 0, target a single dot. With no MX record, mail falls back to any A or AAAA record the domain has, per RFC 7505.

What happens if I just delete the MX record instead of publishing a null MX?

If the domain has no A or AAAA record, deleting MX also makes delivery fail, since RFC 5321 treats the unusable implicit MX as an error, but a null MX still holds if an A record is added later. If it has one, such as a website, deleting MX leaves that address as the implicit mail target under RFC 5321, so publish the explicit null MX record instead.

Can I remove MX records from a domain that still forwards email?

No: a domain that still forwards mail elsewhere needs a working MX record, so it is not parked in this sense, and removing MX breaks the forwarding rather than tightening security. Confirm whether the domain still forwards mail before applying this fix.

Why is my DMARC report showing no data after I set up a parked domain?

Aggregate reports only arrive from receivers that saw mail using the domain, on days they saw it, so a quiet parked domain can mean nothing happened, not a broken record. Receivers that do see mail typically send one report per UTC day, so confirm the record's validity with a checker rather than waiting on reports. If rua= points at a mailbox on another domain, also check with dig that the authorisation record shown above is published in that domain's DNS; without it, receivers ignore that address and send it nothing.

Do I still need SPF and DKIM if the domain never sends mail?

Yes for SPF: publish v=spf1 -all so a receiver sees no sender is authorised. DKIM has no equivalent "never sign" record; revoke old selectors with an empty p= value if the domain used to sign mail. None of SPF, DKIM or the null MX replaces the others, each closing a different part of the same gap.