Subdomain takeover and email

18 March 2026 · 13 min read

Most discussions of email spoofing assume the attacker is forging your domain from the outside: a stranger on a random VPS putting yourcompany.com in a From header and hoping receivers do not check. DMARC exists to stop exactly that, and when it is set to p=reject it does. But there is a quieter, nastier failure mode where the attacker does not forge anything. They take over a piece of your own DNS, stand up real infrastructure under one of your subdomains, and send mail that genuinely passes SPF, DKIM and DMARC because, as far as every receiver on the internet is concerned, that subdomain belongs to them now. This is subdomain takeover, and email is one of the highest-value things an attacker can do with it.

This article is specifically about the intersection of dangling DNS and email authentication: how a forgotten CNAME becomes a way to send authenticated-looking mail from your domain, why your DMARC policy will not save you, and the concrete steps to find and close the gap. It is not a general DMARC explainer. If you want the foundations first, RFC 7489 DMARC explained covers the protocol and the requirements page covers what Google, Yahoo and Microsoft now expect from bulk senders.

What a subdomain takeover actually is

A subdomain takeover happens when a DNS record on your domain points at a third-party service that no longer holds the resource it used to. The record still resolves. The target is gone. That gap, the "dangling" reference, is the vulnerability.

The classic shape is a CNAME. Say two years ago your marketing team spun up a campaign microsite on a hosted platform and pointed a subdomain at it:

promo.yourcompany.com.   CNAME   yourcompany-promo.somehost.io.

The campaign ended. Someone deleted the site inside the hosting platform's dashboard, freeing the name yourcompany-promo on that platform. Nobody deleted the CNAME in your DNS, because the person who set it up has left and the record looks harmless. Now promo.yourcompany.com is a loaded gun: it still points at yourcompany-promo.somehost.io, but that hostname is unclaimed. An attacker who notices this registers yourcompany-promo on that same platform, and the platform happily serves their content at a hostname your DNS already delegates to. They now control everything served at promo.yourcompany.com without ever touching your DNS zone.

The same pattern applies to other record types:

• A dangling CNAME to a deprovisioned cloud bucket, CDN distribution, app-platform app, or pages host where the name can be re-registered.
• An NS delegation to a DNS provider account that has lapsed, so an attacker who controls that provider account controls the entire subdomain's DNS.
• An A or AAAA record pointing at an IP you have released back to a cloud provider's pool, which the attacker then gets assigned on a fresh instance.
• An MX record pointing at a mail host you no longer operate.

The common thread is the same: your DNS asserts that a name belongs somewhere, and "somewhere" is now controllable by someone who is not you.

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

Most write-ups treat subdomain takeover as a web defacement or phishing-page risk, and it is both. But the email angle is more dangerous because of how email authentication is anchored, and because of how DMARC alignment is scoped.

Three things make a hijacked subdomain a serious mail-sending asset.

One: the attacker can publish their own SPF and DKIM under your subdomain. If the takeover is a hijacked NS delegation, or a takeover of a host that lets them control DNS-validated records, the attacker can publish a TXT SPF record and DKIM keys at promo.yourcompany.com and selector._domainkey.promo.yourcompany.com. Mail they send from something@promo.yourcompany.com then passes SPF and DKIM for real, because the authoritative DNS for that subdomain is theirs.

Two: DMARC alignment can be satisfied at the organisational level. DMARC requires the authenticated domain to align with the From domain. By default that alignment is "relaxed", meaning the organisational domain has to match, not the exact label. A message From promo.yourcompany.com that passes DKIM for d=promo.yourcompany.com aligns under relaxed mode with a DMARC policy published at yourcompany.com. So the attacker's mail does not just pass SPF and DKIM, it passes your DMARC, and it does so from a name that ends in your real domain. There is no forgery for a receiver to catch.

Three: subdomains inherit your DMARC policy unless you say otherwise. Receivers look up the DMARC record for the exact subdomain first, and if there is none, they fall back to the organisational domain's policy, optionally overridden by the sp= (subdomain policy) tag. Most organisations never publish per-subdomain DMARC records and never set sp, so every subdomain quietly inherits the parent. That inheritance is usually a good thing. With a hijacked subdomain it means the attacker is operating inside your authenticated, aligned, policy-covered namespace.

Put those together and you get the worst case for a defender: mail from billing@promo.yourcompany.com that passes SPF, passes DKIM, passes DMARC, shows a green authentication result in the receiving system, and carries your actual domain. A recipient sees a real subdomain of a company they trust. Your p=reject policy waves it straight through, because nothing about it is failing. DMARC was never designed to stop you from authenticating your own mail, and as far as the protocol can tell, that is exactly what is happening.

Why p=reject does not protect you here

This is the point people find counterintuitive, so it is worth being precise. DMARC at p=reject instructs receivers to reject mail that claims your domain in From but fails authentication and alignment. The attacker on a hijacked subdomain is not failing anything. They are passing.

