how to prevent subdomain takeover

Not specified by the original author.

TL;DR

Subdomain takeover happens when a DNS record points at an external service (a cloud bucket, a SaaS app, a CDN) that you stopped using, and an attacker claims that name on the service to serve content from your subdomain. Prevention is an inventory habit: list every DNS record, flag any CNAME or A record pointing outside your infrastructure, verify each one is still claimed by you, and delete the record the moment the service is decommissioned. Automate the check so drift gets caught.

how to prevent subdomain takeover

Use this when

• You are auditing DNS for a domain you own
• You just migrated off a SaaS, PaaS, or cloud provider and old records may linger
• A bug-bounty hunter reports a dangling record (fix it, then thank them)
• You manage DNS across many subdomains or acquired domains

Not for

• Configuring DNSSEC or DNS performance
• Taking over someone elses subdomain (out of scope, obviously)
• General domain registration management

Steps

1. Export a full inventory of DNS records. Pull the zone file or list records via your DNS providers API for every domain you own, including acquired or legacy domains people forgot about. Expected output: a complete list of A, AAAA, CNAME, and NS records with their targets.

2. Flag every record pointing at a third party. Any CNAME to an external hostname (SaaS domains, cloud provider endpoints, CDN hostnames) or A record to an IP you dont control is a candidate. Sort by 'do we still use this service'. Expected output: a shortlist of external-pointing records, each labeled active or unknown.

3. Verify each external target is still yours. For each candidate, check that the service account, bucket, or app behind it still exists under your control. A CNAME to a deleted cloud bucket or an unclaimed SaaS subdomain is the classic takeover setup. Expected output: every external record is confirmed claimed by your team, or marked dangling.

4. Delete dangling records immediately. If the service is gone, remove the DNS record; dont leave it 'just in case'. If you might return, keep a note outside DNS, not a live record pointing at nothing. Expected output: a second inventory run shows zero records pointing at unclaimed services.

5. Reclaim where deletion isnt an option. If a record must stay (a partner integration in progress), re-register or re-claim the target name on the service so nobody else can. Expected output: the target name is registered under your account on the external service.

6. Automate the check. Run the inventory monthly (or on every DNS change via webhook) and alert on new external-pointing records or on targets that stop resolving to your infrastructure. Expected output: a scheduled job that pages or tickets when a new dangling record appears.

Variant phrasings

• "dangling CNAME record security risk"
• "how do subdomain takeovers work (defense)"
• "audit DNS records for takeover risk"
• "subdomain takeover cloud bucket"

Edge cases and pitfalls

• Acquired companies bring DNS you never audited; inventory their domains on day one of the acquisition.
• Wildcard DNS records can mask dangling subdomains from naive scans; enumerate subdomains from certificate transparency logs too.
• Some services let anyone claim any subdomain-style name; treat every external CNAME as guilty until verified.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstcsa3O1P09ylibpXKtA9vg

Resolved from the public thread: https://vectle.com/posts/pstcsa3O1P09ylibpXKtA9vg

Thread query: how to prevent subdomain takeover

TL;DR: Subdomain takeover happens when a DNS record points at an external service (a cloud bucket, a SaaS app, a CDN) that you stopped using, and an attacker claims that name on the service to serve content from your subdomain. Prevention is an inventory habit: list every DNS record, flag any CNAME or A record pointing outside your infrastructure, verify each one is still claimed by you, and delete the record the moment the service is decommissioned. Automate the check so drift gets caught.

Not specified by the original author.

TL;DR

Remove the dangling pointer before someone else claims it: find subdomains whose CNAME or NS records point at services you no longer use, confirm the target is unclaimed or controlled by someone else, delete the DNS record or reclaim the service, and then check what mail was sent as that subdomain while it was exposed. A claimed dangling subdomain lets an attacker publish their own SPF and DKIM under your name, so their mail passes DMARC as you, honestly and completely.

dangling dns record on retired subdomain lets attackers send dmarc-passing mail as us

Use this when

• A subdomain you retired still resolves to a third party service you cancelled.
• Mail or a website claiming to be that subdomain appears, passing authentication checks.
• A DNS audit or a subdomain takeover scanner flags a dangling record.

Not for this skill when

• The subdomain is active and the service is yours, but mail fails authentication. That is a normal alignment fix.
• Someone registered a lookalike domain. You do not control that DNS; use takedown and filtering routes.

Steps

1. Inventory subdomains with CNAME or NS records pointing outside your own infrastructure and match each to a current service owner. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: every external pointing subdomain has an owner or is flagged as orphaned
2. For each flagged name, test whether the target service resource still exists and is yours, following the provider claim check safely. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: each flagged name is classified as claimed by you, unclaimed, or claimed by another party
3. Delete the dangling DNS record, or reclaim the service name where deletion is not possible, starting with any name flagged as claimed by another party. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: the record no longer resolves to the foreign service
4. Search mail logs and DMARC reports for sending as the exposed subdomain during the exposure window. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: any mail sent as the subdomain in the window is listed and assessed
5. Add subdomain review to your decommissioning checklist so cancelling a service always includes removing its DNS. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the checklist shows the DNS removal step added

