What 99,300 Domains Reveal About Email Authentication and DNS Resilience
In short:
- Primary email providers and gateways handle message delivery, but domain owners are ultimately responsible for configuring and maintaining DMARC policies to prevent domain forgery.
- A Palisade study of 99,300 domains revealed that two in five domains lack a DMARC policy, and over a third of domains with DMARC remain in passive monitoring mode rather than enforcing protection.
- Over 20% of DMARC-publishing domains omit aggregate reporting addresses, leaving administrators without the visibility required to fix authentication failures and transition to strict enforcement.
Organizations often treat their choice of Microsoft 365, Google Workspace, or an email security gateway as the main decision protecting business email. Those services matter, but they do not finish the job.
The visible domain in an email address is governed by the Domain Name System (DNS), and the domain owner must still publish a policy specifying how receiving systems handle messages that fail authentication.
That policy is Domain-based Message Authentication, Reporting, and Conformance (DMARC).
DMARC connects the domain shown in the “From” line with the two main mechanisms used to authenticate email: the Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). When alignment fails, an enforcing DMARC policy asks participating receivers to quarantine or reject the message. Without a valid DMARC record, receivers have no DMARC handling request from the domain owner. A criminal can still try to forge the organization’s exact domain in an invoice, a password reset notice, or an executive request.
To see how widely that control is deployed, my colleagues at Palisade measured public DNS records across a pinned corpus of the top 100,000 web domains. We observed 99,300 domains during a single scan window on 14 August 2026, resolving DMARC, SPF, Brand Indicators for Message Identification (BIMI), and Mail Exchange (MX) records through the same public resolvers.
2 in 5 Domains Have No DMARC Policy
The broad result was mixed. Only 58.1% of observed domains published DMARC. Among those publishers, 64.0% asked receivers to quarantine or reject failures. Put differently, roughly two in five observed domains had no DMARC policy, while more than one-third of DMARC publishers remained in monitoring mode.
We also compared domains based on their observed inbound-mail infrastructure. Because highly ranked domains can have different security profiles from lower-ranked ones, we standardized each provider group to the same rank-band distribution. After that adjustment, DMARC adoption was 89.4% among observed Microsoft 365 domains and 80.6% among Google Workspace domains. Enforcement among DMARC publishers was 68.3% and 62.1%, respectively. Recognized email gateways measured 94.7% adoption and 76.0% enforcement.
These are observational differences, not evidence that choosing one provider causes better authentication. An MX record indicates where inbound mail appears to be handled. It may not reveal the underlying mailbox platform, especially when a gateway sits in front of it. More importantly, the DMARC policy still belongs to the domain owner. Buying a leading email platform does not ensure that the policy is published or enforced safely.
The Reporting Gap may be Just as Important as the Policy Gap
DMARC can direct aggregate reports to the domain owner, showing which services send mail using the domain and whether those messages align with the domain. Yet 20.7% of DMARC publishers in the study had no aggregate-reporting address. Without that feedback loop, operators have less evidence to identify forgotten senders, correct authentication failures, and move safely from monitoring to enforcement.
SPF offered another reminder that email resilience depends on DNS operations. Across domains that published SPF records, 2.6% experienced recursive lookup failures. These errors can appear when a record depends on too many external services or when one of those dependencies changes. A policy can exist in DNS and still fail when it is evaluated.
The Practical Response is Not to Chase a Perfect Provider Score
Domain owners should maintain an inventory of legitimate senders, collect DMARC reports, correct SPF and DKIM alignment, and move deliberately toward quarantine or rejection. They should also retest after DNS or vendor changes rather than treating authentication as a one-time project.
Public DNS measurements offer a useful view of readiness—but interpreting them requires careful boundaries. A DNS record does not prove that an organization was attacked, that a provider caused the outcome, or that every message is safe. It does show whether the domain owner has published an explicit policy, preserved a reporting path, and avoided several common configuration failures.
Email depends on shared infrastructure, but responsibility remains distributed. Providers can supply strong systems; receivers can evaluate authentication; standards bodies can improve the protocols. The domain owner still has to publish, monitor, and maintain the policy. That final step is what turns a mailbox service into a more resilient identity layer.
Samuel Chenard is the CEO and co-founder of Palisade, where he works with IT teams and managed service providers on email authentication and deliverability. He leads Palisade’s reproducible public-DNS research on DMARC, SPF, BIMI, and MX deployment.
The views expressed by the authors of this blog post are their own and do not necessarily reflect the views of the Internet Society.