Email security software: how to choose a category fit

How the options were evaluated

Five criteria separate the types, checked against current first-party vendor documentation on 2026-08-12.

• Position relative to delivery. Before the mailbox, after the message lands, or never at all.
• What it can do to a message. Block, quarantine, rewrite, claw back after delivery, or only report.
• What you have to change. An MX record, a tenant permission grant, a license tier, or a DNS record.
• Direction of protection. Mail arriving at your users, or mail sent to other people using your domain.
• Evidence it leaves. Quarantine logs, message trace, tenant alerts, or aggregate reports from receivers.

Deployment mode is often a setting inside a product rather than a property of the vendor. Proofpoint documents "Flexible Deployment via API or SEG" for Core Email Protection, and Cloudflare documents that its Email Security service deploys through "API, BCC/Journaling, or MX/Inline". Ask which mode a proposal assumes: it changes the migration work more than the detection engine does.

Secure email gateway

A gateway sits in front of the mailbox. You point your MX record at the vendor, the vendor inspects and filters, and only surviving mail reaches your mail system. Barracuda's Email Gateway Defense documentation states the prerequisite plainly: "Before you can use Email Gateway Defense, you must modify your domain's MX records to point to Barracuda Networks mail servers", and warns that any record still pointing elsewhere can interfere with its ability to filter. Mimecast and Proofpoint sell the same shape.

The model buys one enforcement point that works regardless of what runs behind it. On-premises Exchange, a hybrid migration, several platforms across acquired companies: a gateway covers them the same way and can refuse a message before any user account is involved.

The cost is that you have joined your mail flow. An MX cutover is a change window, a vendor outage becomes an organization-wide delivery event, and a false positive sits in a quarantine the user cannot see. Gateways are a reasonable answer when pre-delivery blocking is a requirement and an expensive one when it is not.

API-connected cloud email protection

The API model connects to Microsoft 365 or Google Workspace with granted permissions instead of a routing change. Abnormal states its deployment as "Deploy in 60 seconds via API. No MX changes." Cloudflare's API and BCC or journaling modes put a product in the same position, beside the mail path rather than in it.

Two things follow. These tools read the mailbox and the tenant, not only the message, so they can learn who normally emails whom and flag payload-free impersonation a content filter has nothing to match on. Abnormal names "novel BEC, AI-generated lures", account takeover, and invoice and payment fraud as its targets. They also act after delivery, pulling a message back out of the mailbox once a verdict changes.

That is also the tradeoff: the message reaches the mailbox before anything pulls it back, an exposure window for anyone who reads mail quickly. The model also needs a supported cloud provider and a broad tenant permission grant.

Native provider controls

Both large cloud providers ship email security systems you already pay for. Microsoft documents a ladder: the built-in security features for all cloud mailboxes "prevent broad, volume-based, known email attacks", while Defender for Office 365 Plan 1 "protects email and collaboration features from zero-day malware, phishing, and business email compromise (BEC)" and Plan 2 adds simulations, hunting, and automated investigation.

Google Workspace exposes named settings an admin switches on, including "Protect against domain spoofing based on similar domain names", "Protect against spoofing of employee names", and "Protect against any unauthenticated emails". For each one the admin chooses whether the action is a warning, a move to spam, or quarantine.

Starting here costs no migration, and the tuning is work any product would need. Teams still buy a layer on top because capability is tied to license tier and default policies are often left as they shipped, so check what is actually enabled in your tenant first. Microsoft's own guidance also sends admins back to SPF, DKIM, and DMARC records in DNS so the service can more accurately protect against spoofing attacks.

The email authentication layer

The fourth type protects different people. Filters decide what reaches your users. Authentication decides what the rest of the internet does with mail claiming to come from your domain, including mail your gateway never sees because it was never addressed to you.

RFC 9989 defines the mechanism: DMARC "permits the owner of an email's Author Domain to enable validation of the domain's use", to state a handling preference for mail that fails validation, and to "request reports about the use of the domain name." Two limits in the same document matter at buying time. A receiving organization "can choose to honor the Domain Owner's requested message handling for validation failures, but it is not required to do so", and "a DMARC pass by itself does not guarantee that delivery to the recipient's inbox would be safe or desirable."

This layer is not an inbound filter and cannot be scored as one. It is the only one of the four that reduces impersonation of your brand in other people's inboxes. How DMARC works covers the record and the alignment rule.

How to choose

1. Write down the mail systems you actually have

Count every mail platform in the organization, including the ones from acquisitions. A single cloud tenant opens the API option. Anything mixed or on-premises usually does not.

2. Decide whether pre-delivery blocking is a requirement

If an auditor or your own risk position says a malicious message must never reach a mailbox, that is a gateway requirement. If the concern is fraud that reads like ordinary correspondence, post-delivery detection matches the threat better.

3. Enable and tune the native controls first

Compare the policy state in your tenant against the settings each provider documents. A layer bought to cover a control you own but left switched off is the most common wasted line here.

4. Publish and maintain authentication either way

No filtering type stops someone sending as your domain to your customers. That work is SPF, DKIM, and DMARC, and it continues after the filter is chosen.

5. Compare the evidence, not the detection claims

Ask what an analyst can retrieve six weeks later: which messages were held, on what basis, who released them, and how the sender authenticated. Detection rates are vendor-measured; evidence is what you use during an incident.

Where authentication tooling fits

Palisade belongs to the fourth type only. It automates DMARC and email authentication: it reads the aggregate reports receivers send back, identifies the systems sending as your domain, drafts the SPF and DKIM fixes, and proposes each policy step for a person to approve. Palisade's documentation describes it as an email deliverability monitoring and DMARC compliance platform.

It is not a gateway and not an API filter. It never sits in the mail path, so it cannot block, quarantine, or release an inbound message, and it will not stop a phishing email reaching your users. If inbound filtering is the open problem, the other three types are where to look. To see where a domain stands on authentication before any of these decisions, run the email security score tool and review the published records.

Evidence

Sources and further reading

• Microsoft Defender for Office 365 overview
• Google Workspace advanced phishing and malware protection settings
• Cloudflare Email Security documentation
• Proofpoint Core Email Protection
• Barracuda Email Gateway Defense MX record documentation
• Abnormal inbound email security
• RFC 9989: Domain-based Message Authentication, Reporting, and Conformance