# 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.

- Sector: Healthcare
- Practice: Cloud and infrastructure
- Year: 2026
- URL: https://cloudfactory.it/en/work/email-gateway-to-microsoft-365-labs/

## In brief

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.

- **8** domains with MX, SPF, DKIM and DMARC reworked
- **07.05.2026** inbound email cutover
- **p=reject** final DMARC policy, with pct=100
- **3** sending systems with a new sender address

## 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

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **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

Microsoft 365, Exchange Online, Exchange Online Protection, Postfix, LibraESVA, SPF, DKIM, DMARC, DNS

## 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.

---

Cloudfactory S.r.l., Rome. Contact: hello@cloudfactory.it