SMTP for Microsoft 365 — sending limits without the workaround
Microsoft 365 is excellent for the mail your staff write themselves, but it is not a sending platform. Hard per-mailbox limits apply to the number of recipients and messages per day, and those limits are deliberate: they protect the platform's shared reputation.
Applications that send automatically — a webshop, a CRM, an accounting package, a newsletter — therefore do not belong in a Microsoft 365 mailbox. You move those to a relay built for it, while your people keep working in Microsoft 365.
Why it goes wrong without a relay
It rarely goes wrong straight away. It goes wrong on the day you send slightly more than usual: the limit is reached, the remaining messages are refused, and you only find out when a customer calls. A separate route for automated mail takes that spike away from your staff's mailboxes.
Setting up SMTP in Microsoft 365
Collect your details
Log in to your 2mail account and retrieve your SMTP server, username and password there.
Fill them in inside Microsoft 365
You change nothing about Microsoft 365 itself. In the application that sends, you replace the Microsoft SMTP details with those of 2mail. Use a sender address on the same domain if you like, so the recipient sees no difference — only the route underneath changes.
Authenticate your domain
Make sure SPF, DKIM and DMARC are set correctly for your domain, so recipients can verify that the mail comes from you.
Test
Send a test message to an address at a major provider and check that it arrives in the inbox and not in the spam folder.
The fields Microsoft 365 asks for
Every platform names them slightly differently, but it is always the same five. The actual values are tied to your account and can be found in your 2mail account — take them from there, so you are sure to use the right ones.
| Field | What you enter |
|---|---|
| SMTP server (host) | The server name from your 2mail account. |
| Port | The port that matches your chosen encryption; your account shows which one. |
| Encryption | TLS. Never send unencrypted — your credentials would otherwise travel in plain text. |
| Username | The SMTP login of your 2mail account. |
| Password | The matching password. Never use the password of an employee's mailbox. |
Which emails Microsoft 365 sends
As soon as the relay is set up, all of these run through 2mail — you do not have to configure them one by one.
Pitfalls with Microsoft 365
One domain, two sending routes
If you send from the same domain through both Microsoft 365 and a relay, <strong>both</strong> must appear in your SPF record. Forgetting one makes exactly that traffic fail the check.
Do not use a mailbox password
A relay gets its own login. Never use an employee's username and password: those expire, change when someone leaves, and on a leak give access to the entire mailbox.
Replies have to land somewhere
If an application sends from an address nobody reads, customer replies disappear. Set a sender that leads to a real mailbox or group.
A different platform?
SMTP is a standard protocol: any system that speaks SMTP — a CRM, an ERP, a custom application or a server — can send through 2mail using the same five fields.
