Announcing Public Preview of Inbound SMTP DANE with DNSSEC for Exchange Online

thats great news! I don't see any subscription limitation mentioned anymore. Is E5 still mandatory for Dane to work ?

I think the documentation assumes that the example-com.mail.protection.outlook.com

MX has a priority of 0, and that the new MX will initially be added with a lower priority. You then recommend testing that mail is capable of flowing to both endpoints before making the new endpoint the default. It is possible that the old MX has a value greater than 20, and in that scenario the user is making the new endpoints primary earlier than expected. 

The documentation also assumes that people have not configured a "backup" MX record. It might be enough to say in the documentation "if you have more than one MX record contact your administrator for guidance", rather than trying to account for every possible complication of MX records.

At several points you mention the need to set the MTA-STS policy to "test". You should also mention the need to update the _mta-sts TXT record every time the policy is updated. If the "id" in the TXT record is not updated Sending MTAs might not check the policy at all until the max_age has expired.

Succes!

johnjonestag Deployed DANE on at least one domain. Internet.nl does show a phase-out cipher in use, so that prevents the 100% (I assume, as I currently am not IPV6 enabled which also prevents 100%, submitted a support ticket for that). 

The_Exchange_Team The Learn article mentions several times setting MTA-STS mode from "enforce" to "Test" . This however has to be "testing" per RFC.

Satyajit321 I read that differently, I assumed this is the ability to set per domain whether outbound DANE is mandatory; meaning that if outbound DANE is set to mandatory for example contoso.com and the receiving domain is not DANE capable (permanent or temporary) you tenant wil *not* send any mails to that domain.

Currently DANE will be used, but will fall back if it would fail. Similar to Opportunistic TLS and Mandatory TLS.

Thanks michaelkennedy it worked.

I noticed that my WARP was connected and the command kept failing erroring out with..

So make sure your device doesn't have any WARP connected at the time of running the command

johnjonestag 

- Regarding a sample domain to test, we don't provide sample domains for our features. You'll have to set up a cheap test domain with a DNS Provider, which can be purchased for a couple dollars and last a year.

- The RCA shows the correct output for broadcom.com so maybe we need to improve the interpretability. It shows DNSSEC passing for broadcom.com and DANE not succeeding (emphasis on not succeeding, I did not say DANE failed) because there is no TLSA record for broadcom.com. The TLSA record is required for SMTP DANE validation to succeed. If the TLSA is not present, then we say the SMTP DANE validation didn't succeed and show the yellow warnings you are seeing.  

- It's healthy as we've been testing with it for several months. Feel free to use dig to review SOA/NS configuration or DNSViz for the DNSSEC info. Can I ask why you are concerned about this?

DMStork thanks 🙂 I'm pushing through a doc update ASAP. And your explanation regarding us using Outbound SMTP DANE with DNSSEC in an opportunistic manner is spot on. I will make this clearer in our public documentation.

Satyajit321 no typo's and DMStork explained it well. We are using SMTP DANE with DNSSEC opportunistically on the outbound path because most destinations don't support SMTP DANE (yet!). Outbound Mandatory SMTP DANE will allow Exchange Online customers to make passing SMTP DANE with DNSSEC validations mandatory for the email to successfully send. So, if the SMTP DANE or DNSSEC validation fails, we will not try to fallback to a secondary, unsecured MX record for that same domain, which does happen with current behavior. I'll clean up the documentation so it's clearer. 

Richdc165 Do you have MTA-STS on your M365 domain configured? Then see my notes in a previous post. M365 DANE requires an MX record change and if you have MTA-STS, you need to take careful steps in order to retain a valid MTA-STS policy published and pushed.

DMStork so I got duped and didn't pick up on the fact the record update said 'test' in the instructions and just fixed that this morning to 'testing'. It's very possible that was part of the issue and need to wait for everyone to see in DNS there is an updated policy file. Feel like we're still missing a lot of emails but yeah...I thought about that one and may just have to wait it out

Richdc165 Don't forget to update the id in your _mta-sts TXT record, otherwise GMail will use the cached policy file with potentially the incorrect values. If the TTL of that record is high, you might want to (temporarily) lower it.

As for the mail sent by Google: All mails eventually dropped in again in my case, basically treating the issue as if you SMTP server was down/unavailable. So, most mails will be delayed unless the sending server has specific retry/fail settings.

Richdc165 More import is to increase the id value of your _mta-sts TXT record, not just the TTL. When the id changes, the sending server is forced to update the policy file live and not wait on the max_age set inside the policy file. That max_age is often several days (604800 seconds is one week)
So, the id triggers an refresh update of the policy file, earlier than the set max_age. However the id change is only seen when the DNS TTL has expired: so two stacked intervals you have to take into account.