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 wil talk about:
-
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 as long as secure email standards aren’t enforced.
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 Confidential 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.
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 prevents downgrade attacks and validates TLS without relying on DNSSEC.
The European Committee strongly recommends DANE as the standard to protect e-mails 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 less than % of 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 Workflow—Breaks 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?
-
Employees have to find an alternative way to send the message
-
Often, they don’t know what to do
-
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. For example, 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 lets organizations 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 Think They Send Secure Emails, But They Don’t
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.
Conclusion: Working 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.
