Email Security Landscape: ESA, CES & Cloud vs On-Prem

Overview

A message lands in the finance inbox from your CEO’s address, asking for an urgent supplier payment. Nobody hacked anything to send it: the sender connected to your mail server and typed the CEO’s address, and a server with no policy beyond SMTP itself had nothing that could tell the claim was false. Any organisation that accepts public internet mail takes connections from untrusted systems, and base SMTP doesn’t authenticate the envelope sender or the From: author — which is why email stays one of the main delivery channels for phishing, social engineering and malware.

This lesson names the threats, shows where a Cisco Secure Email gateway answers each one, and compares the places that gateway can run. It ends with a lookup you can run from your own terminal against any domain.

Terminology: The Names Changed, the Product Did Not

Cisco has renamed its email products and several of their features since the SESA exam was written, and its documentation and the exam objectives mix both generations. Keep this table beside you for the rest of the course:

Both gateway forms run AsyncOS, Cisco’s operating system for its email and web appliances: Cisco publishes Cloud Gateway release notes under the same AsyncOS version numbers (see the Cloud Gateway’s AsyncOS 15.0 release notes). The lessons use “the gateway” when a statement holds for all of them, and the product name when it does not.

Terminology: Why SMTP Takes the Sender’s Word

The Simple Mail Transfer Protocol (SMTP) moves mail between servers, and a message travels with two sender identities:

Nothing requires the two to match, and the session has two more claims around them: the greeting (EHLO, “I am this host”) and the recipients (RCPT TO). A receiving server can apply local policy to any of them — refuse recipients it doesn’t host, refuse to relay, score the greeting — but base SMTP gives it no way to prove the sender domain or the author is genuine.

Enlarge figure: One SMTP session drawn as four commands on a line: EHLO, MAIL FROM, RCPT TO, and DATA with the From: header. Under each, what it claims and what checks it: EHLO says I am this host, scored rather than proven; MAIL FROM is the envelope sender, where bounces go, and SPF checks its domain; RCPT TO names the recipient, which the gateway checks against its recipient table; the From: header is the author the reader sees, which DKIM signs and DMARC aligns. A footer states that none of these must match: the envelope and the From: header can name different senders.

The protocol’s own standard says so. RFC 5321 §7.1 states that SMTP mail “is inherently insecure in that it is feasible for even fairly casual users to negotiate directly with receiving and relaying SMTP servers and create messages that will trick a naive recipient into believing that they came from somewhere else.”

The checks used today were added around SMTP later. Take them as a separate layer, one question each — and notice that none of them asks “which person wrote this”:

• Reputation — how the connecting IP address has behaved across many networks; on the gateway it’s a score, the SBRS
• Sender Policy Framework (SPF) — whether the envelope sender’s domain (or the HELO name, when the envelope sender is empty) authorises the connecting IP address
• DomainKeys Identified Mail (DKIM) — whether a domain signed the message, and that the signed parts were not altered
• Domain-based Message Authentication, Reporting and Conformance (DMARC, RFC 7489) — whether the visible From: domain aligns with a domain that passed SPF or DKIM, and what the domain owner asks receivers to do when neither does

Any receiving server can evaluate them. A gateway is the place an organisation chooses to evaluate them centrally, for every mailbox it protects.

Threat Types: What Arrives by Email, and What Leaves

This lesson groups inbound threats into five representative categories. They are not the only ones, but the grouping matters because each is answered by different features, at different points:

Three of those features need a line of their own, because their names don’t say what they do:

Business email compromise (BEC) deserves its own line because it often carries no attachment and no link. The message asks a person to do something — pay an invoice, change a bank account, send a file — and the only malicious thing in it is the claim about who sent it. That claim can take three forms, and domain authentication only answers one of them:

• A spoofed domain — the attacker uses your partner’s real domain; if the mail fails DMARC and the domain publishes an enforcing policy, receivers that apply it quarantine or reject it
• A lookalike domain or display name — a domain the attacker controls can pass SPF, DKIM and DMARC, and a borrowed display name isn’t authenticated by any of them, whatever domain it comes from; this needs impersonation detection
• A compromised real account — the mail genuinely comes from the domain, so domain authentication passes; detection depends on content and behavioural analysis, account-security controls, and verifying requests out of band

The outbound direction adds data loss. A user, or a compromised account, sends something that should not leave. The gateway’s Data Loss Prevention (DLP) and encryption features act on mail your own servers send, which is why a gateway is placed on the outbound path as well as the inbound one. A second outbound risk is to your reputation: a compromised account that sends spam through your servers gets your addresses scored as a spam source, so outbound mail policies can be configured to scan with anti-spam and anti-virus too.

