Email Security Guide: SEG, ICES and API-Based Protection

Email remains a primary route for phishing links, malware and payment fraud, and organisations regularly lose credentials to messages that passed straight through an email security gateway. No single product closes that gap: protection comes from layers that each do a different job, from the MX record and sender authentication to inline filtering, API-based post-delivery remediation, transport encryption and the identity controls behind the mailbox. This guide compares secure email gateways (SEG), integrated cloud email security (ICES) and API-based protection, sets out SPF, DKIM and DMARC from the RFCs together with the Google and Yahoo bulk sender requirements, and covers MX routing, TLS, sandboxing, remediation, rollout and measurement. It is written for email administrators, security architects and SOC leads running Microsoft 365, Google Workspace or hybrid mail.

Key takeaways

• SEG and ICES solve different problems. A gateway filters inline before delivery and controls routing; an API-based tool sees mail after the platform has filtered it, including internal mail, and pulls it back from mailboxes.
• Routing mistakes undo filtering. If the cloud tenant still accepts direct delivery, attackers skip the gateway, and bypass rules on shared gateway IPs let spoofed mail through. Lock inbound connectors to the gateway.
• DMARC at p=reject is the goal. Google and Yahoo require only p=none for bulk senders, which stops nobody spoofing you. Move through quarantine to reject, and publish reject records on domains that never send.
• Post-delivery remediation is a core control. Links are weaponised after delivery and verdicts change, so clawback, time-of-click checks and fast search-and-purge decide how long a malicious message stays usable.
• Most email losses end in an identity event. Credential phishing, OAuth consent, forwarding rules and stolen sending keys turn a message into account access, so phishing-resistant MFA and app governance belong in the design.

SEG, ICES and API-based protection compared

These category names come from the market rather than a standard, and products increasingly offer more than one deployment mode, so judge the architecture, not the label. Microsoft's description of the split is useful: gateways "filter emails before they reach" its cloud filtering, while ICES products "detect and remediate threats after" it and "act as a secondary filter", using the Microsoft Graph API to move messages between folders.

Choosing a design

• Cloud-only mail, small or mid-sized organisation: run the platform's own protection on its strict preset and add an API-based layer if reported phishing and BEC losses justify it. An inline gateway only for spam filtering adds routing complexity for little gain.
• Hybrid or on-premises mail, many domains, heavy outbound needs: a gateway still earns its place for routing control, outbound encryption, enforced partner TLS and archiving integration.
• High BEC exposure (finance, legal, supplier payments): prioritise behavioural detection of impersonation and vendor account compromise, which needs internal and conversational context. This is where API-based tools are strongest.
• Stacking: gateway in front, platform in the middle and API layer after is a supported pattern if each layer trusts the right hop. Two inline filters in series mostly add latency and false positives.

MX routing, connectors and bypass

The MX (mail exchanger) record tells the internet where to deliver your mail. When it points at a gateway in front of a cloud tenant, four problems follow unless they are configured away.

• Direct delivery bypass: the tenant has its own public endpoint, so attackers can deliver straight to it. Microsoft's guidance is to "lock down your Exchange Online organization to only accept mail from your third-party service" with a Partner inbound connector using TlsSenderCertificateName (preferred) or SenderIpAddresses, with RestrictDomainsToCertificate or RestrictDomainsToIPAddresses set to $True.
• Lost sender data: after a gateway, the message "adopts the source IP of the last hop", so SPF and DMARC at the platform see the gateway. Enhanced Filtering for Connectors (skip listing) restores the original IP and sender; it is not for services that scan after Microsoft 365.
• Bypass rules on shared IPs: Microsoft warns that gateway providers share IP addresses among customers, so "bypassing scanning on these IPs might allow spoofed and phishing messages". Use skip listing instead of a spam-filter bypass rule.
• Modified messages: gateways that rewrite links or add banners break DKIM signatures. If the gateway supports ARC (RFC 8617), add it as a trusted ARC sealer.

Outbound, the platform usually sends through the gateway as a smart host. SPF must authorise whichever system actually connects to the internet, and DKIM signing should happen at the last hop that modifies the message.

Sender authentication: SPF, DKIM and DMARC

These standards protect the exact domains you own. They do nothing against look-alike domains or compromised accounts, but they are what lets receivers reject mail that spoofs you.

Alignment is what makes DMARC work

RFC 7489 put it simply: "When the domain in the RFC5322.From address matches a domain validated by SPF or DKIM (or both), it has Identifier Alignment." DMARC passes if either aligned check passes. SPF often fails alignment for third-party senders, which use their own envelope domain, and it breaks on forwarding. DKIM signing with your own domain at every third-party sender is the reliable route to a passing result.

What changed with RFC 9989

