Use of Email Security Standards in the Netherlands (September 2025): only 14% DANE, 6% MTA-STS

Summary

• Only 14% of the domains analyzed support DANE, and just 6% support MTA-STS. This means that over 80% of domains still fail to meet the basic standard for secure email transport.

• One in three domains (32.5%) has no standard configured at all, meaning emails are still often delivered unencrypted or via vulnerable STARTTLS connections.

• When weighted by email volume, large organizations perform better: 25% of all email traffic is secured with DANE and 19.1% with MTA-STS (driven mainly by @gmail.com and @hotmail.com). Still, 13.6% of all email traffic is sent to domains without any protection.

• The trend between July and September 2025 is fragile: 47 domains upgraded to DANE, but 33 domains regressed to “no standard.” While there is progress, structural assurance is still missing.

Conclusion: Without the use of sending mail servers that support multiple standards (DANE, MTA-STS, and DNSSEC with certificate validation) and a secure fallback, email traffic in the Netherlands remains both vulnerable and non-compliant with NIS2, ISO 27001.

1. Introduction

In 2025, email remains the most widely used communication channel in the Netherlands. Healthcare institutions exchange patient data, municipalities communicate with citizens, and companies send contracts, invoices, and confidential information. Precisely this ubiquity makes email vulnerable.

The underlying protocol, SMTP, dates back to 1982 and was never designed with security in mind. Without additional safeguards, email in transit can easily be intercepted, manipulated, or compromised. This is not a theoretical concern: in practice, it leads to data breaches, legal issues, and reputational damage.

That is why strong transport security (TLS with enforceable standards) is the absolute baseline. Without reliable encryption between sender and receiver, the entire framework of secure emailing collapses. Even a “confidential” or “registered” email is meaningless if the underlying connection can be downgraded to insecure SMTP.

In this blog, we map the current state of transport security standards in the Netherlands. Based on an analysis of the 10,000 most-emailed domains by Zivver customers, we provide a realistic picture of how well organizations are prepared for secure email. We look not only at the current adoption rates, but also at trends over time, and compare the figures against the obligations set by NIS2, ISO 27001, the GDPR, and EU-recommended standards such as DANE and MTA-STS.

Read also: The Working and Application of Standards for Secure Emailing

2. Three Levels of Secure Emailing

It is important to distinguish between different levels of secure emailing:

1. Secure mail (strong transport security): TLS encryption of the connection between sending and receiving mail servers, combined with assurance of the receiving server’s identity, prevents interception in transit.

2. Confidential mail: Adds extra authentication for the recipient (e.g., SMS code). This protects against unauthorized access caused by email providers, hackers, administrators, or others with (improper) mailbox access.

3. Registered mail: Provides legally valid proof of delivery and message content.

Deze blog richt zich op niveau 1: transportbeveiliging. Want als dit fundament ontbreekt, stort de hele piramide in.

3. Transport Security: A Two-Sided Dependency

Transport security in email is like a handshake: it only works if both hands grip firmly. If one party lets go, the security is lost. This makes email unique compared to many other security technologies: its success depends on both the sender and the receiver.

• On the sending side, an organization can configure its system to deliver email only over TLS and attempt to enforce standards such as DANE or MTA-STS. But if the receiving server does not support these standards, the connection will automatically fall back to a weaker protocol such as STARTTLS — or even to plain SMTP without encryption.

• On the receiving side, an organization may properly publish a DANE record or configure an MTA-STS policy. But if the sending mail server does not understand or support these standards, the email remains vulnerable to downgrade or man-in-the-middle attacks.

In practice, this means that a secure route can only be established when both sender and receiver support a standard — and the sender enforces it.

This two-sided dependency creates a “weakest link” problem: the level of security is always determined by the least advanced party in the chain. Because email chains are often long — think of hospitals communicating with small suppliers, or municipalities exchanging messages with citizens — the likelihood that somewhere in the chain a weak link undermines the connection is high.

That is why broad adoption of all three standards — DANE, MTA-STS, and DNSSEC — is essential, and why the sender must also implement a secure fallback mechanism. Only then can organizations guarantee that messages are not delivered unprotected in transit.

4. The Three Standards in Detail

Transport security with TLS sounds simple: “encrypt the connection and you’re done.” In reality, it’s more complex, because TLS without additional safeguards remains vulnerable to attacks and misconfigurations. That’s why three standards have been developed to make TLS enforceable and reliable.

4.1 DANE (DNS-Based Authentication of Named Entities)

DANE cryptographically binds a mail server’s TLS certificate to the domain via DNSSEC. This allows the sending mail server to verify that the certificate offered truly belongs to the receiving server.

Advantages:

• Highest level of assurance: prevents man-in-the-middle attacks.

