For many organisations, email security still starts and ends with spam filtering, phishing awareness and a few DNS records. That is no longer enough. Modern email security is now a layered model: you need to verify who is allowed to send on behalf of your domain, prove message integrity, and strengthen the DNS and transport layers that email relies on. That is why standards such as SPF, DKIM, DMARC, ARC, DNSSEC and SMTP DANE are increasingly part of the same conversation rather than separate topics.
Microsoft’s move to provision new Exchange Online accepted domains under *.mx.microsoft from July 2026 is a good example of that shift. On paper, it looks like a DNS change. In practice, it reflects something bigger: Microsoft is building more of its email architecture around DNSSEC-enabled infrastructure so that stronger transport protections such as inbound SMTP DANE become practical at scale.
The first layer of a sound email security strategy is still sender authentication. SPF helps receiving systems validate whether a server is authorised to send mail for your domain. DKIM adds a cryptographic signature so recipients can verify that a message was signed by an authorised domain and was not altered in transit. DMARC then brings SPF and DKIM together by checking alignment with the visible From: domain and telling receiving systems what to do when those checks fail. Microsoft’s own guidance is clear on this point: SPF alone is not enough, and the strongest baseline comes from using SPF, DKIM and DMARC together.
Even with SPF, DKIM and DMARC in place, email still depends on DNS. Your SPF record lives in DNS. Your DKIM public keys live in DNS. Your MX record tells the world where to deliver mail. If the DNS layer can be spoofed or tampered with, the trust model underneath email authentication becomes weaker. That is exactly what DNSSEC addresses: it adds cryptographic validation to DNS so resolvers can verify that the records they receive are authentic and unchanged.
This is also where SMTP DANE becomes relevant. Microsoft describes SMTP DANE with DNSSEC as a way to make mail transport resistant to downgrade attacks and adversary-in-the-middle attacks. In practical terms, it gives sending servers a stronger way to validate that they are connecting to the legitimate receiving mail server over TLS, instead of relying on a more opportunistic trust model.
That does not mean every organisation needs to implement every standard at once. It does mean that “email security” can no longer be reduced to sender authentication alone. The transport path and the DNS trust chain are now part of the same security architecture.
Microsoft has explicitly said that new accepted domains in Exchange Online will be provisioned under new subdomains beneath mx.microsoft, not under mail.protection.outlook.com. More importantly, Microsoft also states that while mail.protection.outlook.com will remain operational, it will not receive new DNS enhancements such as SMTP DANE with DNSSEC.
That distinction matters. Existing domains will not suddenly stop working because they still point to the legacy naming model. But if the long-term security improvements are being built into the mx.microsoft path, then staying indefinitely on the legacy path means staying outside that roadmap. Microsoft’s own documentation for inbound SMTP DANE with DNSSEC includes a supported migration path for existing domains: enable DNSSEC for the verified domain, add the new mx.microsoft target, move mail flow over, remove the legacy MX, and then enable inbound SMTP DANE if required.
That is why we do not see MX migration for existing domains as a bad idea at all. It is not an emergency move, and it is not the first thing every organisation should do tomorrow morning. But once your core authentication controls are in order, migrating existing MX records toward Microsoft’s newer DNSSEC-enabled model is a rational next step. That is an inference based on Microsoft’s direction: the old zone keeps working, but the new security capabilities are being built elsewhere.
The right starting point is still the basics. Make sure SPF is accurate and maintainable. Enable DKIM on all production sending domains. Use DMARC reporting to map every legitimate sender and move toward quarantine or reject with intention rather than guesswork. If you use intermediaries that modify mail in transit, review whether ARC is relevant so legitimate message changes do not break authentication results.
The second step is to review how mail actually moves through your environment. Third-party gateways, SaaS platforms, relays and forwarding services often create the gap between what is documented and what really happens. That is where many email security programmes fail: not because the standards are wrong, but because the actual mail path is more complex than assumed.
The third step is to modernise the trust layer under that mail flow. If your DNS provider supports DNSSEC properly, that should no longer be treated as an optional extra for “later”. For Microsoft 365 customers, it is increasingly part of the direction of travel, especially now that Microsoft is aligning accepted-domain mail flow with DNSSEC-enabled infrastructure under mx.microsoft.
And finally, if you automate domain onboarding or DNS provisioning, stop relying on old naming assumptions. Microsoft is explicit that hardcoding mail.protection.outlook.com into MX lookup logic is no longer reliable, and that the serviceConfigurationRecords endpoint in Microsoft Graph is the proper source of truth for the mailExchange value.
The bigger lesson behind Microsoft’s 2026 change is simple: email security is no longer just about blocking bad messages. It is about building trust across the full mail chain. SPF, DKIM and DMARC remain essential, but they are now the baseline, not the finish line. If you want a stronger email security posture today, the next conversation should include DNSSEC, transport security, and whether your current MX design still fits where the platform is going.
If your organisation wants to improve email security beyond the basics, this is the right moment to review your sender authentication, DNS design and Exchange Online mail flow together. At Synsec, we help organisations turn that into a practical roadmap instead of a collection of disconnected settings.
Thanks to our strategic partnerships with Microsoft and our broad experience, we are uniquely positioned to deliver a comprehensive, end-to-end solution to keep your security under control.
Let’s talk about how we can help secure your environment via eb.cesnys@olleh or +32 494 03 28 66
