Email Authentication at the World’s Biggest AI Companies

The artificial intelligence industry spent two years making convincing digital impersonation effortless for everyone. We decided to check how well the world’s leading AI companies defend their own corporate domains against the exact same impersonation risks. On 6 August 2026, we ran live recursive DNS lookup tests across eight core email security protocols for 30 major AI companies.

The headline finding is simple. Every single company has deployed the foundational layer of email authentication. All 30 publish SPF and DMARC records, and at least 28 confirm DKIM. Once you look beyond those basics, the security posture drops off a cliff. Only two out of thirty companies publish MTA-STS. Only six sign their DNS records with DNSSEC, and 19 still leave their SPF records set to softfail.

Not a single AI-native company in our benchmark publishes MTA-STS. The only two players in the analysis that do are Google and Microsoft.

This leaves every AI startup in the cohort vulnerable to downgrade attacks and traffic interception in transit, even if their DMARC records pass verification.

Audit Your Domain Security

Want to see where your own domain stands? Check your domain setup in real time using the PowerDMARC Domain Analyzer while you explore the complete benchmark dataset.

What We Measured and How

Our research sample covers 30 major AI organisations: OpenAI, Anthropic, Google, DeepMind, Microsoft, Meta AI, NVIDIA, Amazon, Apple, IBM, xAI, Mistral, Cohere, Perplexity, Hugging Face, Stability AI, Midjourney, Character.AI, ElevenLabs, Runway, Databricks, Scale AI, DeepSeek, Cursor, Replit, Groq, Together AI, Cerebras, Writer, and Glean. We evaluated the corporate apex domain for each entity on 6 August 2026 – Google and DeepMind are tracked as separate apex domains throughout this report.

We measured eight specific protocols and parameters: SPF record configuration, DKIM selector presence, DMARC policy deployment, DNSSEC validation, MTA-STS, TLS-RPT, BIMI (Brand Indicators for Message Identification), and MX service providers. We queried public recursive resolvers (1.1.1.1, 8.8.8.8, 9.9.9.9, 8.8.4.4) with EDNS0 enabled and ran three to four retries per record. SPF apex TXT records were retrieved using DNS-over-HTTPS to avoid TCP/53 fallback issues on oversized TXT sets. SPF recursive lookup counts were calculated strictly per RFC 7208 section 4.6.4.

To keep this research completely transparent, we note six clear analytical limitations:

• DKIM Probe Limits: DKIM selectors cannot be enumerated via standard DNS queries. Our count of 28 out of 30 represents a lower bound. For example, meta.com returned no hits across 100+ probed selectors, which indicates a custom selector rather than missing DKIM.
• Wildcards: databricks.com runs a DNS wildcard under _domainkey. Any selector query resolves, making an exact selector count meaningless. We recorded this setup as a wildcard finding.
• Apex Scope: We tested primary corporate apex domains only. Dedicated marketing or transaction subdomains were not evaluated.
• DNS Failures on Sub-includes: amazon.com relies on spf3.amazon.com, which failed to resolve due to size. Amazon’s recorded total of four lookups serves as a floor.
• Point-in-Time Scope: DNS configurations change. This data reflects a live snapshot from 6 August 2026.
• Posture vs Breach: A looser authentication policy reflects a weaker anti-spoofing stance. It does not imply a security breach or operational negligence.

Every data point in this report can be verified independently using standard dig commands against public resolvers.

Everyone Passes the Basics of Email Authentication

The baseline protocols enjoy total adoption across the AI sector. All 30 companies publish an SPF record, all 30 publish a DMARC record, and 29 publish a valid aggregate reporting address (rua). Ninety percent of the sample enforces DMARC at either p=quarantine (12 companies) or p=reject (15 companies).

However, context matters. Exactly 50.0% of these top AI companies enforce a strict p=reject policy. For context, our recent United States DMARC & MTA-STS Adoption Report shows a 49.0% p=reject enforcement rate nationwide. The world’s most valuable AI firms are performing right at the national average for basic DMARC enforcement.

If you want to understand what p=reject actually does, it serves as the final gateway to block unauthorized messages before they hit the inbox. Three companies in the benchmark, Hugging Face, Stability AI, and Cerebras, remain parked at p=none, which monitors traffic without blocking spoofed mail.

Protocol Adoption Matrix (Sample of 30 Major AI Companies)

Source: PowerDMARC Live DNS Research (6 August 2026)

Only Two of Thirty Publish MTA-STS

While basic domain verification is everywhere, transport-layer security tells a very different story. Out of 30 market leaders, only Google and Microsoft publish RFC 8461 MTA-STS (Mail Transfer Agent Strict Transport Security) records and TLS-RPT (SMTP TLS Reporting). Zero AI-native startups or specialized hardware providers publish these records. Our MTA-STS explainer walks through exactly how the protocol works.

