A compromised email security gateway can let phishing through with your own approval, read or copy mail in transit, send mail that passes authentication as your domain and hand over the directory and mailbox credentials it uses to do its job. Email gateways have been a repeated target: CISA's Known Exploited Vulnerabilities catalog lists remote command execution flaws in several vendors' gateway appliances, including CVE-2023-2868 and CVE-2025-20393, and in the 2023 case the vendor told customers that compromised appliances must be replaced regardless of patch level. This guide is for email administrators, incident responders and SOC leads. It covers appliance and virtual gateways in the mail path, cloud gateways and API-connected email security services that hold mailbox permissions. It is vendor-neutral: confirm exact settings in your vendor's documentation. Preventive hardening is covered in Securing the email security gateway itself, and this page does not repeat it.
Key takeaways
- Replace, do not clean, a compromised appliance. Root-level compromise of an appliance cannot be trusted after patching; build or obtain a fresh one, restore only reviewed configuration and keep the old one isolated for evidence.
- Keep mail flowing through a safe path. Plan an alternative route, such as the mail platform's native filtering or a standby gateway, so containment does not mean switching off email.
- Rotate everything the gateway held. Directory bind accounts, mailbox API applications, DKIM private keys, TLS certificates, relay and connector secrets, and cloud management accounts all need new values.
- Review what was let through. Allow-list entries, policy changes and quarantine releases made during the window decide which delivered messages must be found and purged.
- Treat DKIM keys as compromised signing credentials. A stolen key lets someone sign mail as your domain until you retire its selector in DNS.
Gateway models and what each exposes
Containment depends on how the gateway connects to your mail. This is our view of the three common models.
| Model | Where it sits | What it holds | Main containment lever |
|---|---|---|---|
| Appliance or virtual appliance | In the mail path; MX records or relays point to it | Admin accounts, directory bind credentials, TLS private keys, DKIM keys, quarantine store, relay settings | Isolate the appliance and reroute mail around it |
| Cloud gateway service | In the mail path, run by the vendor | Your tenant configuration, connector settings, DKIM keys if outbound signing is used, quarantine | Lock your tenant, rotate connector trust, follow vendor instructions |
| API-connected email security | Beside the mail platform, using its APIs | An application identity with permissions to read, move or delete mail in mailboxes | Disable the application identity and remove its permissions |
How the compromise shows up
- Exploitation of the appliance: a vendor advisory or KEV entry for your product and version, unexpected processes or outbound connections from the appliance, or files added to it. Gateway flaws exploited in the wild include command injection triggered by crafted attachments (CVE-2023-2868, CVE-2025-59689) and a flaw in an internet-exposed spam quarantine feature (CVE-2025-20393); all three are in the KEV catalog (ATT&CK T1190 Exploit Public-Facing Application).
- Policy tampering: new sender or domain allow entries, relaxed attachment or URL rules, or detection switched to monitor only, seen in the gateway's audit log (ATT&CK T1685 Disable or Modify Tools).
- Quarantine abuse: releases of high-risk messages by an unusual admin or at unusual times.
- Mail copying: new journaling, archive or blind copy destinations, or outbound routes to unknown hosts (ATT&CK T1114.002 Remote Email Collection).
- Application identity misuse: the gateway's mailbox application signing in from new locations, or reading far more mail than its scanning pattern needs.
- Outbound abuse: mail signed with your DKIM selector that your systems did not send, or relay volume from the gateway with no matching internal source; DMARC aggregate reports often show this first.
Triage: the first hour
- Identify the model and version and check the vendor advisory and KEV catalog for known exploitation of that version.
- Decide whether the gateway is still trustworthy for mail flow. Code execution on an appliance, or any unexplained admin activity, means no.
- List what the gateway holds: directory accounts, mailbox applications, DKIM selectors, TLS certificates, connector secrets, SMTP relay credentials, file transfer or backup credentials, and cloud management accounts.
- Fix the window: the earliest suspicious event, so you know which policy changes, releases and deliveries to review.
- Confirm an alternative mail path exists and who can switch it.
- Brief the help desk and SOC to expect phishing that the gateway let through.
Containment by priority
- Take the gateway out of trust. For an appliance, isolate it from the network apart from the forensic path. For any model, change the mail platform's inbound connectors so mail claiming to come through the gateway is no longer accepted on that basis, and route inbound mail through the alternative path.
- Disable the mailbox application identity. For API-connected services, disable sign-in for the application before removing credentials; Microsoft's playbook for compromised applications recommends this order so you can assess impact first. In Microsoft 365, check both the permissions consented in Microsoft Entra and any Exchange Online RBAC for Applications assignments, because Microsoft documents that the effective access is the union of the two.
- Disable directory bind accounts used for recipient validation or LDAP lookups and check them for sign-ins from anywhere other than the gateway.
- Stop outbound signing and relay through the gateway. Move outbound mail to a path that signs with a new DKIM key, and block the old relay at the mail platform.
- Freeze policy. Export the current gateway policy, allow lists, block lists and quarantine history before anyone changes them, then lock admin access to the response team.
Rollback: the alternative mail path is the rollback. Test it in advance with a small domain or a test recipient group so that switching under pressure does not cause a mail outage.
Credential and key rotation
| Item | Rotation action | Source of the practice |
|---|---|---|
| Directory bind and LDAP accounts | Reset passwords, reduce to read only lookups, restrict sign-in to the new gateway | Vendor advice after the 2023 appliance compromise listed connected LDAP and AD accounts |
| Vendor cloud management account | Reset, enforce MFA, review sessions | Same vendor advice |
| File transfer and SMB credentials used for backup or reporting | Reset and restrict | Same vendor advice |
| TLS certificates and private keys on the gateway | Revoke and reissue with new keys | Same vendor advice listed private TLS certificates |
| DKIM private keys | Publish a new selector, switch signing, then set the old selector's p= value to empty | M3AAWG DKIM Key Rotation best practices |
| Mailbox application credentials | Add a new certificate, remove every old secret and certificate, scope permissions to the mailboxes needed | Microsoft compromised application playbook; Exchange Online RBAC for Applications |
| Connector certificates and shared secrets with the mail platform | Replace and update the connector configuration | Lesson of the 2021 certificate compromise below |
On DKIM, M3AAWG recommends never reusing a selector name, keeping a retired selector's record in DNS with an empty p= value rather than deleting it, and pre-publishing the next public key so an emergency rotation needs only the mail administrator. In an incident, retire the old selector straight away rather than waiting the 7 to 30 days M3AAWG suggests for routine rotation, accepting that some delayed legitimate mail will fail DKIM. See the DMARC, SPF and DKIM Guide.
Eradication and rebuild
- Replace the appliance: deploy a new physical or virtual appliance on a current release; do not restore a full configuration backup taken during the window, because it can carry the attacker's changes.
- Rebuild policy from a reviewed baseline: compare the exported policy with your last approved version and re-create only the entries you can explain, especially allow lists.
- Remove mail copy paths: delete unknown journaling, archive, blind copy and outbound route destinations on both the gateway and the mail platform.
- Check the mail platform: look for new transport rules, connectors, inbox forwarding rules and application consents created in the window.
- For cloud services: follow the vendor's eradication statement, then verify your own tenant configuration rather than assuming the vendor's clean-up covered it. Where a vendor states that a fixed release removes known persistence, as one vendor did for CVE-2025-20393, still review admin accounts and configuration yourself.
Recovery and message clean-up
- Find what was let through. Use message trace for the window to list messages delivered because of allow entries, policy changes or quarantine releases; see the Email Gateway and Message Trace Detection Guide.
- Purge and warn. Remove malicious messages from mailboxes, block their senders and URLs, and contact recipients who clicked.
- Pilot the new gateway. Route one domain or recipient group through it, check verdicts and DKIM signatures, then widen in rings.
- Restore inbound trust. Re-enable the mail platform's connector restriction for the new gateway only, using new certificates or source addresses.
- Audit DKIM a week later. M3AAWG recommends checking the
d=ands=values on sent mail against your records after a rotation.
Evidence and notification
- Preserve: the isolated appliance or its disk image, gateway audit logs, message logs, quarantine history, policy exports, mail platform audit logs and DMARC reports for the window.
- Personal data: mail content in quarantine or copied out can contain personal data; under GDPR Article 33 the controller notifies the supervisory authority within 72 hours of becoming aware where feasible, unless the breach is unlikely to result in a risk to individuals. See the Data Breach Notification Checklist.
- Other regimes: sector and national rules may apply; see the Cyber Incident Reporting Requirements Map.
- Vendor: report to the vendor, keep case numbers and ask for indicators of compromise for your version.
Decision guidance
| Situation | Choose | Trade-off |
|---|---|---|
| Appliance with confirmed code execution | Replace the appliance and rotate everything it held | Hardware lead time; use a virtual appliance or native filtering meanwhile |
| Admin account misuse only, no code execution | Reset admin access, review and roll back policy, rotate keys the admin could export | Faster, but rely on the audit log being complete |
| Vendor-side breach of a cloud service | Rotate connector trust, DKIM keys and API credentials; keep service if the vendor's scope statement holds | Continuity versus trusting the vendor's investigation |
| Small organisation without a standby gateway | Fall back to the mail platform's native protection | Possibly weaker filtering for a period; warn users |
| Large organisation with several gateways | Drain mail to unaffected nodes or regions | Needs tested routing changes and capacity |
Detection and measurement
- Time to safe mail path: minutes from declaration to inbound mail flowing around the compromised gateway.
- Allow-list hygiene: share of allow entries with an owner and an expiry; target 100%.
- DKIM rotation readiness: a pre-published next selector exists for every signing domain.
- Purge completeness: malicious messages delivered in the window that were removed, out of those found.
- Credential coverage: items the gateway holds that have documented rotation steps.
- Exposure: number of gateway admin or quarantine interfaces reachable from the internet; target zero.
Framework mapping
| Framework | Reference | Where it applies |
|---|---|---|
| NIST CSF 2.0 | RS.MA-01, RS.AN-03, RS.MI-01, RS.MI-02, RS.CO-02, RC.RP-05 | Response with the vendor, analysis, containment, eradication, notification, verified restore |
| NIST SP 800-53 Rev. 5 | IR-4, IR-6, IA-5, SC-12, SC-17, CM-3, SI-4 | Incident handling, authenticators, keys, certificates, change control, monitoring |
| NIST SP 800-177 Rev. 1 | Trustworthy Email | SPF, DKIM, DMARC and TLS for mail |
| CIS Controls v8.1 | Control 9, Control 15, Control 17 | Email and web browser protections, service providers, incident response |
| ISO/IEC 27001:2022 Annex A | 5.14, 5.24 to 5.28, 8.24 | Information transfer, incident management and evidence, use of cryptography |
| MITRE ATT&CK | T1190, T1685, T1114.002, T1649, T1199 | Exploitation, defence impairment, mail collection, certificate theft, trusted relationship |
Common failure patterns
- Patching a rooted appliance and calling it fixed. In 2023 the affected vendor stated that compromised appliances must be replaced regardless of patch version level.
- Forgetting the certificate that links the service to your mail platform. In the Mimecast certificate compromise, a stolen certificate used to connect an email security service to Microsoft 365 became the route into customer tenants.
- Rotating DKIM by reusing the selector. M3AAWG advises against reusing selector names; a new selector also makes it clear which key signed which message.
- Leaving the old inbound connector open. If the mail platform still trusts the old gateway's addresses or certificate, an attacker can keep injecting mail.
- Skipping the delivered mail review. Phishing let through during the window keeps working after the gateway is replaced; see the Business Email Compromise Response Playbook if accounts were taken over.
Practitioner checklist
- Keep an inventory of every credential, key and certificate the gateway holds, with rotation steps.
- Test the alternative mail path at least once a year.
- Pre-publish a standby DKIM selector for each signing domain.
- On compromise, isolate the gateway and remove the mail platform's trust in it.
- Disable the mailbox application identity before removing its credentials.
- Replace compromised appliances; rebuild policy from a reviewed baseline.
- Review allow-list changes and quarantine releases for the whole window.
- Purge malicious mail delivered during the window and warn recipients.
- Check the mail platform for new rules, connectors and consents.
- Preserve gateway and mail platform logs before retention expires.
Standards and references
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST: SP 800-177 Rev. 1, Trustworthy Email
- CISA: Known Exploited Vulnerabilities Catalog
- M3AAWG: DKIM Key Rotation Best Common Practices
- Microsoft: Compromised and malicious applications investigation
- Microsoft: Role Based Access Control for Applications in Exchange Online
- Barracuda: ESG vulnerability notice (CVE-2023-2868)
- Cisco: Security advisory for CVE-2025-20393
Related NHI Mgmt Group resources: Email Security Guide · Securing the email security gateway itself · Edge Device Compromise Investigation Playbook · Microsoft 365 Tenant Compromise Playbook · Email security gateway integration security guide