To send scheduled reports through Microsoft 365, point your reporting tool at smtp.office365.com on port 587 with a secure connection and a licensed mailbox. Microsoft's SMTP AUTH clients report in the Exchange admin center then shows which apps and devices are actually using that route. One date matters more than any setting: Exchange Online is scheduled to turn off SMTP basic authentication by default at the end of December 2026. This guide covers the settings, the report, and how to keep report delivery running after that change.
TL;DR
- Use
smtp.office365.com, port 587, secure connection (STARTTLS), and the full email address of a licensed mailbox as the account name. - "Office 365 SMTP reports" can mean two things: reports sent through SMTP (scheduled PDFs and Excel files) or the Microsoft report on SMTP use (the SMTP AUTH clients report). This page covers both.
- Exchange Online is set to disable basic auth for SMTP client submission by default in late December 2026 for existing tenants. Admins can re-enable it, but plan a move to OAuth, a relay connector or the Graph API.
- Check the SMTP AUTH clients report now, before the cutoff, to find every sender still using a stored password.
Table of Contents
- The settings your reporting tool needs
- Two ways to send: client submission or relay
- What is changing in December 2026
- Check who is sending: the SMTP AUTH clients report
- Beyond the SMTP report: Microsoft 365 email activity
- Why report delivery needs more than SMTP settings
- Our perspective: treat SMTP as plumbing you will have to replace
- Fixing common sending problems
- Automating report delivery with PBRS, ATRS and CRD
- FAQ
- Sources
The settings your reporting tool needs
Most report servers ask for the same five fields. For Microsoft 365 they look like this:
| Field | Value |
|---|---|
| SMTP server | smtp.office365.com |
| Port | 587 |
| Security | Secure connection (STARTTLS) |
| Account name | Full email address of the sending mailbox |
| Password | The mailbox password (basic auth) or an OAuth token flow |
| From address | The same mailbox, or an alias it has permission to send as |
The server and port pairing is what other reporting vendors document too. Telerik's Report Server guide, for example, gives smtp.office365.com with port 587 for Outlook and tells you to tick the secure-connection option. Grafana Enterprise requires SMTP to be configured before reports can be sent, which is true of nearly every scheduler that mails a dashboard.
Three details that cause most failures
- The mailbox must be licensed and allowed to use SMTP AUTH. A shared mailbox or a user with SMTP AUTH switched off will authenticate and then be rejected.
- The From address must match the account. Sending as a different address without Send As permission produces a rejection, not a warning.
- Multi-factor authentication and security defaults break password logins. A reporting service cannot answer an MFA prompt. That is the practical reason this route is moving to OAuth.
When the test email works but a scheduled report fails, look at the report itself, not the SMTP settings. Attachment size is the usual cause: a large Excel export can exceed the mailbox limit, and the fix is to deliver a link or a file share copy instead.
Two ways to send: client submission or relay
Microsoft 365 gives you two common ways to push automated mail. They behave differently, and the difference decides how exposed you are to the December change.
| Client submission | SMTP relay | |
|---|---|---|
| Endpoint | smtp.office365.com | Your Exchange Online connector endpoint |
| Port | 587 | 25 |
| Authentication | Username and password (basic) or OAuth | Source IP address, no credentials |
| Recipients | Internal and external | Internal only by default |
| Affected by the basic auth retirement | Yes | No |
The comparison comes from the CaptainDNS timeline and migration guide. Relay suits a reporting server with a fixed IP that only mails internal staff. Client submission suits reports going to customers, auditors and partners outside your tenant.
Be honest about the trade-off. Relay avoids passwords altogether, but it ties delivery to an IP address and limits who can receive. OAuth keeps external delivery but adds an app registration to maintain.
What is changing in December 2026
Microsoft has moved this date more than once. According to the CaptainDNS timeline, the retirement was announced in April 2024, postponed in December 2025, and revised again on January 27, 2026. The current plan, as summarized there:
- Late December 2026: basic auth for SMTP client submission is disabled by default on existing tenants, and an admin can re-enable it.
- After that: new tenants do not get basic auth for client submission at all.
- Second half of 2027: Microsoft is expected to announce a final, irreversible removal date.
A client still using basic auth after the cutoff gets error 550 5.7.30, which says basic authentication is not supported for client submission. A second write-up, from Netsys Group, describes the practical effect: scan-to-email and old line-of-business apps simply stop sending, and nobody notices until a recipient asks where a report went.
Because Microsoft has changed the date several times, confirm it on Microsoft's own deprecation page before you schedule work.
Check who is sending: the SMTP AUTH clients report
The second meaning of the keyword is the report Microsoft provides about SMTP use. Microsoft describes the SMTP AUTH clients report in the Exchange admin center as a way to spot unusual activity and see TLS usage for clients and devices that use SMTP AUTH.
To open it:
- Sign in to the Exchange admin center with an admin account.
- In the left pane, go to Reports, then Mail flow.
- Select SMTP AUTH clients.
- Use Export to download the data, as walked through in this step-by-step knowledge base article.
The report has an authentication column that separates basic from modern authentication. Admins in a Reddit thread ask how to read that value, which shows the column is not always obvious. Treat any row marked basic as a migration to-do.
A short audit routine:
- Export the report and list every sending account and client.
- Match each one to an owner: a printer, a monitoring tool, an ERP, or your report scheduler.
- Mark each as moves to OAuth, moves to relay, or moves to Graph API.
- Re-check the report in January and look for senders that were active in December and have gone quiet.
That last check matters because failure is silent. The mail does not bounce to a person who will complain loudly.
Beyond the SMTP report: Microsoft 365 email activity
If what you want is volume, not authentication, the Microsoft 365 admin center has a separate usage report. Go to Reports, then Usage, then Email activity, and you see messages sent, received and read per user over a period. It is useful for adoption questions. It will not tell you whether the Monday sales report reached the regional director, because it counts mailbox activity rather than the reports a scheduler generated.
For message-level questions, such as whether a specific report mail left Exchange Online, you need message trace, and for reports sent by a BI scheduler you also need that tool's own delivery log.
Why report delivery needs more than SMTP settings
SMTP only moves a message. Everything before that (rendering the report, applying filters per recipient, choosing PDF or Excel, retrying on failure) is the job of the reporting tool. When teams say their Office 365 reports are unreliable, the weak point is usually that layer.
Some things to look for in how reports are mailed:
- Per-recipient content. One schedule that produces a filtered version for each region or customer, rather than one file everyone sees.
- Format control. PDF for reading, Excel for analysis. If your finance team still builds management packs by hand, a walkthrough such as building a management reporting dashboard in Excel (a Dutch-language page) shows the kind of layout that is worth automating once it works.
- Error handling. A failed send should retry and alert someone, not vanish.
- Alternatives to email. File shares, cloud storage or collaboration tools remove attachment limits and reduce your exposure to SMTP changes.
Our perspective: treat SMTP as plumbing you will have to replace
We have spent more than two decades automating report delivery for Power BI, SSRS, Tableau and Crystal Reports, and SMTP trouble is one of the most common reasons a working schedule suddenly stops. The cause is rarely the BI tool. A password rotates, a security policy changes, or Microsoft retires a protocol, and a mailbox that nobody owns stops accepting logins.
Our advice to BI administrators:
- Give report delivery its own identity. A dedicated sending mailbox, owned by a named team, is easier to move to OAuth than a former employee's account.
- Do not rely on a single path. Email is one destination. Delivering the same report to a file location or a collaboration tool as a fallback means a protocol change does not leave executives without numbers.
- Watch failures, not only successes. A schedule that reports "complete" while the mail server rejects every message is worse than a loud failure. We wrote about this in SMTP failure reporting for BI admins.
- Keep the tenant change on your calendar. Late December is the worst time to learn that a month-end finance pack depends on basic auth.
Native subscriptions in a BI platform are fine for a handful of reports. They get hard to manage once you have hundreds of recipients, per-recipient filters and strict deadlines, and that is where a dedicated scheduler earns its place.
— Christian Ofori-Boateng
Fixing common sending problems
Authentication fails with basic auth
If you see 550 5.7.30 after the cutoff, the tenant is blocking basic auth for client submission. Your options are to move the sender to OAuth, switch it to an SMTP relay connector if recipients are internal, or temporarily re-enable basic auth for that mailbox and set a date to remove it.

