Brand-Adjacent Domains

Overview

A brand-adjacent domain carries a well-known brand’s name, spelled correctly, combined with a plausible product or function word: exampledrive.com, example-billing.net, examplelogin.com. It is not a typo and not a homoglyph, so the techniques in datapulse_help(topic="typo_squatting") do not describe it — there is no misspelling to detect. These names are found by substring search (datapulse_dns_searchlabels(search_term="example")), not by fuzzy matching.

This shape matters because it defeats the three checks that domain triage usually stops at. A brand-adjacent domain is frequently old, opens the brand’s real website under a valid certificate, and publishes an MX that names the brand’s mail platform. All three can be true of a domain the brand does not control and has never heard of.

The three checks that pass

1. Age proves the name is old, not who owns it

registrationdate measures how long the string has existed. Brand-adjacent names are often registered early, held dormant for years, and activated or resold later. A 2012 registration date on a name activated in 2026 tells you about 2012.

Cross-check age against datapulse_dns_dphistory: a long registration with a short or churning operational history is a different object than a long registration on stable infrastructure.

2. A redirect hands you the destination’s identity

When the domain redirects to the brand’s real site, the page you render and the TLS certificate you validate belong to the destination. They are evidence about the brand’s property, not about the domain that sent you there.

In datapulse_domain_overview, compare these three fields against the domain you asked about:

When tls.subject names a host other than the domain under investigation, the certificate is not evidence about that domain. A genuine brand property normally presents a certificate whose subject is the domain itself.

The extractor reports this independently: scrape.extraction.domain_mismatch is "yes" when the page content does not match what the domain name claims, and extraction.nature_domain explains the discrepancy in prose.

Who issues the redirect is the question. Resolve the address records and identify the operating network:

datapulse_live_dns(domain="exampledrive.com")
→ A records → look up the ASN via datapulse_dns_dphistory enrichment

A redirect to the brand originating from the brand’s own edge network is consistent with brand control. The identical redirect issued from a general-purpose VPS (Vultr, DigitalOcean, Hetzner, Sharktech, and similar) is a third party pointing at the brand. The destination looks the same in both cases — only the origin distinguishes them.

3. An MX record is a claim, not a credential

Anyone may publish an MX pointing at any host. Publishing one does not mean the named platform provisioned anything. See Mail below.

What actually resolves control

Lock depth, diffed against a domain the brand certainly owns

This is strong comparative evidence when the brand’s own portfolio shows a consistent posture, and it is objective. Look up a domain the brand indisputably controls and compare the RDAP status arrays:

datapulse_live_rdap(query="exampledrive.com")
datapulse_live_rdap(query="example.com")        # known-good reference

A brand-carrying name sitting behind a single default lock is not portfolio posture, whatever its age. Compare ianaid as well, and weigh lock depth heavily: it is a configuration the owner had to choose, whereas a registrar name is a shortcut that misreads acquisitions, regional offices, and legacy registrations. It is not decisive on its own: registry-level locks are a registrar/registry service that not every legitimate owner has arranged, so a missing lock is a difference from the reference domain, not a verdict.

Registrant hidden versus named

GDPR redaction is applied by the registrar to everyone and says nothing about the registrant. A named privacy-proxy service is different: it is something the registrant selected and paid for.

Attribution is the entire purpose of a defensive registration — a brand registering a lookalike wants that registration traceable to itself. A purchased proxy on a brand-carrying name therefore cuts against brand ownership rather than being neutral.

RDAP will not give you the registrant directly, and the compact RDAP these tools return does not expose the registrant fields where a proxy service would be named either: this signal needs a raw RDAP or WHOIS record from another source. See datapulse_help(topic="registrant_lookup") for what is and is not possible.

Nameserver and hosting history

datapulse_dns_dphistory(domain="exampledrive.com")

Established brand portfolios sit on one DNS provider for years, often with the provider’s records spread across several TLDs for resilience. Read the history for:

• Provider rotation — moves between unrelated DNS operators
• Jurisdictional spread — authoritative servers answering from networks in unrelated countries, especially when the brand is a single-jurisdiction company
• Hosting churn — a sequence of unrelated hosting ASNs over a short window
• Delegation mismatch — the history distinguishes ReportedNS (what the registry publishes) from OperationalNS (what actually answers). A period where these disagree is worth stating plainly; it usually means control changed at one layer and not the other.