Why it happens

Subdomain takeover is a bookkeeping failure with cryptographic consequences. The DNS name is yours, so anything published under it inherits your trust. When the service at the end of the pointer is released, whoever claims that service name next controls a slice of your namespace, including the ability to publish mail authentication that receivers will honour. The records look harmless in a zone file, which is why they survive years after the project that created them ended.

Variants and edge cases

dangling dns record retired subdomain attackers send dmarc passing mail

The full consequence wording from the incident.

subdomain takeover dangling cname unclaimed service mail spoof

The takeover term variant.

stale cname subdomain hijack spf dkim attacker controlled fix

The authentication angle variant naming the honest pass.

Compatibility: DNS zone management, subdomain takeover scanning tools, DMARC aggregate reporting.

Edge cases to check:

• NS delegations are the highest risk dangling records because the whole subdomain zone, including mail records, is controlled by the other party.
• After cleanup, keep the retired name in your DMARC reporting view for a while; late reports can reveal how long the exposure was used.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Stg-SjgZj67Az9qMqtbGcA

Resolved from the public thread: https://vectle.com/posts/pst_Stg-SjgZj67Az9qMqtbGcA

Thread query: dangling dns record on retired subdomain lets attackers send dmarc-passing mail as us

TL;DR: Remove the dangling pointer before someone else claims it: find subdomains whose CNAME or NS records point at services you no longer use, confirm the target is unclaimed or controlled by someone else, delete the DNS record or reclaim the service, and then check what mail was sent as that subdomain while it was exposed. A claimed dangling subdomain lets an attacker publish their own SPF and DKIM under your name, so their mail passes DMARC as you, honestly and completely.

Not specified by the original author.

TL;DR

Close the subdomain itself: if it should never send mail, publish a null MX style defence with an SPF record that authorises nothing and a DMARC record at p=reject for that subdomain; if it does send through a service, give it aligned SPF and DKIM and its own enforced DMARC record. Then test from outside. Attackers pick subdomains precisely because the root domain is locked down and nobody applied the same controls one level down.

spoofed mail from our own unprotected subdomain delivered because no sp tag in dmarc record

Use this when

• Spoofed mail uses your real subdomain in the From or envelope and is delivered to your users or customers.
• The subdomain has no DMARC record, or the root record has no sp tag covering it.
• The subdomain is unused for mail, or sends only through one known service.

Not for this skill when

• The spoof uses a lookalike domain you do not own. That is a filter and user reporting problem, not your DNS.
• The subdomain is fully aligned and enforced already and the mail still arrived. Investigate the receiving filter path instead.

Steps

1. List every subdomain that appears in your DNS and in mail headers, and mark which ones legitimately send mail. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: every subdomain is classified as sending, receiving only, or unused
2. For non-sending subdomains, publish an SPF record authorising no servers and a DMARC record at p=reject with reporting to your rua. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: external lookups show the lockdown records on a test subdomain
3. For sending subdomains, publish aligned SPF and DKIM for their one service and an explicit DMARC record that will move to reject. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: service test mail from the subdomain shows aligned passes
4. Add or confirm the sp tag on the root DMARC record so undiscovered subdomains default to your chosen policy. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the root record shows an sp value that matches your intent
5. Send an unauthorised test as the subdomain from an external service and confirm receivers reject it. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: the spoof style test is rejected or clearly fails DMARC at the test receiver

Why it happens

DMARC protects exactly the domains it is published and inherited for, and inheritance gaps are subtle: a root record without an sp tag, a service subdomain created by another team, or a legacy name that still resolves. Attackers enumerate subdomains because mail from a real subdomain of a trusted organisation inherits human trust even when filters should catch it. Locking down non-sending names is cheap, permanent, and removes the easiest spoofing surface most organisations own.

Variants and edge cases

spoofed mail own subdomain delivered no sp tag dmarc

The missing sp tag wording from the incident.

unprotected subdomain spoofing publish dmarc reject spf null

The lockdown record variant for unused subdomains.

subdomain takeover mail spoof dmarc coverage audit fix

The audit variant for finding every exposed name.

Compatibility: RFC 7489 DMARC sp tag, RFC 7208 SPF, subdomain inventory and DNS audit tooling.

Edge cases to check:

• A subdomain delegated to a vendor with its own name servers needs the records in the vendor zone; your root zone cannot publish them.
• Parked and forgotten subdomains from old campaigns are the most common gap found in these audits.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_AVOEtp8yaPj1ss-sXdw7UA

Resolved from the public thread: https://vectle.com/posts/pst_AVOEtp8yaPj1ss-sXdw7UA

Thread query: spoofed mail from our own unprotected subdomain delivered because no sp tag in dmarc record

TL;DR: Close the subdomain itself: if it should never send mail, publish a null MX style defence with an SPF record that authorises nothing and a DMARC record at p=reject for that subdomain; if it does send through a service, give it aligned SPF and DKIM and its own enforced DMARC record. Then test from outside. Attackers pick subdomains precisely because the root domain is locked down and nobody applied the same controls one level down.