Switch each site over once, then bill it every month.
An agent on each customer's network accepts SMTP with a username and password and delivers through that same customer's Microsoft 365 tenant over OAuth2. Every site is visible and managed centrally in the cloud.
Two sites are free of charge, one for your own office and one to try at a customer. Payment details are only needed from the third one, and billing then covers all of them.
Deadline
Microsoft has not named a calendar day, only “end of December 2026”. Administrators can switch SMTP AUTH back on afterwards, and Microsoft does not announce the final date until the second half of 2027.End of 2026
At the end of December 2026 Microsoft turns Basic Auth for SMTP AUTH off by default in existing Microsoft 365 tenants.
Affected
- Multifunction printers and scanners
- ERP and merchandise management
- Monitoring and alerting
- NAS and backup
Devices that sign in with a username and password get an error instead of a delivery from that point on.
Margin per month
Check the arithmetic with your own numbers
Two figures are enough. We do not suggest a resale price; what your market will pay is something you know better than we do.
The amount you charge your customer.
Fill in both fields and the result appears here.
- What you pay us per month
- —
- What you invoice per month
- —
- Your contribution margin per month
- —
what you pay Mailwerk
what your customers pay you
fill in both fields
Under the German small-business rule (Section 19 UStG) we do not charge VAT. The amount shown is therefore also the amount invoiced.
| Sites | Per site per month |
|---|---|
| 1 to 49 | €10.00 |
| 50 to 199 | €8.00 |
| 200 and above | €6.00 |
Billed monthly, cancellable monthly, per site. Two sites are free of charge; from the third one on, every site is billed.
This table is what you pay. What your customer pays is in your quote, not in our price list.
Setup
How a site gets added
Three steps per site. You create customers and sites in the cloud and enrol agents there; the mail path from the device to Microsoft 365 then runs without you.
Create the customer and the site
In the platform you create the customer, and under it every site that gets an agent. The customer brings its own Microsoft 365 tenant: an app registration there, with the application permissions Mail.Send and Mail.ReadWrite, restricted to the mailbox that is meant to send. The site is also the unit that gets billed.
Install the agent and enrol it
Mailwerk Relay is a single program with no further dependencies, on a machine or server on the customer's network. On first start it registers itself against its site with an enrolment key, keeps its data in its own directory and generates a certificate covering its hostname, its LAN addresses and loopback. Devices that verify certificates need that certificate imported, or you can supply your own.
Point the device at it
On the device, set the server address to the agent and enter the local credentials, port 587 with STARTTLS or 465 with implicit TLS. Whatever sender address the device is configured with does not matter: the agent uses the address of the login, so a misconfigured or compromised device cannot send as anyone else.
The path of a message
The customer's network
Device
Mailwerk Relay
The customer's tenant
Microsoft 365
Recipient
No email leaves your customer's network in our direction.
In the cloud
What you see across every customer
One view across every customer, every site and every agent, instead of thirty local interfaces with thirty logins.
One estate, not one customer at a time
Every customer, every site, every agent and its state in one list. Without it the same information sits in as many Exchange admin centres as you have customers, and nobody ever sees it together.
The failure reaches you before the phone call does
When an agent stops delivering or a tenant loses its permission, it lands with you and not with the customer. Otherwise a scanner that has sent nothing since Tuesday is a ticket on Thursday.
Evidence you can put in front of the customer
What a site sent in a month, what failed and what it failed on. Anyone who has to explain a line on an invoice needs those numbers, and without this view nobody has them.
Delivery does not depend on us
The agent delivers under its own power. If billing for a site ends or the connection to the platform breaks, remote administration and the enrolment of new sites stop; delivery carries on. A billing dispute between you and us must never switch off your customer's alert emails.
Where we stop
Why not the free Microsoft connector?
Microsoft has its own answer for exactly this case, and it costs nothing: an inbound connector in Exchange Online that recognises the device by a static public IP address or by a certificate. We think pretending it does not exist would be the wrong approach. For a single customer with a static public IP address it is the right answer.
| Aspect | Microsoft connector | Mailwerk |
|---|---|---|
| Cost | Free, included in the Microsoft 365 subscription. | 10 EUR per site per month for 1 to 49 sites, 8 EUR from 50, 6 EUR from 200. |
| Requirement | Per customer, a static public IP address that this customer shares with no other organisation, or a certificate on every device. Microsoft does not support dynamic addresses for this route, and dynamic is what branch offices and small businesses mostly have. | No static address and no certificate on the device. The agent authenticates itself to Microsoft using OAuth2; whichever public address the line currently has makes no difference. What it needs instead: an app registration in the customer's tenant and a machine on the network to run on. |
| Path of the message | From the device straight to Exchange Online. | From the device to the agent on the customer's network, from there to Exchange Online. In both cases the message ends up in that customer's tenant. |
| Administration | Per tenant, in that customer's own Exchange admin centre. Each customer is set up separately, and none of those setups is visible from anywhere else. | Centrally for every customer, in one account. The agent still has a local interface of its own; day to day you do not need it. |
| When something breaks | Nothing tells you that a connector has stopped working. You hear it from the customer. | The agent keeps the message in its queue, retries, and writes its logs on site. The failure surfaces centrally with you, rather than when the customer calls. |
If a site has a static public IP address, use the Microsoft connector. It costs nothing, it comes from the vendor, and you do not need us for it. Across thirty customers on lines whose addresses change, with devices that also send outside the tenant, the arithmetic is different: thirty setups in thirty places, no view that holds them together, and no signal when one of them stops working. That is what Mailwerk is for.
This table sets two routes side by side; in practice there are five. A firmware update to OAuth, Microsoft High Volume Email for devices that only send to recipients inside their own tenant, and a new device are just as likely to be the answer, depending on the line, the recipients and the model. Which one fits when is in the guide to the Basic Auth shutdown.
Data
Where the data sits
Processors we use
One processor, and no more: Hetzner (server and hosting, Germany). No provider outside the EU is involved. Exactly who processes what is set out in the privacy policy.
Hosting in Germany
This website and the platform behind it run on our own server in a Hetzner data centre in Germany.
This site stores nothing about you
There is no form here, no sign-in and no database. Beyond the server log data every web server writes, your visit creates no record at all. What you create in the cloud is separate from this and has a privacy policy of its own.
No cookies, no third-party scripts
This page sets no cookies and loads nothing from third-party servers. The calculator above works out its numbers in your browser and sends us nothing. That is why there is no cookie banner here. You can check it in your browser's developer tools rather than taking our word for it.
Your customers' mail is not part of it
The cloud knows your customers, their sites and the billing. It knows nothing about the messages an agent delivers on a customer's network, because none of them ever reach it.
Your customer's data stays with your customer
The agent keeps its data in a SQLite file on the machine inside the customer's network: the queue, the devices' local credentials and its own log. The platform holds your customers, their sites and the state of the agents - no message content, and credentials only sealed, in a form we cannot read ourselves.
Questions
Frequently asked questions
What happens to my customers if I stop paying?
Your customer sees nothing of it. Whatever is in dispute between you and us must not switch off an end customer's alert emails, so delivery is not coupled to it. What ends is remote administration and the enrolment of new sites. Billing runs monthly and per site, and you can cancel at the end of any month: lose a customer and you end that one site, not a contract covering all of them. The prices are on the pricing page.
What happens to my customer's mail if the agent or the line goes down?
The agent answers the device with 250 OK only once the message is on disk with an fsync and its queue row is committed. From that moment the device may delete its copy. If Microsoft 365 cannot be reached, the message stays in the queue and is retried at growing intervals; after 24 hours without success it is dead-lettered, and its body is kept for 30 days so it can be sent again once the cause is fixed. Failures are recorded with the plain-text reason, not just a status code. If the agent itself is down it accepts nothing: the device gets a connection error and reports it, exactly as it would with any other SMTP server. Messages already accepted carry on after a restart. None of this depends on the platform.
Can you see my customers' mail?
No, and not because we promise it: the content never reaches us. The message goes from the device to the agent on the same network, and from there straight into that customer's Microsoft 365 tenant. The logs sit as files on the machine the agent runs on. State, counters and error messages are meant to reach the platform, so that a failure surfaces with you rather than with your customer; the content of the messages is no part of that, and nothing about it would work better if it were.
What does my end customer see of you?
Nothing, unless you want them to. The platform has no end-customer accounts; the people signed in are you and your technicians. Reports and notifications to the customer go out under your name and your logo, and so does the agent's local interface.
Are my customers isolated from each other?
Yes, and the isolation that matters most sits outside the platform. Every device login on an agent is bound to exactly one app registration, and everything submitted through that login goes to that one tenant. An agent can hold several registrations - the usual setup is one agent per site, holding its own customer's credentials - but no login can move to a different tenant. No shared outbound mailbox carries several customers' mail. Inside the platform, every record belongs to exactly one customer under your account as well.
Can I run the platform on my own hardware?
Yes, as your own installation for a single company, sharing nothing with anyone else's. It is not billed per site but per partner: annually in advance, at a price we agree with you. What has to be settled depends on your environment, which is why the pricing page carries no number for it.
What exactly happens at the end of December 2026?
Microsoft disables Basic Authentication for SMTP AUTH by default in existing Microsoft 365 tenants. An administrator can switch it back on afterwards for the time being; the change is a new default, not yet a removal of the feature. In tenants created after that date, this authentication method is unavailable by default. Microsoft intends to announce the final removal date in the second half of 2027; that date is not known today. The hard deadline is therefore later than the tone of most articles suggests - the work across thirty sites stays the same either way. All the dates, and what follows from them, are in the shutdown overview.
Does this work with Google Workspace?
No. At first release Mailwerk delivers through Microsoft 365 only. That is where the shutdown happens, and where the customer tenants in question sit. Google Workspace is intended as a later step, but is not part of the first release. If your customers are mostly on Google, Mailwerk is not for you today.
Which permissions does the app registration in my customer's tenant need?
Mail.Send and Mail.ReadWrite as application permissions, with admin consent, one app registration per customer tenant. Mail.Send alone is not enough: any attachment large enough to need an upload session is created as a draft first, and creating a draft requires Mail.ReadWrite. With scans that is the normal case. Granted tenant-wide, Mail.ReadWrite means read and write access to every mailbox in that customer's tenant, which is not what you want: restrict the application to exactly the mailbox that is meant to send, using RBAC for Applications or an Application Access Policy. Step by step instructions are in the Entra ID setup guide.
Get started
Two sites free of charge, no payment details
Create a customer, roll the agent out, repoint the device. Two sites are free of charge: one for your own office, one to try at a customer. From the third one on it is billed, for every site, monthly and cancellable monthly.