Any of these is control churn. None of them is what a brand’s defensive registration looks like.

Mail: check the tenant, not the record

Hosted mail platforms derive the inbound hostname from the tenant’s own domain. For Exchange Online, a correctly provisioned record for exampledrive.com reads:

exampledrive-com.mail.protection.outlook.com

The domain’s own label, with dots replaced by hyphens. An MX on exampledrive.com that instead names another organisation’s tenant hostname is a record that was copied, not one that was provisioned. Read the hostname against the domain publishing it before drawing any conclusion from the platform it names.

The platform confirms this at delivery time. Exchange Online answers mail for a domain its tenant does not accept with:

550 5.7.64 TenantAttribution; Relay Access Denied

The MX points into the tenant endpoint; the tenant knows nothing about the domain. Such a record is decorative — it survives any check that performs the MX lookup and stops there.

Inbound and outbound are separate questions

A broken inbound path does not narrow the outbound one. With no SPF and no DMARC, nothing prevents a third party sending mail as the domain, whether or not it can receive any. Check SPF, DMARC, and CAA in their own right — datapulse_live_dns returns DMARC in its own dmarc field and SPF among the TXT records — and never infer any of them from the presence or absence of an MX.

No MX can be the correct posture

A genuine brand domain not intended to receive mail commonly publishes no MX at all, while still publishing a restrictive SPF (-all) and p=reject DMARC. That configuration refuses inbound structurally and strongly protects against successful spoofing at DMARC-enforcing receivers (a forged message can still be sent; compliant receivers reject or quarantine it).

These are opposite postures, and the one with the more brand-shaped mail record is the weaker of the two. Do not score MX presence as reassurance or MX absence as a gap without reading SPF and DMARC alongside.

What does not discriminate

DNSSEC. Do not treat an unsigned zone as a signal in either direction here. Large, genuine brand domains are routinely unsigned, so its absence separates nothing and citing it as suspicious produces false positives against real corporate portfolios. Verify DNSSEC status when the question is DNSSEC; do not recruit it as an ownership signal.

Registrar name alone. See lock depth above. Registrar reputation is a weak proxy for a configuration you can read directly.

Redirect destination. Covered above — it is the origin that carries information.

Investigation workflow

# 1. Profile the domain and a known-good reference from the same brand
datapulse_domain_overview(domain="exampledrive.com")
datapulse_domain_overview(domain="example.com")

# 2. Diff the registration posture — lock depth against the known-good reference
datapulse_live_rdap(query="exampledrive.com")
datapulse_live_rdap(query="example.com")

# 3. Read the operational history: NS rotation, jurisdictions, hosting churn,
#    and any ReportedNS / OperationalNS mismatch
datapulse_dns_dphistory(domain="exampledrive.com")

# 4. Registrar transfers and abuse-contact changes over time
datapulse_dns_rdap_history(domain="exampledrive.com")

# 5. Mail posture in its own right — SPF and DMARC, not inferred from MX
datapulse_live_dns(domain="exampledrive.com")

Risk assessment

Stating the conclusion

This class of evidence supports a specific and defensible claim: the domain is not demonstrably under the brand’s control, and is configured in a way that suggests otherwise. Say that plainly, and describe what the arrangement would enable.

It does not establish a campaign, and you should not assert one. No tool in this suite returns intent. Describe the capability the configuration creates and leave the characterisation to the reader — a domain that cannot be shown to belong to the brand, carrying the brand’s name, with no outbound mail protection, is a statement of fact about capability. Anything beyond that is inference the data does not carry.

Related Topics

• datapulse_help(topic="typo_squatting") — misspellings, homoglyphs, and defensive registrations
• datapulse_help(topic="email_security") — SPF, DKIM, DMARC analysis
• datapulse_help(topic="rdap") — EPP status codes and registration data
• datapulse_help(topic="history") — reading datapulse_dns_dphistory output
• datapulse_help(topic="registrant_lookup") — why registrant data is unavailable
• datapulse_help(topic="searchlabels") — finding brand-adjacent names by substring
• datapulse_help(topic="subdomain_cloaking") — trusted-looking hostnames hiding attacker control