SubdoMailing Explained: How Subdomain Hijacking Enables Email Spoofing

SubdoMailing is an email abuse technique in which attackers exploit a compromised or hijacked subdomain to make malicious emails, links, or other communications appear associated with a legitimate organization. Rather than simply forging a visible œFrom address, an attacker may first gain control of a legitimate subdomain, such as subdomain.example.com, and then attempt to use that trusted domain context to make phishing or other malicious messages more convincing.

The risk is significant because email security relies on multiple signals, including domain reputation and authentication mechanisms such as SPF, DKIM, and DMARC. A successful subdomain takeover does not automatically allow an attacker to pass SPF or DMARC, but it can create additional opportunities for email abuse when subdomain authentication, DNS records, or domain policies are weak or improperly configured. This can turn a web-facing DNS or asset-management problem into an email security risk.

SubdoMailing can begin with stale DNS records that continue to point to a third-party service, CDN, or cloud-hosted resource after the original application or account has been removed. For example, a forgotten CNAME record pointing to a third-party hosting service, a stale A record pointing to retired infrastructure, or an unused virtual-host configuration can leave a subdomain exposed to takeover. In many cases, the underlying problem is weak domain lifecycle management: organizations provision services successfully but fail to remove associated DNS records when vendors are replaced, applications are retired, or cloud resources are deleted.

Subdomain Hijacking: Core Concepts and Common Causes

Subdomain hijacking occurs when a DNS entry for an organization-controlled name points to a resource that the organization no longer controls, but an attacker can re-register, claim, or bind. The result is a subdomain takeover, where the attacker can serve content, configure email, or demonstrate a proof of concept through the affected subdomain.

The Role of DNS Records and Virtual Hosts

In the Domain Name System (DNS), a subdomain can be directed to web or application infrastructure through different types of records. For example, a CNAME record may point jobs.example.com to a third-party hosting platform, while an A record can point the subdomain directly to an IPv4 address assigned to hosted infrastructure. If the underlying application, cloud resource, account, or virtual host is later removed while the DNS record remains active, the organization may leave behind a dangling DNS record.

Virtual hosting is particularly relevant because many hosting platforms serve multiple customer domains or subdomains from shared infrastructure. The platform can determine which site or application to serve based on the hostname requested by the visitor. If a provider allows another customer to claim an abandoned hostname without adequately verifying domain ownership, an attacker may be able to take control of the subdomain.

Provisioning, Deprovisioning, and Order of Operations

The safest order of operations is simple: during provisioning, first create and validate the service, then add the required DNS records. During deprovisioning, first remove the DNS entry, then delete the remote service. In practice, teams often reverse this process. They delete a GoHire instance, ReadMe project, Okta app, AWS resource, or CDN distribution, but forget removing DNS records at the domain registrar or DNS provider.

That creates a classic dangling DNS record. The CNAME record or A record still advertises that the subdomain should resolve somewhere, but the original secure service is gone. If the destination has a known service vulnerability or weak vendor verification, the attacker can perform a subdomain claim.

Domain Ownership Verification

Strong domain ownership verification prevents many takeover attempts. A reliable provider asks the customer to verify domain ownership using an ownership challenge, such as placing a DNS TXT record with a randomly generated string, uploading a file, or completing a challenge-response workflow. Okta, for example, may require an Okta verification string, while some Custom Domains features rely on explicit ownership proof.

Weak domain ownership verification is dangerous when linking custom domain functionality exists in a configuration panel. If the platform allows anyone to add subdomain.example.com without checking the domain registrar, authoritative DNS, or a valid TXT record, the subdomain takeover risk rises sharply.

How Abandoned DNS Records Create Takeover Opportunities

Attackers and defenders can identify potential subdomain takeover candidates through subdomain enumeration. Passive discovery may use certificate transparency logs, public DNS information, search engines, and publicly available repositories, while active discovery can involve DNS queries and controlled subdomain discovery techniques.

Tools such as Amass, Sublist3r, MassDNS, puredns, dnsgen, and Nuclei can assist with subdomain discovery and security assessment. For example, automated checks may identify indicators such as provider-specific error responses, references to unclaimed cloud resources, or other signs that a DNS record points to an unavailable service. These indicators do not by themselves prove that a subdomain is vulnerable to takeover and should be validated safely.

After identifying a potentially abandoned subdomain, security teams should verify whether the DNS record still serves a legitimate business purpose and whether the referenced resource remains under organizational control. Reviewing the DNS configuration, hosting account, and domain-ownership controls can help determine whether the subdomain presents a genuine takeover risk.

Common Attack Scenario

A realistic attack scenario looks like this:

1. A company creates careers.example.com using GoHire and points a CNAME record to custom.gohire.io.
2. Later, HR completes deprovisioning by deleting the GoHire account but does not remove DNS entry data at the domain registrar or DNS provider.
3. The abandoned DNS records remain live, producing a dangling DNS record.
4. An attacker notices the error during subdomain enumeration, creates a new GoHire instance, and attempts to bind the same custom hostname.
5. If domain ownership verification is absent or flawed, the attacker completes the subdomain takeover.

Similar patterns have appeared in security writeups involving ReadMe, where a stale custom documentation mapping may reference a ReadMe project such as edoverflows-test-project.readme.io or main.readme.io. The same concept applies to Okta Custom Domains, Cloudflare-managed DNS, AWS-hosted assets, or any cloud-based hosting model that supports customer-controlled hostnames.

The Link Between Hijacked Subdomains and Email Spoofing

Once subdomain hijacking succeeds, the attacker may not stop at hosting a phishing page. The more dangerous SubdoMailing angle is email abuse. If the attacker controls a virtual host or cloud-based hosting resource tied to the subdomain, they can often configure outbound mail, landing pages, tracking links, or authentication-related records.

Email recipients are more likely to trust messages that appear to come from news.example.com, docs.example.com, or careers.example.com than from an unknown domain. This is why exploiting subdomain takeovers is such a powerful attack vector: the attacker benefits from the parent brands reputation while operating from infrastructure that defenders may not monitor closely.

A security researcher reporting vulnerabilities might demonstrate a harmless proof of concept, such as serving a verification page from the claimed subdomain. A criminal, however, may use the same subdomain takeover to send credential theft emails, host fake login pages, or impersonate HR, support, billing, or identity teams.