Architecture and operating model
Deploying an anti spam mail gateway requires a prepared destination and rollback path as well as an MX change. This guide turns inventory, pilot testing, delivery evidence and controlled cutover into an operational migration plan.
Inventory domains, aliases, distribution groups and application senders first. Configure an explicit verified destination rather than a general domain lookup that routes back to the gateway. This distinction helps prevent routing loops. An inbound security migration does not automatically change the outbound sending path.
Microsoft's third-party cloud filtering topology directs MX to the gateway and uses a connector for destination delivery. Preventing direct delivery from bypassing that path is a separate task. Do not add an inbound-only gateway to SPF merely because it receives your mail; reassess SPF when the outbound path changes. Track DNS, connector and security policy changes separately.
Schedule cutover during a quieter period and preserve previous settings. Reducing TTL does not invalidate previously cached answers retroactively, so allow the appropriate preparation time. Rollback must address queues on both systems, connector restrictions and delivery responsibility as well as restoring the previous MX record.
- 1Inventory and pilot
- 2Destination and connector tests
- 3Controlled MX cutover
- 4Monitoring and queue reconciliation
Design parameters
- Inventory and ownership
- Assign change owners for DNS, gateway and destination; exercise emergency access before cutover.
- Delivery destination
- Validate the real target hostname, TCP reachability, TLS behavior and recipient acceptance with a pilot domain.
- Test matrix
- Record separate scenarios for legitimate text, large attachments, aliases, invalid recipients and authorized security tests.
- Rollback thresholds
- Choose organization-specific delivery failure, queue age and business impact thresholds; do not present them as provider guarantees.
- Evidence
- Correlate timestamps, Message-ID, gateway transaction ID, destination SMTP result and mailbox checks for every trial.
Worked example
For an illustrative 200-mailbox migration, start with 10 test users on a pilot domain. Send from two independent external systems, including tests for an alias and distribution group. Locate each accepted message in the destination log and check the mailbox. An SMTP 250 response alone does not prove inbox placement.
An example rollback trigger is unexplained queue age beyond five minutes or failure to deliver to a critical team. First distinguish DNS, connectivity and recipient policy faults. If you roll back, track messages already accepted by the new queue. Reconcile transaction records rather than draining both systems without coordination.
Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| A message returns to the gateway | The target route may resolve back through public MX. | Inspect the transaction chain and explicit delivery destination. |
| Only certain recipients fail | The alias, group or recipient-validation inventory may be incomplete. | Compare acceptance records for working and failing recipients. |
| Authentication scoring changes after cutover | The connector may interpret source context incorrectly. | Review original headers and the platform's Enhanced Filtering configuration. |
Acceptance checks
- Confirm domain, alias, group and application inventory.
- Prove destination delivery before changing DNS.
- Complete connector and direct-access tests.
- Record TTL preparation and cutover time.
- Test valid and invalid recipients end to end.
- Reconcile both queues after any rollback.
Related concepts
Trust boundary and failure domain
A trust boundary separates components governed by different access decisions; a failure domain groups resources that one event can affect together. Two VLANs do not create a strong trust boundary when routing between them is unrestricted. Backups in different folders still share a failure domain if one administrator can delete both. Assess physical location, identity provider, management account, network path and power source separately. Test which access paths and recovery options remain available when a component is lost.
Authentication and sessions
Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new access attempts are denied when the identity provider becomes unavailable.
TLS and certificate validation
TLS protects confidentiality and integrity in transit; certificate validation helps verify the peer’s identity. Evaluate names, chains, validity periods and trusted roots together. Encryption does not prove correct application authorization. If a reverse proxy or inspection device is used, show where TLS terminates. Disabling validation is not a permanent troubleshooting solution: investigate hostname mismatch, missing intermediate certificates and incorrect device clocks separately.
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behavior. A log describes an event, a metric shows behavior over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
Availability versus recovery
High availability aims to keep service running through specified failures with a short interruption; backup recovers lost or corrupted data from an earlier point. A cluster can replicate an accidental deletion to another node. HA therefore does not replace backup. Consider DNS, identity, network, storage and power dependencies together. Successful node failover is insufficient by itself: measure user sessions, application writes and external integrations after the transition as well.
Policy lifecycle
A policy needs management as its scope changes, not just when it is enabled. Separate drafting, observation, pilot deployment, enforcement and periodic review. Every exception needs an owner, reason, scope and expiry date. A successful pilot can still cause production false positives if test data does not represent real user behavior. Identify affected users and applications before deploying with measurable acceptance criteria. A rollback path should identify who may reverse the change and under which conditions, rather than merely locating an interface button.
Primary documentation
Explore cloud email security and continuity
Review cloud email security and Backup MX options with SecuraWall MailFlow, operated by Doz Teknoloji. Assess setup requirements against your existing mail infrastructure.
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.