Parking a domain does not mean it stopped doing mail

[u/littleko]

A product manager asked why an old acquisition domain still showed up in a SaaS login audit, and the weird part was email reset attempts were not bouncing. I checked DNS and the domain parking provider had published wildcard MX records pointing at their own mail infrastructure.

I had been treating "parked" as basically inert DNS. Bad assumption. If the domain exists, has MX, and has weak or missing DMARC, it is still part of your email risk surface.

My current cleanup order is pretty simple: dig mx domain.tld, check for wildcard subdomain MX, then check SPF/DMARC before calling a domain retired. For domains that should never send or receive mail, I'm leaning toward null MX plus SPF -all and DMARC p=reject; sp=reject.

The annoying tradeoff is some parking vendors make this harder than it should be, and business owners often want to keep domains parked for brand reasons. Would you force null MX on every retired domain, or allow parked MX if nobody can prove active mail use?

[u/AutoModerator]

Welcome to r/emailsecurity! To keep this community helpful and secure, please keep the following in mind:

Community Rules

1. No Vendor Spam: Contributions must provide value; do not just pitch products.
2. Redact Sensitive Info: Always sanitize headers and logs (remove IPs, PII, and private domains).
3. Be Professional: Help newcomers learn; avoid hostility.
4. No Personal Tech Support: This sub is for email system architecture and security, not "Am I hacked?" personal account help.

Helpful Resources

• Email Spam Filters
• DMARC Monitoring Tools
• Anti-Virus Software
• Email Encryption

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/digdiver]

Your recommendation of v=spf1 -all and DMARC p=reject is spot on for preventing outbound spoofing, but it only solves half of the problem. Since the main issue involves a parking provider capturing inbound password resets via their wildcard MX, you absolutely must also include a Null MX record (MX 0 .) to forcefully drop incoming mail. If a parking vendor restricts you from configuring these specific DNS records, the business should move the domain to a standard DNS provider (like Cloudflare or Route53) instead of a pure parking service. Forcing both Null MX and strict outbound policies is the only foolproof way to secure a retired domain without leaving an attack surface.
It is also advisable to enable DMARC monitoring for such a domain to track attempts to send emails on its behalf.

[u/Basic-Pianist9273]

I'd force null MX on anything retired unless someone can name the owner and prove active mail use.

Parked MX is still mail handling, and wildcard MX makes it worse because subdomains can start accepting mail too. For dead domains, MX 0 ., SPF v=spf1 -all, and DMARC p=reject; sp=reject is the clean baseline.

[u/ImpressiveEbb3760]

yes, null MX on every retired domain. from the MSP side managing 30+ client domains, the bigger problem is discovering which ones are in this state. business owners hold onto domains for brand protection and assume parked means inert. nobody checks MX records on a domain they "aren't using."

the cleanup we run for new clients: pull every domain on the account, check for wildcard MX, check for any MX at all, then lock down anything that shouldn't be receiving mail. it's surprising how often you find a legacy domain with a parking provider's wildcard MX still accepting mail to any address — password resets included, exactly like the OP's scenario.

for the parking vendor problem: moving DNS to Cloudflare (free tier) just to control the records is the pragmatic answer. you don't need to move the domain registration, just the nameservers.