1. Home
  2. Free tools
  3. Email deliverability tools
  4. Microsoft 365 SMTP AUTH cut-off checker

Will my Microsoft 365 sending break in December? SMTP AUTH cut-off checker

In short: Paste sending domains and see which run on Microsoft 365, whether SPF, DKIM and DMARC are set up for it, and what to switch to OAuth before the end of December 2026. Limit: DNS shows which domains are on Microsoft 365, not how your sequencer logs in; confirm each inbox uses OAuth in its settings.

Microsoft says Basic auth for SMTP AUTH client submission in Exchange Online will be disabled by default for existing tenants at the end of December 2026. Any sequencer or app that sends through a Microsoft 365 inbox with a password stops working unless it uses OAuth. Paste your sending domains to see which are on Microsoft 365 and get a checklist for each one.

Only the domains are sent, for DNS lookups. 100 domains a run, or 500 when you sign in.
Sample result from the Microsoft 365 SMTP AUTH cut-off checker
Show the sample result as

Sample result

getacme.example is on Microsoft 365: switch its inboxes to OAuth before Basic auth for SMTP AUTH is turned off at the end of December 2026.

Domain
getacme.example
Cut-off
End of December 2026
DKIM
selector1 + selector2

What this means for you

Reconnect each inbox in your sequencer with its Microsoft sign-in option, then add a rua= address to DMARC. SPF and both DKIM selectors are already in place.

Next step:Check the next domains
  • Which sending domains are on Microsoft 365
  • SPF include, both DKIM CNAMEs and DMARC
  • A per-domain checklist before the cut-off
  • Up to 100 domains a run, 500 signed in
  • Microsoft 365
  • SMTP AUTH
  • Bulk

By SimpleVerifier Team · Last updated

How do I check which of my sending domains are on Microsoft 365?

  1. Paste your sending domains, one per line, or the inbox addresses themselves; the domain is taken from each. Up to 100 a run, 500 signed in with Google.
  2. Press Check Microsoft 365. Each domain's MX, SPF, the selector1 and selector2 DKIM CNAMEs and DMARC are read from DNS.
  3. Read the answer per domain: Microsoft 365 yes, likely (MX goes through a gateway but SPF or DKIM points at Microsoft), or no.
  4. Work through each Microsoft 365 domain's checklist, starting with reconnecting the inboxes in your sequencer by OAuth, then download the CSV to track it.

Example

You enter
Three sending domains: getacme.example (MX getacme-example.mail.protection.outlook.com), tryacme.example (Google Workspace MX) and acmehq.example (MX at a Proofpoint gateway, SPF with include:spf.protection.outlook.com).
You get
getacme.example: Microsoft 365 yes, SPF include and both DKIM CNAMEs published, DMARC at p=none with no rua=, so the checklist asks for a rua= address and for every inbox to be reconnected by OAuth before the end of December 2026. tryacme.example: Microsoft 365 no. acmehq.example: Microsoft 365 likely, behind the gateway.
Limits
Up to 100 domains a run without an account and 500 when signed in with Google. DNS only (MX, TXT, two CNAMEs, DMARC); no email is sent and no mailbox is logged in to.

What is changing in Microsoft 365 in December 2026?

SMTP AUTH client submission is the login an app uses to send through smtp.office365.com on port 587. Today it still accepts a username and password (Basic auth). In its 27 January 2026 update, Microsoft's Exchange team set the timeline: no change until December 2026, Basic auth for SMTP AUTH disabled by default for existing tenants at the end of December 2026 (admins can still turn it back on), and the final removal date to be announced in the second half of 2027. That update replaced the earlier plan to finish removal by 30 April 2026, which Microsoft put on hold.

Microsoft's Basic authentication deprecation page points to the same post for current dates and names OAuth 2.0 as the supported way to keep using SMTP AUTH, with step-by-step OAuth instructions for developers and Microsoft Graph as the alternative. Only client submission is affected; it isn't a change to how Microsoft 365 receives mail.

Will Instantly or Smartlead stop sending from my Microsoft inboxes?

If an inbox was connected with its SMTP and IMAP settings and a password or app password, yes: once Basic auth is off in the tenant, the sequencer's login is refused and the inbox stops sending and syncing replies. Inboxes connected with the sequencer's Microsoft or Outlook OAuth option (the one that opens a Microsoft sign-in window) authenticate with a token and aren't affected by this change.

DNS can't tell which method was used, so this checker answers the first question, which of your domains are on Microsoft 365, and the checklist tells you what to confirm. Reconnect each inbox by OAuth before the end of December 2026, and do the same for anything else that sends through a Microsoft 365 mailbox with a password: CRMs, website contact forms, scanners and scripts.

What other Microsoft sending limits apply in 2026?

Two others. First, the Tenant External Recipient Rate Limit (TERRL): the maximum number of external recipients a whole tenant can send to in a rolling 24 hours, based on its license count (Microsoft Learn: Exchange Online limits). In Message Center post MC1454397 (published 14 August 2026, timeline updated 29 September 2026), Microsoft started rolling out a new calculation from mid-September 2026, due to finish by the end of November 2026: tenants under 31 days old get 10% of the standard quota, 31 to 60 days 25%, and trial tenants 500 external recipients a day. Over the limit, mail to external recipients is blocked with 550 5.7.233 (550 5.7.232 on trials). That matters to cold emailers who set up new tenants for new sending domains. The admin center shows the tenant's figure under Reports, Mail flow.

