What a gateway change has to carry over

A mail gateway usually holds more logic than is documented: allow and block lists, exceptions for individual senders, routing per domain, TLS requirements for partners, quarantine processes, disclaimers, journaling and submission by applications. Inline gateways in the MX path and API-based solutions also hook into Microsoft 365 at different points; switching between the two models changes connectors, Enhanced Filtering and the assessment by EOP.

Services

  • Mail security gatewaysProofpoint, FortiMail, Barracuda, Cisco Secure Email, xorlab and others: export the rule set, assess it and map it to the target system instead of carrying legacy configuration over one to one.
  • Move to Microsoft Defender for Office 365Remove the upstream gateway and carry its protection features over into EOP and Defender, including policies, quarantine and allow lists.
  • Bulk mail gatewaysSending systems for newsletters, invoices and customer communication: preserve load profile, IP reputation, SPF, DKIM, DMARC and bounce processing during the move.
  • SMS gatewaysMail-to-SMS and SMS sending from applications: switch interfaces, sender IDs and delivery receipts to the new provider.

How an engagement runs

  1. EvaluationMeasurable criteria and a requirements specification instead of product brochures, when the target system is still open.
  2. Rule set analysisRecord every rule and exception of the legacy system and decide: carry over, replace or drop.
  3. Parallel operationPart of the traffic through the new gateway, comparison of verdicts, delivery and load.
  4. Cutover and decommissioningSwitch MX and connectors reversibly, then remove the legacy system from DNS, SPF, allow lists and monitoring.

Real-world examples