KoltrixDangling DNS records and email: subdomain takeover risks
Stale CNAMEs and forgotten includes can let someone else send or host content on your domain. How takeovers happen and how to audit DNS for them.
On this page(7 sections)
DNS records outlive the services they point to. A CNAME for a marketing site that was shut down, an SPF include for a vendor you left, a DKIM selector delegated to a platform you no longer pay for: each is a small door left open.
For a domain that sends email, some of those doors lead straight to your reputation.
What "dangling" means
A dangling DNS record points at a resource you no longer control. The classic web example is a CNAME such as promo.example.com pointing to a cloud hosting hostname that was deleted. If the hosting platform lets anyone claim that hostname, an attacker can create it, and promo.example.com now serves their content, under your domain, often with a valid TLS certificate.
That subdomain takeover is bad on its own: phishing pages on your real domain are very convincing. Email adds several more ways for dangling records to hurt you.
Email-specific risks
1. Stale SPF includes
An SPF record like this delegates authorization to other domains:
example.com. TXT "v=spf1 include:_spf.mailhost.example include:spf.old-vendor.example ~all"If old-vendor.example lapses and someone else registers it, they control what spf.old-vendor.example returns. They can publish an SPF record including their own servers, which then pass SPF as authorized senders for your domain.
Even without a takeover, an include that returns nothing counts as a void lookup under RFC 7208. Two void lookups in one evaluation produce a permerror, which breaks SPF for all your mail.
2. Delegated DKIM selectors
Vendors often ask you to CNAME a DKIM selector to their infrastructure:
s1._domainkey.example.com. CNAME s1.dkim.old-vendor.example.Whoever controls the target publishes the public key. If the vendor's domain or that hostname falls into someone else's hands, they can publish a key whose private half they hold, and sign mail with d=example.com that verifies and aligns. DMARC passes. This is the most serious email-specific takeover, because it produces authenticated mail as your exact domain.
3. Subdomains that inherit trust
With relaxed DMARC alignment, mail authenticated for a subdomain aligns with your organizational domain. If an attacker takes over promo.example.com and the hosting platform also lets them configure email for it, or they can otherwise publish records under that name, they may be able to send mail authenticated for a subdomain that aligns with your From addresses.
4. Bounce and tracking domains
Custom bounce domains (bounce.example.com) and click-tracking domains (links.example.com) often CNAME to a provider. After you leave the provider, a dangling tracking CNAME can let someone else serve redirects from a domain your old emails link to, turning historical messages into phishing links.
5. MX records pointing nowhere useful
An MX record for a subdomain that points at a mail service you no longer use can, on some platforms, let another customer claim that domain and receive mail sent to it, including password reset emails sent by third-party services to addresses at that subdomain.
How to audit your DNS
Start from a full export of your zone, not from memory. Then check each record type:
| Record type | What to check |
|---|---|
| CNAME | Does the target resolve? Do you still have an account with the service? |
| SPF includes | Does each included domain still publish SPF? Is it still a vendor you use? |
| DKIM selectors (CNAME or TXT) | Is the vendor still active? Does the target still resolve? |
| MX on subdomains | Is the mail service still yours? |
| NS delegations | Do delegated subdomains still have working, controlled nameservers? |
| A/AAAA | Do the IPs still belong to you, especially cloud elastic IPs you released? |
A rough first pass with dig:
# CNAME targets that no longer resolve
while read name; do
target=$(dig +short CNAME "$name")
[ -n "$target" ] && [ -z "$(dig +short "$target")" ] && echo "DANGLING? $name -> $target"
done < names.txt
# SPF includes that return no SPF record
for inc in $(dig +short TXT example.com | grep -o 'include:[^ "]*' | cut -d: -f2); do
dig +short TXT "$inc" | grep -q 'v=spf1' || echo "VOID include: $inc"
doneA target that does not resolve is the obvious warning sign, but a target that still resolves is not proof of safety: it may already have been claimed by someone else. Confirm ownership through your account with each service.
Fixing and preventing
- Delete records when you leave a service. Make DNS cleanup part of every vendor offboarding checklist, alongside cancelling the subscription.
- Remove records before deprovisioning resources. Delete the CNAME first, then the cloud resource, so there is no window where the name points at a claimable target.
- Keep an owner for each record. A comment in your DNS-as-code, or a simple register, saying who created a record and why, makes audits fast.
- Manage DNS in version control. Pull requests make new delegations visible and easy to question.
- Audit quarterly. Run the checks above, review SPF includes and DKIM selectors against your current vendor list, and look at DMARC aggregate reports for unexpected sources passing DKIM.
- Prefer delegation you can revoke quickly. A CNAME you control can be removed in minutes; a key you published as TXT can be revoked with an empty
p=value.
A typical way it happens
The sequence is usually mundane. A team trials an email marketing platform, follows the setup guide, and publishes a DKIM CNAME and an SPF include. Months later the trial ends and the subscription is cancelled, but nobody touches DNS, because DNS was set up by someone else and nothing appears broken. Years later the platform shuts down or restructures its domains, and the hostnames your records point at become available to whoever asks for them.
Nothing in that story involves negligence by any single person. It is a process gap between whoever buys tools and whoever owns DNS, which is why the fix is a process: offboarding checklists and regular audits, not heroics.
Watching for abuse
DMARC aggregate reports can reveal a selector takeover: look for DKIM passes with d=example.com and a selector you do not recognize, or from source IPs that do not belong to any current sender. Certificate Transparency logs can reveal a web takeover: an unexpected certificate issued for one of your subdomains deserves immediate investigation.
Key takeaways
- Dangling records point at resources you no longer control and can be claimed by others.
- Delegated DKIM selectors are the highest-risk case, because a takeover yields aligned, authenticated mail as your domain.
- Stale SPF includes risk both unauthorized senders and void-lookup permerrors.
- Remove DNS records as part of every vendor offboarding, before deleting the underlying resource.
- Audit regularly and watch DMARC reports for unknown selectors.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
