The Working and Application of Standards for Secure Email Transport

Email remains the most widely used digital communication channel in organizations, but it was never designed as a secure medium. The risks of unsecured email are significant: interception, human error, unauthorized access, and phishing are among the leading causes of data breaches and incidents. That is why regulations such as ISO 27001 require organizations to structurally and demonstrably secure email traffic.

Secure Email – ensuring that email is always encrypted in transit and delivered to the correct server – forms the minimum baseline measure. This is achieved through standards such as SPF, DKIM, DMARC, STARTTLS, DANE, MTA-STS, and DNSSEC. The recipient must configure their infrastructure to allow others to send email securely (e.g., by supporting DNSSEC, DANE, and MTA-STS). The sender, however, is legally responsible for safe delivery: each message must be checked to confirm that the receiving domain supports these standards. If no secure route exists, the message must not be sent or must instead be delivered through a secure portal.

This article makes clear that:

• Only the combined and correct use of modern email standards offers true protection against eavesdropping and misuse.

• Many organizations remain non-compliant because these standards are not, or only partially, implemented.

• The responsibility for safe delivery lies primarily with the sender, but the receiver’s mail server must support the correct standards.

• If secure delivery via standards is not possible, a secure portal is the only practical and legally acceptable alternative.

Organizations that follow this approach demonstrably meet the requirements of ISO 27001 and minimize legal and reputational risks.

Conclusion:

Truly secure emailing requires continuous attention, technical investment, and clear processes. Only by both sender and receiver taking responsibility and maximizing the use of the relevant standards can data breaches, incidents, and non-compliance be prevented. Organizations that fail to implement structured secure emailing expose themselves to unnecessary risks and fail to comply with current legal requirements.

Email Security: More Than Technology, a Legal Obligation

Email is the most widely used digital communication channel, yet it was never designed to be secure. Technically, an email still resembles a digital postcard—anyone intercepting it can read it. Over time, several standards have been introduced to make email more secure. These standards are essential for maintaining confidentiality and integrity, but only if correctly applied.

For organizations subject to frameworks such as ISO 27001, correct implementation of these standards is mandatory, not optional. Nevertheless, knowledge and implementation remain insufficient, creating unnecessary risks and leaving many organizations non-compliant.

This article describes:

• The specific risks of using email.

• What ISO 27001 requires for email security.

• Which standards are mandatory (SPF, DKIM, DMARC, STARTTLS, DANE) and why.

• How DANE, MTA-STS, and DNSSEC technically function.

• Why these standards are essential for both incoming and outgoing email.

• The difference between secure, confidential, and registered emailing.

• How organizations can practically comply with baseline security requirements

Key Risks of Email Usage

ISO 27001 requires organizations to conduct a risk assessment and implement appropriate controls accordingly. Because email is the most widely used communication channel, and because sensitive data is frequently shared via email, it must be included in any risk assessment. A proper analysis reveals that email consistently ranks as one of the highest risk sources in any organization.

The four main risks are:

• Human error – such as misaddressed emails, wrong attachments, or failing to enable encryption.

• Interception during transport – emails sent without proper standards may be transmitted in clear text.

• Unauthorized access to mailboxes – for example, through stolen passwords or lack of multi-factor authentication.

• Phishing, malware, ransomware – email remains the most common entry point for cyberattacks.

What Does ISO 27001 Require for Email?

ISO/IEC 27001:2022 establishes clear requirements for protecting information exchanged between organizations, business partners, and individuals. Two clauses are especially relevant to email security:

Clause 5.14 – Information transfer
Organizations must ensure that information transfer policies and procedures protect information from unauthorized access, misuse, or compromise during transmission. In practice, this means that email—being one of the most common transfer mechanisms—must be secured against interception, alteration, and misrouting. Policies should explicitly define when and how email may be used for transmitting sensitive information, and require the use of secure channels or fallback mechanisms (e.g., secure portals) if standards cannot guarantee safe delivery.

Clause 8.24 – Use of cryptography
This clause requires that cryptographic controls be applied where necessary to protect the confidentiality, integrity, and authenticity of information. For email, this translates directly into the use of transport encryption and server authentication mechanisms. By enforcing cryptographic safeguards, organizations can ensure that sensitive data cannot be read or altered in transit, and that it reaches the legitimate receiving server.

Together, these two requirements mean that email cannot be treated as a “best-effort” communication channel. Instead, organizations must implement strong technical and organizational measures to ensure that:

• Email is encrypted during transfer (to comply with 8.24).

