Backup MX vs a Primary Email Security Gateway

Backup MX supports the secondary route

A backup mail exchanger has a higher numeric MX preference than the legitimate primary records. The primary route remains preferred. SecuraWall Backup MX normally stays on standby while the primary is available and can queue eligible mail during temporary destination outages. Mail delivered directly to the working primary never passes through SecuraWall. Backup MX does not apply content scanning or personal quarantine.

Email Security inspects the primary route

SecuraWall Email Security requires gate.securawall.com as the only published MX. Save and verify the actual receiving destination before changing DNS. Enabled policies inspect incoming gateway traffic; authorized users can review quarantined messages. Accepted mail can also queue during temporary destination outages. Receiving-side restrictions are needed where direct-delivery bypass must be prevented.

Compare the setup, not just MX preference

For Backup MX, keep legitimate primary MX records and give the gateway a higher preference number. For Email Security, remove alternative published MX records after validating the real onward target. Publish and retain the current ownership TXT record in both cases. Neither service creates remote mailboxes or changes the customer’s mailbox passwords.

Understand what continuity means here

Both services can retry accepted messages within their configured queue lifetime. Neither guarantees unlimited storage, a fixed recovery time, inbox placement or access to mailboxes during an outage. Permanent destination rejection and queue expiry are different from temporary delivery delay. A permanent archive or outage webmail service is a separate requirement.

Keep outbound sending separate

SMTP Relay is an optional outbound add-on for an active base service on the same domain. It does not upgrade Backup MX into incoming protection or alter the receiving MX route. Sending approval, account authorization, TLS, SPF and quotas apply; customer DKIM signing is optional and recommended. An alternative sending route is not a guarantee of inbox delivery or blacklist removal.

Plan a controlled change

Record existing DNS, receiving settings and service dates. Validate the target and recipient acceptance, then change the route and test delivery to your own mailbox. When returning to Backup MX, restore the real primary MX topology. Review queue state and destination results after a change; changing DNS does not move messages already queued on another sender’s system.

References and service conditions

• SMTP mail routing: RFC 5321
• Cisco: email security deployment approaches
• Current plan limits
• Security responsibilities