Second, mail you send to Outlook.com, Hotmail and Live addresses: since 5 May 2025, Microsoft has rejected mail from domains sending over 5,000 a day that don't pass SPF and DKIM and publish DMARC, with 550 5.7.515 (Microsoft's announcement). That applies whatever platform you send from, which is why the checklist includes SPF, DKIM and DMARC. Our Outlook sender requirements checker covers it in depth.

How does the checker tell that a domain uses Microsoft 365?

From three DNS signals. MX hosts ending in mail.protection.outlook.com (or the newer mx.microsoft) mean Exchange Online receives the domain's mail: that's a yes. If MX points elsewhere, usually a security gateway such as Proofpoint or Mimecast, but SPF includes spf.protection.outlook.com or the selector1._domainkey and selector2._domainkey CNAMEs point at Microsoft's DKIM zones (onmicrosoft.com or dkim.mail.microsoft), the domain probably sends from Microsoft 365: that's a likely.

For Microsoft 365 domains it also checks what Microsoft's own setup asks for: the SPF include, both DKIM selector CNAMEs so key rotation works, and a DMARC record. Every answer comes from DNS; nothing is sent to the domains or their mail servers.

Which Microsoft changes does this checklist cover?

What changesWhenWho it hits
SMTP AUTH Basic authPassword logins to smtp.office365.com disabled by defaultEnd of December 2026Sequencers and apps connected by password
Tenant external recipient limitNew quota calculation: 10% then 25% for new tenants, 500 a day on trialsRolling out mid-September to end of November 2026New and trial tenants sending to external recipients
Outlook.com sender rulesSPF and DKIM must pass, DMARC at least p=none; else 550 5.7.515Enforced since 5 May 2025Domains sending over 5,000 a day to Outlook.com

Who uses this tool, and for what?

Cold emailers
Paste every secondary sending domain, find the Microsoft 365 ones, and reconnect their inboxes by OAuth in Instantly or Smartlead before the cut-off.
Agencies
Audit each client's sending domains in one run and send them the CSV checklist of what to switch and which DNS records to fix.
IT admins
Confirm which domains are on the tenant, then hunt down the printers, forms and scripts still using smtp.office365.com with a password.
Inbox resellers
Check the Microsoft 365 domains you provision have SPF, both DKIM selectors and DMARC before handing them over.

What can’t this tool tell you?

  • DNS shows where a domain's mail is hosted, not how a sequencer or app logs in. Whether an inbox uses OAuth is something you confirm in its settings.
  • A domain behind a gateway is only marked likely when SPF or DKIM points at Microsoft 365; one that hides both can't be identified from DNS.
  • The SPF include is looked for in the record and the includes it names, one level down; deeper nesting shows as missing.
  • It can't see a tenant's external recipient limit or usage; that's in the Exchange admin center.
  • Microsoft has changed this timeline before. Dates are as published by Microsoft on the dates cited.

Common questions

When does Microsoft turn off Basic auth for SMTP AUTH?
At the end of December 2026 Basic auth for SMTP AUTH client submission will be disabled by default for existing Exchange Online tenants, per Microsoft's 27 January 2026 update. Admins can re-enable it for now; Microsoft says it will announce the final removal date in the second half of 2027.
Does this affect Google Workspace inboxes?
No. This is a Microsoft Exchange Online change. A domain whose MX is Google Workspace shows Microsoft 365: no here, unless its SPF or DKIM shows it also sends from Microsoft 365.
How do I switch Instantly or Smartlead to OAuth?
Remove the inbox that was added with SMTP/IMAP settings and add it again with the sequencer's Microsoft or Outlook sign-in option, which uses OAuth. Your Microsoft 365 admin may need to approve the app for the tenant first.
What error will I see if I miss the cut-off?
The sequencer or app reports a failed SMTP login: the server refuses the username and password even though they're correct. Microsoft's posts don't publish a single code for it, so treat any authentication failure on smtp.office365.com after the cut-off as this change until proven otherwise.
Can my admin just turn Basic auth back on?
For existing tenants, yes, for now: Microsoft says admins will still be able to enable it after the default change. It's a stopgap: Microsoft has said a final removal date is coming, so plan the move to OAuth now.
What does 550 5.7.233 mean?
It's the bounce Exchange Online returns when a non-trial tenant has hit its tenant external recipient limit for the rolling 24 hours. Trial tenants get 550 5.7.232. Mail to external recipients resumes when usage drops below the limit.
Does the checker log in to my mailboxes?
No. It only reads public DNS records for the domains you paste. It never asks for or sees a password.

Sources

Authentication and capacity are half of deliverability.

The other half is who you send to. Every hard bounce counts against the domain and inboxes you are sending from, and nothing in DNS can tell you which addresses on your list are dead.

  • Bulk verification with real SMTP mailbox checks
  • Hard bounces removed before a send, not discovered after
  • Catch-all, disposable and role detection on every row
Get started — $29.99/moSee the published limits first

One plan, cancel anytime, no contract. Sign in with Google and your first 100 email checks are free, no card. The free tools stay free either way.

Clean your next list before it bounces

100 free email checks when you sign in with Google, no card. Then monthly plans from $9, or one flat price with fair use, never cut off.

Check 100 emails freeSee pricing

100 free checks, no card Cancel anytime Secure payment by Stripe