How dotBrands Can Combat Email Spoofing 

When a company evaluates the ROI of its own dotBrand, a branded top-level domain (TLD) like .brand or .google, most teams gravitate toward conversations about optionality and brand authority. Some discussions explore security, but real-world value is often kept close to the vest.  

As bad actors deploy increasingly sophisticated social engineering tactics, such as pairing voice phishing calls (vishing) with real-time email, the gateway to email has become a critical battleground. Owning and controlling your own TLD opens a unique defense mechanism that can help receiving mail systems detect and reject unauthorized use of your dotBrand in visible From addresses. 

The Threat & Defense: Turning Your TLD Into a Defense 

Bad actors are very good at hiding, and spoofing the From email address is an old but great tool in their kit.  We’ve long known that a brand name conveys trust, and as consumers have become savvier to bad actor threats, like phishing, many have learned to look at the email address that emails are being sent from.  Managing an enterprise-size domain portfolio across dozens of global jurisdictions makes real-time monitoring an ongoing challenge. A threat actor can forge a visible From address such as security@case.brand, even when case.brand doesn’t exist. 

With dotBrands in the ecosystem, some bad actors have started to spoof their emails as if they are coming from dotBrands.  Whether the from email is a dotBrand or another domain extension, when the domains don’t exist, it makes it very hard for a brand owner to protect consumers.   

While not spoken about outside of small circles, controlling your own TLD can enable the operator to publish a Public Suffix Domain (PSD) DMARC policy at the TLD level.  While subject to any required ICANN approval, publishing a TLD-level PSD DMARC policy can help participating mail systems identify and reject messages that misuse unauthorized or nonexistent domains within the dotBrand. 

Owning your dotBrand registry flips this dynamic from reactive monitoring to proactive blocking, after the appropriate set-up: 

1. Closed Namespace Control: Unlike an open TLD, a dotBrand is operated as a controlled namespace. As the TLD owner, you decide which names are registered and how they are used, enforcing centralized governance, security, and approval requirements across the TLD.
2. Registry-Wide DMARC Policy: By publishing a TLD-level PSD DMARC policy, the operator can provide a fallback policy for nonexistent names and domains under the dotBrand.
3. Automated Gateway Rejection: If a message using a dotBrand From address has neither an aligned SPF pass nor an aligned DKIM pass, receiving gateways can treat it as a DMARC failure and apply the published policy, reducing likelihood that the message reaches an inbox. 

It’s important to be precise about what this supports: a registry-wide DMARC policy makes unauthorized use of your namespace easier for participating mail systems to detect and reject. Attackers can still forge a From address ending in the dotBrand but successfully delivering that message becomes more difficult. 

It also does not stop attackers from registering a lookalike domain entirely outside your namespace (the classic “brand-adjacent” domain trick). The two defenses are complementary, and dotBrand ownership helps provide additional control and authenticity while removing one attack surface, though each tactic is only part of a strong security program. 

This isn’t theoretical. In November 2023, .BANK and .INSURANCE became the first non-governmental TLDs to implement a TLD-level Public Suffix Domain DMARC policy following ICANN approval. Their deployment provides a useful precedent. The policy acts as a fallback for nonexistent names and domains that do not publish their own applicable DMARC record, while a domain-level policy takes precedence when one exists. In May 2026, RFC 9989 incorporated PSD DMARC into the updated standard. The .BANK and .INSURANCE implementation demonstrates that this approach can be approved and deployed, although each dotBrand operator must still evaluate its own Registry Agreement and any required ICANN process. 

Actionable Impact Across Teams 

If you are considering applying, but have been trying to understand near-term value, ensure your security teams are aware of this opportunity. 

If you own a dotBrand, work with your registry service provider, email security team, and ICANN counsel to assess whether this policy is appropriate.  

Ready to explore how your domain portfolio can strengthen your security architecture? Contact our dotBrand strategy team today to discuss the intersection of your own application and technical security protocols.