DMARC was first published as an Informational, Independent Submission RFC. In May 2026 RFC 9989 put it on the Standards Track, with aggregate reporting in RFC 9990 and failure reporting in RFC 9991. For record owners: the pct tag is removed (receivers ignore unknown tags); the new t=y flag asks receivers to apply one policy level lower; np covers non-existent subdomains; and the organisational domain is found by a DNS tree walk capped at eight lookups rather than only the Public Suffix List. Rollouts staged with pct=10 should move to t=y or per-subdomain policies.

Domains that never send mail

Parked and defensive domains are spoofed because nobody watches them. The UK government pattern is: SPF v=spf1 -all; DMARC v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s plus a reporting address; an empty DKIM key at *._domainkey (v=DKIM1; p=); and a null MX with priority 0 and value . (RFC 7505).

Google and Yahoo bulk sender requirements

Since February 2024 Gmail and Yahoo have enforced baseline rules for anyone sending to personal Gmail and Yahoo addresses, including HR, billing and marketing systems.

Gmail also warns senders not to impersonate Gmail From: headers because it will apply DMARC quarantine to its own domain. Yahoo recommends ARC for anyone who forwards mail.

Transport security: opportunistic and enforced TLS

• Opportunistic TLS: servers upgrade with STARTTLS when both sides support it, otherwise send in plaintext. NCSC notes STARTTLS "is susceptible to a downgrade attack by a 'man in the middle'", and you must still accept unencrypted mail to receive from everyone.
• Enforced TLS: for regular partners (law firms, payroll, regulators), require TLS with certificate validation per domain and refuse to send otherwise.
• MTA-STS: start in testing mode with TLS-RPT reports, monitor for at least a month as NCSC advises, then enforce. Change the id in the _mta-sts record whenever the policy file changes.
• Message-level encryption: S/MIME or an encryption gateway protects content beyond the next hop. Note that Microsoft documents Safe Links "ignores S/MIME signed messages".

Filtering, sandboxing and post-delivery remediation

Before delivery

• Sender MTA reputation analysis: IP and domain scoring, forward-confirmed reverse DNS (the PTR name resolves back to the same IP), blocklists and connection behaviour remove most unsolicited commercial email cheaply. Snowshoe spam spreads low volumes across many IPs and defeats per-IP thresholds, so it needs content and domain-age signals.
• Attachments: block file types you never need (executables, scripts, disk images, macro-enabled legacy formats), then detonate the rest in a sandbox. Holding mail during detonation is safer but adds delay.
• URL rewriting: wrapped links are checked at time of click. With Microsoft's "Wait for URL scanning to complete" on, messages "are delivered only after the URLs are confirmed to be safe". Avoid double wrapping: Microsoft notes that another service wrapping links first "might prevent Safe Links from processing links".
• Backscatter: reject unknown recipients during the SMTP session rather than bouncing later to forged senders.
• External sender banner: keep it short and reserve stronger warnings for first-time or look-alike senders, or users stop reading it.

After delivery

• Automatic clawback: Microsoft's zero-hour auto purge (ZAP) "retroactively detects and neutralizes" phishing, spam and malware in Exchange Online, but its search "is limited to the last 48 hours of delivered email", users are not told, and allow lists and mail flow rules can override it. Check the window your post-delivery tool covers.
• Search and purge: analysts need a tested way to find every copy of a campaign by sender, URL or attachment hash and remove it within minutes, with an audit trail.
• User reporting: a report button feeding the same triage queue turns one report into tenant-wide removal.
• Outbound: run email DLP with a few high-confidence detectors in audit mode before blocking, set per-user sending limits, block automatic external forwarding by default, and protect archives with the same access controls as live mailboxes.

Where identity fits

Filtering decides whether a message arrives. Attackers want the account behind it, and much of the email estate runs on non-human identities.

• Credential phishing past the gateway: adversary-in-the-middle pages relay passwords and one-time codes in real time, often from legitimate hosting that passes reputation checks. Phishing-resistant MFA makes the stolen credential useless. See the Passwordless and Passkeys Guide.
• API-based security tools are privileged applications: an ICES product typically holds application permissions to read and modify every mailbox. Record its permissions, owner and credentials and review them like an administrator. See the SaaS and OAuth App Governance Guide.
• Sending credentials: SMTP relay passwords and email API keys are authorised in your SPF and signed with your DKIM keys, so whoever steals them sends fully authenticated mail as you. The TruffleNet campaign used stolen AWS keys to send business email compromise through Amazon SES, and Gravity SMTP CVE-2026-4020 exposed email API keys. See the API Key Management Guide.
• Mailbox access by apps and rules: a consented or hijacked app reads mail through the API without any message passing a filter, as in the Microsoft Midnight Blizzard breach. Forwarding rules (ATT&CK T1114.003) keep access "even after compromised credentials are reset". For payment fraud from real supplier mailboxes, see the Email Identity and BEC Guide.