DMARC and MTA-STS solve entirely different problems in the security stack. DMARC authenticates the identity of the sender to prevent header spoofing. MTA-STS enforces encrypted TLS connections between mail servers to prevent man-in-the-middle interception and downgrade attacks. One protocol does not replace the other.

To be fair, a 6.7% adoption rate within this sample still outperforms the 1.7% national baseline reported in our US research. The real takeaway is structural: the only companies in the AI ecosystem enforcing transport security are the two tech giants that run global cloud mail platforms. You can verify your transport encryption status with the PowerDMARC MTA-STS Checker.

The DNSSEC Gap – Including Every Big Tech AI Player

DNSSEC (Domain Name System Security Extensions) provides cryptographic proof that DNS answers have not been forged. Only six of the thirty companies in our research sign their corporate zone with DNSSEC: Hugging Face, ElevenLabs, Databricks, Scale AI, Writer, and Glean. That represents a 20.0% adoption rate, slightly ahead of the 18.0% US national baseline.

The standout finding is who is missing. Not a single Big Tech player in our sample signs its primary corporate domain with DNSSEC. Google, Microsoft, Meta, NVIDIA, Amazon, Apple, and IBM all leave their apex domain unsigned.

Protocol Adoption Rates: Top 30 AI Companies vs. Baselines (2026)

Source: PowerDMARC Original Research (August 2026) | Valimail 2026 Industry Report

Stability AI’s Incomplete Deployment

Our scans revealed a classic deployment gap at Stability AI. The domain publishes a valid DNSKEY record within its zone, but lacks a corresponding DS (Delegation Signer) record at the parent registrar. Because the chain of trust breaks at the top level, validating resolvers treat the zone as completely unsigned. It looks like protection on paper, but provides no security to end users.

DNSSEC matters directly for email security because SPF, DKIM, and DMARC records are all delivered over plain DNS. Without cryptographic zone signing, attackers can manipulate DNS answers in transit to bypass email controls entirely.

Nineteen of Thirty Still Softfail SPF

Our research shows that 19 out of 30 companies end their SPF record with a ~all (softfail) qualifier instead of a -all (hardfail). Only nine use hardfail, while two companies (Meta and Writer) use a redirect= mechanism.

Interestingly, 10 of the 15 companies enforcing p=reject still use ~all in their SPF records. This list includes Anthropic, Google, DeepMind, NVIDIA, Perplexity, Character.AI, Databricks, Replit, Groq, and Glean. You can inspect your domain’s SPF syntax with the PowerDMARC SPF Lookup Tool.

It is crucial to understand SPF softfail vs hardfail syntax in this context. When a domain enforces DMARC at p=reject, the overall DMARC policy dictates message delivery. A softfail in SPF does not open a security hole when DMARC is active. However, using -all provides an explicit, unambiguous signal for receivers evaluating SPF independently. Moving from softfail to hardfail remains a simple way to harden your posture.

SPF Qualifier Breakdown at p=reject (15 Companies)

Nobody Is Over the SPF Lookup Limit – Yet

RFC 7208 sets a strict limit of 10 DNS lookups for SPF evaluation. Exceeding this limit causes a PermError, which invalidates the SPF check completely. None of the 30 companies exceed the 10-lookup ceiling. Writer sits closest to the edge at 9 lookups, followed by Perplexity at 8. OpenAI, Microsoft, and Cohere sit at 7 lookups.

OpenAI’s SPF record offers a great example of modern corporate email stacks. Their include chain includes Google Workspace, Microsoft 365, HubSpot, Marketo, and Oracle Cloud. That setup uses seven lookups, leaving three lookups of headroom. Adding just one more external marketing tool could push their record into an operational failure.

SPF DNS Lookup Headroom (Selected Companies Near 10-Lookup Limit)

Five Companies Already Outsource SPF Management

Managing lookups manually gets difficult at scale. Five companies in our benchmark use dedicated third-party services to handle their SPF infrastructure:

Four out of these five organizations use SPF macros rather than flat IP lists. SPF macros evaluate incoming connections dynamically at query time, making them a proven standard for complex corporate networks.

Organizations looking to circumvent lookup limits without manual tracking can evaluate PowerDMARC PowerSPF Hosted SPF Solutions.

Writer’s configuration highlights why proper implementation matters. Their third-party redirect mechanism consumes nine of their ten permitted lookups in a single step. Using a managed hosted SPF service should simplify your record, not consume almost all of your lookup budget.

Three Majors Are Still Monitoring-Only

Hugging Face, Stability AI, and Cerebras maintain a DMARC policy of p=none. This setting collects delivery reports without protecting the domain from abuse. Attackers can send unauthorized messages using these domain names, and receiving mail servers will still deliver them normally.

