Microsoft has confirmed that Exchange Online will begin blocking all POP3 and IMAP4 client connections that still negotiate TLS 1.0 or TLS 1.1 starting in July 2026. After more than two years of warnings and postponed deadlines, the legacy TLS cutoff is now final—and the systems most likely to break are not modern Outlook clients, but the non-human accounts used by scanners, printers, monitoring tools, and legacy business applications.

For IT administrators who have already secured SMTP AUTH and REST-based workloads, this may feel like déjà vu. Yet POP3 and IMAP4 have stubbornly clung to life in thousands of organizations precisely because they underpin unattended workflows that rarely get patched. The new timeline gives you a breathing room, but the work to inventory and update every non-human client must start now.

A Long Road to TLS 1.2

Microsoft’s crusade against outdated Transport Layer Security in Exchange Online began in earnest when it forced all SMTP AUTH submissions to use TLS 1.2 by January 2023 (MC279147). At the time, the company signaled that POP3 and IMAP4 would eventually follow, but the precise deadline kept sliding. An early announcement in March 2024 (MC719722) set a September 2024 enforcement date, which was hastily pushed to February 2025, then to July 2025 with a grace period. Each delay acknowledged the reality that thousands of tenants were unprepared.

The final word came in February 2025 via Message Center post MC980183. There, Microsoft abandoned the phased approach and set a hard cliff: beginning in July 2026, POP3 and IMAP4 connections that negotiate TLS 1.0 or 1.1 will be refused. The long lead time, the company says, is meant to allow thorough audits and client updates without disrupting business continuity.

What’s Actually Changing?

The scope is remarkably narrow. Only the following will be affected:

  • POP3 client connections (port 995, usually SSL/TLS) that initiate a handshake with TLS 1.0 or TLS 1.1.
  • IMAP4 client connections (port 993, usually SSL/TLS) that do the same.

Other Exchange Online protocols are already safe:

  • Outlook clients communicate via MAPI-over-HTTPS, Exchange Web Services (EWS), or ActiveSync—all of which have required TLS 1.2 for years.
  • SMTP AUTH submissions (client submissions on port 587) were forced to TLS 1.2 in January 2023.
  • Inbound mail flow via SMTP (port 25) from other mail servers is not affected, as it typically uses opportunistic TLS; Microsoft does not control the TLS version of the sender, but inbound connectors can be configured to require TLS 1.2.
  • The Outlook on the web and REST APIs have been TLS 1.2-only since 2019.

In short, if your organization uses only Outlook, mobile mail apps that connect via ActiveSync, or modern connectors, you will see zero impact. The trouble lurks entirely in the corners of your IT landscape where devices and applications still talk to Exchange Online the old-fashioned way.

The Real Culprits: Non-Human Clients

The excerpt from Microsoft’s advisory is blunt: “non-human clients are the systems most likely to break.” That phrase points to a long list of often-forgotten devices and services:

  • Multi-function printers and scanners that “scan-to-email” using POP/IMAP credentials.
  • Legacy line-of-business applications (ERP, CRM, HR systems) that send status notifications or retrieve mailbox data via IMAP.
  • Network monitoring tools (PRTG, Nagios, Zabbix) that poll a mailbox for alert emails.
  • Older mail gateways or backup utilities that pull mailbox contents via IMAP.
  • Custom scripts written years ago using Perl, Python, or PHP libraries that still force TLS 1.0.
  • Third-party mail clients that have not been updated in years, often on embedded systems.

These clients typically run on devices with infrequent patch cycles—or no update mechanism at all. A printer that was deployed in 2018 may still be running firmware from its manufacture date, blissfully unaware that the TLS library baked into its firmware is about to be rejected. Even when updates are available, the staff who configured the scan-to-email function may have long since left the company, leaving no documentation.

Timeline and Enforcement

July 2026 is not a single “flip the switch” date. Microsoft’s plan follows a pattern seen in previous TLS deprecations:

  • Now through mid-2025: Microsoft will increasingly surface health alerts in the Microsoft 365 admin center. Tenants with active POP/IMAP connections that use legacy TLS will see advisory messages. The service will also begin emitting SMTP headers or return-path tags that make those connections identifiable in message traces.
  • Early 2026: A small subset of tenants—likely those with the highest volume of legacy TLS connections—will be moved into a “limited enforcement” ring. They will start receiving hard blocks for a few hours each week, forcing them to address the issue.
  • July 2026: Full enforcement begins. Any POP3 or IMAP4 client that presents a TLS 1.0 or 1.1 ClientHello will receive a connection reset or an explicit TLS alert, and the session will fail. There will be no permanent opt-out.

Microsoft has, in the past, offered temporary opt-out periods via its support channels for critical business continuity scenarios. However, the company’s messaging for this cutoff makes clear that such exceptions, if granted, will be strictly time-limited. The message center post warns that “reliance on legacy TLS for POP3 and IMAP4 constitutes an unacceptable risk to your data and compliance posture.” Translation: do not expect a get-out-of-jail-free card.

How to Identify Clients Running Afoul