The test email arrives, scheduled reports do not
Check whether the scheduler runs under a different service account than the one you tested with, and whether the report exceeds the size limit. For Power BI Report Server in particular, see our troubleshooting page on email subscriptions that are not working.
Reports land in spam
External recipients judge the sending domain, not your report. Make sure the From address uses a domain with proper SPF, DKIM and DMARC records, and avoid sending large attachments from a brand-new mailbox.
Tableau or SSRS reports stop after a password change
A stored credential in the scheduler is the culprit. Update it where the SMTP account is saved. Guides on scheduling SSRS reports to email and emailing Tableau reports as PDF attachments show where that account is configured.
Automating report delivery with PBRS, ATRS and CRD
If your reports are scheduled through Power BI, SSRS, Tableau or Crystal Reports and you are tired of SMTP and subscription limits, this is what we build for. PBRS for Power BI and SSRS, ATRS for Tableau and CRD for Crystal Reports schedule, personalize, export and deliver reports to email, cloud, database and collaboration destinations, with data-driven schedules, event triggers and automated error handling. Software is licensed as a subscription or a perpetual license, and the software runs on-premises.
Read how PBRS exports Power BI reports without Power Automate, follow the tutorial on weekly scheduled Power BI reports to PDF, or see all products and start a trial on the ChristianSteven Software site.
FAQ
What are the SMTP settings for Office 365?
Use smtp.office365.com, port 587, a secure connection, and the full email address of a licensed mailbox as the account name. Reporting tools such as Telerik Report Server document the same server and port. Port 25 relay is a separate option that authenticates by IP address.
Does Office 365 still support SMTP?
Yes. As of this writing, SMTP client submission still works, but basic authentication for it is scheduled to be disabled by default in late December 2026 on existing tenants. OAuth, relay connectors and the Graph API remain supported routes.
How do I find the SMTP AUTH report in Office 365?
Open the Exchange admin center, then go to Reports, Mail flow, and choose SMTP AUTH clients. You can export the data from that page. Microsoft's documentation for the report explains the columns.
How can I get an email activity report in Microsoft 365?
In the Microsoft 365 admin center, go to Reports, then Usage, then Email activity. It shows sent, received and read counts per user. For tracing a single message, use message trace in Exchange Online instead.
Sources
- End of Basic Auth SMTP on Exchange Online: timeline and migration guide, CaptainDNS
- Microsoft 365 Turns Off SMTP Basic Auth in December 2026, Netsys Group
- How to view report for SMTP authentication in Office 365, Oryon
- SMTP AUTH clients report discussion, Reddit r/Office365
- Office 365 Reporting: Types, Limits and What It Misses, EmailMeter
- Configuring Report Server SMTP, Telerik
- Reporting in Grafana, Grafana Labs
- Excel managementrapportage, KOOT Finance
