From an antispam gateway straight to Microsoft 365.
A group of clinical and genetics laboratories received email through an on-site antispam gateway and an internal Postfix relay. After a serious security incident we removed the gateway and moved everything to Exchange Online.
Inbound email went through an on-premise antispam gateway, LibraESVA, and an internal Postfix relay. After a top-priority security incident, in which third parties were abusing the gateway as an SMTP relay, the group decided to remove it. We handled DNS, SPF, DKIM and DMARC across 8 domains, coordinating the external DNS provider and the group's IT: on 7 May 2026 inbound email moved to Exchange Online. The second phase covers the internal systems that send email.
Context
The group's mailboxes are on Microsoft 365, but inbound email took a longer route: from the on-site antispam gateway to the internal Postfix relay, then to Exchange Online. Lab instruments, bioinformatics servers and the phone system, which feeds a BI system, all send through the same relay. The domains' DNS is run by an external provider.
The problem
Every extra hop is one more thing to protect. Even before the incident we had traced some spoofed emails to the relay: it accepted any external sender and forwarded mail that failed DMARC checks, as we proved with live SMTP tests. The abuse of the gateway as a relay then made the decision unavoidable. But the move touches 8 domains, an external DNS provider and systems that have sent email with the same settings for years: one wrong record and legitimate mail stops.
What we did
- 01
Evidence first
Live SMTP tests on the relay to show what it accepted and what it forwarded. With the evidence in hand, the group could decide on facts rather than assumptions.
- 02
Eight domains put in order
For each domain, MX pointed to Exchange Online Protection, SPF records reviewed and Microsoft DKIM CNAMEs added. Changes went through the external DNS provider, coordinated with the group's IT.
- 03
Cutover in an agreed window
On 7 May 2026 inbound email moved to Exchange Online, in the window agreed with the group. The gateway left the mail path.
- 04
DMARC up to p=reject
The DMARC policy went from p=none to p=reject with pct=100: mail pretending to come from the group's domains is rejected.
- 05
The systems that send
Lab instruments, bioinformatics servers and the phone system send through the Postfix relay: its smarthost moves from the gateway to Microsoft 365, and three systems get a new sender address.
- 06
A rollback, then the fix
The first outbound cutover, on 16 June 2026, was rolled back because Microsoft 365 was marking the mail as spam: the relay's public IP was missing from SPF on several domains. We added it on 3 domains and scheduled the new cutover for September 2026.
How it went
Inbound email reaches Exchange Online directly, with no on-site gateway, and the domains reject spoofed messages. The 16 June rollback protected the internal systems' email while SPF was being fixed: a cutover can be undone, mail sitting in recipients' spam folders can't.
Tools
FAQ
Is an antispam gateway still needed with Microsoft 365?
Not always. Exchange Online Protection filters inbound mail; an extra gateway only makes sense if it adds checks you actually need, and it must be patched and locked down like any other exposed server.
Why did mail land in spam after the switch?
Because the IP it was sent from wasn't authorised in some domains' SPF. With DMARC at p=reject, an unaligned sender is treated as suspicious even when it's legitimate.
What changes for instruments that send email?
They keep sending to the internal relay, which delivers to Microsoft 365. The relay's smarthost changes and, where needed, the sender address.