• Delivery is only made to authenticated servers, preventing man-in-the-middle attacks (5.14 + 8.24).

• Sensitive data is never sent via unsecured routes; if secure delivery is not possible, alternative secure channels must be used (5.14).

In short, ISO 27001 requires organizations to treat email as a controlled, security-critical process, with enforced safeguards and cryptography as a standard—not an option.

Mandatory Email Standards and Why They Matter

The European Commission have designated several mandatory standards for secure email:

• SPF (Sender Policy Framework) – verifies that the sending mail server is authorized.

• DKIM (DomainKeys Identified Mail) – adds a digital signature to verify that the email has not been altered in transit.

• DMARC (Domain-based Message Authentication, Reporting & Conformance) – defines handling of emails failing SPF/DKIM and provides reporting.

• STARTTLS & DANE – STARTTLS enables encryption between mail servers; DANE ensures authenticity of those encrypted connections.

Together, SPF/DKIM/DMARC address sender authentication and phishing risks, while STARTTLS/DANE are essential for confidentiality and integrity during transport.

In this article, we focus on the risk of “interception during transport”, often referred to as “secure email.” We will explain the role of DANE and STARTTLS in this context, how they work, and what alternatives exist.

Secure, Confidential, and Registered Email: What’s the Difference?

Secure email – sending emails encrypted with assurance about the receiving server

This article primarily concerns secure emailing: transmitting email messages over a guaranteed encrypted and authenticated connection from the sender to the recipient’s mail server. In other words: you guarantee that the message is unreadable in transit and that it is actually delivered to the correct mail server. This is the baseline security required under ISO 27001.

Confidential email – sending emails encrypted with assurance about the receiving person

Confidential emailing goes one step further. While secure emailing focuses on safe and authentic transport from server to server, confidential emailing ensures that only the intended recipient can access the message. The goal is to prevent “third parties” from reading the information — for example, a hacker who has stolen the password, a family member with mailbox access, a mail server administrator, or a commercial email provider with potential access to user mailboxes.

Confidential emailing guarantees, through additional authentication (e.g., via an SMS code), that only the recipient themself can read the contents. It is therefore necessary for sensitive communications where absolute certainty about the recipient is crucial, such as medical data, legal documents, or financial information.

Example:

A doctor wants to send medical records to a patient. Because the patient uses a public email address (e.g., @gmail.com), where it cannot be guaranteed who has access, the doctor chooses confidential email via a secure portal with SMS-based authentication. The patient first receives a notification email with a secure link to the portal. They then receive a unique SMS code on their mobile phone, which must be entered as an extra step. Only after entering this code can the patient safely open, read, reply to, download, or forward the message. In this way, the confidentiality of the medical information is fully safeguarded.

Registered email – sending emails encrypted with legal proof

Registered emailing goes beyond confidential emailing. In addition to ensuring that only the intended recipient can access the message, it also provides the sender with legal evidence about the exact time the message was sent, the moment it was received, and — depending on the solution — proof that it was opened and read by the recipient.

Registered emailing is comparable to registered postal mail and is primarily used for communication where legal certainty and accountability are essential, such as official decisions, legal correspondence, contracts, and financial transactions.

Example:

A lawyer wants to send an important legal letter to a client. Because it is essential to prove later, in court if necessary, that the message was sent, received, and actually read, the lawyer chooses registered emailing with legal delivery evidence. The client receives a notification email, authenticates through an extra security step, and then opens the message in a secure portal. A week later, the lawyer requests a digital certificate showing precisely when the message was sent, when it was opened, and when attachments were downloaded. This evidence can serve as indisputable legal documentation in case of disputes.

This article: focus on secure email as the mandatory baseline

This article addresses secure emailing as the minimum baseline measure, one that is mandatory for organizations that must comply with ISO 27001 — but, in fact, relevant for any organization that takes information security seriously. Confidential and registered emailing are applicable in more specific scenarios where even higher levels of privacy, authentication, and legal assurance are required.

In Depth: How Email, STARTTLS, DANE, MTA-STS and DNSSEC Work

How Does Email Work Under the Hood?

Before diving into the security standards, it’s important to briefly explain how email delivery actually works. This provides the necessary context for why these email security standards exist and why they matter.

Sending Email: How the SMTP Process Works Behind the Scenes

When you click “Send” in your email program (such as Outlook, Gmail, or Apple Mail), it may look as though your message is delivered instantly to the recipient. In reality, the email goes through a number of invisible steps, where different servers and internet standards work together to deliver the message.

