Email remains one of the most consistently targeted attack surfaces in cyber security. Despite evolving defences, phishing, spoofing, and impersonation attacks continue to be effective—largely due to gaps in how organisations authenticate the email they send. The frontline of defence? A triad of DNS-based protocols: SPF, DKIM, and DMARC.
- SPF (Sender Policy Framework) allows domain owners to define which mail servers are authorised to send on their behalf.
- DKIM (DomainKeys Identified Mail) ensures email integrity by attaching cryptographic signatures to outgoing messages.
- DMARC (Domain-based Message Authentication, Reporting and Conformance) enables domain owners to instruct how unauthenticated mail should be handled, and provides reporting for monitoring abuse.
These mechanisms have long been recommended, but enforcement across the email ecosystem has been inconsistent in our experience, when reviewing M365 configurations for clients in many industries.
Microsoft’s Enforcement Shift
This article is not intended as a guide to strengthening your organisation’s email security from first principles. If you’re looking for detailed, practical advice on that front, we recommend reading this post by my colleague Pat, on bullet-proofing your email gateway.
Instead, this time we wanted to focus on a specific upcoming change: Microsoft’s enforcement of new requirements for email authentication and the potential operational implications it carries.
From 5th May 2025, new requirements for high-volume email senders will be enforced targeting Outlook.com recipients. According to Microsoft’s announcement, organisations sending more than 5,000 messages per day must:
- Authenticate email using SPF, DKIM, and DMARC.
- Publish a DMARC policy of p=quarantine or p=reject—this means p=none will not suffice anymore.
- Support one-click unsubscribe on bulk messages (in line with RFC 8058).
- Maintain a spam complaint rate below 0.3%.
Microsoft will start enforcing these requirements gradually, beginning with consumer domains, and eventually extending to enterprise scenarios. The move is intended to reduce spam, improve email trustworthiness, and promote industry-wide adoption of email authentication best practices. This enforcement from Microsoft seem to align with similar initiatives by Google and other major providers.
The Practical Challenge & JUMPSEC’s Response
For many IT and security teams, managing SPF, DKIM, and DMARC across multiple domains and services is complex. Vendors and cloud platforms often introduce their own sending infrastructure, and maintaining accurate records with correct policies can be labour-intensive. Additional complications arise from:
- Recursively included SPF records and domain-level redirections
- DKIM selectors not being published properly
- DMARC reports not being reviewed or misconfigured rua/ruf addresses
Moreover, this isn’t a one-time task. Mail infrastructure changes frequently. Ongoing validation and visibility are critical.
I recently developed a tool that can tackle the operational reality of domain authentication at scale, and can assist organisations in navigating this shift. Allow me to introduce the Asynchronous Mail Checker, a free and open-source utility written in Python, designed to make large-scale validation of SPF, DKIM, and DMARC both fast and accessible.
Asynchronous Mail Checker is a Python-based tool that performs asynchronous DNS checks for SPF, DKIM, and DMARC across any number of domains. Built with operational efficiency in mind, it uses aiodns for fast parallel queries and a Streamlit-based interface for intuitive inspection.

Asynchronous Email Checker dashboard!
What It Does
- Performs non-blocking DNS queries for SPF, DKIM, and DMARC
- Recursively resolves and parses SPF includes and redirects
- Checks for common DKIM selectors across services
- Analyses DMARC policy strength, rua, ruf, fo, and alignment settings
Reporting and Visualisation
- Matrix view showing protection status for each domain
- DMARC policy charts, FO distributions, and authentication gaps
- Historical trend graph, built from CSV-backed scan records, to track posture improvement
- CSV export for audit, compliance, and internal reviews

Records matrix and high-level analysis out of the box, to identify gaps at a glance.

Charts, graphs and historical trends canbe shown when selected in the menu, visually organising the data off the scans.
How to Use It
Follow the guidance in the repository (https://github.com/JumpsecLabs/AsyncMailChecker) to clone and setup the app, then:
- Run the app
streamlit run AsyncMailChecker.py --server.headless true --server.address "<host ip>"
- Upload a line separated .txt list of domains
- Configure SPF recursion depth, DNS timeouts, retries, and concurrency
- Run DNS Checks and review the data!
Conclusions
Microsoft’s new rules are no longer a proposal—they’re being enforced in the near timeframe of May 2025. Without the appropriate records and policies in place, legitimate business email will begin to suffer from delivery failures. For organisations with complex mail infrastructures or third-party dependencies, having visibility is non-negotiable.
Async Mail Checker allows teams to:
- Validate email authentication posture at scale
- Catch misconfigurations or omissions early
- Improve deliverability and align with the new baseline standards
The tool is available now via GitHub:
👉 https://github.com/JumpsecLabs/AsyncMailChecker
We encourage the community to use it and ensure your organisation’s domains are secure, compliant, and trusted when delivering emails.
Furthermore, we are also releasing additional tooling that parses and analyses mail transport rules in Exchange Online. They can be used in tandem to have optimal visibility of what’s going on with your mail transport rules in Exchange Online.
These can be found within JUMPSEC Labs GitHub repositories, namely:
https://github.com/JumpsecLabs/ExchangeOnline-MTR_Domains – A PowerShell script that analyses approved and rejected domains specified via Mail Transport Rules in Exchange Online, leveraging the ExchangeOnline PowerShell Module.
https://github.com/JumpsecLabs/MTR-Analyser – A PowerShell script that analyses Mail Transport Rules leveraging the Exchange Online PowerShell Module.