nanoPost

The WordPress Email Authority

Microsoft 365 SMTP relay and Direct Send on WordPress: what the AUTH retirement changes (and doesn’t)

Last reviewed/updated:

Microsoft’s announcement that it is disabling password SMTP for Exchange Online has WordPress operators on every M365 tenant checking whether their site is on the affected path. The quickest test is the WordPress mailer settings. If the SMTP username and password fields are blank, and the host field is either blank or points at a name ending in mail.protection.outlook.com, the site is not on the retiring path.

The site is on one of two other Microsoft mail flows: SMTP relay via an inbound connector, or Direct Send from WordPress to Office 365. Neither uses SMTP AUTH; the end-of-December 2026 retirement of SMTP AUTH Basic Authentication for client submission does not disable either one. Neither is entirely safe, though. Direct Send has separately been narrowed by Microsoft to internal-tenant recipients only, which quietly breaks any WordPress site using it to email people outside the organisation. That change is the more urgent one for the Direct Send cohort. If the SMTP form does have a username and password after all, the migration hub for the SMTP AUTH path is the right page.

Recognise which flow you are on

Both flows look almost identical from the WordPress side. Both are anonymous, both use port 25, and both send to Microsoft’s tenant MX endpoint. The difference is whether an inbound connector has been configured in Exchange Online to trust the WordPress server.

SMTP relay via an inbound connector

The WordPress-side signals:

  • Mailer plugin’s SMTP host field is either blank or contains something of the form yourdomain-com.mail.protection.outlook.com (the tenant’s primary domain with the dots replaced by hyphens, followed by .mail.protection.outlook.com).
  • Port is 25.
  • Username and password fields are blank.
  • Encryption is enabled (STARTTLS or TLS depending on the plugin’s naming); Microsoft accepts port 25 with STARTTLS.
  • The From address is a mailbox on the tenant’s own accepted domain, not a Gmail or personal address.

The tenant-side confirming signal, for the operator with Global Admin access: in the Exchange admin center, Mail flow → Connectors, an inbound connector exists whose authentication is either “IP address of the sending server” (scoped to the WordPress server’s static public IP) or “subject name on the certificate that the sending server uses” (scoped to a TLS certificate the site presents).

Microsoft’s canonical description of this flow is the SMTP relay section of How to set up a multifunction device or application to send email using Microsoft 365 or Office 365.

Direct Send

The WordPress-side signals are the same as the connector flow, with one addition:

  • No inbound connector is configured on the tenant.

The tenant-side confirming signal: no inbound connector is present in the Exchange admin center, and mail sent from the WordPress site to an address on the tenant’s own domain still arrives. Microsoft describes this flow in the Direct Send section of the same page.

One thing to check before trusting either signal. WordPress plugins can be reconfigured at runtime through filters (wp_mail_smtp_options, fluent_smtp_options, phpmailer_init) or through environment variables that render as blank in the admin screen. Empty credential fields in the mailer UI are not proof of an unauthenticated flow. If in doubt, run the plugin’s Test Email tool with debug logging enabled and read what actually goes on the wire.

Why the AUTH retirement does not apply here

Microsoft’s end-of-December 2026 change disables SMTP AUTH Basic Authentication for client submission. That is the authenticated path on port 587 (or port 25 with authentication) used by WordPress mailer plugins that carry a mailbox username and password. Both SMTP relay via connector and Direct Send are anonymous submissions to the tenant MX endpoint on port 25 and present no mailbox credentials at all.

Server authentication does still happen on the relay flow, just not with mailbox credentials: Microsoft checks the source IP against the inbound connector’s scope, or validates the TLS certificate the WordPress server presents against the connector’s subject-name rule. On Direct Send there is no such check; Microsoft acts as the tenant’s own inbound MX and evaluates the sending domain’s SPF, DKIM, and DMARC as the trust signal instead. Microsoft’s scope description is on the Enable or disable SMTP AUTH in Exchange Online page; the migration hub carries the full timeline.

