Backup MX is a secondary incoming mail service intended to receive and queue eligible mail when a primary receiving system is unavailable. “Secondary MX” describes a less-preferred mail exchanger in DNS; “Backup MX service” describes the operational service behind that route. Publishing an extra MX record alone does not create a reliable delivery queue.
Secondary MX is a route; continuity is a process
An MX record contains a preference number and a mail-server hostname. Sending systems prefer lower numbers. A secondary exchanger is commonly published with a higher number than the primary so it is a less-preferred delivery candidate.
Consider an example domain with a primary mail exchanger at preference 10 and a backup at preference 20. Those numbers describe ordering, not seconds, percentages or guaranteed recovery time. Whether a sender reaches the backup depends on its SMTP behavior and the failure it encounters.
What happens during an outage?
A functioning backup service needs more than DNS. It must know the permitted recipient domain, the real destination for later delivery and the rules for accepting mail. If it accepts responsibility for a message during an outage, it stores that message temporarily and attempts delivery to the destination.
SecuraWall standalone Backup MX follows a standby model governed by scheduled health observations. When the primary is observed as available, it defers senders to retry the primary. During an eligible outage, accepted messages can enter its temporary queue. The service is not an alternate user mailbox.
Temporary queue versus mailbox backup
A delivery queue holds accepted mail that has not yet reached its destination. It is not a long-term mailbox archive, historical restore service or outage webmail system. Employees should not assume that adding Backup MX lets them read all their mail during a server outage.
Queue retention, retry intervals and message-size limits determine the practical boundaries of the service. Read the current values before making a recovery plan. Also decide what the team will do if an outage lasts longer than the queue lifetime.
Keep the destination independent of the public backup route
The backup service needs a destination that identifies the receiving server. Pointing that destination back at the public backup route can create a loop. Confirm the correct receiving hostname and permitted traffic with the mail-server administrator before changing DNS.
Two different MX names are not proof of redundancy: they might resolve to the same host or depend on the same network. Ask how the backup route is separated from the primary system, and test the complete recovery path rather than only checking that both records exist.
Does Backup MX include spam filtering?
That depends on the service. SecuraWall standalone Backup MX does not include incoming content inspection or personal quarantine. SecuraWall Email Security adds those supported incoming controls and includes Backup MX continuity. Choose based on whether the immediate goal is outage queuing, incoming protection or both.
What to verify before enabling a secondary MX
- Confirm the primary MX records and their preference values.
- Configure the backup destination and authorized domain before publishing the route.
- Check current queue retention, retry and accepted-message limits.
- Arrange a controlled outage test and confirm the observed standby behavior.
- Restore the receiving system and trace accepted mail through to its final delivery outcome.
Use the free MX Lookup to inspect published records. Then review Backup MX service scope and current limits or compare Backup MX with Email Security.
Technical reference
SMTP route selection and retry behavior are described in RFC 5321. The DNS lookup is one part of delivery, not an end-to-end availability test.