Email security on-premises Exchange and Microsoft 365: one process for both

Email security on-premises Exchange is the part of the estate that most tools quietly skip. Vendors assume everyone has moved to Microsoft 365, so the on-prem server gets a spam filter from 2015 and nothing else. In practice, many organizations run both: a Microsoft 365 tenant for most staff and an Exchange Server for a department, a subsidiary, or a system that cannot move. This guide explains what inbound email security needs to cover on both platforms, how to measure it, what to do when a phishing message lands, and how to run one process across the two rather than two half-processes.

Why on-prem Exchange is still a target

An Exchange Server reachable from the internet is one of the most attacked pieces of software a company can run. The vulnerabilities of recent years (ProxyLogon, ProxyShell and their successors) were exploited soon after publication. Microsoft's guidance is clear: stay on a supported cumulative update, apply security updates promptly, and run the Exchange Health Checker. See Microsoft Learn: Exchange Server updates.

Patching is one of three jobs. The other two are the same as on Microsoft 365: keep bad mail out (inbound posture), and deal with the mail that gets in anyway (reports, triage, purge). A hybrid estate makes both harder because the admin tools and logs are split in two. The attacker does not care which server a mailbox is on. Your process should not either.

Inbound posture: the controls that must be true

Before buying anything, check what is already configurable and whether it is actually on. These controls apply to both platforms; the place you set them differs.

Every row should have a measured answer, not a remembered one. "We turned DKIM on last year" is not the same as a check that reads the DNS record today and confirms the selector still resolves.

What "measured" means

A posture check that counts reads the actual state from the server, the tenant or public DNS, and reports it with a date. A screenshot in a folder is not a measurement. The reason this matters is drift: a transport rule is disabled during troubleshooting and never re-enabled, a DNS migration drops the DMARC record, a new sending domain is added without SPF. The same principle applies beyond email; see IT audit evidence: measuring controls from live data, not screenshots.

When a phishing email gets through

Filtering fails. The question is what happens in the ten minutes after a user notices.

The usual answer: the user forwards the message to the help desk, a ticket is opened, someone on the security team looks an hour later, decides it is malicious, then searches for other copies. On Microsoft 365 that is Content Search or Threat Explorer. On-prem it is Search-Mailbox or a compliance search. In a hybrid estate it is both, done by different people, reconciled by hand.

Three things break:

• Reporting is awkward. Forwarding strips headers. Users do not know the address. Many do not report at all.
• Each report is judged alone. The same campaign hits forty mailboxes; the analyst sees forty tickets, or one, and never learns about the rest.
• Purge is slow and partial. By the time the search finishes, several users have clicked. On-prem mailboxes are often left out because the tool is different.

What good looks like

• A Report button in Outlook that sends the full message, headers intact, to a dedicated location.
• Reports grouped into campaigns automatically: same sender, subject pattern, URL or attachment hash. One decision covers the group.
• A purge that removes every copy from every mailbox, on both platforms, in one action, with a record of what was removed.
• A visible turnaround figure: time from first report to purge.

There is a full article on the mechanics of the button and the purge at A phishing report button for Outlook, and purging the whole campaign.

Beyond the filter: the server, the domains and the endpoints

Inbound email security does not end at the mail server. It also does not look the same on both platforms. A few things are different enough on Exchange Server to call out first.

The on-prem specifics

No Graph API. Microsoft 365 tooling reaches mailboxes through Microsoft Graph. On-prem, you have Exchange Web Services and PowerShell remoting. Ask any tool that promises to purge a campaign "everywhere" how it reaches an on-prem mailbox. If it does not, those users are a blind spot.

Credentials. Basic authentication is retired on Microsoft 365 but often still enabled on-prem because an old device needs it. A purge tool that needs a Basic-auth service account is a liability. Prefer a helper that runs inside the network with a scoped Exchange role, assigned to a service identity rather than an admin's personal account, with every use logged.

Patching the server itself. Cumulative updates are large and disruptive, so they get delayed. Treat the Exchange host as a high-value server: first ring after the canary, not last. See Patch management rings: canary, pilot, everyone.

Exposure. OWA, ECP and anything else the server publishes belong in the external scan of your public surface. Finding an exposed /ecp on an old build is faster than waiting for the next advisory.

