Sending Your Website’s Email Through Your Own Microsoft 365

By default your website tries to send its own email, which is why form notifications and receipts so often land in spam or vanish. This guide connects your website to your own Microsoft 365 account instead, so every email the site sends is handed to Microsoft and sent as if you had sent it yourself. Budget roughly an hour the first time. Most of that is in Microsoft’s admin portal rather than in WordPress, and there is one date you will need to write in your calendar before you finish.

The deadline that makes this worth doing now

There are two ways a website can send through Microsoft 365, and only one of them has a future.

The old way is ordinary SMTP, where the site is given a Microsoft 365 username and password. Microsoft is retiring password-based sign-in for SMTP. Their current position is that existing tenants can keep using it until the end of December 2026, tenants created from January 2027 will not have it at all, and a final removal date is to be announced during 2027. Note that many organisations already have it switched off, because Microsoft’s security defaults disable it.

The method in this guide does not use SMTP at all. It connects through Microsoft’s modern sign-in and sends via Microsoft Graph, so it is unaffected by that retirement. If anyone has ever set your website up with a Microsoft 365 email address and password in an SMTP box, that arrangement is on borrowed time and this is what replaces it.

Is this the right choice for you?

This is the right home for form notifications, order receipts and account emails. It is not the right home for a newsletter or a large mailing list. Keep bulk sending on a service built for it.

Before you start

• You need to be an administrator of your Microsoft 365 account and an administrator of your website. Two different logins, both open.
• You will register an application in Microsoft Entra ID, which used to be called Azure Active Directory and which you reach through the Azure portal. You will see both names used, sometimes on the same screen. They are the same place.
• Microsoft may ask for a card to verify the account even though nothing here costs anything.
• Decide which address the site should send from before you begin.

Part one: in Microsoft

Microsoft’s screens are renamed and rearranged often enough that we will not pretend a screenshot would still be accurate. For the click-by-click follow WP Mail SMTP’s own documentation, which stays more current than anything we would copy. Below is the shape of the job and the parts that catch people out.

1. Open your website’s settings first, not Microsoft’s. In your dashboard go to WP Mail SMTP, then Settings, and choose 365 / Outlook as the mailer. The screen shows a Redirect URI. Copy it now and keep it. It will look like your own website address with /wp-admin/ on the end.
2. Sign in at portal.azure.com with your Microsoft 365 administrator account, and go to App registrations, then New registration.
3. Name it something you will recognise in two years, such as your domain name followed by the word website. Nobody outside your business sees this.
4. For the platform choose Web, and paste in the Redirect URI you copied from your own site in step one. It has to match exactly.
5. Register it. The overview page then shows an Application (client) ID. Copy that.
6. Go to Certificates and secrets, then New client secret. Choose the longest expiry Microsoft offers you, which is currently two years, and write that expiry date in your calendar now with a note saying the website email will stop.
7. Copy the secret’s Value. See the warning below, because this is where most people go wrong.

Part two: in WordPress

1. Back in WP Mail SMTP, then Settings, with 365 / Outlook selected.
2. You may see an option called One-Click Setup. Leave it switched off. It needs a licence that is not active on your site, and with it on the sign in button is greyed out and nothing happens. The fields below are the route that works.
3. Paste the Application (client) ID from Microsoft into the field the plugin calls Application ID.
4. Paste the secret Value into the field the plugin calls Application Password. The names differ between Microsoft and the plugin, but these are the same two pieces of information.
5. Set the From Email and From Name, then Save Settings.
6. Now click the button to allow the plugin to send email using your Microsoft account, and approve the request Microsoft shows you. Approving it is the step that actually completes the connection.
7. Send a test from the Email Test tab to an address outside your own domain, such as a personal address. Sending to yourself proves less than you think.

The From address rule

The site can only send as the Microsoft account you connected, or as an address that account is already permitted to send on behalf of, such as a shared mailbox it has been given rights to. The address also has to be a Microsoft-hosted one.

If you want the site to send from something like [email protected], set that up properly in Microsoft 365 first and then use it here. Typing in an address that does not exist is a common cause of a test that fails without explaining why.

When it stops working

1. The Application Password expired. Far and away the most common, because it is guaranteed to happen eventually. Create a new secret in Microsoft, paste the new Value into the plugin, save, and reconnect. You do not need to register the application again.
2. The website address changed. The Redirect URI is your own site’s address, so moving domain, or registering the www version when your site uses the plain one, produces a sign-in error about a mismatch. Tell us if the site has moved and we will sort the value.
3. Something changed on the Microsoft account. A password reset, a new multi-factor requirement, or an administrator withdrawing consent for the app will all end the connection.

What to send us if it will not connect

• The exact error, copied as text or screenshotted in full.
• The Redirect URI you entered in Microsoft, so we can compare it with the one your site expects.
• The address you connected with, and the From Email you set.
• The expiry date you chose for the Application Password.

Never send us the Application Password by email. We do not need it, and it is the one part of this that should never leave your own screen. If we genuinely need to look, we will ask you to add us to the site instead.

Related

• Sending your website’s email through your own Google Workspace
• Form emails not arriving
• Generating your DKIM records in Microsoft 365
• What not to touch, and when to email us instead