Dangling DNS and Subdomain Takeover: Why Old Records Hurt Email

Every service you have ever connected to your domain left a record behind: a CNAME for a landing-page builder, an MX for a help-desk tool, an SPF include for a newsletter platform you stopped paying for. When the service is gone but the record remains, it is "dangling", and in the worst case anyone who signs up for that service can claim your subdomain and send mail from it that passes your own authentication. Here is how that happens and how to clean it up in an hour.

Quick answer

A dangling record points at a service that no longer knows about your domain. If the service lets new customers claim any hostname, an attacker can register yours and receive or send mail on a subdomain of your domain. The fix is an inventory: list every DNS record, identify what each one is for, delete the ones for cancelled services, and remove their SPF includes and DKIM selectors at the same time.

How a takeover actually works

1. Two years ago you pointed campaigns.yourdomain.com at a marketing platform with a CNAME, and added its include: to your SPF record.
2. You cancelled the platform. Nobody deleted the CNAME or the SPF include.
3. An attacker scans your DNS, sees a CNAME to the platform, and checks whether the hostname is unclaimed there. It is.
4. They open a free account at the platform and claim campaigns.yourdomain.com. The platform now serves their content at your subdomain.
5. Because the include is still in your SPF record, mail the attacker sends through the platform passes SPF for your domain. If your DMARC record lacks an sp= tag for subdomains, or is still p=none, the mail lands.

The records to hunt for

• CNAME records pointing to hosting, page-builder, help-desk, status-page, or CDN providers you no longer use.
• MX records on subdomains for ticketing or inbound-parsing tools you cancelled.
• SPF include: mechanisms for platforms you no longer send from. Each one is also a wasted DNS lookup.
• DKIM selector records (anything under _domainkey) for old providers. A previous mail host that still holds the private key can sign as you until you delete its selector.
• TXT verification records (google-site-verification, MS=, and similar) for accounts you closed. Low risk, but noise that hides real problems.
• A and AAAA records pointing at cloud IPs you released. Cloud providers reuse addresses.

The one-hour cleanup

1. Export the full zone from your DNS host, or copy every record into a spreadsheet: type, host, value, and a column for "what is this for".
2. Fill in the purpose column. Anything you cannot explain gets a question mark.
3. For each CNAME, visit the target hostname in a browser. An error page saying the domain is not configured or unclaimed is a red flag.
4. For each SPF include, confirm you still have an active account at that provider. If not, remove the include.
5. For each DKIM selector, check whether it belongs to your current mail host. If not, delete it.
6. Delete the question-mark records after a week of asking around, and keep the spreadsheet as your DNS inventory.
7. Re-check SPF with a lookup-count tool. Removing stale includes often fixes a PermError you did not know you had.

What a clean record set looks like

A small business running mail through OquMail and a website at a single host typically needs fewer than ten records: A or CNAME for the site, MX to mail.oqumail.com priority 10, one SPF TXT of v=spf1 mx a:mail.oqumail.com ~all, one DKIM selector at _domainkey, a DMARC TXT at _dmarc, and perhaps a couple of verification TXT records. OquMail's live DNS verification confirms the four mail records are correct, which makes the extras easy to spot.

Protect subdomains you have not created yet

• Add sp=reject to your DMARC record so mail from any subdomain without its own DMARC policy is rejected.
• Publish a wildcard-free zone: avoid *.yourdomain.com records that match anything.
• When you decommission a service, delete its records the same day, as part of the cancellation checklist.

Common questions

Do all providers allow subdomain takeover?

No. Many now require a verification record before a hostname can be claimed. The risk is real at providers that still let anyone claim an unverified hostname, and you cannot easily tell which those are from outside, so removing dangling records is the reliable defence.

Is a stale SPF include dangerous if the CNAME is gone?

Less so, but it still authorises every customer of that provider to pass SPF for your domain, and it costs a DNS lookup. Remove it.

How often should I repeat the inventory?

Annually, and after cancelling any service that touched DNS. Keep the spreadsheet current and the check takes ten minutes instead of an hour.