SMTP relay for Microsoft 365: get sending working again

Reviewed by: Holger D. Erbe, Managing Director of LOGIN SystemHaus GmbH Published: August 2, 2026 Last reviewed: August 28, 2026

A device or application has been sending email through Microsoft 365 without a hitch for years. Then comes an update, a tenant migration or a change on Microsoft's side, and suddenly nothing goes out. This article explains what happened, what your options are and which of them hold up in practice.

The error message that brought you here

It is almost always one of these three:

Why Microsoft 365 refuses the login

With basic authentication, a device sends its username and password along with the connection. Anyone who steals the password can use it anywhere, and no second factor gets in the way. That is why Microsoft has switched off this sign-in method for the legacy protocols in Exchange Online and is phasing it out for SMTP submission as well. New tenants have SMTP AUTH disabled from the start, and existing ones are being switched over step by step.

The problem is not the decision itself but the other end. A multifunction printer, an ERP system from 2018 or a line-of-business application only knows username and password. It cannot do OAuth, and it never will, because the vendor ended support long ago. So sending is not broken. It just no longer matches what your email provider accepts.

Microsoft's three options, and what they cost you

Re-enable SMTP AUTH per mailbox

SMTP AUTH can be switched back on for the whole tenant and per mailbox. It is the fastest route and the one most people try first. It has three catches. The mailbox needs a license, even if it only serves as the sender for a printer. Security settings such as security defaults or a Conditional Access policy regularly conflict with it, so the exception stops working after the next change. And you permanently keep open a sign-in method that Microsoft has said it is phasing out. It buys you time. It is not a fix.

Direct Send

With Direct Send, the device delivers straight to your tenant's inbound server without signing in. That works without a license, but only for recipients in your own domains. An invoice to a customer cannot go this way. Delivery also depends on the reputation of the IP you send from, and for a device in the office that IP usually belongs to your internet connection and changes.

A connector with a static IP

An inbound connector in the Exchange admin center accepts mail from a specified IP address and also relays it to external recipients. This is the official route for devices that have to send to people outside your organization. It requires a static public IP address that is listed in your domain's SPF record. Without a static IP, this option is out. If you have one, you shift the delivery risk onto it: if it lands on a blacklist, everything stops again, and nobody but you looks after that address's reputation.

The fourth option: put an SMTP relay in front

Instead of getting Microsoft to accept an old device, the device sends its email to a service built for exactly this job. It still signs in with a username and password, because that is what it can do. The relay service accepts the message, signs it with DKIM, encrypts the transfer and delivers it to the recipient, whether that recipient is in-house or with another provider.

This changes three things for you. First, you no longer need a license for the printer. Second, your Microsoft 365 security policy stays untouched, because no exception is needed there anymore. Third, you no longer send from an IP address whose reputation you have to vouch for yourself. What an SMTP relay does in general is summarized on our home page.

The trade-off is one more service in the chain and, depending on the provider, the question of where your email travels. When invoices and HR data pass through, server location is not a side issue.

Setup in three examples

In all three cases you enter the same four values: server, port, username, password. Set encryption to STARTTLS, port 587.

• Multifunction printer. In the scan-to-email settings, replace the old server name with the relay's. The sender address stays as it is, as long as the domain is approved for sending. Many devices have a very short timeout. If the first test fails, check that before you start doubting the credentials.
• Inventory management or ERP. There is usually exactly one place for the outgoing mail server. What matters is that the sender address belongs to a domain you have verified in the portal. Otherwise the relay service rightly rejects the message.
• WordPress or an online store. Install an SMTP plugin and enter the credentials there. Without a plugin, PHP sends mail through the hosting provider's server function, and that mail reliably ends up in spam.

The complete sequence with screenshots, from adding the domain and the DNS records to the first verified email, is in the Getting started guide.

What happens to your mailboxes

Nothing. An SMTP relay only affects the outbound path from devices and applications. Mailboxes, calendars, Teams and regular sending from Outlook stay in Microsoft 365, unchanged. You replace exactly the part Microsoft no longer wants to handle and leave everything else alone.

The sender address stays the same, too. For recipients to recognize the email as genuine, though, the relay service has to be listed in your SPF record and sign with DKIM. How these three mechanisms work together is explained in our article on SPF, DKIM and DMARC.

Quick answers

Do I still need Microsoft 365? Yes, for everything else. The relay does not replace mailboxes. It only takes over sending from devices and software.

What about replies? Replies go to the sender address and land in the mailbox as usual. Bounce messages also show up in the relay's log, where they are explained in plain language.

How long does the switch take? Changing the settings on the device takes minutes. What takes time are the DNS records, because changes there can take a few hours to become visible everywhere, depending on your provider.