How to Find and Retire Orphaned Email Domains

The incident that should not have happened

In March, a marketing team launched a campaign microsite. They set up a domain, pointed it at a server, and added a catch-all MX record so the inbox would catch form submissions and test replies. The MX forwarded everything to an intern's mailbox.

In April, the campaign ended. The website was taken down.

In May, the intern left the company.

In July, someone found spam flowing through the catch-all mailbox. Nobody could explain why. The domain had no DMARC record. Nobody was assigned to own it. The team that had launched it considered it dead. From an email security perspective, it was a wide-open receive path with no owner and no protection.

This is not a rare scenario. It is a repeatable pattern that plays out in organizations of every size, and it rarely shows up in security reviews until something has already gone wrong.

What is an orphaned email domain

An orphaned email domain is a domain that was registered or configured for a specific project, campaign, or short-lived service and later abandoned without properly decommissioning its DNS records.

The domain may no longer have a website. The team that created it may have disbanded. The person who approved the mail setup may have moved on. But the MX record is still live, pointing at a mailbox nobody monitors, accepting mail for any recipient at that domain.

The problem is not the domain itself. The problem is what the domain's DNS records still do, and who is responsible for them.

Why catch-all MX makes orphaned domains dangerous

A catch-all MX record accepts mail for any address at the domain, not just known addresses. That is the intended behavior when a domain is actively used. When a domain is abandoned, the catch-all becomes a receive path that attackers can probe, test, and potentially exploit.

Common abuse patterns:

Inbound spam and phishing relay. The catch-all accepts inbound spam. If forwarding is enabled, the mailbox forwards it elsewhere or gets flagged as a spam source.
Mailbox enumeration. Attackers can send test messages to common addresses at the domain and observe which ones are accepted versus rejected, building a map of valid recipients.
Credential stuffing via forwarded mail. If the abandoned mailbox still has active credentials and is connected to other services, a compromised forwarding rule can expose its contents.
Reputational damage. If the mailbox is used to relay mail out (even inadvertently due to an open relay), the domain's IP reputation suffers.

The catch-all is not inherently dangerous. It is dangerous on a domain that nobody owns, nobody monitors, and nobody intends to keep running.

How missing DMARC compounds the risk

Without DMARC, there is no published policy telling receivers how to handle mail that claims to be from the domain but fails authentication. More importantly, there is no mechanism for the domain owner to receive reports about who is sending mail using the domain.

This means:

Unauthorized senders using the domain can operate invisibly. There is no aggregate report (RUA) sent to a mailbox nobody checks.
Legitimate internal services that send mail from the domain are unknown and unprotected. If one of them misconfigures SPF, mail lands in spam with no warning.
The transition from "abandoned" to "actively exploited" happens without any alert. By the time abuse reports arrive, the damage may already be done.

A domain with no DMARC record is not just unprotected. It is unmonitored. Those are two different problems, and both matter.

How the real incident played out

Here is what happened at the company with the abandoned microsite domain:

The abuse report arrived at the security team, not the marketing team. The security team had no record of the domain. They traced the MX back through DNS logs and found it belonged to a campaign that had been decommissioned months earlier. The marketing team that had launched it had no idea the MX was still active. The intern who had owned the mailbox was gone. The server had been repurposed, but the domain's DNS records had not been updated.

The domain had no DMARC record. There was no way to know whether any other systems were sending mail using the domain, or whether external parties had already been probing it.

The fix was straightforward: remove the MX record, or point it to a null MX and publish DMARC p=reject. But getting there required figuring out who owned the domain, who had authorized the original mail setup, and whether any legitimate mail streams depended on it. That investigation took longer than the actual fix.

How to audit your domain portfolio for orphaned MX records

Run this audit at least quarterly, or after any decommissioning project that touched DNS.

Step 1: Get a complete list of your domains

Export every domain registered under your organization, including subdomains that appear in DNS records. Do not limit yourself to apex domains. A subdomain like campaign-summer-2025.example.com can have its own MX records independent of the apex.

Step 2: Check each domain for MX records

For every domain in your list, query its MX records. You can do this with dig MX domain.com or any DNS lookup tool. Flag every domain that returns MX records.

Step 3: Classify each MX as active or orphaned

For each domain with MX records, determine:

Is the website or service still live?
Is there a documented owner for this domain?
Does the MX destination go to a monitored, maintained mailbox?
Is there a DMARC record for the domain?

A domain is orphaned if the website or service is dead, there is no clear owner, and the mailbox is unmonitored or abandoned.

Step 4: Check for DMARC on domains with MX records

Any domain accepting mail should have a DMARC record, even if it is just p=none for monitoring. Run dig TXT _dmarc.domain.com and look for a published policy. If nothing is there, flag it.

