Dangling DNS records: the hidden email spoofing and SPF risk

3 June 2026 · 16 min read

A dangling DNS record is a record that still resolves, or still references another name, but the thing it points at is no longer yours. The classic example is a CNAME for status.yourdomain.com aimed at a hosting provider you stopped paying for two years ago. The record is still in your zone. The provider released the underlying resource. Anyone who can now claim that resource at the provider inherits a hostname that the whole world believes belongs to you.

For a marketing or product team this is a broken-link problem. For email authentication it is something worse: a dangling record is a standing invitation to send mail that your own domain vouches for. SPF include: mechanisms, DKIM selector CNAMEs, MX records and subdomain delegations all decide, on your behalf, who is allowed to speak as you. When the resource on the other end changes hands, that decision is being made by someone else. This article is specifically about the email blast radius of stale DNS, the mechanisms that are vulnerable, how an attacker actually exploits them, and how to find and close the gaps before they appear in your DMARC reports as mail you cannot explain.

What "dangling" means, precisely

Three different failure modes all get called "dangling", and they carry different risk:

The target name no longer resolves. A CNAME points at app123.someplatform.io, and that name now returns NXDOMAIN. This is a dead record. It breaks things but is usually not directly exploitable, until the platform recycles that name for a new customer.
The target resolves to infrastructure you no longer control. The name still answers, but the IP belongs to a shared platform, a cloud load balancer pool, or a provider edge where account ownership, not DNS, decides who gets served. This is the dangerous case, because someone else can claim it.
The reference is logically stale. An SPF include: still pulls in a provider you stopped using, or a DKIM CNAME still chains to a selector at a vendor you offboarded. The record resolves perfectly. It just authorises a party who no longer has any business sending as you, and whose own security you no longer audit.

All three matter for email. The second is how subdomain takeover happens. The third is how spoofing slips through SPF and DKIM while every record still looks green in a checker.

Why this is an email problem and not just a web problem

Email authentication is a chain of DNS lookups that grant authority. Walk the chain and every link is a record that could dangle:

SPF publishes a TXT record that lists who may send from your domain, often by chaining into other domains with include:, a:, mx: and redirect=. Each chained domain is a third party whose own SPF record you inherit at evaluation time.
DKIM publishes public keys at selector._domainkey.yourdomain.com, very commonly as a CNAME that points into a sending platform's key management so the provider can rotate keys for you.
DMARC publishes policy at _dmarc.yourdomain.com and ties everything together with alignment, but DMARC only protects the visible From domain. Subdomains, and the cousin domains in your SPF chain, each have their own posture.
MTA-STS and BIMI add further CNAMEs and policy hosts (mta-sts.yourdomain.com, _mta-sts.yourdomain.com, the BIMI logo and VMC URLs) that frequently point at external storage or a vendor.

Every one of those references is a trust delegation. A dangling one is a delegation to a stranger. If you have never enumerated them, run your live domain through the DMARC checker, SPF checker and DKIM checker and look not at the pass or fail verdict but at every external name each record depends on. That list of external names is your attack surface.

Mechanism 1: subdomain takeover via a dangling CNAME

This is the highest-impact dangling-record class and the one most directly tied to spoofing.

A subdomain takeover happens when something.yourdomain.com is a CNAME to a third-party platform, and that platform no longer has a tenant claiming the target. Many platforms route traffic by Host header: whoever registers myapp.theplatform.io in their account gets to serve anything sent to that hostname, including any custom domain that CNAMEs to it. If you deleted the tenant but left the DNS record, an attacker registers the same target name in their own account and now controls content served at your subdomain.

A typical vulnerable record:

status.yourdomain.com.   300   IN   CNAME   yourcompany.statuspage-vendor.io.

If yourcompany.statuspage-vendor.io is unclaimed and the vendor lets anyone claim arbitrary subdomains, an attacker claims it and serves their own content under status.yourdomain.com with a valid TLS certificate, because certificate authorities will issue for a domain whose DNS the attacker now effectively controls via the takeover.

