[ad_1]
As previously announced in Support of DANE and DNSSEC in Office 365 Exchange Online, Exchange Online is deploying two industry standards for email security that address significant gaps in the securing of SMTP mail transactions today: DNS-based Authentication of Named Entities (DANE) for SMTP and Domain Name System Security Extensions (DNSSEC).
DANE uses TLS Authentication (TLSA) DNS records to securely signal TLS support to ensure that sending servers can successfully authenticate legitimate receiving email servers. This provides a secure connection between sending and receiving servers that is resistant to downgrade attacks (those that neutralize TLS encryption) and Man-in-the-Middle (MITM) attacks (a form of eavesdropping where the communication is monitored and/or modified by a nefarious actor).
DNSSEC works by digitally signing records for DNS lookups using public key cryptography. This ensures that the destination endpoint’s DNS records returned to the sending server have not been tampered with and are authentic.
When will those features roll out?
We will deploy support for DANE for SMTP and DNSSEC in two phases. The first phase, DANE and DNSSEC for outbound email (from Exchange Online to external destinations), is slowly being deployed between now and March 2022.
We expect the second phase, support for inbound email, to start by the end of 2022.
For both phases, we will also add TLS-RPT (RFC 8460) support for diagnostic reporting of TLS connectivity issues. This will help destination domain admins get fast insight into errors their senders may encounter, allowing them to fix them before they hear about those errors from Exchange Online customers.
What does this mean for Exchange Online customers?
As an Exchange Online customer, you don’t have to do anything to reap the benefits of this enhanced email security for outbound email. It’s built into the system and once enabled over the coming weeks it will be on by default for all Exchange Online customers.
Note that to take advantage of these security benefits, the domains receiving your email must be configured to support these standards. If you send email to a domain that is not configured for DANE and DNSSEC, your email will still be sent, but opportunistic TLS will be used instead. So, if you wish to secure your outbound mail using these standards, be sure to talk to the business partners to whom you send email and ask them to configure their DNS records for DANE and DNSSEC.
If you send email to a domain that has DANE and DNSSEC misconfigured, your mail flow to that domain may be blocked because Exchange Online will not trust a misconfigured email system. There are 2 scenarios where an email will be blocked and an NDR will get returned to an Exchange Online sender:
- The destination domain signaled DNSSEC support but one or more records were returned as inauthentic.
- All MX records for the destination domain have TLSA records and 1) none of the destination server’s certificates match what was expected per the TSLA record data or 2) TLS is not supported by the destination server.
If an email sent from Exchange Online is blocked, the resolution MUST BE implemented by an admin of the receiving domain. An Exchange Online admin cannot perform any remediation.
To help partners outside of Exchange Online properly configure their DANE and DNSSEC they can use the upcoming DANE and DNSSEC Validation test in the Microsoft Remote Connectivity Analyzer (to be released within a week) to diagnose and debug SMTP DANE errors. This is a great tool that contains a test module to help troubleshoot SMTP DANE issues when receiving mail from Exchange Online. It makes the same DNSSEC and DANE checks that Exchange Online performs when sending an email and it will show the same errors if a problem exists.
Known Issues
There are two known issues that will be addressed in future updates.
Currently, when a domain signals that it supports DNSSEC but fails DNSSEC checks, Exchange Online generates an NDR that with a generic DNS error and not a DNSSEC specific error:
4/5.4.312 DNS query failed
There are several DANE failure scenarios that fall into this error code, we need to decompose the scenarios into distinct error codes:
4/5.7.323 TLSA-invalid: The domain failed DANE validation
What’s Next
Securing customer email is a top priority and adding support for DANE, DNSSEC, and TLS-RPT reports is a fantastic update that delivers enhanced security for email to your business partners and customers.
The next phase for DNSSEC and DANE is support for the emails being sent to Exchange Online. As mentioned above, we estimate this to be completed by the end of 2022.
To learn more about SMTP DANE, see How SMTP DNS-based Authentication of Named Entities (DANE) works to secure email communications.
Source link
