Everyone talks about data sovereignty - but why does nobody start with the low-hanging fruit?
Data sovereignty is a hot topic. News outlets, LinkedIn, and government policies all reference it; conferences make it a headline issue and CISOs increasingly use it as a strategic cornerstone. And rightly so. Organizations want—and must—retain full control over their confidential information. This isn’t just about the US Cloud Act, but also about regulations like NIS2, DORA, and the fast-growing threat of digital espionage and sabotage.
That’s why Zivver and Kiteworks recently launched the Private Data Network (PDN): a fully sovereign, secure, and practical solution for communication and data exchange. From collaboration (as an addition to or alternative for e.g. SharePoint) to email, managed file transfer, and web forms—everything remains under the organization’s control, whether on-premises or in a private cloud.
At the same time, there’s an uncomfortable paradox: everyone talks about data sovereignty, but almost no organization has its foundational email security in order.
In this blog article we unpack:
-
Why email security is critical for data sovereignty
-
Why TLS (such as STARTTLS) doesn’t provide sufficient protection
-
How DANE and MTA-STS solve these issues—and why they’re rarely implemented well
-
How Microsoft and Google handle these standards
-
Why fallback and enforcement are crucial for workable email security
-
How Zivver enables secure communications with built-in fallback
Real data sovereignty starts with secure email—and that’s where it usually goes wrong
In my experience, less than 1% of organizations have set up email security according to the standards recommended by leading authorities for years. Yet email and file transfer remain the main channels for sharing sensitive information—legal documents, medical records, HR files, financial reports, client data, intellectual property, and more. Recent research shows that for over 90% of employees, email is still essential to their daily work.
Despite this, most organizations lack proper email security. Why? Lack of awareness, underestimation of the risks, or the belief that securing email is simply too much hassle.
The consequences? Sensitive emails can be intercepted, redirected, or read by unauthorized foreign entities, without sender or recipient ever knowing. This is not a distant scenario, but a real, daily risk.
And that directly contradicts the concept of digital sovereignty. You can’t claim control over your data if you don’t secure the infrastructure you use to share that data—especially email—against basic forms of interception. Sovereignty means deciding who has access to your data. If you can’t guarantee this for email, the whole idea of sovereignty is little more than an illusion.
It raises the question: for many organizations, is the “sovereignty movement” more about optics than genuine progress? If you’re serious, start with the basics.
What Is TLS encryption and why is it not enough for fonfidential email?
Most organizations rely on so-called opportunistic TLS (STARTTLS) to encrypt emails. TLS (Transport Layer Security) is a protocol that encrypts communication between servers, such as when sending email. This leads many to believe their security is sufficient. But STARTTLS has fundamental flaws:
- No guarantee of use: If the recipient’s server doesn’t support TLS, the connection simply downgrades to unencrypted transmission. The request to use TLS is itself unencrypted, making it easy for an attacker to force a downgrade (downgrade attack).
- No guarantee about the recipient’s server: STARTTLS does not authenticate the recipient server. You can’t be sure you’re really communicating with the right party. This opens the door for man-in-the-middle attacks - a very real risk.
As many security agencies, such as the Dutch Nation Cyber Security Centre (NCSC), have warned: “An active attacker can easily undo the use of STARTTLS.” You may think your communications are secure, but they can actually be intercepted quite easily, sometimes by exactly the actors from whom you are trying to protect your data.
Why Microsoft and Google’s TLS fall short
Recent research shows that Microsoft 365 and Google Workspace do not guarantee secure email delivery—even when “force TLS” is enabled. Google still delivers emails using outdated and vulnerable TLS 1.0/1.1 protocols, while Microsoft 365 sends messages completely unencrypted if secure TLS is not available. These unsafe fallbacks happen silently, exposing sensitive data without warning or audit trail—leaving organizations with a false sense of security
DANE and MTA-STS solve TLS vulnerabilities—but few organizations use them effectively
Fortunately, there are standards that do solve these problems:
-
DANE (DNS-based Authentication of Named Entities) links mail server certificates to DNS records signed with DNSSEC. This guarantees you’re communicating with the right server—and that TLS is enforced.
-
MTA-STS (Mail Transfer Agent Strict Transport Security) achieves something similar using HTTPS policies. It validates TLS without relying on DNSSEC.
The European Committee strongly recommends DANE as the standard to protect emails at the transport level.
MTA-STS is seen as less secure and more complex to manage than DANE. It requires a separate HTTPS infrastructure and regular manual maintenance of policy files, which can be error-prone, especially for organizations with limited IT resources.
Both standards make mail routing between servers genuinely secure but, in practice, they are rarely, or incorrectly, implemented.
Microsoft and Google: Limited support and enforcement
Microsoft and Google have supported MTA-STS for several years. As of October 2024, Microsoft also supports incoming DANE, a major step, driven in part by pressure by European governments, such as the Dutch parliament.
Yet adoption remains very low: less than 20% of domains in most western countries support DANE, and even fewer domains support MTA-STS.
More importantly, these standards cannot be enforced in Microsoft 365 or Google Workspace, and there is no indication this will change soon. At best, you can check if DANE/MTA-STS is present, but you cannot require its use. Even if enforcement were possible, there’s still a problem: there’s no fallback mechanism if the recipient doesn’t support the required protocols.
Without fallback, secure communication and workflows break down
If you do manage to enforce DANE or MTA-STS and the recipient doesn’t support it, your email simply won’t be delivered—the sender receives a “bounce” (Non-Delivery Report). What happens next? Typically, employees have to find an alternative way to send the message and often, they don’t know what to do. To ge the job done quickly and easily, sensitive information ends up being sent via insecure or uncontrolled channels
In other words, the workflow breaks down. For professionals who just need to “quickly send something confidential”—think civil servants, healthcare professionals, legal, or HR staff—the lack of fallback is a dealbreaker. Secure communication becomes impractical, so organizations shy away from enforcing the standard, even if they want to in principle.
If this enforcement was available in Microsoft 365, about 70% of messages would bounce; for Google, it could be 99%. Clearly, this is unworkable. That’s why even the most informed organizations often fail to strictly implement these standards.
Secure email standards can be simple with the right infrastructure
With a robust secure email solution, enforcing standards like DANE and MTA-STS can be straightforward. Zivver offers full support for enforcing these standards as an add-on to M365, Exchange, Google, and others. Our infrastructure actively checks for secure routes and enables organizations to truly enforce these standards, including fallback options to secure portals—so employees can keep working as usual.
Technically, it can be set up in just a few hours. Yet, only a small fraction of organizations actually choose to enforce it.
Why? The topic is often seen as complex, both internally and when explaining it externally. In practice, however, the reasoning is clear: as an organization, you value data sovereignty, so you follow recognized security standards. If a recipient doesn’t comply, it’s their risk—and responsibility—to adapt, not yours as the sender.
False sense of security: Many assume their emails are secure
Some organizations or vendors claim to send “secure” email via DANE or MTA-STS. But look closer, and you often find:
-
Secure email is used only if an employee manually clicks the right button, chooses a label, or enters a trigger word
-
DANE or MTA-STS is only used opportunistically, not enforced
-
Third-party “secure email” solutions that lack their own mail server and simply send via services like Amazon SES, which doesn’t support DANE or MTA-STS, meaning emails may travel in plain text through US-managed infrastructure
This actually increases the risk of interception and undermines the whole point of data sovereignty. It’s a false sense of security.
Data sovereignty starts with email security - not expensive prestige projects
Here’s the rub: organizations talk enthusiastically about data sovereignty—European clouds, local data centers, legal controls, geopolitical independence. All important, but if the foundation of secure communication is missing, it’s just symbolic politics.
Enforcing DANE or MTA-STS is low-hanging fruit. The investment is small, the technical barrier is modest, and the impact on sovereign communication is significant.
Successful sovereignly starts with email security and DANE
Everyone talks about data sovereignty. But if you really mean it, don’t start with prestige projects. Start by enforcing secure email. Start with DANE.
Does your organization already have this covered? Let us know—so others can learn from your approach, or so we can help you strengthen your foundation.
Want to know how your organization can enable email security with DANE and fallback today, and meet NIS2 and other compliance requirements? Contact us for a demo or advice.
