Say goodnight
to your last
Exchange Server.
The SMTP relay for Microsoft 365. Your printers, scanners and apps keep sending – the server finally sleeps.
Not released yet – preview coming soon.
Sendman is the policy-enforcing SMTP relay for Microsoft 365, built for every printer, scanner and application that only speaks plain SMTP. It authenticates them against Microsoft Entra ID, fences them in by IP address and sender policy, and hands the mail to Exchange Online or the delivery service you already use — so the last on-premises Exchange Server has nothing left to do.
THE PROBLEMThe Server That Only Exists for the Printers
In almost every organization there is one Exchange Server left. Nobody reads mail on it. It is still running because a scanner, a nightly ERP export, and an alarm panel need to send — and the only thing any of them knows how to do is open a port and authenticate.
Four Dead Ends
Everyone has tried at least one of these. None holds up.
- 01
Keep the Exchange Server running
You are patching a mail server so a scanner can email a PDF. Every Exchange advisory is now your weekend.
Dead end: The server stays - 02
Open an unauthenticated internal relay
Anything that can reach the connector can send as anyone in your domain. No identity, no sender control, nothing to audit afterwards.
Dead end: Control is gone - 03
Put one mailbox password on 200 devices
It cannot be rotated without visiting every device, and a copy of it is on a sticker in the copy room.
Dead end: Control is gone - 04
Point everything at a bulk sending service
Delivery works. Nothing on the way checks who is sending as whom, or to whom, and the shared API key is as good as a domain-wide send permission.
Dead end: Control is gone - 05 · The way out
All four are the same trade. You either keep a mail server alive for the sake of the devices, or you give up control over who is allowed to send as whom. Sendman is the option that refuses the trade.
Way out: Server gone, control kept
Replace the Relay Function of On-Premises Exchange
Route to Exchange Online or External Delivery Services
Legacy SMTP Logins, Modern Identities
Separate Routing by Domain
Keep Your Existing Setup
One Session, End to End
Sendman sits in the SMTP conversation itself, not beside it. There are five moments where it decides something — pick one and watch which part of the exchange it governs.
Three Policies. Change Who Is Knocking.
This is the real evaluation order, running live: the allow list, then the policies that apply to this identity and this address, then the sender, then every recipient on its own. Change any of the four and watch what the relay answers.
Policy 10 is scoped to svc-scan@contoso.com from 198.51.100.24. scan@contoso.com matches its allowed senders and accounting@contoso.com matches its allowed receivers, so Sendman opens its own session to the backend and hands the message over unchanged.
The policies being evaluated
Global allow list: 198.51.100.16 – 198.51.100.31, 192.0.2.128 – 192.0.2.143
svc-scan@contoso.com, from headquarters
senders: scan@contoso\.com
receivers: .*@contoso\.com
mfp-3f, from anywhere on the allow list
senders: .*@contoso\.com
receivers: .*@contoso\.com
Any device at headquarters, no sign-in
senders: noreply@contoso\.com
receivers: .*@contoso\.com
Policies are selected by scope, then reduced to the lowest priority number that applies. Policies that tie on priority are merged, so a device can be granted rights from several rules at once.
Exchange's Last Job, Plus Control
Legacy devices need three things to keep working: a port to talk to, an authentication mechanism they understand, and permission. Sendman gives them all three, and puts the third one under your control.
Entra ID authentication
Usernames and passwords keep working as they are, validated against Microsoft Entra ID – no app registration, no consent, nothing to change in your tenant, and no directory to synchronise.
Hybrid logins work as they are
A device configured years ago with
CONTOSO\svc-scankeeps working. Sendman resolves the domain login to the right Entra user, so nothing has to be retyped on the device and nobody has to visit the printer.
A credential vault of your own
For devices that should not carry a directory identity, issue a Sendman credential instead. Stored with AES-256-GCM, compared in constant time, never displayed again – and the same goes for your backend password.
LOGIN, PLAIN and NTLM
The three mechanisms old hardware actually implements — including NTLM, which almost nothing else in front of Microsoft 365 will still speak. Each one can be switched off independently.
A global IP allow list
Ranges are evaluated the instant a connection is accepted — before the SMTP greeting, and on port 465 even before the TLS handshake. Everything else never reaches the conversation, let alone the authentication.
Policies with priorities
Scope a rule to a username, an IP range, or both. The lowest priority number that applies wins; rules that tie are merged, so a device can inherit rights from more than one.
Sender and recipient control
Regular expressions on both sides, enforced at
MAIL FROMand at everyRCPT TO. Nobody sends as the CEO, and nothing becomes an open relay by accident.
Anonymous relay, on purpose
Some devices simply cannot authenticate. They get a narrow lane that has to be switched on deliberately, is scoped to an IP range, and is still bound by sender and recipient rules.
TLS on every port
Implicit TLS on 465, STARTTLS on 25 and 587 – with a certificate issued for you or one you bring yourself, renewed without a restart. Onwards to the backend, the session is encrypted wherever the backend supports it.
Any backend you send through
Exchange Online without SMTP AUTH – unaffected by Microsoft's Basic Authentication retirement – or Azure Communication Services and other transport services. Switching is a setting, not a redeployment.
Live on the next connection
Configuration is read fresh for every session that opens. Edit a policy and the next device to connect is already governed by it. No restart, no change window, no cache to wait out.
Metrics you can alert on
Every session leaves a trace – authentications, deliveries, session times – searchable in the portal and ready to alert on. A device that stopped sending is a query away, not a support ticket.
Roles that mean what they say
Viewers see every rule and change none; admins change configuration. Enforced by the service on every request, and every entry records who created it — policies also record who last changed them.
Searchable event log
Every authentication failure and policy violation, filterable by user, address, sender and recipient, with the rule that rejected it named in the entry. “Why did that bounce” takes one search.
On the roadmapSniff Mode
Open a capture window and watch exactly what a device presents: the source address, the username it offers, the sender it claims. For the printer nobody has the password for and no vendor still supports.
Specifications
The names and numbers an admin asks for before the first test mail.
Connectivity
- Ports
- 25 and 587 with STARTTLS, 465 with implicit TLS
- Certificate
- Issued for you or bring your own, renewed without a restart
- Allow list
- IPv4 address ranges, up to 16,384 addresses each
Authentication
- Mechanisms
- LOGIN, PLAIN, NTLM
- Identity sources
- Microsoft Entra ID (including hybrid DOMAIN\user logins), Sendman credential vault
- Vault encryption
- AES-256-GCM
Policies
- Scope
- Username, IP range, or both
- Priorities
- Lowest number wins, ties are merged
- Sender and recipient rules
- Regular expressions, enforced at MAIL FROM and every RCPT TO
- Anonymous relay
- Per policy, bound to an IP range
Delivery
- Backends
- Exchange Online (no SMTP AUTH), Azure Communication Services, other SMTP transport services
- Message size
- Up to 25 MB per message (your backend may allow less)
- Handling
- Passed through unchanged, no queue, no copy kept
Operations
- Configuration
- Platform Portal, live on the next connection
- Roles
- Viewer, admin
- Telemetry
- Searchable in the portal
- Included
- All updates, incident support
- Certification
- Our development and operations teams are certified according to ISO 27001
Why Retire the Last Exchange Server
Once Sendman has taken over the relay, the server can go. Here is what you gain.
A smaller attack surface
On-premises Exchange is one of the most attacked workloads there is. Once the last server is gone, there is no Exchange CVE left to patch on a weekend and no zero-day aimed at your perimeter.
Nothing left on the internet
OWA, ECP, Autodiscover and the Exchange web services disappear from your edge. One less entry point for initial access, one less target for remote code execution.
No more Exchange patching
No cumulative updates and security updates to test, install and monitor, no maintenance windows for them, and no Exchange Server left to fall behind when the next critical fix lands.
No next migration
Exchange 2016 and 2019 lost support in October 2025, and Subscription Edition is the next upgrade on the calendar. Without a server, there is no next migration to plan, fund or survive.
One privileged system less
Exchange is deeply wired into AD and highly privileged. Removing it takes a prime credential-theft target off the table, and after the SOA transfer most of its footprint leaves AD too.
Less to operate
No monitoring, backup, certificates, storage or VMs to run for Exchange, and no separate disaster recovery concept to write, test and keep current. One workload fewer on every checklist.
A cleaner architecture
Messaging is Exchange Online, full stop. No hybrid special case, and fewer components to check when mail flow, Autodiscover, recipients or authentication misbehave.
Less know-how to keep
On-premises Exchange expertise is getting scarcer and pricier. Without a server to look after, you no longer have to retain it, or buy it in when the one person who has it is on holiday.
Clearer roles, lower cost
Less infrastructure, operations, backup, monitoring and admin effort. Microsoft runs the platform, you administer Exchange Online, and the line between the two is finally clear.
Three Steps, and One Server You Can Switch Off
- Point Sendman at your backendPoint Sendman at your backendChoose Exchange Online, Azure Communication Services, or whichever host you already send through, and enter what it needs. One form in the portal, and no redeployment when it changes.
- Let the devices in, and say what they may doLet the devices in, and say what they may doAdd the ranges they connect from, issue vault credentials to the devices that should not carry a directory identity, then write the policies for who may send as what, and to whom.
- Repoint DNS, retire the serverRepoint DNS, retire the serverPoint the hostname your devices send to at Sendman instead of the Exchange Server. Ideally, that is all it takes – not a single device is touched, and the Exchange Server has nothing left to do.
The Questions That Come Up First
What admins ask before the first test mail goes through.
01Does Sendman store our email?
No. It proxies the SMTP session and forwards it as it arrives. There is no mailbox, no queue, no spool and no archive, and the message itself is passed through unchanged, headers included. The only thing Sendman keeps is your configuration.
02Do we have to register anything in our Entra tenant?
No. Sendman validates device credentials against Microsoft Entra ID with no app registration, no consent and nothing to change in your tenant. Hybrid logins such as CONTOSO\svc-scan work as they are.
03What about multi-factor authentication on those accounts?
Neither gets in the way. A vault credential never touches your directory, so there is nothing to prompt for. Entra ID accounts work as well: multi-factor authentication and Conditional Access do not stand in the way, even with strict policies, and the device never sees a prompt. What an account may send as, and to whom, is not a mailbox permission in Exchange Online but a Sendman policy: sender and recipient rules decide, for vault credentials and Entra ID accounts alike.
04What if a device cannot do TLS at all?
It can still connect on a plain port, and identity, IP and policy are enforced in exactly the same way. Whether you accept an unencrypted first hop from that device is your decision; the allow list keeps it to your own egress addresses, and from Sendman onwards the session is encrypted wherever the backend supports it.
05What happens to SPF, DKIM and DMARC?
They belong to the domain you send from and are handled by the backend that actually delivers, Exchange Online or Azure Communication Services. Sendman does not rewrite your envelope or your headers, so whatever you have set up for that backend keeps working exactly as it does today.
06What happens if Sendman cannot reach its configuration?
Connections are refused with a temporary “service not available” reply that tells a well-behaved sender to hold the message and retry, so a storage hiccup delays mail rather than losing it.
07Can we keep Exchange Online as the backend?
Yes. Many organizations keep Exchange Online as the delivery path and use Sendman for the authentication and policy layer their devices need. The backend can be changed later without touching a single device.
08Where does our configuration live, and who can see it?
In storage isolated to your tenant. Credentials are encrypted before they are written. Access to the portal comes from your platform tenant, viewers see every rule and change none, admins change configuration, and every allow-list entry, policy and credential records who created it.
09How do we find out what a device is actually sending?
Every authentication failure and policy violation lands in the searchable event log, with the rule that rejected it named in the entry, and the reply the device receives tells you which gate refused it. Sniff Mode, a capture window that shows exactly what a device presents, its source address, the username it offers and the sender it claims, is on the roadmap.
Meet Us in Person
Sendman is on the road this autumn. Come by, bring your printer story, and see the relay in action.
Workplace Ninja Summit
Community conference in Baden on Microsoft Endpoint Management and Security
it-sa
Meet us again this year at Europe's leading trade fair for IT security
Cloud-Based RADIUS Service RADIUSaaS
Cloud-Native Certificate Authority SCEPman