Here is what happens step by step:

1. Your email program sends the message to your own mail server (SMTP server):
   Your email client (like Outlook or Gmail in the browser) connects to your organization’s or provider’s mail server. This server is often called the outgoing mail server and communicates via the SMTP protocol (Simple Mail Transfer Protocol).

2. The sending mail server determines where the message should go:
   The mail server looks at the recipient’s email address (for example, john@organization.com). It needs to find out which mail server is responsible for receiving emails for the domain organization.com.

3. DNS lookup: finding the correct receiving mail server via the MX record:
   To find this information, the sending server queries the Domain Name System (DNS) — the internet’s “address book.” Specifically, it looks for the MX record (Mail Exchanger record) of the recipient’s domain.

   - The MX record specifies which server (usually identified by a hostname like mail.organization.com) should receive the email and provides the corresponding IP address.

   - Sometimes multiple MX records exist, with priorities assigned, so the sending server knows which destination to try first.

4. Establishing a connection with the receiving mail server:
   Equipped with the address of the correct receiving server, the sending server attempts to connect over the internet to that mail server.

5. The SMTP handshake and message transfer:
   Once the connection is established, a digital handshake takes place:

   - The servers introduce themselves.

   - They exchange technical information about their capabilities (for example, whether they support encryption via STARTTLS).

   - They agree on how the message will be transmitted and processed.

   - All of this happens using the SMTP protocol, which is the global standard for transferring email between servers.

6. Message delivery and confirmation:
   Once everything is agreed, the sending server actually transfers the email message to the receiving server. The receiving server then confirms acceptance (unless an error occurs). Finally, the receiving server ensures that the message is placed in the inbox of the correct recipient.

The Role of DNS and MX Records in Email

DNS functions like the phone book of the internet: it translates domain names (such as organization.com) into technical addresses (such as mail servers and IP addresses).

The MX record is specifically designed for email. It defines which mail server(s) are authorized to receive messages on behalf of a domain. Without a properly configured MX record, no mail server in the world will know where to deliver email for that domain.

Important: If the MX record is incorrect or missing, email cannot be delivered to that domain at all.

The Vulnerability of Standard Email

By default, SMTP is not secure: anyone “in between” the sending and receiving servers can potentially eavesdrop, alter data, or even impersonate the receiving server. In other words, you assume you are really communicating with the correct server, but technically this is not guaranteed.

STARTTLS: A Necessary but Weak Extension for Encryption

STARTTLS is an extension to SMTP that allows mail servers to communicate using TLS encryption. However, STARTTLS is opportunistic: encryption is only applied if both sides support it and use compatible versions.

As the National Cyber Security Center (NCSC) notes, “an active attacker can easily strip away the use of STARTTLS” through a downgrade attack, causing email to be transmitted in plaintext despite both servers supporting encryption.

Enforce TLS: Stronger, But Still Flawed

Most mail servers — including Microsoft 365, Exchange, and Google — allow administrators to configure Enforce TLS. This means that email will only be sent if the receiving party supports TLS.

• If the receiving server does not accept TLS, the message will not be delivered.

• The sender receives a bounce (also called a Delivery Status Notification, DSN) stating that delivery failed.

These situations often cause operational issues: when messages cannot be delivered, users resort to alternative communication channels — usually even less secure ones.

For organizations that do enforce TLS, another fundamental problem remains: while TLS encrypts the connection between servers, it does not verify the authenticity of the receiving mail server itself.

This opens the door to man-in-the-middle attacks: a malicious party can impersonate the recipient’s mail server, intercepting the email even though it was transmitted in encrypted form. The message may end up on a server controlled by, for example, a hostile government or hacker — without the sender or recipient realizing it.

DANE: The Only Truly Secure and Accepted Standard for Email Transport

DANE (DNS-based Authentication of Named Entities) is the only standard that fully guarantees both the authenticity and the encryption of email transport. DANE uses a special record in the Domain Name System (DNS), called a TLSA record, which publishes which TLS certificate belongs to the mail server of a given domain.

The Role of DNSSEC

To ensure that this information cannot be tampered with in transit by malicious actors, DANE is always combined with DNSSEC (Domain Name System Security Extensions). DNSSEC adds digital signatures to DNS records, allowing the sending mail server to verify that the received DNS information — such as the TLSA record — is authentic and unaltered. Without DNSSEC, an attacker could attempt to inject false DNS information and perform a man-in-the-middle attack.