A practical note: reviewing DMARC reports for all your domains at once is faster and more reliable than querying each TXT record individually. DMARCFlow processes DMARC aggregate reports across your entire domain portfolio and flags domains that have no published DMARC policy, making the orphaned domain check in Step 4 faster to execute at scale.

Step 5: Identify catch-all MX on inactive domains

A catch-all MX accepts mail for @domain.com and any @anything.domain.com. On a live domain with an active mailbox, this is normal. On a domain you have forgotten, it is an open door. Check whether the accepted addresses are being monitored and whether forwarding rules could turn inbound mail into outbound abuse.

How to retire or secure an orphaned domain

Once you have identified an orphaned domain, you have two choices: retire it fully, or bring it under management.

Retire it if the domain is genuinely unused

1. Remove the MX record entirely, or set it to a null MX (0 .).

2. Publish DMARC p=reject so receivers reject any mail claiming to be from the domain.

3. Remove any SPF records that might authorize sending from the domain, or set SPF to v=spf1 -all.

4. Update your domain registrar records so the domain cannot be accidentally renewed by someone else without going through a deliberate re-registration process.

5. Document the retirement in your domain inventory so the decision is recorded.

Secure it if the domain might be needed again

1. Assign a named owner to the domain. Document this in a domain inventory with a contact person.

2. Set the MX to a monitored, maintained destination. If you do not need the mail, use a null MX and handle inbound mail through a forwarding rule to a monitored address.

3. Publish DMARC p=none for at least 30 days. Review aggregate reports to confirm no unexpected mail is being sent from the domain.

4. After confirming the domain is clean, upgrade to DMARC p=quarantine or p=reject depending on how critical the domain is.

5. Schedule a quarterly review of the domain to confirm it is still needed.

If third parties need to send mail using the domain

This is where things get complicated. If a vendor, partner, or subsidiary sends mail that appears to come from the domain, removing MX or setting p=reject will break their delivery. Before taking action, confirm whether the domain has legitimate third-party senders. DMARC aggregate reports will show you who is actually sending mail from the domain, which is the fastest way to answer that question.

How DMARC reports help catch orphaned domains automatically

The audit above is a point-in-time snapshot. DMARC reports run continuously.

DMARC aggregate reports (RUA) are sent to the mailbox you specify in your DMARC record. They contain a summary of every domain sending mail claiming to be from your domain, along with authentication results and the sending infrastructure.

If a retired campaign domain suddenly appears in your DMARC reports, that is a signal it has not been properly decommissioned. The report shows which servers are sending mail using that domain, giving you the information to track down who set up the MX and whether the sending is legitimate or unauthorized.

This is why the audit Step 4 matters. Without DMARC reports, discovering an orphaned domain requires a manual DNS sweep. With DMARC reports, the discovery happens automatically, every time a report is delivered. If a decommissioned campaign domain is being used to send mail - whether by a misconfigured internal service or an external party - DMARC reports surface it without you having to think about it.

For teams managing a large domain portfolio, processing DMARC reports manually is time-consuming and error-prone. DMARCFlow automates this across your entire domain set, flagging domains with no DMARC policy, unexpected sending sources, and sudden changes in authentication results. Running a quarterly manual audit alongside ongoing DMARC monitoring gives you both the broad view and the continuous watch.

FAQ

Can I just remove the website and leave the MX?

No. The website and email infrastructure are independent. Removing the website does not remove the email attack surface. Attackers do not need a website to send mail to or from the domain.

Is p=none enough for a domain I am retiring?

No. p=none provides visibility but no protection. A domain that is retired should have p=reject set, or have its MX removed entirely. p=none is appropriate during the monitoring period before retirement, not after you have decided the domain is no longer needed.

How often should I audit my domain portfolio?

At minimum, quarterly. After any decommissioning project that touched DNS, run an immediate audit to confirm records were cleaned up. Domain ownership and project teams change frequently. A domain that was active and monitored six months ago may now be orphaned.

Who should own a decommissioned domain?

Nobody, if it is truly retired. But the decision to retire must be documented, and the execution must include DNS cleanup. If a domain might be needed again, it needs a named owner who is responsible for its DNS records, its mail flows, and its DMARC policy.

What if a third party is legitimately sending mail from my retired domain?

You need to know about this before you retire the domain. DMARC reports show you exactly which servers are sending mail using your domain. If a third party has legitimate sending infrastructure, their IPs should be included in your SPF record or they should be aligned via DKIM. If they are sending unauthenticated mail, that is a problem whether or not you retire the domain.

My catch-all MX goes to an unmonitored mailbox. Should I just delete it?

Probably yes, but first confirm nobody is using it. Check your DMARC reports to see if the domain is receiving mail. Check your mail logs to see if anything has arrived in the catch-all mailbox in the past 90 days. If the mailbox is truly empty and unmonitored, remove the MX, set a null MX, and publish DMARC p=reject.