Skip to content 
MX records control which mail servers receive incoming messages for a domain, and they use priorities to determine the order in which connections are established. I will show you how to MX Records correctly, choose priorities sensibly and plan the entire email delivery path so that your mail hosting works reliably.
Key points
For quick orientation, I will briefly summarize the most important aspects of mx record routing and highlight the core topics that you should master for secure mail hosting. I keep the list short and only include points that you can apply immediately. Based on practical experience, I prioritize those settings that avoid downtime. You will find the relevant details for each keyword later in the article. For more in-depth configurations, I provide additional tips and typical stumbling blocks along the way so that you can Error from the very beginning.
- Priority determines the order: smaller number = first
- Redundancy Secure with multiple MX records
- Delivery path Understanding from DNS to mailbox
- TTL and propagation times
- SPF/DKIM combine for better delivery
I then go deeper into the technology section by section and translate the concepts into comprehensible configurations. In doing so, I focus on Practice and clear action steps.
How MX Records control the routing
An MX record tells sending servers which host accepts emails from your domain, and thus directs the Routing the delivery. I set at least two MX entries per domain so that another host can be reached immediately if the first host fails. I can define separate MX destinations for subdomains if separate mailboxes or special gateways are required. The DNS zone contains the name, target host, priority and a well-dosed TTL value. To get you started, the compact MX-Records Guide, with which you create and check entries cleanly; I refer to this when you plan the first tests.
When sending, the sending remote station first queries the DNS for MX records and then establishes an SMTP connection to the preferred host. I also pay attention to A or AAAA records of the destination host, because an incorrect destination name stops any mail flow. Short TTL values accelerate changes, while longer values reduce the load on requests; I select the appropriate value depending on the project. Compromise. This means that your mailboxes remain accessible even if you swap destinations or change gateways. It is always crucial that the MX hosts themselves can be resolved correctly and are accessible via SMTP.
Understanding priorities: low number, high weighting
The MX priority is an integer, and the smallest number wins the MX priority. right of way. If you set two hosts with the same priority, they share the incoming traffic alternately, so to speak. I like to use this for load balancing with equivalent systems. For a clear failover, however, I plan one level higher, for example 10 for primary and 20 for backup. This way, the backup system reliably steps in as soon as the first host does not respond or returns an error.
The same priority is suitable for peering clusters, different values for high availability with a clear sequence. After each change, I confirm by test sending and log which MX has actually accepted. This allows me to recognize incorrect settings early on and correct them. Sequence, before users experience downtime. Sensibly set priorities reduce support requests and keep delivery consistent. Also keep in mind that some gateways have limits or anti-abuse rules that can affect connections.
Email Delivery Path step by step
When sending, the sending server resolves the recipient domain, reads the MX records and establishes the SMTP connection to the preferred host; I call this path the Delivery path. After a successful SMTP handshake, the target server accepts the message, saves it and transfers it internally to the mailbox system. The recipient then accesses it via IMAP or POP3, while the server applies spam filters and virus checks in parallel. If an MX fails, the sender automatically tries the next priority level. This means that delivery remains available even in the event of maintenance or location problems.
I check this process with tools such as dig/host and a short SMTP test via Telnet or OpenSSL. These checks show in seconds whether the DNS and MX chain are working properly. Without correct host resolution or with a typing error in the destination name, the dispatch immediately ends in an error. That's why I first set up a stable DNS base and then train recurring Checks for operating teams. This means that the path from the DNS to the mailbox remains transparent and traceable.
Typical configurations and failover strategies
For many projects, I use two to three MX hosts of the same rank and add a pure backup host with a higher rank. Priority. This combines load distribution and a clear fallback level. In smaller setups, one primary plus one backup is often sufficient, whereby both locations should use separate network connections. I prefer speaking host names such as mx01.domain.tld, mx02.domain.tld and mxb.domain.tld, so that I can immediately recognize in logs which host has accepted a message.
The following table summarizes common patterns and helps to structure your own planning. I organize examples by role and add notes for the company. This allows you to quickly transfer the structure to your Mail hosting and minimize failed attempts.
| Priority | Hostname | Role | Note |
|---|---|---|---|
| 10 | mx01.example.de | Primary | Main objective; high availability, monitoring active |
| 10 | mx02.example.de | Primary (of equal rank) | Shares load with mx01; identical policies |
| 20 | mxbackup.example.de | Backup | Intervenes in the event of a fault; limited retention |
| 30 | filter.example.de | Gateway | Only if connected upstream; otherwise omit |
I test each configuration with real deliveries and compare the logs of all hosts. Only when all paths are working properly do I shorten the test plan to a few regular checks. Checks. This keeps operations lean and keeps response times to faults short. For locations with a high volume of mail, capacity planning with clear alarm thresholds is also worthwhile. This pays off especially during peak loads.
TTL, caching and propagation without surprises
The TTL value determines how long resolvers cache your MX responses; I often start with 3600s, because this makes changes visible more quickly. Shorter TTLs are suitable before planned changes, longer TTLs reduce the DNS load during quiet phases. After a change, depending on the provider and cache runtime, it takes a little patience for every sender to see the new MX. I therefore plan changes outside of core times and have a rollback ready. If you plan soberly, you save yourself night shifts and obvious downtimes.
It is also important that the TTLs of all records involved match: MX, A/AAAA and, if applicable, CNAME destinations. Different runtimes can temporarily create mixed states. With controlled TTL windows and clear milestones, I keep the change clear. This includes a final check with several independent resolvers. This routine brings Migrations Calm in the process.
MX Record Routing with Microsoft 365 and Google Workspace
If you move to Microsoft 365 or Google Workspace, I completely replace the existing MX targets with the specifications of the service. Mixed constellations with local mailboxes and external suites otherwise quickly lead to loops. In such scenarios, I remove superfluous forwarding and double-check transport rules. I also check that SPF entries include the new sending IPs. This is the only way to avoid rejections by restrictive recipient systems.
After the MX changeover, I always test a dispatch from outside and inside to verify the line and return routes. Logs in the suite and on gateways clearly show which MX has taken effect. Then adapt spam and malware policies to the new platform. This ensures consistent Policies across all mailboxes. If you migrate cleanly, you won't experience any nasty surprises the next day.
Practice: Setting up MX in hosting panels
In most panels, I open the DNS management, select the MX type, set the host name, destination and priority, set the TTL and save the Amendment. I then check the display in the zone file and manually trigger a dig/host check. I then test the dispatch from an external account and check the header for the accepted MX. If the resolution still shows old values, I wait for the TTL runtime and validate again. Only when routing and delivery are clean do I inform users about ready mailboxes.
As a little reminder, I keep host names consistent and document each priority with a purpose, such as Primary, Primary2, Backup. This clarity helps enormously with fault analyses. I also check that there are no more historical MX entries. Old destinations often cause confusion in the Operation. A quick DNA hygiene check will save you from lengthy tickets.
Fix common errors quickly
Incorrect priorities lead to unnecessary delivery attempts on less suitable hosts; I correct these Values immediately and test again. Typos in the destination host stop any delivery, so I meticulously verify spellings. Missing backup MXs are a nuisance in the event of failures, which is why I set at least one alternative route. Forgotten old entries cause sporadic misrouting, so I consistently delete obsolete records. If propagation takes time, I plan this phase transparently and wait patiently instead of resaving every minute.
If a host shows persistent rejections, I check spam policies, greylisting and TLS requirements. I use logs to determine whether rate limits or blocklists are the cause. If an error occurs after a change, I roll back specifically and analyze at my leisure. This controlled reaction reduces Downtime and avoids hectic consequential damage. Good notes make all the difference here.
Strengthen deliverability: SPF, DKIM, DMARC
A clean MX setup only solves part of the delivery challenge; I always add SPF, DKIM and DMARC for clean Authentication. SPF defines which servers are allowed to send for your domain. DKIM signs emails cryptographically, and DMARC defines guidelines for dealing with faulty messages. This combination increases trust and reduces suspicion of spam. For a quick introduction, the overview of SPF, DKIM and DMARC, which I regularly use as a checklist.
After setting it up, I check the header evaluation of the recipients with a test dispatch. If all checks pass, bounces and quarantines drop noticeably. Make sure to keep the DNS keys up to date and renew expired keys in good time. With automated reminders, the Integrity are retained. This means that your MX and policy settings act as a cohesive unit.
Monitoring and testing: tools and CLI
I check MX and target hosts regularly with dig, host and short SMTP checks, because early Warnings Shorten disruptions. A monitor checks port 25, TLS certificates and response times. I also evaluate mail server logs and set alarms for error codes that indicate delivery problems. Clear documentation of the test steps is worthwhile for admin teams. Standardizing tests saves time and significantly reduces follow-up costs.
The finishing touches also include a DNS quality check, which detects inconsistencies and ensures consistent TTLs. You can find a helpful practical overview at DNS management at all-inkl, which I like to use as a guide for recurring checks. I also use periodic live tests with real mails so that I can see the full chain from the DNS to the mailbox. Such real-world checks uncover special cases that synthetic tests don't touch. This keeps your Quality high in day-to-day business.
Valid MX destinations: RFC traps and name resolution
For stable delivery, I strictly ensure that an MX record is based on a Hostnames never points directly to an IP. The hostname itself should be resolvable with A and, if desired, AAAA records. I avoid CNAMEs as MX targets because in practice they can lead to unexpected resolution paths and errors. If a provider does technically introduce a CNAME, I test the entire chain intensively using DNS traces and real deliveries.
In the panel, I set the target name as a fully qualified host (FQDN). Some interfaces expect a final dot, others add the zone automatically; I check the resulting zone file so that no relative name is created. An accidentally relative host (e.g. „mx01“ instead of „mx01.example.de.“) often ends up in NXDOMAIN situations. Finally, I validate each MX with an authoritative query against the responsible name servers and check whether hosts can be resolved correctly via both IPv4 and IPv6 - including negative tests for typing errors so that I can avoid such problems at an early stage.
Operating Backup-MX correctly: Queue, policies, misunderstandings
A backup MX is only helpful if it contains the same Policies like the primary host. I therefore activate identical anti-spam rules, greylisting behavior and recipient checking. The backup should detect unknown recipients while of the SMTP dialog (recipient verification, e.g. via callout or synchronized recipient maps) and not generate NDRs only after acceptance - this way you avoid backscatter. Otherwise, spammers will deliberately choose the „softer“ target.
For the queue, I plan conservative but limited retention (around 2-5 days) and a traceable retry interval. I monitor hard disk space, queue length and defer rates so that a failure does not lead to unnoticed congestion. The backup MX must never refer back to the primary as a smarthost if it is already the target of the delivery - otherwise there is a risk of Loops. Also important: The HELO/EHLO identity and banner of the backup host are set correctly so that senders retain trust and can clearly assign logs if required.
Dual stack, TLS and certificates on MX hosts
I prefer to operate MX-Hosts dual stack with A and AAAA records. Many senders test IPv6 first; if port 25 v6 is closed or limited, sending switches to IPv4 - but time is lost in the process. I therefore make sure that firewalls release port 25 for both protocols, ICMP is essentially permitted (for path MTU) and monitoring checks both stacks. For STARTTLS, I set certificates that carry the specific MX host names in the SAN. Wildcards help if there are many nodes, but I still prefer clear, explicit entries.
For hardened transport encryption, I plan to use modern cipher suites and activated TLS 1.2/1.3. Optionally, I set up MTA-STS in a gentle „testing“ phase and only switch to „Enforce“ once the results are stable. DANE (TLSA) can be supplemented with DNSSEC; I check the DNS chain particularly carefully because faulty TLSA records can severely impair incoming connections.
Split horizon, gateways and internal routes
In networks with separate internal and external recipients, I often use Split-Horizon DNS external resolvers see public MX destinations, internal clients receive MX entries to internal gateways or directly to the mailbox servers. This reduces latencies and avoids unnecessary detours via Internet gateways. I ensure that internal zones are not inadvertently published externally and that naming conventions remain consistent.
In hybrid environments with upstream filters or DLP systems, I check that the MX destinations only show the dedicated ingress gateways. Internal transport rules must not result in a mail accepted from outside being sent back to the Internet. I document the direction of all routes (inbound, internal, outbound) and specifically test special cases such as large attachments, NDRs and forwarding. This is how I keep the Delivery path free of loops and dead ends.
Orderly migration: step sequence and rollback
For MX changeovers, I follow a clear timetable with a lead and fallback level:
- Inventory: check current MX, host resolution, certificates, policies and monitoring.
- Reduce TTL: MX and target hosts to 600-1800 seconds, in good time before the change.
- Connect a new destination: First enter the new MX with a higher priority number, have tests delivered and monitor logs.
- Proof of functionality: Validate SMTP handshake, TLS, spam filter, recipient check and queue behavior with real mails.
- Switch over: Set priority of the new primary to the lowest number, temporarily tighten monitoring thresholds.
- Observe: closely monitor for 24-48 hours, keep an eye on error codes and latencies.
- Clean up: Remove old MX entries, raise TTLs again, update documentation.
- Rollback ready: As long as the old infrastructure is still in place, I can quickly roll back in the event of anomalies.
With this discipline, even large removals can be carried out without noticeable Downtime realize. It is important that all teams involved are aware of the plan and that a fixed communication channel is available for queries.
Special cases: subdomains, wildcards and international addresses
If I have subdomains such as support.example.de delivered separately, I define separate MX records for each subdomain. This helps to clearly separate teams or systems. I stay away from wildcard MXs („*.example.de“) because they can attract typos and unwanted recipient areas. It is better to only explicitly define required subdomains and leave all others unoccupied.
For international domains (IDN), I make sure that DNS is properly mapped in Punycode and that the MX destinations remain ASCII-compatible. For local parts of the address with umlauts (EAI/SMTPUTF8), I check the MTA support carefully. If systems have limitations here, I communicate clear naming conventions or use gateways that reliably reject incompatible paths instead of running into poorly legible error messages.
Capacity planning, limits and cluster consistency
To prevent load peaks from becoming a trap, I plan capacity at connection and content level. I define Uniform limits for MX hosts of the same rank (same connection and message rate limit) and keep spam and greylisting states synchronized if the products allow this. Otherwise it can happen that a sender is rejected at mx01 but still accepted at mx02 - this creates inconsistent behavior. Shared state or deterministic policies reduce such effects.
I constantly measure key figures such as connection attempts, acceptance rate, defer and reject rates, queue length, latency until acceptance, TLS usage rate and average message size. These metrics show early on when bottlenecks are looming (e.g. due to virus scan performance or limited I/O in the queue directory). When cluster changes are made, I synchronize configurations automatically to prevent policy drift. The result is stable, predictable behavior of all MXHosts in the network.
Interpreting error messages and targeted testing
Experience has shown that a small error message compass speeds up the analysis. Temporary errors (4xx) often indicate rate limits, greylisting or short-term network problems; permanent errors (5xx) indicate policy violations, non-existent recipients or TLS violations. I deliberately provoke test cases: wrong recipient, TLS enforced/not enforced, attachments too large, missing reverse lookups on the sending test system. This is how I check whether the reactions of your stack are consistent and understandable.
I do not rely on „round robin“ for MX hosts with equal priority. Many MTAs choose in random order or on the basis of internal metrics if they have the same preference. In practice, I check whether the distribution really evens out over a longer period of time and, if necessary, adjust limits or the number of equally prioritized hosts to avoid hotspots.
Brief summary for your routing
Correctly set MX records with well thought-out priorities form the basis of reliable email routing, which I secure with clear tests and supplement with SPF, DKIM, DMARC; this results in clean email routing. Processes without bottlenecks. Set at least one backup MX, plan TTL windows deliberately and check logs after each adjustment. Avoid legacy loads in the zone and manage hostnames consistently. Keep lean documentation ready that makes changes traceable. With this setup, your email delivery path remains transparent, fail-safe and easy to maintain.
If you would like to go into more detail or implement the setup step by step, I refer you to a compact Instructions for MX-Records, which you can use as a handy reference guide. Plan changes carefully, test each path thoroughly and have corrections ready. This will help you achieve a smooth Delivery - today and in the future.