What Makes DANE Unique and Secure?

• Authenticity of the receiving mail server: DANE ensures you are connecting to the legitimate server of the domain, not to an attacker.

• Certificate binding: DANE enforces the use of the correct, pre-published TLS certificate and requires TLS to be used, guaranteeing encryption.

• Protection against interception: By combining authenticity and encryption, DANE effectively prevents man-in-the-middle attacks and interception of email in transit.

DANE is strongly recommended by the European Commission as a standard for all of Europe. Unfortunately, major providers such as Google still do not support DANE for inbound email, limiting universal adoption in practice.

MTA-STS: An Alternative Where DANE Is Not Available

MTA-STS (Mail Transfer Agent Strict Transport Security) is a security standard widely adopted by Google as an alternative to DANE, particularly because Google has not yet implemented DANE for inbound email. MTA-STS allows organizations to explicitly state that their mail servers always require an encrypted TLS connection, and to specify which servers and certificates must be used.

How does MTA-STS work?

• Organizations publish a special text file, the mta-sts.txt, at a well-known location on their domain (e.g., https://mta-sts.organization.com/.well-known/mta-sts.txt).

• A dedicated DNS record indicates that the domain supports MTA-STS.

• Sending mail servers can fetch and read this policy file, which specifies which servers may receive email for the domain and what type of secure connection is required.

• Only if these requirements are met will the email be delivered.

Advantages and limitations:

• MTA-STS is easier to implement than DANE because it does not rely on DNSSEC or TLSA records.

• However, its security is weaker: since DNSSEC is absent, an active attacker could block, intercept, or manipulate the policy before the sending server retrieves it.

• Despite this, MTA-STS provides significantly stronger protection than opportunistic STARTTLS, especially when communicating with major providers like Gmail and Google Workspace.

Best practice: Ideally, organizations should implement both DANE and MTA-STS, ensuring that the widest possible range of sending servers can enforce secure delivery.

DNSSEC with Certificate Validation: A Practical Fallback

When neither DANE nor MTA-STS is available on the receiving domain, it is still possible to strengthen authenticity by combining DNSSEC with certificate validation. This provides greater assurance than plain STARTTLS or Enforce-TLS, though it is not as secure as DANE.

How does this method work?

1. Secure DNS lookup using DNSSEC: The sending mail server retrieves the MX record (which specifies the receiving mail server) with DNSSEC protection, ensuring authenticity and integrity of the DNS data.

2. TLS certificate validation: Once the correct mail server address is established, the sending server initiates a STARTTLS connection. It then verifies that the TLS certificate offered by the receiving server is valid, matches the server address, and is not expired or revoked.

3. Delivery: Only if these checks succeed is the email delivered.

Advantages and limitations:

• Offers stronger protection than opportunistic STARTTLS or Enforce-TLS, since authenticity and encryption are both validated.

• Lacks the additional assurance of a TLSA record (as in DANE), meaning the binding between server and certificate is not as strong.

• Nevertheless, it is a practical and valuable safeguard where DANE or MTA-STS is not (yet) widely adopted.

In short: DNSSEC combined with certificate validation forms an important, pragmatic step toward more secure email transport. Even when advanced standards are not universally supported, this approach allows organizations to raise their security level and move closer to compliance with best practices and regulatory requirements.

How Do the Standards Work in Practice for Incoming and Outgoing Email?

In every form of communication — including email — there are always two main roles: the sender and the receiver. Both parties have their own responsibility when it comes to securely sending and receiving messages. Email standards are designed to support both roles, but their practical application and associated risks differ depending on the role.

Incoming Email: The Role of the Receiver in Secure Emailing

As a receiver, your goal is to make it as simple as possible for other organizations to email you securely. Your primary task is to provide a secure and verifiable infrastructure. Concretely, this means:

• Enable DNSSEC for your domain: This protects your domain’s DNS information so that others can be sure they are reaching the correct mail server.

• Publish a DANE/TLSA record for your mail servers: This allows sending parties to verify that they are communicating with your legitimate, authenticated mail server.

• Implement MTA-STS: Particularly important if you receive a lot of mail from providers such as Gmail/Google, which (still) do not support DANE.

• Check your STARTTLS configuration: Ensure your mail server always accepts encrypted connections and that your certificates are valid and up to date.

In practice, this means that as a receiver, you provide the technical “building blocks” for others to deliver securely. However, you cannot enforce that every sender actually validates and applies these standards. It is therefore essential to configure your domain in such a way that it is as easy as possible for senders to deliver to you in a compliant and secure manner.

Example:
A hospital implements DNSSEC and publishes a DANE/TLSA record. An insurance provider that wants to send sensitive patient information checks the MX and TLSA records via DNSSEC. Only if all checks succeed will the email be delivered securely to the hospital.

Outgoing Email: The Role of the Sender in Secure Emailing

For outgoing email, the responsibility lies entirely with the sender. The sender decides how — and whether — an email is sent securely. Legal and regulatory frameworks explicitly place the responsibility for the secure delivery of sensitive information on the sender: if something goes wrong in transit, the liability rests with the sender.

Steps for Secure Outgoing Email:

• Check if the receiving domain uses DNSSEC: Ensures you are connecting to the correct mail server.

• Check for a DANE/TLSA record: Confirms the server identifies itself with the correct certificate.

• Check for MTA-STS: If DANE is not available, verify whether the domain supports MTA-STS — particularly important for communication with providers like Google/Gmail.

• Combine DNSSEC with certificate validation: If neither DANE nor MTA-STS is present, raise the level of assurance by validating the TLS certificate in combination with DNSSEC.

• Send only if all checks succeed: If the receiver does not meet the minimum requirements, it is up to the sender to either bounce the message or deliver it via a secure portal.

In Summary:

• The receiver provides a secure channel, but it is the sender who decides whether the email is actually sent securely and in line with the standards.

• Therefore, the real challenge — and the legal liability — lies with the sender.

Bottom Line:

• The receiver enables secure emailing by properly configuring infrastructure and publishing the necessary standards.

• The sender is responsible for applying those standards in practice and ensuring that sensitive information is only delivered through secure routes.

In this way, the standards support and strengthen both roles — but they also make clear where the greatest risks and responsibilities lie.

What If the Receiver Does Not Comply with the Standards?

The reality is that many receiving mail servers do not meet the required standards such as DANE or MTA-STS. Less than 30% of Dutch domains support DANE, global adoption of MTA-STS is below 1%, and major providers like Google still do not support DANE for inbound email. Around 40% of organizations in the Netherlands may have DNSSEC, but not DANE or MTA-STS.

This means that even if a sending organization uses a solution that supports all three standards for outgoing email, 20–30% of emails will still face recipients that cannot receive mail securely enough. This creates a dilemma for organizations that want to remain compliant with ISO 27001 while also ensuring smooth email communication.

The Sender’s Options When Standards Are Missing:

1. Deliver the email anyway, despite the risk
   The sender may choose to send the message even when no secure delivery route exists. However, this is not compliant with ISO 27001 and carries significant legal and privacy risks. In highly regulated sectors such as healthcare, government, and financial services, transmitting sensitive information over an insecure route is completely unacceptable.

2. Refuse to send the email (bounce)
   In this case, the mail server refuses to deliver the message, and the sender receives a bounce notification (Delivery Status Notification, DSN) stating that secure delivery was not possible. Although technically and legally correct, this is often impractical: employees must then find another way to get the message through, leading to unsafe alternatives like personal email accounts, USB sticks, or even WhatsApp. This frustrates users and increases the risk of data breaches.

3. Deliver the email via a secure portal
   Here, the email is not sent directly to the recipient’s inbox but placed in a secure portal. The recipient receives a notification — usually by email — with a link, and after strong authentication can safely read, reply to, download, or forward the message.

Why Falling Back to a Secure Mail Portal Is the Only Realistic Alternative

• User experience: The workflow remains simple; the sender notices no difference, and the recipient receives clear instructions.

• Compliance: The organization fully meets legal requirements: sensitive data is delivered only through a controlled and secure channel.

• Audit & logging: It is always traceable who accessed which message, when, and how — essential for audits and incident investigations.

• Risk management: By avoiding insecure email routes, the risk of interception is minimized.

• Adoption: Secure mail portals are already standard in government, healthcare, and finance, so recipients are familiar with this method.

• Reduced burden on end-users: End-users do not need to interpret technical error messages or look for unsafe alternatives themselves.

Example:
A hospital wants to email sensitive patient data to a patient. The patient’s mail server does not support DANE, MTA-STS, or DNSSEC. Instead of taking risks or bouncing the message, the hospital’s system automatically routes it through a secure portal. The patient receives a notification with a secure link and can then safely view or download the message. This ensures compliance with regulations while minimizing the risk of a data breach.

Practical Tips for Implementing Secure Email

A properly configured email environment must address both incoming and outgoing flows. Below are the key steps and considerations for each role:

For Incoming Email (the receiver’s role)

To allow others to send you secure email, it is essential to secure your infrastructure as fully as possible. Ideally, implement all relevant standards:

• Enable DNSSEC: Protects your domain’s DNS information from manipulation; the essential foundation for further security.

• Publish a DANE/TLSA record: Allows sending parties to verify they are talking to your legitimate mail server.

• Implement MTA-STS: Particularly important if you communicate often with domains that do not yet support DANE (e.g., Gmail/Google).

• Check your STARTTLS configuration and certificates: Always accept encrypted connections and ensure certificates are valid.

If full implementation isn’t yet possible:

• Do what is feasible — for example, enable DNSSEC and/or add MTA-STS if DANE is not supported by your current provider.

• Note: Some hosting or email providers do not yet support DANE, DNSSEC, or MTA-STS. In that case, investigate whether switching to a provider that does is feasible. This not only increases your own digital resilience but also helps other organizations send to you securely and compliantly.

For Outgoing Email (the sender’s role)

As the sender of sensitive information, you carry the full responsibility to ensure that the email is delivered only through a secure route. Even if the recipient is not fully compliant, you must do everything possible to stay compliant and protect data.

• Use a mail gateway or solution that supports the standards: Choose one that fully supports DANE, MTA-STS, and DNSSEC, and checks each message against the receiving domain’s capabilities. This ensures you always pick the most secure route available.

• Deliver securely or fall back to a secure portal: Configure your system so that messages are only delivered over secure connections (DANE, MTA-STS, or DNSSEC with certificate validation). If none are available, automatically deliver via a secure portal.

• Implement logging and monitoring: Record and monitor all delivery attempts and outcomes to demonstrate compliance and provide evidence during incidents or audits.

• Automate fallback mechanisms: Ensure your mail solution automatically switches to a secure portal when DANE, MTA-STS, or DNSSEC are missing. This keeps the process simple for users and prevents unsafe improvisation.

If you cannot send an email securely enough:
Take responsibility: never deliver sensitive information over an insecure route, unless there is a specific agreement with the recipient that provides sufficient safeguards. In such cases, whitelist the recipient only after careful assessment. By designing your processes to always apply maximum security — and falling back to a secure portal as the last resort — your organization ensures ongoing compliance and guarantees confidentiality, regardless of the recipient’s limitations.

Conclusion: Secure Emailing Requires Proactive Responsibility from Both Sender and Receiver

Modern standards for email security — such as DANE, MTA-STS, DNSSEC, and STARTTLS — are not theoretical luxuries. They are a legal and practical necessity for every organization that exchanges confidential information by email. The goal is clear: email must be protected in transit against eavesdropping, tampering, and misdelivery, and must only be delivered to the intended server of the recipient.

In addition, the General Data Protection Regulation (GDPR) explicitly requires organizations to take appropriate technical and organizational measures to transmit personal data securely. This means that the sender of personal data is legally responsible if a data breach occurs during transmission due to insufficient security. Non-compliance can lead to significant fines from supervisory authorities. For this reason, secure delivery via standards such as DANE, MTA-STS, and DNSSEC is not only a practical safeguard but also a concrete legal obligation under privacy law.

The success of secure email transport depends on both roles working together:

• Receivers must optimally configure their infrastructure and implement all relevant standards so others can email them securely. If full implementation is not yet possible, they should at least adopt as many safeguards as possible and consider switching to a provider that fully supports these standards.

• Senders carry the ultimate responsibility. For each message, they must verify whether the recipient’s domain is securely reachable and ensure that sensitive information is only delivered via a controlled, secure route. If the necessary standards are not supported by the recipient, delivery through a secure portal is not optional but required.

In practice, this means:

• Only the combination of standards such as DANE, MTA-STS, DNSSEC, and STARTTLS provides optimal protection and compliance.

• Where full adoption is not yet possible, organizations must at least take all feasible measures, always choose the safest available route, and — where necessary — fall back on additional solutions such as a secure portal.

• By following this approach, organizations not only avoid technical vulnerabilities but also demonstrably comply with the requirements of ISO 27001 and GDPR.

In short:
Truly secure emailing requires continuous attention, ownership, and collaboration from both sender and receiver. By investing in the right standards and processes, you not only safeguard the privacy of your stakeholders but also protect the reputation and continuity of your own organization. Don’t wait for enforcement action or a damaging incident — take control of secure email transport today.