Architecture and operating model
An SMTP sender tries recipient-domain MX records in priority order. If the primary target is temporarily unavailable, a suitable Backup MX can accept and queue the message, retrying delivery after recovery. This does not provide mailbox access or archiving; it holds inbound messages under controlled policy during an outage.
A Backup MX must not become an open relay. It should accept only authorized domains, define recipient-validation strategy, enforce message and queue limits, and specify failure modes for spam and malware controls. A permanent 5xx response from the primary must not be treated like a network failure or temporary 4xx response.
A lower numeric value means higher MX preference. Failover still depends on sender retry policy, DNS caching, connection timeout and greylisting. Draining an accumulated queue with unlimited concurrency can overload the recovered primary, so delivery rate and parallelism should ramp up under control.
Doz Teknoloji's SecuraWall MailFlow provides Backup MX, SMTP Gateway, AntiSpam and Antivirus services within Email Security and Continuity. This layer does not replace independent data backup or mailbox archiving; domain routing, target validation and acceptance policy must be tested for each organization.
- 1Sending MTA and DNS MX
- 2Backup MX acceptance and scanning
- 3Durable queue and retry
- 4Primary mail server
Design parameters
- MX and TTL
- Plan TTL before cutover; validate preference, target names and A/AAAA resolution through external resolvers.
- Recipient validation
- Accepting invalid recipients and bouncing later can create backscatter; test directory/SMTP validation and failure behavior.
- Queue capacity
- Calculate incoming rate × average encoded size × outage duration, adding peak and overhead headroom.
- Recovery rate
- Set concurrency and rate against primary capacity, backing off on 4xx responses.
Worked example
At 12,000 messages/hour, 250 KiB average encoded size and an eight-hour outage, raw queue data is about 24 GiB. Large messages, indexes, logs and 30% headroom suggest at least 32 GiB of working space; this example is not a capacity guarantee without measured distribution.
During a maintenance test, stop the primary SMTP target under change control. Send an external message with a unique Message-ID and verify the Backup MX acceptance response and queue record. Restore the target, then confirm one delivery and recorded queue age and final SMTP response.
Example commands: replace lab values and confirm permissions and software versions before use.
dig +short MX example.com
openssl s_client -starttls smtp -connect mx-backup.example.net:25 -servername mx-backup.example.net
# Use an authorized test identity and unique Message-ID; never probe for open relay in production.Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Sender never reaches Backup MX | MX data, DNS cache or sender connection policy may intervene. | Test external MX resolution, target A/AAAA records and TCP 25 independently. |
| Queue grows while primary is online | TLS, recipient rejection, rate limiting or routing may block delivery. | Correlate the last SMTP response and target connection log for one Queue ID. |
| Primary fails again during drain | Queue delivery concurrency may exceed target capacity. | Measure active sessions, 4xx rate and throughput, then apply a controlled ramp-up. |
Acceptance checks
- Reject relay attempts for unauthorized domains.
- Verify a test message in queue during primary outage.
- Test invalid-recipient behavior and backscatter boundaries.
- Exercise queue disk and age alerts.
- Validate single delivery by Message-ID after recovery.
- Document that Backup MX is not webmail, archive or independent backup.
Related concepts
DNS caching and dependencies
DNS results depend on client and recursive-resolver caches as well as authoritative data. Changing a TTL does not retroactively shorten already cached answers. A/AAAA, CNAME, MX and TXT records serve different purposes. Test internal and external views separately; split DNS may intentionally return different results. Record resolver, response type, TTL and query time when troubleshooting. Successful access by IP address alone does not prove correct DNS configuration.
Queues and concurrency
A queue holds work arriving faster than a resource can process it. More concurrency can improve utilization up to a point, then increase waiting time. In a stable system Little’s law relates L = λ × W: average work in the system equals throughput multiplied by average total time. Units must agree. At 2,000 operations/s and 5 ms total time, roughly 10 operations are present concurrently. This is a planning relationship; queue limits, bursts and highly variable service times still require measurement.
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.
Failover and failback
Failover moves service to another component; failback returns it to the preferred location. Their risks and sequencing may differ. DNS updates, routing, sessions, replication lag and application dependencies determine user interruption. Define failover triggers, false-alarm behaviour and approval for returning service. Simply shutting down a VM does not test every failure type. Measure network, storage and management-plane failures separately.
RTO and end-to-end recovery time
RTO specifies how soon a service must become usable after an incident. Downloading a backup or booting a VM accounts for only part of that duration. Record detection, approval, infrastructure preparation, data transfer, application startup and business validation separately. Define exactly what starts and stops the test clock. The same technical restore duration can produce different business interruptions when dependencies or access approvals introduce additional waiting.
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behaviour. A log describes an event, a metric shows behaviour 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.
Primary documentation
SecuraWall MailFlow
Email Security and Continuity
Backup MX, SMTP Gateway, AntiSpam and Antivirus services.
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.