DMARC's job is to bind the visible From domain to a cryptographically or path-authenticated identity. It does that job correctly. The flaw is upstream: your DNS has handed authority over a chunk of your namespace to a stranger, so the identity the attacker authenticates as is legitimately one of yours. No DMARC policy distinguishes "mail authenticated by a subdomain we control" from "mail authenticated by a subdomain an attacker controls", because at the DNS layer there is no difference any more.

A useful way to hold this in your head: DMARC defends the From domain against outsiders. Subdomain takeover turns an outsider into an insider. Once they are inside the namespace, the policy that was protecting you is now protecting them.

This is also why BIMI and reputation make it worse rather than better. If you have invested in domain reputation and a BIMI logo at the organisational level, mail from a hijacked aligned subdomain can ride that reputation and, depending on the receiver's BIMI scoping, even display trust signals. The attacker borrows the credibility you built. You can review what is published at the parent with the BIMI checker, but the deeper point is that strong parent-domain trust amplifies the blast radius of a single dangling record.

A concrete attack walkthrough

Walking through the sequence makes the abstract risk tangible.

1. Reconnaissance. An attacker enumerates subdomains of yourcompany.com using certificate transparency logs, passive DNS, and brute-force wordlists. Every TLS certificate your organisation has ever requested is a public record, so subdomains that were meant to be obscure are not. They find promo.yourcompany.com, status.yourcompany.com, cdn.yourcompany.com and forty others.

1. Finding the dangle. For each subdomain they resolve the chain and check whether the target is claimable. promo.yourcompany.com is a CNAME to a hosting platform, and the platform returns a "no such site" fingerprint, the classic signal that the name is free to register. That fingerprint is the tell that a takeover is possible.

1. Claiming the target. They create an account on that platform and register yourcompany-promo, the exact name your CNAME points at. The platform binds the hostname to their account. They now serve content at promo.yourcompany.com and, on platforms that automate it, can obtain a valid TLS certificate for that subdomain through automated domain validation, because they pass the validation challenge by controlling what is served there.

1. Standing up mail. If the hijacked resource lets them control DNS records under the subdomain, or if the takeover was an NS delegation, they publish:

promo.yourcompany.com.                 TXT   "v=spf1 ip4:203.0.113.50 -all"
sel1._domainkey.promo.yourcompany.com. TXT   "v=DKIM1; k=rsa; p=MIGfMA0G..."

They send from accounts@promo.yourcompany.com through a server at 203.0.113.50, signing with the DKIM key they published.

1. The receiver's view. A receiving mail server checks SPF against promo.yourcompany.com's SPF record: pass. It checks the DKIM signature against the published key: pass. It checks DMARC alignment: the DKIM d= is promo.yourcompany.com, which aligns under relaxed mode with the yourcompany.com DMARC policy. DMARC: pass. Disposition: deliver. The message lands in the inbox, fully authenticated, from a real subdomain of a trusted brand, and it asks the recipient to confirm their payment details.

Nothing in that chain is forged. Every check is honest. The compromise happened in step three, in your DNS, long before any mail was sent.

How this shows up in your DMARC reports, and how it does not

If you are reading aggregate reports, a hijacked subdomain has a frustrating property: it can look like legitimate mail, because in authentication terms it is. You will see a source IP you do not recognise, sending for a subdomain, passing SPF and DKIM, aligned, disposition none or delivered. That is the same pattern as a legitimate new sender you forgot about, which is exactly why takeovers hide so well.

The signals that should raise your eyebrow:

• Authenticated, aligned mail attributed to a subdomain you do not actively send from. A promo or status or cdn subdomain producing email volume is suspicious on its face, because those names usually serve web content, not mail.
• A DKIM d= of a subdomain rather than your organisational domain, from a selector you do not recognise and did not create.
• Mail aligned to a subdomain whose SPF or DKIM records you cannot account for in your own change history.

The trap is that the "unknown source" triage most teams use leans on the assumption that aligned, passing mail is yours. With a takeover that assumption is wrong. So when you work through unfamiliar sources, do not stop at "it passes, so it must be ours". Confirm you can explain the subdomain and the selector. The general triage method is in DMARC reports show unknown sources; the extra rule for this threat is to treat passing-but-unexplained subdomain mail as a takeover candidate until you prove otherwise. Group and resolve your sources with the DMARC report analyzer so you are looking at per-source detail, not raw XML.

Be honest about the limits, too. If the attacker is sending low volume to targeted recipients, the receivers involved may not be ones that send you aggregate reports, or the volume may be small enough to disappear in the noise. Reports are a strong detective control for spoofing of the parent domain. For an aligned subdomain, they help, but they are not a guarantee you will see it.

Finding dangling DNS before an attacker does

