Architecture and operating model
A backup mail exchanger is a secondary MX service intended to accept incoming messages temporarily and retry delivery when the primary mail server is unavailable. A reliable design considers DNS preference, delivery routing and queue limits together.
A lower MX preference value has higher priority. A primary record at 10 and a secondary at 20 do not make 20 the stronger route. Senders perform delivery attempts under SMTP rules and their own retry behavior; adding a secondary record does not guarantee an immediate switch for every message.
Define how accepted messages reach the destination. The secondary's delivery route must not resolve back to itself. Restrict relay to authorized domains and test invalid-recipient handling and open-relay prevention. Postfix's primary and secondary MX examples illustrate why these tasks require configuration beyond a DNS record.
SecuraWall Backup MX is a standby service that accepts eligible messages when destination unavailability is confirmed. Content filtering and personal quarantine are outside the standalone package. Its temporary queue is neither a recoverable archive of delivered messages nor outage webmail. This distinction prevents secondary MX from being confused with mailbox backup.
- 1Primary MX attempt
- 2Secondary route and acceptance
- 3Temporary outage queue
- 4Destination delivery retry
Design parameters
- MX preference
- Verify primary and secondary hostnames at authoritative DNS; equal preference represents a different routing design.
- Outage acceptance
- Determine whether acceptance is continuous or tied to confirmed failure; monitor health information age and alerts.
- Queue contract
- Confirm retention, size, capacity, permanent rejection and expiry behavior against current terms.
- Relay and recipient scope
- Relay only verified customer domains; test destination recipient rejection separately from unauthorized-domain relay.
Worked example
For a lab domain, publish primary MX preference 10 and secondary preference 20. Send from two independent external systems and record normal delivery first. Then interrupt only the controlled test destination. Measure when each sender reaches the secondary and record queue identifiers for accepted messages. The experiment exposes sender-dependent failover timing.
When the destination returns, verify delivery in destination SMTP logs and the mailbox. An empty secondary queue does not establish that every message succeeded: reconcile permanent rejection and expiry records too. Keep invalid-recipient tests separate from real users and restore DNS and connectivity restrictions afterward.
Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| The secondary receives no attempts | DNS preference, caches or sender retry behavior may explain it. | Correlate authoritative DNS answers with independent sender records. |
| Queue grows although the target appears online | TCP may work while TLS or recipient acceptance fails. | Inspect the full SMTP result from the last attempt. |
| Relay to an unrelated domain is accepted | Relay scope may be too broad. | Run an authorized laboratory test against an unapproved domain. |
Acceptance checks
- Verify preferences in authoritative DNS answers.
- Record normal primary delivery.
- Test a controlled outage from two independent senders.
- Track every accepted message through its queue identifier.
- Reconcile delivered, rejected and expired outcomes after recovery.
- Verify relay boundaries and recipient error handling.
Related concepts
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.
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.
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.
Capacity and usable headroom
Raw capacity is not the capacity available to applications. RAID or erasure coding, filesystems, reserved space, metadata, snapshots and growth headroom are separate deductions. TB and TiB representations also change the displayed number. Write calculations with units, establish protected usable capacity, then subtract operating reserves. Track growth rate as well as current utilization. The projected exhaustion date should leave enough time to procure and deploy additional capacity.
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.
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.