Use the provider's documented receiving design and an agreed continuity plan; do not add an unrelated MX destination merely because its preference number is higher.
Before adding a second MX record, decide what “backup email” is meant to provide. Do staff need access to existing messages, somewhere for new messages to wait, or a completely separate contact route? Those are different purchasing and recovery requirements. A DNS preference number cannot answer all of them.
Consider a fictional repair shop whose main concern is missing booking enquiries during an outage. Someone suggests retaining an old mail provider as another MX destination. The shop should first compare the proposed service responsibilities. This example is a planning exercise; no domain, mailbox or delivery test was inspected.
What the preference number actually describes
RFC 1035’s MX definition contains a preference value and an exchange hostname; lower values are preferred. The record supplies routing information. It does not create the recipient’s mailbox or describe what a provider has agreed to operate.
Read the current mail provider’s complete receiving instructions before treating its multiple records as optional alternatives. Keep the published set together in the design review. Do not assign one destination to sales and another to support simply by giving them different preference numbers; the proposed recipient arrangement needs an actual service design.
The domain connection guide explains how website and email changes can interfere. Keep the mail review separate from a website migration, and identify who controls the authoritative records before planning any change.
Define the outcome the shop needs
The shop’s owner writes three requirements: customers should receive an understandable delivery outcome, accepted enquiries should remain recoverable, and staff need a known route back to normal work. Each requirement needs an owner and evidence. “There is another server in DNS” is not a sufficient acceptance statement.
RFC 5321 describes routing, equal-preference choices and retries. When there is no clear reason to favour one equal-preference destination, SMTP clients randomize their order to spread load. A temporary failure can leave mail queued; acceptance is not mailbox replication.
Translate the shop’s requirements into questions for the proposed provider rather than assuming its capabilities. What exactly is included? Which recipients are recognized? Where can the operator see the waiting messages? Who investigates a failed handoff? Ask for answers about the contracted service, not a general description of SMTP.
The shop might agree that staff can take urgent bookings by phone while a receiving incident is investigated. That is a business choice with a staffing requirement. Write down who answers, what customers are told and how those bookings return to the normal records afterward.
Compare the three proposals on responsibilities
| Proposed arrangement | What the shop must establish | Unanswered question to resolve |
|---|---|---|
| Main provider’s documented MX set | The complete supported configuration and outage process | How does support show the status of an affected enquiry? |
| Contracted continuity receiver | Recipient rules, retention, handoff and monitoring responsibilities | What happens when the normal destination remains unavailable? |
| Unrelated old provider retained in DNS | A current agreement to handle the shop’s mail correctly | Who has approved and maintains this second route? |
This matrix does not rate providers or claim an arrangement has passed. It exposes missing ownership. If the old provider cannot describe its role in the current plan, the shop has not established a continuity service merely by remembering that it once used that account.
A continuity requirement can also include a separately published contact method. Decide who monitors it and when customers should use it. Keep that promise realistic: an unmonitored alternate address is not an operational recovery route.
Ask what happens to each recipient
Make an inventory of the shop’s intended recipient roles without publishing real addresses. Include its booking address, staff mailboxes and aliases that matter to customers. Ask the proposed receiver how it obtains and maintains the approved recipient list.
Then review a normal enquiry, an address that does not exist and an address retired after a staff member leaves. The service should have a documented answer for each. Do not request an unrestricted relay as a shortcut around recipient management; that creates an entirely different and unsafe operating model.
Keep these proposed cases distinct from observed results. A provider’s written explanation is useful design evidence, while a controlled test would supply delivery evidence. Record which kind you have. Do not claim successful operation before the agreed journey has actually been checked.
Specify handoff, retention and visibility
For the hypothetical continuity receiver, ask who owns the waiting-message view, its access rules and the escalation route. Agree how the shop will recognize an enquiry that has not completed its intended journey. The owner should not need to discover that problem only when a customer phones.
Request the service’s documented retention and failure-notification policy instead of inventing a universal waiting period. If the interruption exceeds that policy, what should the shop do? Keep an alternative contact and communication plan available without promising that every outside sender will behave identically.
Also decide how the normal receiver is identified after a repair or migration. A continuity service with no approved destination or accountable handoff owner leaves an important step undefined. The mail-provider migration guide covers the wider transition and existing-message work.
Do not confuse missing MX with an explicit refusal
RFC 7505 defines Null MX: a single record with preference zero and the exchange “.” declares that a domain does not accept mail. It must not coexist with ordinary MX records. An absent MX record is not the same explicit declaration.
The fictional shop intends to receive enquiries, so Null MX is not its outage remedy. Do not paste a no-receiving-service example into the live domain while trying to fix delivery. If a separate domain genuinely should never receive mail, treat that as its own reviewed configuration decision.
If customers receive an error, preserve the relevant delivery report privately and identify what failed before changing records. The bounce interpretation guide helps separate temporary trouble from a permanent rejection without repeatedly sending the same message.
Accept a continuity plan before changing DNS
- Write the required customer and staff outcomes, including access to existing correspondence where needed.
- Confirm the main provider’s supported receiving configuration and the proposed secondary service’s responsibilities.
- Agree recipient handling, visibility, retention, handoff and escalation in writing.
- Plan controlled checks using authorized test addresses, with expected outcomes and rollback instructions.
- After approval, have the responsible operator implement and verify the specific design.
The aim is a supported receiving arrangement whose responsibilities remain clear during an outage and recovery. Keep a routing plan, a continuity service and recovery of stored correspondence as separately evidenced requirements, even when one provider supplies more than one of them.
Sources and verification
Editorial review 2026-10-15. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- RFC 1035: MX resource recordsChecked MX preference and exchange hostname; lower preference values are preferred.
Limits: A routing record does not create a mailbox or define a service contract. - RFC 5321: SMTP routingChecked Candidate selection and retry behaviour.
Limits: Acceptance does not establish mailbox replication. - RFC 7505: Null MXChecked An explicit no-receiving-service declaration, distinct from an absent MX record.
Limits: Null MX must not coexist with ordinary MX records and is inappropriate for a domain intended to receive mail.