This policy choice is particularly notable for Hugging Face, which serves as the central hub for downloading open AI model weights. A convincing fake email from Hugging Face could easily trick developers into downloading compromised code or model files. On the flip side, Hugging Face deserves credit for being one of only six companies in our sample to sign its domain with DNSSEC.

What This Means – and What to Fix

These actionable security recommendations provide a targeted roadmap for the analyzed AI companies to eliminate spoofing vulnerabilities and protect their domain reputation. Implementing these email authentication and DNS controls enforces strict sender verification, secures transit encryption, and establishes ongoing operational oversight.

1. Reach DMARC Enforcement: Move your policy from p=none to p=quarantine, then set a clear target date to reach p=reject.
2. Harden SPF Qualifiers: Change your SPF record ending from ~all to -all once your DMARC aggregate reports confirm all legitimate senders align.
3. Deploy MTA-STS and TLS-RPT: Secure your mail in transit. DMARC verifies the sender’s identity, but MTA-STS protects transport encryption between servers.
4. Enable DNSSEC Correctly: Sign your DNS zone and make sure your registrar publishes the corresponding DS record to complete the chain of trust.
5. Manage SPF Lookup Limits: Monitor your total DNS lookups closely. Use macro-based hosted SPF tools to avoid hitting the 10-lookup ceiling.
6. Explicitly Define Subdomains: Set an explicit sp= policy in your DMARC record to prevent attackers from spoofing unprotected subdomains.
7. Assign Operational Ownership: Technical controls need regular oversight. Pick a dedicated team member to review DMARC reports every week.

Closing the Email Authentication Gap

Our August 2026 research shows that all 30 top AI companies have deployed the core elements of email authentication: SPF, DKIM, and DMARC are present across the board. However, adoption halts as soon as you look past those initial steps. Only two publish MTA-STS, only six sign with DNSSEC, and nineteen still rely on softfail SPF records.

The AI sector has successfully completed the initial setup phase. The next step is adopting advanced controls like transport encryption and zone signing to close the remaining gaps. These improvements do not require switching vendors; they just require operational focus.

Want to see where your domain stands? You can check your own domain with the PowerDMARC Free Domain Record Checker or explore the PowerDMARC Free Security Tools Suite to secure your email posture. Email phishing keeps climbing every year, and the companies profiled here are exactly the kind of brand attackers like to spoof. If you would rather talk through what these gaps mean for your own domain, you can talk to our team directly.

Frequently Asked Questions

Do major AI companies use DMARC?

Yes, 100% of the 30 major AI companies evaluated in our research publish a valid DMARC record. However, only 90% enforce an active policy (quarantine or reject), while 10% remain on monitoring-only mode (p=none).

How many AI companies enforce DMARC at p=reject?

Exactly 15 out of 30 companies (50.0%) enforce DMARC at p=reject. This matches the current US national average of 49.0% recorded across broader industry benchmarks.

What is MTA-STS and why doesn’t DMARC replace it?

MTA-STS enforces encrypted TLS connections for emails in transit between servers. DMARC authenticates sender identity to prevent address spoofing. They protect different parts of the email pipeline, meaning neither protocol can replace the other.

Does DNSSEC matter for email authentication?

Yes, DNSSEC protects your domain against DNS spoofing and cache poisoning. Because SPF, DKIM, and DMARC records rely on DNS queries, DNSSEC ensures those policy records cannot be tampered with in transit.

Is SPF ~all (softfail) a security problem?

Not if your domain enforces DMARC at p=quarantine or p=reject. When DMARC enforcement is active, it overrides the softfail. However, switching to -all (hardfail) offers a stronger security signal for receivers checking SPF independently.

What is the SPF 10-lookup limit and who is close to it?

RFC 7208 limits SPF evaluations to 10 recursive DNS lookups to prevent server abuse. Exceeding 10 lookups triggers a PermError. In our study, Writer leads with 9 lookups, followed by Perplexity at 8.

How was this research conducted?

Data was gathered on 6 August 2026 using live DNS queries across public recursive resolvers. We evaluated corporate apex domains for 30 major AI companies across eight core email security protocols per RFC standards

• About
• Latest Posts

Milena Baghdasaryan

Content Specialist at PowerDMARC

Milena is a skilled writer and content creator with 7+ years of experience in crafting engaging content on IT, cybersecurity, virtual events, and more. She has a proven track record of delivering high-quality work for international magazines and is a graduate of prestigious institutions such as New York University Abu Dhabi, UWC China, and the College of Europe.

Latest posts by Milena Baghdasaryan (see all)

• Email Authentication at the World’s Biggest AI Companies - August 10, 2026
• Top 5 Business Email Compromise (BEC) Tools in 2026 - July 31, 2026
• Free DMARC Tools: Checkers, Generators & Monitoring (2026) - July 30, 2026