The email consequences are direct and several:

Phishing from a hostname your customers trust. A login page at status.yourdomain.com or careers.yourdomain.com is enormously more convincing in a phishing email than any look-alike domain. The link is genuinely on your domain.
A new authenticated sending identity. If the attacker can host content on a real subdomain of yours, they are well placed to satisfy domain-control validation at sending platforms, ESPs and even some DKIM setups, because those checks prove "control of this DNS name", which the attacker now has.
DMARC does not save you here by default. DMARC alignment is per organisational domain, but your subdomain policy governs what happens to *.yourdomain.com. If you never set sp= and your subdomains have no DMARC posture of their own, mail using a taken-over subdomain in the From address can be far weaker than you assume. Set an explicit subdomain policy: see the subdomain policy tag and subdomain DMARC records. A strict sp=reject on the organisational record means a hijacked subdomain still cannot pass DMARC for mail, even if the web side is compromised.

A real-world record set to be suspicious of:

_dmarc.yourdomain.com.   IN   TXT   "v=DMARC1; p=reject; rua=mailto:..."
; ...but no sp= tag, so subdomains inherit p, which is fine,
; UNLESS a subdomain publishes its own weaker _dmarc record left over
; from an old project:
_dmarc.legacy.yourdomain.com.   IN   TXT   "v=DMARC1; p=none"

That orphaned p=none on an old subdomain is itself a dangling policy: it carves a hole in an otherwise strict posture, and a taken-over legacy.yourdomain.com would send through it.

Mechanism 2: stale SPF includes and the authority you forgot you granted

SPF is where logically-stale records do the most quiet damage, because nothing breaks and no checker complains.

Every include: in your SPF record imports another domain's entire list of authorised senders. When you signed up with a marketing platform, a help desk, a payroll provider or a transactional ESP, you added their include. When you stopped using them, did you remove it? Most organisations do not. The include sits there, and its meaning is "every IP this third party authorises is allowed to send as us", evaluated fresh on every message, forever.

yourdomain.com.   IN   TXT   "v=spf1 include:_spf.google.com include:sendgrid.net include:mail.old-helpdesk-vendor.com include:spf.former-newsletter-tool.io ~all"

The last two includes are dangling in the logical sense. The risks compound:

Shared-pool reuse. Many ESPs send all customers from shared IP pools. While you were a customer, your include authorised those shared IPs, which is normal. After you leave, your include still authorises them, and now those same IPs are sending other people's mail, including, on a shared pool, potential spammers. Any of them can put your domain in the envelope and pass SPF.
The include target itself dangling. If spf.former-newsletter-tool.io stops resolving, you get an SPF permerror or temperror depending on how it fails, which can cause legitimate mail to fail authentication. See fixing SPF permerror and SPF temperror is a related lookup-limit failure mode.
Worse, the include domain itself getting taken over. If the vendor lets their domain lapse and someone re-registers former-newsletter-tool.io, the new owner controls spf.former-newsletter-tool.io and can publish an SPF record listing their own IPs. Your domain now imports their authorisation. They send spoofed mail from your domain and it passes SPF and aligns. This is the SPF analogue of subdomain takeover, and it is entirely invisible to a casual record check because the syntax is perfect.

Stale includes also burn your ten DNS-lookup budget. SPF caps the number of DNS lookups during evaluation, and dead includes still consume lookups before they fail. A domain that flirts with the limit can tip into permerror because of includes for providers it no longer uses. The SPF 10-lookup limit explains the mechanics, and our SPF flattening approach exists partly to keep this list honest and minimal.

The discipline is simple to state and rarely followed: an include: is a live trust relationship, and offboarding a vendor is not complete until their include is gone from your SPF record. Audit the chain with the SPF checker, which expands every include so you can see exactly whose IPs you are vouching for.

Mechanism 3: dangling a, mx and ptr mechanisms

Beyond includes, SPF lets you authorise senders by other DNS facts, and each of those can dangle:

yourdomain.com.   IN   TXT   "v=spf1 a:mail.oldserver.yourdomain.com mx ip4:203.0.113.0/24 ~all"

a:mail.oldserver.yourdomain.com authorises whatever IP that name resolves to. If oldserver was a VPS you released and the host recycled the IP, you are now authorising a stranger's machine. If the name itself dangles to a reclaimable cloud IP, an attacker can take the IP and send authenticated mail.
mx authorises every IP in your MX records. If one of your MX hosts is a stale entry pointing at decommissioned infrastructure, the same recycled-IP risk applies.
ip4: / ip6: literals are the most stable, but they too go stale: a /24 you no longer use, or a CIDR that belonged to a previous mail provider, is a block of addresses you are still vouching for and no longer control.

Dangling MX records deserve a special mention. An MX pointing at a host that no longer accepts your mail does not just risk reuse; it can silently route inbound mail to a server someone else now controls, which is a confidentiality breach on top of an authentication one. Enumerate your live records with the DNS record checker and confirm every MX target is infrastructure you still operate.

Mechanism 4: dangling DKIM selectors

DKIM keys are published at selector._domainkey.yourdomain.com, and with most sending platforms you publish a CNAME so the provider can manage and rotate the underlying key:

s1._domainkey.yourdomain.com.   IN   CNAME   s1.domainkey.u123456.platform-esp.com.

When you leave that platform, two stale states are common:

The CNAME still chains to the provider. As long as that provider still serves a key for your selector, any mail signed with the matching private key produces a valid DKIM signature for your domain. If your account is closed but the key material is reassigned, recycled, or simply still live on a shared tenant, you have a DKIM identity in someone else's hands. DKIM that passes and aligns gives an attacker a full DMARC pass.
The CNAME dangles to nothing, the provider released the target, and now that target name becomes claimable in exactly the subdomain-takeover sense above. An attacker who claims it can publish their own DKIM public key there, sign mail with the matching private key, and pass DKIM for your domain.

Old selectors are easy to forget because they are invisible: nothing in your zone's apex points at them, and they only surface if you specifically query the selector name. The defence is selector hygiene, covered in DKIM key rotation: rotate on a schedule, and remove the selector record the moment a provider is offboarded, not "eventually". Check what is live with the DKIM checker, querying every selector you have ever published, including the ones from vendors you no longer use.

Mechanism 5: MTA-STS and BIMI hosts

The newer authentication records add their own danglers:

MTA-STS requires a policy file served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt, with that host typically a CNAME to a vendor or object store, plus a _mta-sts.yourdomain.com TXT record. If mta-sts.yourdomain.com dangles to a reclaimable host, an attacker who takes it can serve their own policy and, in the worst case, weaken the transport security you were trying to enforce. Validate the whole setup with the MTA-STS checker.
BIMI points at a logo SVG and, for verified marks, a VMC, both at URLs that are often on third-party storage. A dangling BIMI asset host is lower-severity, but a taken-over one lets an attacker swap your brand logo. Check with the BIMI checker.

How an attacker actually finds and uses these

This is not theoretical, and the attacker's workflow is mundane:

Enumerate. They pull your subdomains from certificate transparency logs, passive DNS, and brute-force wordlists, then resolve each and read every CNAME target, MX host, SPF chain and known DKIM selector. Certificate transparency in particular hands them a near-complete subdomain list for free.
Fingerprint dangling targets. They look for CNAMEs pointing at platforms with known takeover signatures (an unclaimed-tenant error page is the tell), NXDOMAIN targets on recyclable platforms, lapsed include domains available to register, and selector names whose chains are dead.
Claim. They register the unclaimed tenant, re-register the lapsed domain, or grab the recycled cloud IP. Cost is usually trivial.
Weaponise. They host phishing content on your taken-over subdomain, or publish SPF/DKIM records that make their mail authenticate as you, then send. Because the mail passes SPF or DKIM and aligns, it sails past DMARC, lands in inboxes, and carries the full trust of your domain.