Prevention is a DNS hygiene problem, and it is tractable. The goal is to make sure every record in your zone points at a resource you currently control.

Inventory every subdomain. Pull your full set of names from three sources and reconcile them: your authoritative DNS zone exports, certificate transparency logs for your domain, and any passive-DNS dataset you can access. Certificate transparency in particular surfaces names you forgot existed, because every certificate ever issued for a subdomain is logged publicly.

Resolve every record and check the target. For each CNAME, A, AAAA, NS and MX, confirm the target still resolves to something you own and operate. The dangerous cases are:

• CNAME or alias records pointing at third-party platforms (cloud storage, CDNs, app hosts, pages hosts, helpdesk and status-page providers) where the underlying resource has been deleted but the DNS record remains.
• NS delegations to a DNS provider account you no longer pay for or control.
• A/AAAA records pointing at cloud IPs you have released.
• MX records pointing at retired mail hosts.

Watch for the platform "not found" fingerprint. When a hosted target returns the provider's generic "no such app/site/bucket" response, that is the same signal an attacker looks for. A name returning that fingerprint is claimable and must be fixed now, not scheduled.

Make decommissioning delete DNS first. The root cause of almost every takeover is ordering: the resource was deleted before the DNS record. Flip it. When you retire any externally hosted resource, remove the DNS record that points at it before, or at the same time as, deleting the resource. Bake that into your offboarding and decommissioning runbooks.

Re-scan continuously. Subdomains and their targets change constantly. A one-off audit goes stale within weeks. Periodic re-enumeration and re-resolution is the only durable control.

Locking down the email surface specifically

Beyond general DNS hygiene, there are email-specific moves that shrink what a takeover can achieve.

Set an explicit subdomain policy. If you do not send mail from subdomains, say so at the parent. A DMARC record with sp=reject instructs receivers to reject mail for any subdomain that does not publish its own policy, regardless of whether it would otherwise authenticate. This does not stop an attacker who has hijacked the subdomain's DNS and can publish their own DMARC record there, but it removes the easy case where they rely on inheriting a permissive parent policy, and it is a sensible default. A record might read:

_dmarc.yourcompany.com.   TXT   "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourcompany.com; adkim=s; aspf=s"

Consider strict alignment. The adkim=s and aspf=s tags above require exact-domain alignment rather than organisational-domain alignment. Under strict alignment, mail From promo.yourcompany.com would need to authenticate as exactly promo.yourcompany.com, not merely as an organisational match. This narrows, though it does not eliminate, the alignment that a hijacked subdomain can exploit, and it has real operational implications for your legitimate senders, so test it under p=none first and confirm nothing breaks. Check what is published today with the DMARC checker before you change tags.

Publish a null MX on subdomains that should never send or receive mail. For a web-only subdomain, a null MX record states that the name accepts no mail:

promo.yourcompany.com.   MX   0   .

It is a clear declaration of intent and a small but real signal. Pair it with an explicit empty SPF policy where appropriate so the name asserts it is not a sender.

Keep parent-domain authentication tight and audited. Verify your organisational SPF and DKIM are clean and that you can account for every selector. Run the SPF checker and the DKIM checker and reconcile every authorised sender against a maintained inventory. A selector you cannot explain is either shadow IT or, in the worst case, an attacker's.

Harden the transport layer. MTA-STS does not stop a takeover, but it is part of a tight email posture and ensures inbound mail to your real hosts uses authenticated TLS. Confirm your policy with the MTA-STS checker.

The practical takeaway

Subdomain takeover defeats email authentication not by breaking it but by satisfying it from the wrong side. An attacker who hijacks a dangling CNAME, lapsed NS, or released A record can publish SPF and DKIM under your own subdomain, align it with your organisational DMARC policy under relaxed mode, and send mail that passes every check and inherits your reputation. p=reject does not catch it, because nothing about the mail is failing. The vulnerability lives in DNS, not in the mail path, which is precisely why DMARC alone cannot close it.

The defence is unglamorous and effective: know every subdomain you have published, resolve every record to a resource you still control, delete DNS before you delete the resource it points at, and re-scan on a schedule because zones drift. On top of that, set sp=reject, test strict alignment, null-MX your web-only names, and account for every DKIM selector in your zone. Treat passing-but-unexplained subdomain mail in your reports as a takeover candidate, not a forgotten newsletter.

If you want a current picture of what your domain and subdomains actually publish, start with the DMARC checker and the DMARC report analyzer to see who is authenticating as you. And if keeping the whole authentication and DNS surface clean as it changes is more than you want to own by hand, our done-for-you hosting manages your DMARC, SPF, DKIM and MTA-STS records and watches them for changes, so a dangling reference or an unexpected new selector becomes an alert you receive rather than a takeover you discover after the fact. You can also turn on emailed monitoring with change alerts to catch drift the moment it happens.