Because Exchange Online does not expose the negotiated TLS version in its standard audit logs, you must look for indirect indicators. Here are the most reliable methods:

  1. Check your mail client logs – Many devices and applications log the TLS version they negotiate. For Linux-based clients, search /var/log/maillog or syslog for entries containing “TLSv1” or “SSLv3.” On Windows, check the application event logs of the sending machine.
  2. Test with OpenSSL – You can simulate a TLS handshake from a privileged workstation. For example:
    openssl s_client -connect outlook.office365.com:993 -starttls imap -tls1_1
    If the connection succeeds, clients using that version will work today. Repeat with -tls1_2 to confirm TLS 1.2 works. This test confirms the server’s capabilities; you still need to know what your client actually sends.
  3. Enable SMTP protocol logging on your on-premises hybrid transport server – If mail flows through a hybrid connector, enable verbose logging and capture the TLS hello. This is rarely feasible for cloud-only tenants.
  4. Leverage Azure AD sign-in logs – Non-human POP/IMAP clients typically use legacy authentication (basic auth). If you have legacy authentication disabled (which you should), clients that attempt to authenticate via POP/IMAP will generate failures. Those failures can be traced back to the client IP. While they won’t reveal the TLS version, they highlight the accounts using legacy protocols.
  5. Use a packet capture appliance or cloud proxy – If traffic from your outbound internet edge can be mirrored, you can filter for TLS ClientHello messages on port 993 or 995 and inspect the supported TLS versions.

Once you identify an outdated client, the remediation path will be unique to that device or software. It is essential to build an inventory now while you still have weeks and months to fix things, rather than in the fire drill of July 2026.

Remediation Options: From Patching to Replacement

The right fix depends entirely on the client’s capabilities and business criticality.

  • Update the client software or firmware – For mainstream operating systems and applications (Windows 10/11, recent Linux distros, up-to-date mail libraries), enabling TLS 1.2 is often just a checkbox. Check the vendor’s documentation for the exact setting. Many scanners, for example, have a “Security” menu where you can select “TLS 1.2” under SMTP/IMAP settings.
  • Switch to a modern API – If you maintain the code that uses POP/IMAP, consider retiring it in favor of Microsoft Graph or Exchange Web Services (though EWS itself is being deprecated in favor of Graph). Not only will this automatically support TLS 1.2, but it also eliminates the risk of basic authentication being disabled.
  • Deploy a local relay server – For devices that cannot be updated (common with older MFPs), stand up a lightweight relay inside your network. For example, a small Linux VM running stunnel or haproxy that accepts unencrypted or TLS 1.0 connections on a local IP and then connects to Exchange Online using TLS 1.2. This wraps the old protocol in a modern TLS session. Be careful to restrict the relay’s IP address to prevent open relay abuse.
  • Use a third-party email delivery service – Some organizations route all scan-to-email traffic through a service like SendGrid or Mailgun, which then forwards to Exchange Online via a properly secured connection. This can be a quick workaround while you plan a hardware refresh.
  • Retire the device entirely – If the device is already out of support and no business case justifies a replacement, now is the moment to decommission it. The TLS 1.2 requirement is a forcing function that aligns neatly with broader end-of-life strategies.

What About SMTP AUTH?

If your non-human clients use SMTP AUTH (client submission on port 587) rather than POP/IMAP to send mail, you may be wondering if this affects you. The answer is no—but only if you already enforced TLS 1.2 for SMTP AUTH. Microsoft made that change years ago, and most tenants are compliant. However, if you still have legacy devices submitting mail via SMTP AUTH with TLS 1.0, those connections have likely been failing since early 2023 without anyone noticing—until the device’s error logs fill up. It is worth a spot check.

Note that POP3 and IMAP4 are used for receiving mail. Many non-human clients only need to send (e.g., scan to email), so they only use SMTP AUTH. Those clients are already past the TLS 1.2 hurdle. But if the same device also pulls email for processing (e.g., a helpdesk system that monitors a shared mailbox via IMAP), then you have a dual exposure.

Proactive Governance: Lock Down Legacy Protocols Now

Even before the TLS enforcement date, you can use Exchange Online administration tools to tighten your security posture and immediately block clients that refuse to talk TLS 1.2.

  • Disable POP3 and IMAP4 at the tenant level – In the Exchange admin center, navigate to Settings > Mail flow. There you can toggle off POP3 and IMAP4 entirely. If your organization has no valid use case for these protocols, turn them off today. This is the simplest way to eliminate the risk.
  • Use authentication policies – With modern authentication policies, you can block legacy authentication for specific protocols. While basic authentication for POP/IMAP is already deprecated by default, some tenants may have exemptions. Review and revoke them.
  • Conditional Access – if applicable – Conditional Access policies do not directly control TLS versions, but you can require that all mail client access come from managed devices or trusted IPs, which can indirectly catch non-compliant clients.

Finally, Microsoft’s Message Center post encourages administrators to run the “Mailbox usage” report in the Microsoft 365 admin center. It shows which protocols are being used to access each mailbox. If you see POP3 or IMAP4 activity, investigate immediately.

Looking Ahead

The July 2026 cutoff is a final curtain call for TLS 1.0 and 1.1 in Exchange Online. When enforcement lands, the internet will not break, and 99% of Outlook users will sail through without a blink. But the 1%—the printers, the monitoring boxes, the creaky ERP module that emails invoices—will silently stop working. Emails will pile up in unsent queues; scan-to-email buttons will fail; automated alerts will go dark.

The fix is straightforward once you know where to look. Start by asking every department head: “Do we have any old equipment that uses email?” Then trace the connection strings. Every non-human client you upgrade or retire between now and July 2026 is one fewer fire drill on the day the switch flips.