Finding Legacy Domains That Still Send But Nobody Monitors

Most organisations carry old filing boxes in their DNS: domains set up for a 2017 campaign, a Brisbane pop-up, or a Sydney acquisition, then forgotten. Years later, these entries still resolve and their MX records remain untouched, so they can still send mail that looks like it came from you.

These dormant assets sit outside the active security perimeter. Firewalls do not watch them, dashboards do not flag anomalies, and the team that created them has moved on. Attackers love this quiet corner, which lets them impersonate your brand from infrastructure you still own.

Australian regulators have noticed. The Australian Cyber Security Centre warns that business email compromise is a top cybercrime, and the Notifiable Data Breaches scheme under the Privacy Act 1988 means a successful spoof can quickly become a reporting obligation. Cleaning these loose ends is part of meeting local compliance, not just hygiene.

The good news is that finding them is methodical. Working through your authoritative DNS, authentication records, and historical marketing footprint, you can map every domain still authorised to send, then decide which belong there.

Audit Your Authoritative DNS Records

Start at the source: the zone file held by your DNS provider. For .au domains, that means records maintained with your accredited registrar. Pull the zone and sort by subdomain. Anything not resolving to a service you still operate is a candidate for review.

Watch for subdomains created for one-off projects. A campaign microsite for a Melbourne trade show, a transactional subdomain for a defunct loyalty program, or a leaked development environment are common patterns. These often carry their own MX records, letting them send email independently of your primary domain.

List every subdomain with an MX or A record pointing to a mail server, then cross-reference with current business registers. If the team has been restructured, or the service decommissioned after a Perth office closure, the record has no business existing. Mark each for retirement or re-integration.

Review SPF, DKIM, and DMARC Across Every Zone

Your SPF record is a literal allow list of every host permitted to send mail for your domain. Read it slowly. Many Australian mid-sized businesses have SPF entries edited by hand over a decade, with multiple includes and a softfail default nobody questioned. Every mechanism is a legacy domain still authorised to send.

DKIM keys tell a similar story. Selectors like google, k1, or mandrill hint at historical providers. If your Adelaide team used a transactional platform three vendors ago, its DKIM key is still published, and mail signed with it will pass authentication. DMARC will not save you unless set to reject, which many local domains are not.

For each mechanism, ask whether the service is still under contract. Before removing it, confirm no live system relies on it, since transactional mail from your old Sydney ticketing partner could break. Set DMARC to quarantine, monitor reports for a quarter, then tighten to reject.

Trace Old Marketing and Acquisition Footprints

Domains rarely appear in your DNS by accident. They arrive through rebrands, launches, regional campaigns, and acquisitions. Talk to the longest-serving members of your IT and marketing teams, especially anyone who remembers your Sydney headquarters running a separate brand. The answer to why a subdomain exists is often a meeting in a Parramatta boardroom years ago.

Acquisitions are particularly fertile ground. If you absorbed a smaller operator in Queensland or Tasmania, the acquired domain may still be live with full sending rights. The original business might be gone, but its DNS entries were never cleaned, leaving a ghost that can still produce authenticated mail.

Walk through archived collateral, press releases, and invoice templates. Email footers often contain domain references that predated consolidation. Each tells you something is still out there. Periodic sweeps such as how to automate weekly checks for new domains that mimic your brand insights keep the picture current.

Validate Each Domain Against Current Operations

Once you have a list, treat it like an asset register. For each legacy domain, document who owns it operationally, what service relies on it, and when it was last verified. If you cannot answer the first two, the domain has drifted beyond your governance perimeter and is a candidate for removal.

Be careful with domains that still resolve to a website. A parked landing page from a closed Hobart campaign looks harmless, but its DNS often still includes mail records. Attackers register similar-sounding domains and use your dormant ones as cover, sending mail that appears to come from you.

Validation is where you decide between retirement and reactivation. Some legacy assets still serve a purpose, such as a customer portal used by a niche segment in Darwin. Fold these back into your monitored estate with current SPF, DKIM, and DMARC alignment. Everything else should have its MX entries removed and SPF mechanisms stripped.

Build a Repeatable Monitoring Process

A one-off audit will not protect you forever. New legacy domains appear every quarter through acquisitions, temporary projects, and regional campaigns. The teams creating them rarely think about DNS footprint, so the responsibility sits with whoever owns email authentication.

Schedule a quarterly review aligned with the Australian financial year. Automate discovery of new MX records on your apex domain, alert on new SPF includes, and watch for DKIM selectors appearing without an approved change ticket. This hygiene separates organisations that catch spoofing early from those that learn through the legal notices workflow once a regulator is involved.

Finally, document everything. Record the date, reason, and authoriser when you retire a domain. Capture the new authentication posture when you re-onboard a legacy asset. Legacy DNS is a discipline you maintain, much like patching or access reviews, and it pays dividends every time a phishing kit tries to ride on infrastructure you have already cleaned up.