Engine Behavior: Before the Message Exists, and After

Cisco’s user guide divides a gateway’s work into three phases, which it calls the email pipeline (Understanding the Email Pipeline):

• Receipt — while the remote host is still connected: whether this host may send to you at all, connection and message limits, and whether the recipient exists
• Work Queue — after the message is accepted: filtering, safelists and blocklists, anti-spam, anti-virus, Outbreak Filters and quarantining
• Delivery — when the gateway connects outward to deliver, under its own delivery limits and policies

The split explains a design choice you will make again and again. A decision made at Receipt is far cheaper than one made later. Host access, reputation and recipient checks happen before the DATA command, which is where the body crosses the wire — so a refusal there never downloads the message. It isn’t free (the gateway still spends a connection, a lookup and a log line), but accepting the same message means a full download, several engines and disk on top.

Enlarge figure: The email pipeline as three phases on one line. Receipt, on the connection: is the host allowed to send, the IP's reputation score, does the recipient exist, connection limits. Work Queue, on the message: message filters, anti-spam and anti-virus, file reputation and graymail, content and Outbreak Filters. Delivery, on the way out: the SMTP route to the next hop, delivery limits and policies, retries and bounces. A footer states that the body arrives at DATA, so a refusal before it downloads nothing.

You can watch that split on the course’s own gateway: in M1 · Lab 1: Power On the ESA & Mail Server, the gateway’s mail_logs record the connection decision — the line for the incoming connection (its ICID, injection connection ID), naming the sender group, the class of senders the host was sorted into — before the message even has an ID, and the scanners’ verdicts only after it does.

That is why the gateway front-loads reputation. Cisco describes its anti-spam as a multi-layer approach of reputation filtering followed by content scanning (Getting Started, AsyncOS 15.0) — the cheap test first, the expensive one only for what survives it.

The next lesson, SMTP & the ESA Email Pipeline: Packet Walk, walks the SMTP conversation and each pipeline stage in order.

Design Choice: Where the Gateway Sits

A gateway only protects mail that passes through it, so its position is set by routing: DNS for inbound mail, and your own mail servers’ relay setting for outbound. Cisco’s Setup and Installation chapter asks you to register the gateway in DNS: an A record for the gateway’s hostname, and an MX record that maps your public domain to that hostname. Other mail servers find you through the MX record, so they connect to the gateway rather than to your mailbox server. In the other direction, your mail servers are configured to use the gateway as their relay (smart host).

The same chapter wants the gateway at the perimeter — the first SMTP hop that mail from the internet meets. Reputation filtering is why. It scores the connecting IP address, so an SMTP relay in front of the gateway would hide every sender behind one address, and the best test the gateway has would score the relay instead. A firewall that only filters or translates the destination doesn’t have that problem; the sender’s address still arrives intact.

Traffic is separated by listeners, not by interfaces:

• Public listener — “receives connections from many external hosts and directs messages to a limited number of internal groupware servers” (inbound)
• Private listener — “receives connections from a limited number of internal groupware servers and directs messages to many external mail hosts” (outbound)

Both listeners can share one interface. The guide is explicit that only one Ethernet interface is required, and that you can add a second to segregate your internal network from the Internet connection. That gives the two layouts you will see in designs and exam questions:

Enlarge figure: Two topologies side by side. One interface: internet senders reach the firewall, the firewall passes mail to the gateway's Data 1 interface, which carries the public listener on TCP 25 and the private listener on its own port, and the internal mailbox server reaches the private listener back through the firewall and the DMZ. Two interfaces: internet senders reach the firewall and the gateway's public listener on Data 1, while the internal mailbox server connects straight to the private listener on Data 2 on the inside network. Badge 1 marks internet mail arriving through the firewall, badge 2 the internal server's path to the private listener.

Design Choice: On-Premises, Cloud, or Both

The gateway runs on your infrastructure, on Cisco’s, or on both. Both run AsyncOS; what changes is who owns the infrastructure and where the MX record points.

On-premises (Secure Email Gateway). You run the gateway, as a hardware appliance or a virtual machine. The MX records typically point to hostnames the organisation controls, and you own capacity, patching and availability. This is the form the lab in this course uses, and the one where you control the deployment and every supported configuration choice.

Cloud (Secure Email Cloud Gateway). Cisco hosts the gateways, and you administer their policy. You can spot it in DNS, because Cisco names every allocation’s hosts under iphmx.com. The gateways carry a region in the name — esa.<allocation>.iphmx.com in the US, esa.<allocation>.c3s2.iphmx.com in the UK data centre — and an mx1.<allocation> name resolves to the addresses a customer’s MX records use (DNS Records, Hostnames & IP Addresses).

