The alert often comes from an IT manager or an operations director: “ Our management software is no longer sending email notifications, even though it used to work perfectly fine.” ”
At Infologo, an IT service provider based in Geneva and Lausanne, we’ve been receiving calls like this regularly ever since Microsoft tightened the authentication rules for Microsoft 365. The problem is no small matter: an application that can no longer send emails means order confirmations go missing, critical alerts never arrive, and business processes quietly fail. Let’s take stock.
What Microsoft 365 Accepts and What It Rejects
SMTP Relay in Microsoft 365 refers to the ability of third-party hardware or software (such as a scanner, ERP system, billing software, or ticketing system) to send emails through Microsoft’s Exchange Online servers without a user being directly logged in. Microsoft documents three methods for sending emails: authenticated SMTP client (AUTH SMTP), direct SMTP relay, and connection via an inbound connector.
The AUTH SMTP method is the most commonly used by default. It works with a Microsoft 365 account and a password, making it accessible. However, since the rollout of modern authentication and Microsoft’s phased-out of basic authentication, many applications configured with this method have simply stopped working, without a clear error message.
Direct SMTP relay, on the other hand, does not require user account authentication. This is often the right solution for network devices or applications that do not support OAuth. However, it imposes a requirement that many companies are unaware of at first: the application or device must be able to send mail from a fixed public IP address, which must be explicitly declared in the Microsoft 365 connector.
Why is the fixed public IP address non-negotiable?
This is where most configurations fail. Microsoft uses the source IP address to validate incoming messages on the SMTP connector: if the IP address changes, the message is rejected or silently dropped. In many cases, there is no explicit error message—the email simply doesn’t send.
A client in the canton of Vaud contacted us after spending several weeks trying to figure out the problem. Their multifunction scanner had been sending PDFs via email for years. After switching internet service providers, their public IP address changed, and the emails stopped overnight. The Microsoft 365 connector simply needed to be updated with the new address, but no one had made the connection between the two events.
This is not an isolated case. In the incidents of this type that we have handled over the past twelve months, the lack of a static IP address or an IP address not declared in the connector was the cause of the block in the majority of cases. Another common cause: a misconfigured connector, with a sender domain that did not match the email system’s SPF and DKIM rules.
Three questions to ask before setting anything up
Before making any changes to an SMTP configuration, we always ask the same questions:
- Does the application or device have a static public IP address?
- If not, can we get one from the internet service provider?
- And what type of authentication does the application support: standard SMTP authentication, OAuth, or none?
The answers to these three questions determine which method to use. Forcing an AUTH SMTP configuration on an application that does not support modern authentication will simply create an additional blockage after the next Microsoft security update. This is not a robust solution; it is a workaround with an expiration date.
If the application does not support OAuth or a static IP address, the alternative is to use a third-party SMTP relay service (SendGrid, Mailjet, Postmark), which supports authentication via an API key and does not impose any network restrictions. This is sometimes the least expensive solution to maintain over the long term.
What we recommend at Infologo
Configuring SMTP relay on Microsoft 365 isn’t complicated in itself, but it’s poorly documented for non-technical users, and Microsoft’s error messages don’t always clearly explain the actual cause of the issue.
Our recommendation is straightforward: if your organization uses Microsoft 365 and you have applications or devices that send automated emails, check right away to see if these emails are sent through an AUTH SMTP account using basic authentication. If so, the service may stop working during the next Microsoft security policy update, without prior notice. It’s better to plan for this migration than to deal with it as an emergency on a Monday morning.
We do not recommend creating multiple service accounts for SMTP sending without regularly auditing them. These accounts are often created to resolve a one-time issue and then forgotten, while maintaining active access to your Microsoft 365 tenant.
If you’re unsure about your current setup or if you’ve recently switched internet service providers, contact us for an SMTP relay audit. We’ll identify the issue within a few hours, with no obligation.
