Bit of "fun" with O365 email for us this week...
Background: Our main email domain's MX records are on-prem servers that do a bunch of things, and email for our O365 domain relays through them. These on-prem MX servers have been dual-stack (ipv4 and ipv6) for many years now.
Not sure exactly when MS made various changes, but our example-com.mail.protection.outlook.com records have both ipv4 (A) and ipv6 (AAAA) addresses.
And they enforce that email they receive has to be via a "trusted connector" for your domain, pass SPF, or pass DKIM.
> 450 4.7.26 Service does not accept messages sent over IPv6 [dead::beef::1] unless they pass either SPF or DKIM validation (message not signed)
But O365 doesn't yet support adding ipv6 IPs/ranges to the trusted/connector list.
So, suddenly email sent to us without DKIM signatures was getting stuck in the MX server queues.
Our temporary workaround is we added egress firewall rules on the MX servers themselves blocking SMTP to 2a01:111:f400::/48 and 2a01:111:f403::/48 (the published ranges for their MX servers). Not ideal, but at least mail is flowing again.