99,300 Domains: Email Authentication and DNS Resilience

A recent study analyzed 99,300 domains across a broad range of industries and sizes to understand how organizations configure their email authentication and DNS infrastructure. The results are illuminating and, in some areas, concerning.

Most organizations do not know where they stand relative to these benchmarks. They have no visibility into their own DMARC pass rates, SPF lookup counts, or TLS enforcement rates until something breaks. DMARCFlow provides that baseline visibility by reading your aggregate reports continuously, so you can see how your configuration compares to what the study describes.

Here is what the study found.

The Scope of the Study

The dataset covers domains registered across multiple TLDs, with registered domains spanning small business, enterprise, government, and nonprofit categories. The study examined live DNS records and email authentication configurations in real time, not self-reported survey data. This matters because DNS and email authentication records are objective and cannot be faked in a one-time audit.

The study measured five categories:

DMARC policy and alignment configuration

SPF record presence and complexity

DKIM signing configuration

TLS enforcement on MX hosts

DNS nameserver redundancy and response patterns

What it found in each category is worth examining carefully.

DMARC Adoption: Most Domains Still Do Not Enforce

The most striking finding is how few domains actually use DMARC in enforcement mode. Studies of similar scale consistently find that fewer than 20% of domains publish any DMARC record at all. Of those that do, the majority use p=none, which tells receiving mail servers to take no action on messages that fail DMARC alignment.

Only a small fraction of domains with DMARC use p=quarantine or p=reject. This means the organizations that most need email authentication to protect against spoofing are often the ones least likely to enforce it.

The reason is almost always the same: organizations discover during the monitoring phase that they have more legitimate third-party senders than they knew about. Marketing automation platforms, billing systems, CRM tools, and legacy SaaS applications often send email on behalf of the organization using their own mail servers. Each one needs to be identified and aligned before enforcement is safe. That process takes time and cross-team coordination.

What this means in practice: if you have DMARC at p=none or no DMARC at all, you are in the majority. The minority that enforces DMARC has usually spent months in the monitoring phase first.

SPF Coverage: Present but Often Broken

SPF is more widely deployed than DMARC. Well over half of the domains in studies of this size have at least one SPF record. But having an SPF record and having a correct SPF record are different things.

The most common SPF problem is the 10-DNS-lookup limit defined in RFC 7208. Each include: mechanism, each redirect: modifier, and each a: or mx: mechanism that triggers a DNS lookup counts toward this limit. When a domain exceeds 10 lookups, the SPF check returns a permanent error (permerror) and most receiving mail servers treat it as a softfail rather than a pass or fail.

The study found that a meaningful fraction of domains with SPF records exceed the 10-lookup limit. These domains are effectively sending email without reliable SPF validation, because receiving servers handle the permerror inconsistently.

The second common SPF problem is using ~all instead of -all. The tilde (~) means softfail, which tells receivers to treat failing messages as suspicious but not to reject them. The minus (-) means hardfail, which tells receivers to reject messages that do not match. Many domains use softfail because it feels safer, but it provides almost no protection against spoofing.

What this means: having an SPF record is not the same as having a working SPF record. Check your lookup count and your -all vs ~all setting before assuming you are protected.

DKIM Signing: The Least Deployed of the Three

DKIM is the least commonly deployed of the three main email authentication mechanisms. Studies consistently find that fewer domains have DKIM records than have SPF or even DMARC records.

The reasons vary. DKIM requires key generation, key rotation, and alignment configuration that SPF and DMARC do not. Many organizations set up DKIM once and forget about it, then find their DKIM signatures breaking when they rotate DNS without updating their DKIM selector records.

DKIM key size matters too. 1024-bit DKIM keys are increasingly viewed as inadequate; 2048-bit keys are now the minimum recommended for new deployments. The study found a mix of both, with newer domains more likely to use 2048-bit keys and older deployments often still on 1024-bit.

What this means: if you are evaluating your email authentication posture and find DKIM is missing or misconfigured, you are not unusual. But DKIM is also the authentication mechanism that provides the strongest protection against certain types of spoofing, because it is cryptographically tied to the message content and cannot be forged by an external attacker without the private key.

TLS for Email: Most MX Hosts Encrypt, But Not All

The study measured whether MX hosts require STARTTLS, accept plaintext connections, or have valid TLS certificates. The findings are more positive here than for email authentication.

Most large domains and most domains hosted on major email providers have STARTTLS required. The percentage drops for smaller hosting providers and domains running their own mail servers. The study found that roughly 80-85% of MX hosts in similar datasets advertise STARTTLS support, but not all of those require it.

The practical consequence of unencrypted email transport is that messages can be intercepted and read in transit by anyone with network access at any point between the sending server and the receiving server. This is a concern for sensitive industries but less so for routine transactional email.

The TLS certificate aspect also matters for deliverability. Major mailbox providers like Google and Microsoft use TLS encryption as a positive signal for email reputation. Domains that never encrypt transport may be penalized in spam filtering even if their content is legitimate.

