How does subdomain takeover through dangling DNS put your email at risk?

Every DNS record is a promise that a name leads somewhere you control. When you shut down a cloud app, cancel a marketing platform or let an old domain expire, the record often stays behind. Attackers look for those leftovers, claim the thing they point at, and get a working subdomain of your domain, sometimes one that can receive or send authenticated mail.

What is a subdomain takeover?

A subdomain takeover happens when a DNS record in your zone points at a resource that no longer belongs to you, and someone else claims that resource. Microsoft's dangling DNS guidance calls these leftover entries "dangling DNS" records and says "CNAME records are especially vulnerable to this threat."

Microsoft's example runs in three steps:

1. Creation. You create a cloud app at app-contogreat-dev-001.azurewebsites.net and add a CNAME so greatapp.contoso.com points to it.
2. Deprovisioning. You delete the app but forget the CNAME. The subdomain "is now vulnerable and can be taken over".
3. Takeover. An attacker finds the dangling name, creates a resource with the same cloud host name, and traffic for your subdomain now reaches content they control.

The same pattern applies to any service that hands out names on a first-come basis: website builders, help desks, storage buckets, landing-page tools and email platforms. It also applies to records that point at a whole domain you once used and then let lapse.

How does a takeover affect email?

Most writing on subdomain takeover is about websites. The email risks are less obvious and, for a business, often worse.

Microsoft lists phishing among the risks and says it "extends to both malicious websites and MX records. MX records could enable threat actors to receive emails directed to legitimate subdomains associated with trusted brands." Because RFC 5321 tells sending servers to deliver to the hosts in a domain's MX records, a stale MX quietly sends that mail wherever it points. If you're unsure what an MX record does, start with what is an MX record.

Why a hijacked subdomain can pass DMARC

This is the part many people miss. DMARC's default relaxed alignment treats a subdomain as belonging to its parent. RFC 9989, section 11.8 spells out the consequence: "If malicious or unaware users can gain control of the SPF record or DKIM selector records for a subdomain of the Organizational Domain, the subdomain can be used to generate email that achieves a DMARC pass on behalf of the Organizational Domain."

The RFC's own example: an attacker controls DNS for evil.example.com, publishes SPF for it, and sends mail with foo@example.com in the From header. Although the domain owner never authorized it, the message "can produce a DMARC pass" because the two domains are in relaxed alignment. Your p=reject policy doesn't help, because the message passes.

The RFC's advice is to "be careful not to delegate control of subdomains if this is an issue and consider using the strict alignment" option. Our guide to DMARC alignment, relaxed vs strict explains what strict alignment changes and what it can break.

SPF includes that point at expired domains

An SPF include: hands part of your authorization to another domain. RFC 7208, section 5.2 says the mechanism "is intended for crossing administrative boundaries", which is exactly the risk: you trust whatever that other domain publishes.

If the included domain lapses, two things happen in turn:

1. While nobody owns it, the include finds no SPF record. RFC 7208's table says a recursive result of none makes the include "return permerror", so SPF for your domain breaks.
2. Once someone registers it, they write its SPF record. Your include now authorizes their servers, and mail from them passes SPF for your domain.

An SPF PermError that appears out of nowhere is worth investigating for this reason, not just fixing. The same logic applies to old includes for vendors you've stopped using, even when their domain is still alive; see SPF too many DNS lookups for how to prune a record safely.

Where do dangling records come from?

Almost always from ordinary housekeeping gaps, not clever attacks:

• A marketing platform or help desk is cancelled, but its CNAME and DKIM records stay.
• A cloud test app is deleted, but test.example.com still points at its old host name.
• Mail moved to a new provider, but an MX on a subdomain still points at the old one.
• A campaign domain or old brand domain expires while other records still reference it.
• A contractor set up a subdomain in a provider account they've since closed.

The UK NCSC's domain management guidance warns that once a referenced domain expires, "the domain name referred to in the delegation or CNAME record may be used for other purposes", and tells organizations to "remove delegations and alias records once these services are no longer used". It also asks you to treat public DNS like other high-value assets, because it's often configured once and then ignored.

How do you audit your DNS for dangling records?

You can do a useful first pass with nothing more than a zone export and a spreadsheet.