Hybrid. A combination of the two rather than a third kind of gateway. One common split is for the Cloud Gateway to receive inbound mail from the internet while an on-premises gateway handles outbound mail, where policy wants DLP and encryption decided on your own hardware. A hybrid is also how organisations migrate between the two without a flag day.

Secure Email Threat Defense is not a fourth place for the gateway — it is a different position. It connects to Microsoft 365, receives copies of mail through journaling, and uses Microsoft’s APIs to act on messages already in mailboxes (requirements). A gateway decides before delivery; Threat Defense can still act after it. Objective 1.5 covers it in Configure Email Security with Cisco Secure Email Threat Defense.

Enlarge figure: Mail routing for the deployment options. Internet senders look up the MX. Path 1 leads to an on-premises Secure Email Gateway in your network, whose MX names hosts you control, and on to the mailbox platform. Path 2 leads to the Cloud Gateway in Cisco's cloud, MX under iphmx.com, and on to the same mailbox platform. Path 3, the common hybrid split, runs from the mailbox platform back out through your own gateway for outbound mail. Path 4, dashed, connects Secure Email Threat Defense to the mailbox platform by journaling and API, behind the mailbox rather than in the MX path.

Whichever you choose, Cisco Secure Email and Web Manager can sit beside on-premises gateways to centralise reporting, message tracking and spam quarantine across many of them; Centralized Management with Cisco Secure Email and Web Manager (SMA) covers it.

Scale & Limits: Sizing a Virtual Gateway

Objective 1.1 names hardware and virtual machine specifications. The hardware appliances come with their resources fixed; Cisco’s hardware installation guide lists them, all 1 RU:

For virtual gateways you size the VM yourself, and the source is Cisco’s virtual appliance installation guide (revised 2026-09-04). It carries separate tables per hypervisor, and they do not agree on memory:

The memory columns are the guide’s own rows for an AsyncOS 15.0 gateway: the KVM table (page 3) and the ESXi new-install values for 15.0 and later (page 4).

Three rules come out of those guides:

• Meet the table for your release and hypervisor. The KVM and ESXi figures are separate requirements, not a low and a high option.
• Choose a larger model for McAfee. The guide recommends the C300V or C600V for McAfee’s memory needs, and asks C100V users who see McAfee restart errors to consider migrating.
• License before setup. The setup guide warns that a virtual gateway must load its licence before the System Setup Wizard will run.

🔬 See It Yourself: Read Any Domain’s Front Door

You can see where a domain’s inbound mail enters, and what it asks receivers to do with mail that fails DMARC, from your own terminal. No lab is needed. Pick any domain you are curious about and run:

$ dig +short MX <domain>
$ dig +short TXT <domain>
$ dig +short TXT _dmarc.<domain>

The first command lists the hosts that accept the domain’s mail, each with a preference value; sending servers try lower values first. (The order dig prints them in is not significant.) The second returns the domain’s TXT records; the one starting v=spf1 is its SPF policy — the servers allowed to send as its envelope sender. The third returns the DMARC record: what the domain owner asks receivers to do with mail whose From: domain passes neither aligned SPF nor aligned DKIM.

Read the answers with three questions:

1. Whose hosts are in the MX? iphmx.com means Cisco’s Cloud Gateway receives the mail. mail.protection.outlook.com means Microsoft’s Exchange Online Protection does. Hostnames in the domain’s own namespace say only that the domain names its own ingress — the service behind them could be on-premises or hosted.
2. What is the DMARC policy (p=)? none requests no specific delivery action (reports are requested separately, with rua and ruf), quarantine asks receivers to treat failing mail as suspicious, and reject asks them to reject it (RFC 7489 §6.3). These are requests; each receiver applies its own local policy.
3. Is there a subdomain policy (sp=)? Without one, subdomains inherit p=.

$ dig +short MX github.com
0 github-com.mail.protection.outlook.com.
$ dig +short TXT github.com | grep spf1
"v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.2" "27.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all"
$ dig +short TXT _dmarc.github.com
"v=DMARC1; p=quarantine; sp=reject; pct=100; rua=mailto:dmarc@github.com; ruf=mailto:dmarc@github.com; fo=1"

🎥 [Video: one hand-typed SMTP session accepting a forged sender; five representative inbound threats and the outbound risks; a gateway in the MX record, splitting what it can refuse at the connection from what it must scan in the message; the three places the gateway can run and Threat Defense behind the mailbox; a live dig MX and dig TXT _dmarc read aloud. Matches video.script_outline. Runtime: ~8 minutes]