What this means: check whether your MX hosts require STARTTLS, not just whether they support it. If your mail server accepts plaintext connections, consider requiring TLS to improve deliverability and security.

DNS Resilience: The Often Overlooked Finding

The DNS resilience section of the study is the most overlooked part, but arguably the most operationally critical. It measured two things: nameserver redundancy and DNS response consistency.

Domains with only a single nameserver have a single point of failure. If that nameserver becomes unreachable, the entire domain becomes unreachable for email delivery, web hosting, and anything else that depends on DNS. Studies consistently find that a significant fraction of registered domains run on two or fewer nameservers.

The response consistency finding is subtler. Some domains respond to queries from different geographic locations with different answers, sometimes within seconds of each other. This behavior, often caused by anycast routing or DNS load balancing, is not necessarily a problem, but it can mask configuration issues or create intermittent failures that are difficult to diagnose.

What this means: if your domain has fewer than two geographically distributed nameservers, you have a resilience gap. Email delivery depends on DNS resolution at the receiving server. If your nameservers are unreachable, your email stops being delivered even if your mail server is running perfectly.

What the Data Means for Your Email Security Posture

The study paints a picture of an industry where email authentication is widely understood but unevenly deployed. The organizations that have fully implemented SPF, DKIM, and DMARC enforcement tend to be larger enterprises with dedicated email security teams. Smaller organizations and mid-market businesses frequently operate with partial or misconfigured authentication.

The most common gaps in order of frequency:
1. No DMARC record at all
2. DMARC at p=none without a plan to move to enforcement
3. SPF records that exceed the 10-lookup limit
4. SPF at softfail (~all) instead of hardfail (-all)
5. Missing DKIM configuration or broken DKIM key rotation
6. TLS accepted but not required on MX hosts
7. Fewer than two redundant nameservers

Each of these gaps creates a specific risk. Spoofing is possible when DMARC is absent or at p=none. SPF permerrors create inconsistent authentication results when the lookup limit is exceeded. TLS interception is possible when plaintext is accepted. Email unavailability is possible with single-nameserver domains.

How to Benchmark Your Own Email Authentication Setup

The study gives you a population average. Your goal is to know where your own domains stand against that average and against best practice.

Here is the minimum checklist:

Run a DMARC lookup on your domain. If you have no DMARC record, you are below the population average.

Parse your SPF record for lookup count. If you have more than 10 mechanisms that trigger DNS lookups, you have a broken SPF configuration.

Check whether your SPF record ends in -all or ~all. If it ends in ~all, you have softfail protection, which is better than nothing but not the same as hardfail.

Check whether you have DKIM configured for your outbound email. If not, you are missing one of the two strongest authentication signals.

Look up your MX hosts and check whether they require STARTTLS or accept plaintext.

Check your nameserver count and geographic distribution.

Once you have this baseline, you can track improvements over time. DMARCFlow helps with this by reading your aggregate reports continuously, alerting you when your pass rates change and surfacing new sending sources that appear without notice. This turns the study's population benchmarks into a practical comparison: you can see not just where you are today, but whether your configuration is improving month over month.

FAQ

Is a sample of 99,300 domains statistically meaningful?

For broad patterns like DMARC adoption rates and SPF deployment, yes. Studies at this scale reliably capture the overall distribution of configurations across domain registrars, hosting providers, and organization sizes. Specific percentages vary between studies depending on methodology, but the relative ordering of findings is consistent across independent research.

Why do so many domains lack DMARC?

Because moving from no DMARC to p=none is easy. Moving from p=none to p=quarantine or p=reject requires identifying every legitimate third-party sender and getting each one aligned. This is a cross-functional project, not a DNS change, which is why so many domains stall at p=none indefinitely.

What is the biggest email security gap you see in the data?

SPF at softfail is often treated as equivalent to hardfail, but it is not. Softfail tells receivers to treat failing messages as suspicious, which most spam filters handle inconsistently. Hardfail tells receivers to reject messages that do not match, which provides actual protection against spoofing. Moving from ~all to -all is one of the highest-signal, lowest-risk configuration changes available.

How often should I re-benchmark my email authentication configuration?

At minimum quarterly, or whenever you add a new email sending platform, change hosting providers, or modify your DNS configuration. Email authentication is not a one-time project.

Does this data apply to small businesses or only large enterprises?

The study included domains across all sizes, and the patterns are broadly consistent. Small businesses tend to have fewer dedicated email security staff, which means configurations are more likely to be set once and forgotten. The same risks exist regardless of organization size.

How does DMARCFlow help with benchmarking?

DMARCFlow reads your DMARC aggregate reports and turns the raw XML into a readable dashboard. It tracks your authentication pass rates by domain and by receiving mail server, so you can see whether your alignment is improving over time and whether specific receivers are handling your messages differently. If a new sending source starts appearing in your reports without your knowledge, DMARCFlow flags it before it damages your deliverability. This is the practical equivalent of being able to compare your own numbers against the 99,300-domain study dataset every day.