1. Export every zone you own. Include subdomain zones and any domains at other registrars or DNS hosts. You can't check records you don't know exist.
2. List every record that points outside your control. That means CNAMEs to provider host names, MX records, NS delegations, SPF include: and redirect= terms, and DKIM selector CNAMEs.
3. For each one, name an owner and a live account. If nobody can say which account a record belongs to, treat it as suspect.
4. Resolve each target. A CNAME target that returns NXDOMAIN, a provider's "no such app" or "domain not configured" page, or an included domain that no longer has SPF needs attention now.
5. Check domain registrations. For every external domain your records reference, including SPF includes, confirm it's still registered to the provider you expect.
6. Check mail records specifically. Run each sending domain and subdomain through the Email Health Check, look up subdomain MX records with the MX Lookup, and confirm every include in the SPF Checker resolves.
7. Check DKIM selectors. List the selectors you've published and confirm each belongs to a service you still use. The DKIM Checker looks up a selector; how to find your DKIM selector helps if you don't know them.

If you use Azure, Microsoft publishes a PowerShell tool, Get-DanglingDnsRecords, that lists domains with a CNAME associated with Azure resources in your subscriptions or tenants, and accepts CNAMEs hosted at other DNS providers as an input file (as of October 2026). Microsoft Defender for App Service also includes dangling DNS alerts for decommissioned App Service sites.

What a provider's error page tells you

Many services show a distinctive page when a host name isn't attached to any account. Treat that page as a finding, not a curiosity: it often means the name can be claimed. Don't try to claim names on services you don't own to "test" them.

How do you clean up and prevent takeovers?

Microsoft's remediation steps, adapted for mail, are a good order to work in:

1. Delete the dangling records. Remove CNAMEs, MX records, delegations and includes that point at resources you no longer provision.
2. Or reclaim the target. If the subdomain is still needed, recreate the resource in your own account so the record points at something you control again.
3. Investigate whether a takeover already happened. Look at what the subdomain served recently, check your DMARC aggregate reports for unfamiliar sources passing as a subdomain, and search mail logs for messages to addresses on it.
4. Fix the process that left the record. Microsoft suggests putting "Remove DNS entry" on the list of required checks when you decommission a service.

Controls that make takeovers harder

• Use provider ownership checks. Azure App Service supports an asuid TXT record; Microsoft says that with it in place "no other Azure subscription can validate the custom domain or take it over." Many SaaS platforms have similar verification records. Keep them while the service is live.
• Use alias records where offered. Azure DNS alias records tie a record's lifecycle to the resource, so deleting the resource empties the record.
• Set an explicit DMARC subdomain policy. It doesn't stop a hijacked subdomain that passes authentication, but sp= and np= stop spoofing of subdomains that don't publish their own authentication. See the DMARC subdomain policy guide.
• Lock down names that never send mail. On subdomains that hold their own records, a Null MX and v=spf1 -all say plainly that no mail comes from them. A CNAME can't share its name with other records, so for an aliased name the only protection is keeping the target in your control. Our parked domain guide has the records.
• Monitor changes. Unexpected changes to MX, SPF or DMARC are often the first visible sign of trouble.
• Keep your own domains renewed. The NCSC recommends auto-renew, because after expiry "another organisation could register your domain". Our guide to domain registrar security and registry lock covers the account side.

Decommissioning checklist for services that touch email

Use this whenever you cancel a sending platform, help desk, CRM or hosting account:

1. List every DNS record the service asked you to create: CNAME, MX, TXT, DKIM selectors and SPF includes.
2. Remove the SPF include and confirm the record still validates.
3. Remove the DKIM selector records.
4. Remove or repoint any CNAME or MX for the subdomain the service used.
5. If the subdomain stays but no longer sends or receives mail, publish a Null MX and v=spf1 -all on it.
6. Check DMARC reports over the following weeks for mail still claiming that source.
7. Record the change, the date and who made it.

Next steps

• Export your DNS zones this week and list every record that points at another provider or domain.
• Check each SPF include and DKIM selector against the services you actually pay for, using the free SPF Checker and DMARC Checker.
• Add DNS cleanup to your offboarding checklist for vendors, not just people.
• Watch for changes between audits. iBlockSpam's domain monitoring alerts you when your MX, SPF or DMARC records change: weekly on Protect, daily on Protect Plus.

Browse our other SPF, DKIM and DMARC guides.