The reason this is so effective is that it defeats the very controls people install to stop spoofing. SPF and DKIM are designed to answer "is this sender authorised?", and a dangling record makes the honest answer "yes" for an attacker. The output looks identical to legitimate mail in your DMARC report analyzer: aligned, passing, from a source you half-recognise. For how to tell genuine unknown sources from hostile ones, see DMARC reports show unknown sources. For the broader spoofing context, invoice fraud from a spoofed domain shows what the end of this chain looks like to a victim.

Finding your dangling records

A practical audit, in order of value:

Enumerate every subdomain you have ever created, not just the live ones you remember. Pull from certificate transparency, your DNS provider's full zone export, and any infrastructure-as-code that has provisioned hostnames. For each, resolve the CNAME target and check whether it still belongs to you. Any CNAME to a third-party platform is a candidate; verify the tenant on the other side is still yours and active.
Expand your SPF record in full and list every domain it chains into via include:, redirect=, a: and mx:. For each, ask: do we still use this vendor? Does the include target still resolve? Is the include domain still registered to that vendor, or has it lapsed? The SPF checker does the expansion; you supply the "do we still use them" judgement.
Query every DKIM selector you have ever published. Maintain a register of selectors per provider. For any provider you have offboarded, confirm the selector record is gone, and confirm no live selector chains to a tenant you no longer control. The DKIM checker confirms what is currently published.
Verify MX targets, MTA-STS hosts and BIMI asset hosts all resolve to infrastructure you operate, using the DNS record checker, MTA-STS checker and BIMI checker.
Check for orphaned _dmarc records on subdomains that publish a weaker policy than your apex. These are dangling policy records and they undercut everything else.

The hard part is not running the checks; it is knowing the full inventory of names to check. Most takeovers succeed against a subdomain or selector nobody remembered existed.

Closing the gaps and keeping them closed

Remediation is mostly deletion, which is satisfying but only sticks if you change the process that created the danglers:

Delete the DNS record before, or at the same time as, decommissioning the resource. The dangerous window is "resource gone, record still there". Reverse your usual order: remove the CNAME first, then tear down the tenant.
Make vendor offboarding include DNS. A provider is not offboarded until their SPF include is removed, their DKIM selector is deleted, and any CNAMEs into their platform are gone. Add this to the offboarding checklist explicitly.
Keep SPF lean and pinned. Fewer includes means fewer dangling opportunities and more headroom under the ten-lookup limit. Where a provider's include is volatile, our SPF flattening keeps the authorised set explicit and current rather than trusting a chain you cannot see.
Set an explicit, strict subdomain policy. sp=reject on your organisational DMARC record means a hijacked subdomain still cannot authenticate mail as you. Reach enforcement deliberately, as covered in DMARC from none to reject and the enforcement journey.
Monitor for change. A record that is clean today dangles the day a vendor lapses a domain or you forget to delete a CNAME. Continuous monitoring with alerting on record changes turns a silent six-month exposure into a same-day notification. That is exactly what monitoring and change alerts and the monitor service are for.

The practical takeaway

A dangling DNS record is not a tidiness issue. In an email context it is a delegation of your sending authority to whoever next claims the resource on the other end, and SPF includes, DKIM selector CNAMEs, subdomains, MX hosts and policy records are all delegations you can forget you made. The records keep resolving, the checkers keep showing green, and the only sign anything is wrong is mail you cannot explain passing authentication in your reports, by which point someone is already sending as you.

Treat your authentication DNS as an inventory, not a set-and-forget configuration: enumerate every external name your records depend on, delete records the moment the resource behind them is gone, set a strict subdomain policy so a takeover cannot authenticate, and watch for change so a new dangler is caught in hours rather than months. Start by expanding your live records with the SPF checker, DKIM checker and DMARC checker and reading them for trust delegations rather than pass or fail verdicts. If you would rather not carry the audit and ongoing hygiene yourself, our done-for-you DMARC service keeps the full chain enumerated, flattened where it helps, and monitored for the day something starts to dangle.

Dangling DNS records as an email risk