550 5.7.30: Basic Authentication Not Supported (Microsoft 365)

A 550 5.7.30 error means Microsoft 365 refused to send an email because the device or app signed in with just a username and password. Microsoft is switching off that older way of signing in for sending email. It mostly affects things that send email by themselves: office scanners, website contact forms, accounts software, alarms and other equipment.
What the message looks like
The error usually appears in the device’s or app’s own log or error screen, not as a bounce in a mailbox:
550 5.7.30 Basic authentication is not supported for Client Submission.
The exact wording varies a little. The code 5.7.30 is what matters.
What it means
Devices and apps that send email through Microsoft 365 usually connect to smtp.office365.com and sign in with a mailbox’s username and password. Microsoft calls this Basic authentication for SMTP AUTH, and it is retiring it in favour of a more secure sign-in called OAuth (modern authentication).
At the time of writing (last checked 6 October 2026), Microsoft’s timeline is:
- Until the end of December 2026: nothing changes.
- End of December 2026: Basic authentication for SMTP AUTH is switched off by default on existing Microsoft 365 accounts. Anything still using it starts getting 550 5.7.30. An administrator can switch it back on, as a stopgap.
- New Microsoft 365 accounts created after December 2026 will have it unavailable by default.
- Second half of 2027: Microsoft will announce the date it is removed for good.
Microsoft has moved this timeline more than once, so check its current announcement before planning around a date.
Nothing queues and nothing is retried: the email is refused. A scanner may simply show ‘send failed’, and a website form may look as if it worked while the email never leaves.
For a plan to find everything in your office that will be affected, see Microsoft 365 is switching off basic SMTP sign-in.
Common causes
- An office scanner or copier set up years ago to ‘scan to email’ using a mailbox’s username and password.
- A website contact form using an SMTP plugin with a Microsoft 365 username and password.
- Accounts, booking or CRM software that sends invoices or reminders through your Microsoft 365 mailbox.
- Alarms, CCTV and other equipment that email alerts.
- Older email programs that only support a username and password for sending.
How to fix it
- List everything that sends email by itself through Microsoft 365. For each one, look at its email settings. If it uses
smtp.office365.comwith a username and password, it is affected. - Check whether it supports modern sign-in. Look in its settings or ask the supplier for ‘OAuth’ or ‘Microsoft 365 sign-in’. Many website email plugins, and newer scanners, have an option to sign in with a Microsoft account instead of a password. Where it does, switch to it.
- If it doesn’t, give it another way to send. The main options are:
- A Microsoft 365 connector (SMTP relay). Your administrator sets up a connector so devices on your office’s fixed internet address can send without signing in. This suits scanners and copiers in one office.
- A separate email sending service. The device or website sends through a service built for it, with its own records added to your domain (SPF and DKIM).
- Replacing the device or software, if it is old and can do neither.
- Use the stopgap only as a stopgap. If something must keep working while you sort it out, an administrator can switch Basic authentication back on until Microsoft’s final date. Put the real fix in the diary.
- Test each one by sending a scan, a form enquiry or an invoice to yourself.
If you set up a connector or a sending service, make sure your SPF record includes it, or the emails may now go to spam instead. My guide to SPF, DKIM and DMARC explains why.
How to check it worked
Send a test from each device or app to a personal Gmail address. The email should arrive, and in Gmail, under the three dots and ‘Show original’, SPF and DKIM should both show PASS. For a website form, see my guide to contact forms that stop sending.
When to ask for help
Switching a website plugin to Microsoft sign-in is often a ten-minute job. Scanners and older equipment are harder: the settings are buried, the supplier may be gone, and a connector needs an administrator. If several things send email for you, do the list in step 1 before the end of December, so nothing stops without warning. The stopgap only lasts until Microsoft’s final date.
Where to go from here
- Why emails bounce, for other error codes.
- Contact form not sending emails?, if it is your website that stopped.
- Emails going to spam after moving to Microsoft 365 or Google Workspace?, for the records Microsoft 365 needs.
Need help fixing this?
I provide:
- Free initial assessment
- Clear explanation of the issue
- Fixed-price solutions
- UK-based support
Tell me what has stopped sending, and I’ll find a sign-in or sending route that works and set it up.
