Is DANE Right for Your Inbound Email Security?

Introduction

Microsoft has announced that inbound DANE (DNS-Based Authentication of Named Entities) support for Microsoft 365 and Exchange Online will be generally available in October 2024. While this is an exciting development for email security, it's important to consider whether DANE is the right solution for your organisation, especially if you're a small or medium-sized enterprise (SME) currently relying on default opportunistic Transport Layer Security (TLS) to protect your emails in transit.

What is DANE?

DANE is a protocol that allows email servers to specify which SSL/TLS certificate should be used when other mail servers connect to them. It's designed to prevent man-in-the-middle attacks and ensure that email is encrypted in transit.

Why Should Businesses Consider DANE?

Most businesses today rely on opportunistic SMTP TLS for email security. Here's why DANE matters:

Better than the basics: Right now, your emails are probably using "opportunistic TLS" - it's like a handshake between email servers that says "Let's use encryption if we both can." It's better than nothing, but it has limitations.
Preventing downgrade attacks: With opportunistic TLS, a clever attacker could trick the email servers into falling back to an unencrypted connection. DANE prevents this by insisting on a secure connection.
Ensuring you're talking to the right server: DANE verifies that your emails are actually going to the intended recipient's server, not an imposter. It's like checking ID before handing over an important package.
Mandatory, not optional: Unlike opportunistic TLS, which is a "best effort" approach, DANE makes secure connections a requirement. This means consistently better protection for your email communications.
Reducing human error: DANE automates much of the security process, reducing the risk of configuration mistakes that could leave your emails vulnerable.

While DANE offers these improvements over basic email security, it's important to note that implementing it can be complex and resource-intensive, especially for smaller businesses. That's why it's crucial to weigh these advantages against the practical challenges of adoption.

The Challenges of DANE

While DANE offers robust security, it comes with some significant challenges:

Complexity: DANE requires DNSSEC (Domain Name System Security Extensions), which adds another layer of complexity to your DNS setup.
Risk: Misconfiguration of DNSSEC or DANE records can lead to email delivery issues, potentially causing significant disruption to your business.
Limited Support: As of now, Azure DNS doesn't support DNSSEC in general availability, which can be a roadblock for many Microsoft 365 users.

A Simpler Alternative: MTA-STS

For most SMEs without DNSSEC deployed, MTA-STS (Mail Transfer Agent Strict Transport Security) offers a more straightforward and less risky upgrade step from opportunistic SMTP TLS.

How MTA-STS Addresses DANE Benefits

While MTA-STS doesn't provide all the same features as DANE, it does address many of the same security concerns:

Improved Email Encryption: Like DANE, MTA-STS ensures that emails are encrypted in transit. It requires TLS for all connections, preventing downgrade attacks.
Server Authentication: MTA-STS verifies that the receiving server's certificate is valid, helping to prevent man-in-the-middle attacks.
Enforced Security: Similar to DANE, MTA-STS moves beyond opportunistic TLS by enforcing strict security policies for email transmission.
Automated Security: MTA-STS automates much of the email security process, reducing the risk of human error in configuration.
Phishing Protection: By ensuring emails are sent to the correct, authenticated servers, MTA-STS helps protect against certain types of phishing attacks.

The key difference is that MTA-STS achieves these benefits without the need for DNSSEC, making it easier to implement and maintain for many organisations, especially SMEs.

However, it's important to note that MTA-STS does not provide the same level of cryptographic assurance as DANE. Organisations with very high security requirements may still prefer DANE despite its added complexity.

Specific Benefits of MTA-STS

MTA-STS offers several advantages, especially for SMEs:

Easier Implementation: MTA-STS doesn't require DNSSEC, making it simpler to set up and maintain.
Lower Risk: Misconfiguration is less likely to cause email delivery failures, reducing the risk of business disruption.
Wider Support: MTA-STS is already supported by major email providers and can be implemented immediately.
Gradual Adoption: With its testing mode, MTA-STS allows for a phased approach, letting you verify your setup before full enforcement.

MTA-STS Drawbacks

While MTA-STS offers significant benefits, it's important to understand its limitations. MTA-STS mitigates most risks of inbound email interception or downgrade attacks up until the point your own DNS infrastructure is compromised. If an attacker gains control of your domain's DNS, they could potentially update the MTA-STS policy, validate a certificate to host it elsewhere, and update the TXT record ID to have mail servers download a malicious policy.

From a practical perspective, implementing MTA-STS requires hosting a policy text file using your preferred service, like GitHub Pages:

‍https://mta-sts.<domain name>/.well-known/mta-sts.txt

Given the benefits and manageable risks of MTA-STS, let's explore a practical approach to implementing enhanced email security for your organisation.

Implementing Email Security: A Step-by-Step Approach

Instead of jumping straight into complex solutions like DANE, we recommend a measured approach to enhancing your email security and consider if MTA-STS meets your needs as a significant security enhancement over default opportunistic TLS:

Enable TLS Reporting
1. Turn On TLS Reporting for the domain using VerifyDMARC, go to Domains, Show.
2. Over the following weeks, confirm some reports are coming into the VerifyDMARC Dashboard.
3. This step provides visibility without affecting email flow.
Confirm your domain's inbound mail provider supports MTA-STS and review their documentation.
Deploy MTA-STS in Testing Mode
1. When your organisation is ready, implement MTA-STS in testing mode.
2. This allows you to see how the policy would affect your email flow without enforcing it.
3. Check ‘TLS Mode’ in the VerifyDMARC Dashboard reflects ‘MTA-STS Testing’. This means you have a TXT record and your policy text file is accessible and in the expected format.
Review MTA-STS Reports
1. Use the statistics in VerifyDMARC to identify any potential issues or failures. Review this information over a few weeks.
2. This step ensures your policy is correct and won't disrupt inbound email traffic.
3. If you make any MTA-STS policy file changes you MUST change the id in the _mta-sts TXT record.
Update to MTA-STS Enforce Mode:
1. Once you're confident in your policy, update it to enforce mode.
2. Change the id in the domain's _mta-sts TXT record.
3. This step actively secures your email in transit.
4. Check the ‘TLS Mode’ in the VerifyDMARC Dashboard reflects ‘MTA-STS Enforce’
5. Review reports in VerifyDMARC Dashboard regularly and investigate any unexpected failures.

Next Steps

Start with TLS Reporting: Enable TLS reporting for your domain and set up monitoring in VerifyDMARC.
Plan for MTA-STS: Begin preparing for MTA-STS implementation, starting with the testing mode.
Stay Informed: Keep an eye on DANE developments, but don't rush to implement it unless you have specific security requirements that MTA-STS can't meet.
Seek Expert Guidance: If you're unsure about which solution is right for your organisation, consider consulting with email security experts.

Remember, email security is not one-size-fits-all. The best solution for your organisation depends on your specific needs, resources, and risk tolerance. By following this step-by-step approach with VerifyDMARC, you can enhance your email security posture with confidence and minimal risk.