Domains and indicators

Look-alike domains. Attackers register yourcompany-invoices.com or swap a letter in your domain and use it for phishing and vendor fraud. Watching registrations that resemble your domains gives warning before the first message, and lets you pre-block the sender.

Indicators on the endpoint. The email is the delivery. The payload is a link clicked or a file opened on a laptop. Once a campaign is confirmed, the sender domain, URLs and attachment hashes should be hunted on every endpoint: did anyone browse there, did the file land on disk. The purge removes the lure; the hunt tells you whether it already worked.

Data going out the other way. The same Outlook that receives phishing also sends your confidential files. Outbound email DLP belongs to the same program but is a different article: What is Data Loss Prevention (DLP)? A practical guide.

Checklist: email security on-premises Exchange and Microsoft 365

Work through this against both the tenant and the on-prem server. An item is done only when it is measured.

• SPF, DKIM and DMARC published for every sending domain, DMARC at quarantine or reject, and the records re-read on a schedule.
• Spoofing of your own domains blocked at the first hop, whether gateway, transport rule or anti-phishing policy.
• Executable, script and macro-enabled attachments blocked or quarantined inbound on both platforms.
• External sender tag visible in Outlook for mail from outside the organization.
• Mailbox and admin audit logging enabled, retention known, logs shipped off the server.
• Legacy authentication disabled, or enabled only for named accounts with a reason and an expiry.
• Exchange Server on a supported cumulative update, Health Checker run after each update.
• OWA, ECP and autodiscover endpoints included in the external surface scan.
• A Report button in Outlook for every user, including on-prem mailboxes, with the full message and headers preserved.
• Reports grouped into campaigns, one decision per campaign, and a purge that reaches every mailbox on both platforms.
• Time from first report to purge tracked and reviewed.
• Look-alike domain registrations watched for every brand and domain you own.
• Confirmed campaign indicators (domains, URLs, hashes) hunted on every endpoint, not just in the mail store.
• A service identity with a scoped Exchange role for the purge, no personal admin accounts, every use logged.
• One owner for the whole inbound process, not one per platform.

How Tracemark does it

Tracemark's Email & Threat Intel product is built for exactly the mixed estate described above, and it works with Microsoft 365 and on-prem Exchange from one console.

Report button in Outlook. One press reports the message to the security team. Nothing to forward, no address to remember.

Campaign view and one-report purge. All copies of the same message are judged together in a campaign view, so the analyst makes one decision about the campaign. One report purges that campaign from every mailbox. This works with Microsoft 365 and with on-prem Exchange.

Inbound posture, measured. The inbound mail security posture is measured, not assumed, so the table above has dated answers rather than remembered ones.

Brand watch. Look-alike domains that resemble your brands are watched, giving warning before the first message arrives.

Indicators hunted on every endpoint. Because the same Tracemark agent is already on every endpoint, attacker domains and indicators from a confirmed campaign are hunted on the endpoints themselves, closing the gap between "we purged the email" and "did anyone already open it."

Part of one platform. Exposure management ranks the vulnerabilities and open ports of the Exchange host and includes its public endpoints in the external web scan. The Outlook add-in also classifies outbound mail on send. Every change made in the console lands in the admin trail with who, what and when.

Frequently asked questions

Does on-prem Exchange need a separate email security product from Microsoft 365?

No, and running two is usually worse than one. The controls differ in where they are set, but the process (report, judge, purge, hunt) should be identical. Choose tooling that reaches both platforms.

Is Exchange Online Protection enough for a Microsoft 365 tenant?

It is a solid base layer and should be configured fully. It does not cover what happens after delivery: collecting user reports in a usable form, grouping them into campaigns, purging on-prem mailboxes, or hunting indicators on endpoints. Those are the gaps to fill.

How quickly should a reported phishing campaign be purged?

Fast enough that most recipients have not opened it. There is no universal number, but the process should be measured in minutes from first report to purge, not hours from ticket to analyst.

What is the single most important setting for an internet-facing Exchange Server?

Being on a supported cumulative update with current security updates. After that, disable legacy authentication where unused and put OWA and ECP behind multi-factor authentication.

Try it

Try Tracemark free for three months. Claim it at tracemark.ca