Nothing in your Matomo install knows a mailbox password

Matomo sends email. Scheduled PDF reports on Monday mornings, alerts when traffic drops off a cliff, the password reset a colleague needs at an awkward moment. All of it goes out over SMTP, configured under General Settings, with a hostname, a username and a password sitting in the config file.

On Microsoft 365, that arrangement is ending. Basic authentication for SMTP client submission — username and password over the wire — is being phased out of Exchange Online: Microsoft already disables it by default for tenants that aren't using it, and plans to turn it off by default for every remaining tenant by the end of 2026. When it goes for your tenant, Matomo stops sending, and the first thing you notice is a report that never arrived.

The workaround most plugins reach for is worse than it looks

The usual answer is delegated OAuth: connect the plugin to a Microsoft account, click through a consent screen, and the plugin holds a refresh token that lets it send as that person.

It works. It also drags a human being into your infrastructure. That account needs a licence. It needs a password and MFA. If the person leaves, or their password rotates, or the refresh token expires — and refresh tokens do expire — your analytics reports quietly stop and nobody finds out until someone asks where the numbers went. You have replaced a stored password with a stored token belonging to an employee, which is a different problem, not a solved one.

Application permissions remove the human entirely

Missivus takes the other path Microsoft offers. Instead of acting on behalf of a person, it authenticates as an application.

An app registration in Entra ID holds a client secret or a certificate. It is granted the Mail.Send application permission — not the delegated one — with admin consent. It sends to a shared mailbox, which in Microsoft 365 requires no licence at all. There is no user, no sign-in, no MFA prompt, no refresh token, and no mailbox password anywhere in your Matomo install or its database. The credential is an app secret you rotate on your own schedule, and rotating it is a paste into one field.

The part everyone gets wrong

Here is the detail that matters, and the reason this plugin exists rather than a config snippet.

Granting Mail.Send as an application permission gives that app the ability to send as every mailbox in your tenant. By default. That is not a subtlety — it is a tenant-wide send-as capability handed to a service principal, and a great many how-to guides stop right there and call it done.

The restriction is a separate step, in a separate place, in a different admin tool: an application access policy in Exchange Online — Microsoft's newer RBAC for Applications does the same job and is the direction it's steering admins toward — applied via PowerShell, scoping that app to a single mail-enabled security group containing only the mailbox it is allowed to touch. Until you run it, the scope is everything. After you run it, you verify with Test-ApplicationAccessPolicy and confirm access is denied for a mailbox that should be off-limits — because a restriction you haven't tested is a restriction you're assuming.

Missivus ships the PowerShell for this as part of setup rather than leaving it as an exercise, and the plugin will not treat a configuration as complete without it.

What this doesn't do

It is Microsoft 365 only. If you run Google Workspace or your own mail server, this is not for you and SMTP is fine.

It sends outbound mail and nothing else. The application permission is Mail.Send — the app cannot read a mailbox, and shouldn't be able to.

And it moves your Matomo mail through Microsoft's infrastructure, which is a US company operating under EU hosting. If that is the wrong answer for your data, it's the wrong answer here too, and we'd rather say so than let it go unmentioned.

Getting it

Missivus for Matomo is on the Matomo Marketplace, GPLv3, free. The setup walkthrough — app registration, permission grant, access policy, verification — is at missivus.com/setup.

If you'd rather not touch Entra ID and Exchange PowerShell yourself, we do the installation and hand you a working configuration. That is the paid part; the plugin never is.

← All insights