Client SMTP submission
This is the method most setups actually want. The device authenticates as a licensed mailbox on smtp.office365.com, port 587, with STARTTLS at TLS 1.3 or 1.2, per Microsoft's device and application guide.
It can relay to the internet, so external recipients are reachable, and messages are saved to the mailbox's Sent Items.
Two constraints define it. Throughput is capped at 10,000 recipients per day and 30 messages per minute, and SMTP AUTH must be enabled on the mailbox, which Microsoft disables by default for organisations created after January 2020.
Basic authentication on this path is scheduled for deprecation in favour of OAuth, which makes it a poor foundation for a long-lived integration.
SMTP relay via connector
This is the method the term usually refers to. The device connects to the tenant's MX endpoint, in the form yourdomain-com.mail.protection.outlook.com, on port 25, and an inbound connector in Exchange authenticates it.
The connector authenticates by TLS certificate or by static public IP address. Microsoft recommends the certificate approach, and dynamic IPs are not supported for the address-based option.
Its advantages over client submission are real. No licensed mailbox is required, sending limits are higher, and mail can be sent from any address in an accepted domain even where no mailbox exists behind it.
The constraints are equally real. Port 25 must be open outbound, which many networks block. The source cannot be a third-party hosted service such as a cloud VM. And the sending IP being blocklisted disrupts mail flow directly.
An SPF record listing the sending IP is required, or messages route to Junk.
SPF alone is the floor, not the bar. George, our CEO, documents the real requirement in his Email Marketing Bible: SPF, DKIM and DMARC aligned at a policy of quarantine or stronger, which Outlook itself requires once a sender passes 5,000 messages a day.
Direct Send
Direct Send also uses the MX endpoint on port 25, with no authentication and no connector.
It only delivers to recipients inside your own organisation. Mail to external addresses is rejected outright, which rules it out for anything customer-facing.
Microsoft has stated it is working toward disabling Direct Send by default, so building on it now is building on a deprecation path.
Choosing between them
The decision follows from three questions. Do you have a licensed mailbox to send as, is the sending host on a static IP you control, and do recipients sit outside the organisation.
A licensed mailbox with modest volume points to client submission. An on-premises device with a static IP and internal-plus-external recipients points to the connector. Internal-only mail from a device that supports nothing modern points to Direct Send.
None of the three is a good fit for application mail at volume. All are designed to let an organisation's own equipment send through infrastructure it already pays for, and none reports per-message delivery events, bounce classification or suppression state back to the sending application. That reporting layer is what a submission service authenticating as your own verified domain provides.
We see the Microsoft side of this constantly. We identify and record the email stack behind every customer domain, microsoft included, so when a Microsoft-stack account hits a relay problem we know before the support ticket does. One boundary we hold either way: cold outreach infrastructure is not marketing email. Different domains, different mailboxes, different volumes, different deliverability rules, and none of the three Microsoft paths above is the place for either job at volume.