Microsoft announced significant security enhancements to our Exchange Online, Outlook.com, and Hotmail email offerings in February - MTA-STS and DANE. As a former developer on Microsoft's consumer email product, here's why that matters.
When email was originally invented, all emails flowed unencrypted over the Internet through a protocol called the Simple Mail Transfer Protocol (SMTP). Attackers able to listen to Internet traffic between our email server and our recipient's email server would be able to read our emails, just like reading what we might have written on a postcard. As disclosed by various whistleblowers over the last several decades, the intelligence community has such a capability and regularly uses it. This means that any emails we send could be read by our government, the government of the country hosting our email provider, or, in the worst case, someone else in the same coffee shop.
In response to this problem, the STARTTLS command was introduced to SMTP in 2002 to "provide private, authenticated communication over the Internet" in order to give email providers "the ability to protect some or all of their communications from eavesdroppers and attackers." Instead of a postcard, we could use envelopes to protect the contents of our message. However, to preserve backwards compatibility, email providers could choose whether they required incoming emails to be sent over a secure connection (enforced TLS), simply supported a secure connection if the sender wanted to use one (opportunistic TLS), or didn't support secure connections at all. Very few chose to require secure connections. In fact, in 2016, Gmail started notifying users if they were sending email to a email server that still didn't support secure connections to attempt to improve adoption of STARTTLS.
Even worse, the protection that we get from STARTTLS isn't the same as the protection we have when visiting web sites where our web browsers can tell the difference between my bank's web site and a web site pretending to be my bank. The SMTP protocol is vulnerable to tampering that can redirect connections to an attacker's server. In fact, senders have no way to confirm that destination server is the intended server. Our message is protected by an envelope, but we hand it to whoever claims to be the mail carrier.
As a result of these flaws, an attacker sitting between the two email providers could simply pretend to be the recipient email provider and tell the sender either "I don't support secure connections. Send the email without a secure connection" or "I am the recipient's email provider". This is bad! We still can't trust that our emails remain private; an attacker can open our envelope and read the letter and neither us nor our email provider can stop them.
This leads us to these new announcements, which are designed to fix this problem.
The SMTP MTA Strict Transport Security (MTA-STS) standard was developed to ensure that secure connections are always used by SMTP, and to provide a way for senders to refuse to deliver messages to servers they don't trust. The email provider indicates to senders that they support the new standard with a DNS record and a HTTPS web page. Email providers can look up this information before they start to send the email to your email provider and vice-versa rather than after. These protocols secure the web sites we browse every day, so they should be secure and easy for email providers to adopt. Now, we're asking the postal service who our mail carrier is and making sure we only give him or her our envelope. Gmail was the first to adopt this protocol in April 2019.
Although MTA-STS offers a much-needed upgrade to current protections, the second protocol, DNS-based Authentication of Named Entities (DANE) for SMTP, is the current gold standard for securing email communication. A really advanced attacker could still hijack the DNS lookup that's used in MTA-STS. Actually, such an attacker could do that for the web sites we visit, too. Recognizing this weakness, the Internet community has been working on a more secure version of DNS (called DNSSEC) that ensures that DNS records aren't tampered with and are authentic. When using DANE, an email sender would look up the recipient's email provider's DNS records and verify that they are authentic using DNSSEC, start a secure connection to the recipient, verify the recipient's provided information matches what would be expected based on the DNS record lookup, and only then send the message. Our attacker can no longer impersonate the postal service; we proveably know we're talking to the real postal service and that they have not lied about who our mail carrier is, we've checked the mail carrier's identification before trusting them with our letter, and we know the letter won't be opened before it gets to the recipient.
These protocols are a huge step forward in ensuring that our email communication is read only by the intended recipients, and I'm excited to see them roll out in both Microsoft's and others' products to secure the communications of billions of people.
Postscript
As a security expert, I would be remiss not to point out that our email is still not protected from all attackers, even with these new protections. Although MTA-STS and DANE ensure that email gets from you to your recipient without being modified or snooped on, emails are generally readable by both your email provider and your recipient's email provider. Google famously had a long-standing practice of scanning Gmail users' inboxes to deliver more effective advertisements (which they ended in 2017). Your email can also potentially be accessed by the employees of the email providers or governments with a legal order. In the United States, the Electronic Communications Protection Act actually allows law enforcement to obtain emails older than 180 days from email providers without a warrant! For your most sensitive communications, if you have to ensure that only one person can read your communication, an encrypted messaging app like Signal, encrypted messages within Skype, or encrypted email in Outlook or Outlook.com might be more suitable.