Mail and web egress. Operated, not purchased.
We run the mail path and the web egress on our own systems — our own mail stack and our own forward proxy instead of a bought-in gateway. This is not a catalogue product. It is the layer we work on, and the reason we can tell you how it behaves.
Why this page does not describe a product
We used to sell this layer as a package — email security here, web proxy there. It never matched what we actually do. Customers do not buy a filter, they hand over an area of operations. So we describe what we can do, rather than what used to sit in a price table.
The mail path
We run mail ourselves, on our own stack built on mailcow — Postfix as the MTA, Dovecot for IMAP and delivery, Rspamd for filtering and signing. On top sits a service we built and use ourselves: it evaluates incoming messages with language models where rules and reputation lists run out — messages that are formally clean but carry a request nobody was expecting.
The more important part is unglamorous: sender authentication has to be right. SPF, DKIM and DMARC all the way to actual enforcement, MTA-STS and TLS reporting for the transport path, DANE where the zone is signed, ARC for paths through lists and forwarders. It is legwork, and in almost every mandate it is the same story: a DMARC record exists, it has said p=none for three years, and nobody reads the reports.
The web egress
For outbound web traffic we run our own proxy with SOCKS and HTTPS support, rather than operating Squid or an appliance gateway. The reason is the same as for the mail stack: we want to decide what terminates, what is passed on and what is logged — and we want to be able to explain the behaviour when someone asks why a connection did not happen.
Outbound traffic through a defined path is also where segmentation holds up day to day. A server that may only leave through the proxy has a describable exit. One with a direct route has none.
What you get
Not a licence, but someone who operates this layer and hands it over. If you want to keep mail and web egress yourselves, we build it, document it and train your team. If you want to hand it over, we keep running it.
What we do in this area
-
DMARC through to enforcement
Inventory every sending system, get SPF and DKIM straight, read the reports, move to rejection in steps — without cutting off legitimate senders.
-
Transport security for mail
Set up and monitor MTA-STS, TLS reporting and DANE, so the transport path does not silently fall back to cleartext.
-
Operating a mail stack
Postfix, Dovecot and Rspamd as an operated service, including filter rules, quarantine process and recovery.
-
Content-level review of incoming mail
Language-model evaluation where rules and reputation lists no longer reach — as a pointer to the recipient, not a silent deletion.
-
Forward proxy for web egress
Our own SOCKS and HTTPS proxy with policy, logging and defined exceptions, instead of an appliance whose behaviour nobody can explain.
-
Egress as a segmentation control
Servers and networks get one describable way out; anything else stands out and can therefore be dealt with.
What we work with
| Mail stack | mailcow · Postfix · Dovecot · Rspamd · our own evaluation service |
|---|---|
| Mail standards | SPF · DKIM · DMARC · MTA-STS · TLS-RPT · DANE · ARC |
| Web egress | Our own proxy with SOCKS and HTTPS support |
| Operating model | In your infrastructure or with us · handover to your team planned for |
| Automation | Ansible and Terraform for configuration baselines and rollout |
| What it is not | No licence product, no appliance, no price table |
What comes up about this
-
Does this replace Microsoft 365 or Google Workspace?
No, and usually that is not the question. Sender authentication, transport security and the handling of incoming messages are independent of where the mailboxes live. If you want your own stack, we operate it; if you stay with a provider, we harden the path in front of it and behind it. -
Why your own proxy rather than an established product?
Because we have to be able to explain why a connection happened or did not. With a bought-in gateway the explanation often ends at a category database somebody else maintains. If you already run a product, we operate that — our own implementation is an option, not a condition. -
Do you read our email?
The evaluation runs in the delivery path on your side, not as a copy held by us. The purpose is to classify a message, not to store it. What is processed and for how long is agreed in writing before rollout — including your data protection officer and, where required, the works council. -
Can we operate this ourselves later?
Yes, that is the normal case in our mandates. Configuration exists as code, operations are documented, and training your team is part of the work.
Is your DMARC record still on p=none?
In most organisations that is the fastest visible finding, and it takes weeks to fix rather than quarters. We look at the mail path and the web egress and tell you what is actually open.