• Recommended by the European Commission and mandated by the Dutch Standardization Forum for government domains.

• Aligns with ISO 27001 requirements for secure information transfer and cryptographic controls.

Limitations:

• Requires correct DNSSEC implementation; error-prone in management.

Conclusion: DANE is the most robust standard and should be regarded as the baseline in the Netherlands and across Europe.

4.2 MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS enables domain owners to publish a policy over HTTPS stating that their mail servers are only reachable via TLS. Sending servers that support MTA-STS will refuse connections that do not use TLS.

Advantages:

• Widely adopted by international providers, especially Google.

• Makes downgrade attacks more difficult.

• Less complex to manage than DANE.

Limitations:

• Relies on HTTPS and certificate management.

• Less robust than DANE (no cryptographic binding in DNS).

Conclusion: MTA-STS is a valuable complement for interoperability, particularly in international communications.

4.3 DNSSEC + Certificate Validation

Alongside DANE and MTA-STS, a third option exists: combining DNSSEC with TLS certificate validation. This offers additional assurance in environments where DANE is not yet implemented.

Advantages:

• Protects against simple downgrade attacks.

• Provides stronger assurance than STARTTLS or Enforce-TLS.

Limitations:

• Weaker than DANE or MTA-STS.

• Requires DNSSEC, which is not consistently deployed.

Conclusion: A useful addition, but not a full replacement for DANE or MTA-STS.

Important: Three Separate Standards

DANE, MTA-STS, and DNSSEC with certificate validation are not interchangeable but complementary. A sender that supports only DANE may still deliver insecurely to a recipient that only uses MTA-STS. For maximum coverage, a sending mail server must therefore support all three standards and actively enforce them.

Why “Just TLS” (STARTTLS) Is Not Enough

Many organizations still rely on opportunistic TLS via STARTTLS. It may look secure (“the connection is encrypted”), but in practice it is not:

• Downgrade attacks: STARTTLS can easily be stripped by an attacker.

• Fallback to plain SMTP: Without enforceable standards, a mail server may revert to unencrypted transmission.

• No certificate validation: Often certificates are not validated, enabling silent man-in-the-middle interception.

That’s why only DANE, MTA-STS, or DNSSEC with certificate validation make transport security truly reliable.

5. Research Methodology

For this analysis, we conducted a representative scan of the 10,000 domains most frequently emailed by Zivver customers. These are not random addresses, but domains of healthcare institutions, municipalities, ministries, banks, educational institutions, and companies — the organizations that together represent a large share of Dutch email traffic.

For each domain, we checked whether the following standards were active: DANE, MTA-STS, and DNSSEC + certificate validation. We measured results in two ways:

• Per domain: how often a standard is present.

• Weighted by email volume: how much traffic actually benefits from these standards.

The scans were conducted on 1 July and 1 September 2025, giving us not just a snapshot but also insight into changes over time. This showed which domains upgraded to DANE or MTA-STS, and which regressed.

Limitations: Only domains that were actually emailed were included. The results reflect the receiving side, not the security of outgoing mail servers.

6. Results (1 September 2025)

For this research, we analyzed the 10,000 domains most frequently emailed by Zivver customers. This is therefore not a random sample, but the domains that in practice handle a large share of Dutch email traffic: from hospitals and municipalities to ministries, banks, and suppliers. This provides a realistic picture of how well the Netherlands is actually positioned in terms of transport security.

6.1 Per Domain: Many with DNSSEC, Few with DANE, Even Fewer with MTA-STS

Looking purely at the number of domains, the following picture emerges:

Key observations:

• Almost half of the domains have DNSSEC enabled, but only a small fraction go a step further to implement DANE or MTA-STS.

• Only 14% of domains support DANE, the most robust standard and recommended baseline in the Netherlands.

• Even more concerning: 1 in 3 domains (32.5%) has no standard at all, relying solely on STARTTLS without enforcement — or even on plain, unencrypted SMTP.

6.2 Weighted by Email Volume

Because not every domain contributes equally to daily mail flows, we also looked at results weighted by email volume. Large entities such as banks, ministries, and healthcare institutions generate much more traffic than small suppliers or local businesses, as do popular domains like @gmail.com and @hotmail.com (which support MTA-STS but not DANE).

Key observations:

• DANE is far more significant by volume: a quarter of all email can be secured with it.

• MTA-STS adoption rises to 19.1% by volume, largely driven by traffic to Gmail and Hotmail.

• Yet still, 13.6% of all email traffic goes to domains without any security standard in place.

6.3 Development July – September 2025

By comparing the data from 1 July 2025 to 1 September 2025, we can see how domains evolved over time:

Good news:

• 47 domains upgraded from DNSSEC to DANE.