How to implement: a phased rollout

1. Inventory: list every owned domain, MX record, connector, transport rule and system that sends as your domains (marketing, CRM, ticketing, payroll, scanners). DMARC projects stall when an unknown sender appears late.
2. Publish monitoring records: fix SPF (under ten lookups), enable 2048-bit DKIM for every sender, and publish p=none with rua. Publish reject records on non-sending domains now; they carry no delivery risk.
3. Fix routing: enable skip listing, lock inbound connectors to the gateway, remove bypass rules, add ARC trust. Test by sending directly to the tenant endpoint from outside: it must be rejected.
4. Tighten filtering in rings: apply strict policies (attachment blocking, sandbox hold, wait for URL scanning, impersonation protection for executives and finance) to IT and security first, then 10 to 20 per cent of users, then everyone. Keep the old policy on a group so rollback is a membership change.
5. Add post-delivery protection: run any API-based tool in report-only mode for two to four weeks, compare findings with the platform, then automate remediation for high-confidence verdicts only.
6. Enforce DMARC: move to quarantine when reports show legitimate mail passing, then reject. NCSC says many organisations reach reject "after about 3 months" and advises at least two weeks of monitoring after each change; roll back to quarantine if legitimate mail fails.
7. Transport and outbound: run MTA-STS in testing with TLS-RPT, then enforce; enable DLP in audit mode; block external auto-forwarding with an exception process.
8. Operationalise: document search-and-purge, send email telemetry to the SIEM and rehearse a campaign response twice a year.

Detection and measurement

Monitor DMARC aggregate reports (new sending sources, alignment failures, spoofing volume), TLS-RPT failures, quarantine and clawback actions, user reports, time-of-click blocks, new inbox and transport rules (for example New-InboxRule), new OAuth consents with mail permissions, and sign-ins that follow a reported phish.

Common failure patterns

• Gateway in front, tenant wide open: the MX points to the gateway but the tenant accepts direct delivery, and a bypass rule for the gateway's shared IPs means spoofed mail arrives unfiltered.
• DMARC parked at p=none: published to satisfy bulk sender rules and never enforced, so the domain can still be spoofed in invoice fraud.
• SPF overloaded: each new SaaS sender adds an include until the record exceeds ten lookups and returns permerror, failing SPF for all mail. Use per-sender subdomains and DKIM alignment.
• Allow lists that override detection: broad allow entries added to fix one false positive stop filtering and clawback from acting.
• Trusting the filter, not the identity: one message that lands is enough. In the Cyberhaven Chrome extension breach, phishing posing as the Chrome Web Store led to a single OAuth consent that let attackers publish a malicious update. Plan filtering together with phishing-resistant MFA and consent controls.

Framework mapping

In NIST CSF 2.0, filtering and authentication sit under Protect (PR.PS, PR.DS) and reporting, clawback and rule monitoring under Detect (DE.CM) and Respond.

Practitioner checklist

• Inventory owned domains, MX records, connectors and every system that sends as you, each with an owner.
• Publish SPF -all, DMARC reject, an empty DKIM key and a null MX on every non-sending domain.
• Sign all outbound mail with 2048-bit DKIM under your own domain, including third-party senders, and keep SPF under ten lookups.
• Move sending domains to p=reject via quarantine, and replace pct staging with t=y or subdomain policies.
• Where a gateway fronts a cloud tenant, restrict inbound connectors to it, enable skip listing and remove shared-IP bypass rules.
• Block unneeded attachment types, hold mail for sandbox and URL scanning, and avoid double link wrapping.
• Test clawback and search-and-purge end to end and track time from first report to removal.
• Block external auto-forwarding by default and alert on new inbox rules, transport rules and mail-scoped OAuth consents.
• Govern API-based email tools and sending keys as privileged non-human identities with owners, least privilege and rotation.
• Run MTA-STS in testing with TLS-RPT, then enforce, and enforce TLS with named partners.

Standards and references

• IETF: RFC 7208 Sender Policy Framework (SPF)
• IETF: RFC 8301 Cryptographic Algorithm and Key Usage Update to DKIM
• IETF: RFC 9989 Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
• NCSC: Email security and anti-spoofing
• GOV.UK: Protect domains that do not send email
• Google: Email sender guidelines
• Yahoo: Sender best practices
• Microsoft Learn: Manage mail flow using a third-party cloud service with Exchange Online

Related NHI Mgmt Group resources: Email Identity and BEC Guide · SaaS and OAuth App Governance Guide · Passwordless and Passkeys Guide · API Key Management Guide · Deepfake and AI Impersonation Guide