Not affected by the AUTH retirement is not the same as not affected by anything. Both flows have their own failure modes, and Direct Send in particular has been narrowed by Microsoft in the last year.

What actually would break each of these two flows

SMTP relay via an inbound connector

The connector-relay flow can break in four ways.

Site public IP changes. For IP-scoped connectors, moving hosts, changing upstream network, or placing the site behind a new CDN or WAF that rewrites the source IP breaks the connector match. Symptom is a 550 5.7.64 Relay Access Denied (or a close variant) in the mailer’s error log. Fix is a tenant admin updating the connector’s IP scope.

TLS certificate on the sending host changes. For certificate-based connectors, the subject or SAN must still match the accepted-domain value entered when the connector was configured. Rotating a Let’s Encrypt certificate is fine as long as subject and SAN stay the same; changing the cert’s identity is not.

Tenant transport rules. An admin-added rule under Mail flow → Rules can reroute or reject connector mail without touching the connector itself. A “reject mail from outside the org unless X” rule is a common cause. Diagnosis lives in the Exchange admin center; not visible from the WordPress side.

The connector product itself. Microsoft has announced no retirement date for inbound connectors, and the relay flow has been stable for years. Long-tail risk only, worth naming once so the reader knows to watch the Exchange Team blog.

Direct Send

Three risks apply to Direct Send. The first is already active.

External delivery is being cut. Microsoft’s current documentation states that Direct Send delivers to Microsoft 365 or Office 365 recipients only, and that mail to recipients outside the tenant is rejected. Enforcement has been rolling out through 2026 rather than flipping on all at once. A site that still sees password resets landing at Gmail today is on rolling enforcement, not exempted. Any WordPress site whose users are not all in the same M365 tenant needs a different mail flow now, not in December; the migration paths in the hub apply either way.

550 5.7.515 Access denied. For sites where enforcement of the internal-only restriction has not yet landed and Direct Send mail to external recipients is still reaching consumer Outlook addresses (@outlook.com, @hotmail.com, @live.com, @msn.com), a separate Microsoft check applies. Microsoft’s inbound-authentication enforcement on those domains has been live since May 2025 and requires the sending domain to publish SPF and DKIM records, publish a DMARC record (any policy, including p=none), and pass DMARC by aligning at least one of SPF or DKIM with the 5322.From domain. Microsoft has signalled stronger DMARC-policy enforcement (p=quarantine or p=reject) as the next step; today, missing SPF or DKIM is the more common cause of 5.7.515 on a WordPress transactional sender. Direct Send sends from the site’s own IP under the tenant’s domain, so the consumer-Outlook side judges the message entirely on that domain’s records. A site whose SPF record does not include the sending server, or whose domain does not sign with DKIM, will hit 5.7.515 on any password-reset to a Hotmail user. Microsoft’s reference is Fix NDR error 550 5.7.515 in Outlook.com; a nanoPost decoder page is coming.

Tenant transport rules. Same as the connector case: a rule added to inspect or reject anonymous mail can block Direct Send before it leaves the tenant edge.

What to do now

Confirm the flow using the recognition section above. If neither matches, and the SMTP form does hold a username and password after all, the site is on the AUTH-retirement path and the migration hub is the right page.

For SMTP relay via a connector, note where the connector’s IP or certificate scope is documented on the tenant side. That is the record needed when the site’s public IP changes or its certificate rotates.

For Direct Send, check the user base. If the WordPress site sends any mail to addresses outside the tenant, plan a migration now rather than in December. Microsoft’s documented behaviour is that those messages are being rejected; the change is live, not scheduled. Sites that use Direct Send only for internal-tenant notifications can keep running, and should still verify SPF, DKIM, and DMARC on the sending domain.

When Microsoft announces a removal date for SMTP AUTH in the second half of 2027, per the current timeline, re-read the hub to confirm the “not affected” verdict still applies.

Related