• Over 50 domains moved from “no standard” to at least DNSSEC.

Bad news:

• 33 domains that had DNSSEC in July lost it by September.

• 10 domains downgraded from DANE back to DNSSEC only.

This shows that implementations are often not structurally secured. A single expired certificate or incorrect DNS update can cause a domain to suddenly lose secure accessibility.

6.4 Summary: Fragile Progress

The results present a mixed picture:

• Large organizations lead the way: by volume, a quarter of all email is covered by DANE and almost 20% by MTA-STS.

• The long tail remains exposed: one in three domains has no protection at all.

• Implementations are fragile: dozens of domains regressed within two months, losing standards they had previously configured.

Conclusion: The Netherlands is making small steps forward, but the foundation remains fragile. As long as one-third of domains have nothing in place, a large share of email traffic will remain dependent on sending systems that can dynamically determine which standards are available — and that provide a secure fallback when none are.

7. Legal and Normative Framework

The data shows that the adoption of transport security standards in the Netherlands is lagging. This is not only a technical issue, but also one of compliance: various legal and normative frameworks require organizations to demonstrably implement strong transport security.

• ISO 27001: Requires organizations to safeguard information transfer (clause 5.14) and apply cryptography where necessary (clause 8.24). Transport security with enforceable standards is a baseline measure under this framework. Organizations that still rely on opportunistic STARTTLS do not comply.

• NIS2 Directive (EU): Obligates essential and important entities (such as municipalities, hospitals, energy providers, and banks) to take baseline security measures. Transport security is explicitly a core requirement. Importantly, NIS2 also requires evidence — organizations must be able to prove that secure transport is structurally and permanently in place.

• GDPR (EU): Demands appropriate technical and organizational measures for the secure transfer of personal data. If data breaches occur during insecure transmission, the sender is legally responsible and may face significant fines.

• EU recommendations (e.g., on DANE): The European Commission recommends DANE as the standard for secure email transport across Europe.

In short: Organizations that have not implemented DANE, MTA-STS, and DNSSEC are not only taking technical risks but are also in violation of legal requirements — risking fines and reputational damage.

8. The Importance of a Sending Mail Server with Fallback

Even if your own organization has everything perfectly configured — DANE implemented, DNSSEC active, certificates properly maintained — an email can still end up being delivered insecurely. The reason is simple: you have no control over the receiving side. If the recipient does not support any standard, transmission will fall back to unsecured transport.

That is why the role of the sending mail server is crucial. It must not only check which standards the receiver supports, but also automatically make the right decision. A modern sending mail server should:

• Support all three standards: DANE, MTA-STS, and DNSSEC with certificate validation.

• Detect in real time which standard the recipient supports.

• Always select the strongest available route: first DANE, then MTA-STS if possible, and only then DNSSEC with certificate validation.

• Fall back safely to an alternative (e.g., a secure message portal or confidential email) if no standard is available at all.

This fallback mechanism is essential. Without it, there is always the risk that sensitive information will still be transmitted unencrypted over the internet. That is not only technically insecure, but also non-compliant with frameworks such as ISO 27001, NIS2, and the GDPR.

In short: Transport security must be properly implemented on both the receiving and the sending side. Only then can organizations guarantee that sensitive information is always delivered securely and compliantly — even if the recipient lags in adopting standards.

9. Recommendations

The numbers are confronting: too few domains support DANE, MTA-STS adoption remains marginal, and one in three domains has nothing in place at all. This requires action. Below are the key recommendations for organizations that want to secure their email traffic and remain compliant:

1. Implement DANE without delay: DANE is not only the most robust technical standard, but also recommended by the European Commission and mandated by the Dutch Standardization Forum. For any organization that processes personal data or operates in a vital sector, DANE should be the top priority.

2. Complement DANE with MTA-STS and DNSSEC: Because not every recipient supports DANE, it is essential to also implement MTA-STS and DNSSEC. This maximizes the chance that a secure route is always available, including with international parties such as Google.

3. Choose a sending system with multiple delivery options and fallback: No single standard has 100% adoption. Your sending mail server must therefore support and enforce multiple standards, and automatically fall back to a secure alternative such as a secure message portal. Without fallback, there is always a risk of sensitive information being sent unencrypted.

4. Actively monitor your chain partners: Transport security is two-sided. It is not enough to configure your own environment correctly — you must also know which standards your partners, suppliers, and other organizations in your chain support. Monitoring provides insight, helps manage risks, and makes it easier to hold partners accountable.

5. Embed and report structurally: Implementing standards is not a one-time project, but an ongoing process. Certificates expire, DNS records change, and standards evolve. Set up procedures to check this continuously, and report on it within your compliance and risk management processes.