Multiple MX records allow a domain to specify more than one server for receiving email. They help sending mail servers choose a preferred destination and, when properly configured, provide alternatives if a server becomes unavailable.
For businesses managing several email domains, MX records are fundamental to reliable inbound email routing. They determine where incoming messages, customer inquiries, and cold email replies are delivered.
But there is an important distinction: multiple MX records do not automatically mean better email deliverability, balanced traffic, or support for multiple mailbox providers.
A poorly configured secondary server can create more problems than it solves.
This guide explains how to configure multiple MX records, understand MX priorities, manage email routing across several domains, and troubleshoot common DNS problems. It also covers Google Workspace, Microsoft 365, Hostinger, backup MX servers, and multi-domain cold email infrastructure.
TL;DR: Multiple MX Records Explained
Yes, a domain can have multiple MX records. Each record identifies a possible destination for incoming email.
Lower priority numbers are preferred. A server with priority 10 is normally tried before one with priority 20.
Equal priorities allow distribution. Sending servers randomize among equally preferred MX destinations, but an exact 50/50 split is not guaranteed.
Backup MX records require proper configuration. A backup server must accept and correctly handle messages for your domain.
MX records do not split individual mailboxes between providers. Using Google Workspace and Microsoft 365 for different users on one domain requires a supported routing arrangement.
MX and SMTP submission settings are different. MX controls inbound routing; SMTP submission settings control how email clients send outgoing mail.
For multiple domains, verify each domain separately. A correct MX record on one domain does not mean the others are configured correctly.
Quick answer: If you use a managed mailbox provider, follow its published MX configuration. Add additional records only when your provider or mail-routing architecture requires them.
What Are MX Records?
MX stands for Mail Exchanger.
An MX record is a DNS record that tells sending mail servers which hosts are responsible for accepting email addressed to a particular domain.
Suppose someone sends an email to:
hello@example.com
The sending mail server needs to discover where email for example.com should go.
It queries the domain's MX records, selects an appropriate mail exchanger, resolves that hostname to an IP address, and attempts SMTP delivery.
A typical MX record looks like this:
The record contains several components.
Component | Example | Meaning |
|---|---|---|
Domain | example.com | Domain receiving email |
TTL | 3600 | DNS cache lifetime in seconds |
Class | IN | Internet DNS class |
Record type | MX | Mail exchanger record |
Priority | 10 | Preference for this destination |
Exchange | mx1.example.net | Receiving mail server hostname |
An MX record does not point directly to an IP address. It references a mail exchanger hostname, which must resolve to suitable address records.
This separation allows administrators to change a mail server's IP address without changing every domain's MX destination.
How MX records work during email delivery
The basic delivery sequence is:
A sender writes an email to
sales@example.com.The sending mail server queries DNS for the MX records of
example.com.DNS returns the configured mail exchangers and their priority values.
The sending system selects an eligible destination according to SMTP routing rules.
It resolves the selected mail exchanger's hostname.
It attempts an SMTP connection, typically on port 25.
The receiving server accepts, temporarily rejects, or permanently rejects the message according to its configuration and policies.
If delivery cannot be completed, the sending system may attempt another eligible MX destination or queue the message for retry.
A successful MX lookup is therefore necessary for normal mail routing, but it does not prove that the destination will accept every message.
Can a Domain Have Multiple MX Records?
Yes. A domain can publish multiple MX records, with different or equal priorities, to identify more than one receiving mail server.
This is a standard DNS and SMTP configuration.
For example:
Host | Type | Priority | Destination |
|---|---|---|---|
@ | MX | 10 | mx1.example.net |
@ | MX | 20 | mx2.example.net |
@ | MX | 30 | mx3.example.net |
Here, the sending system prefers mx1.example.net.
If that destination cannot complete delivery, it may attempt another configured exchanger.
The additional records are useful only if their destinations are correctly configured.
Does having multiple MX records improve email deliverability?
It depends on what you mean by deliverability.
Multiple MX records can improve incoming mail availability when they provide functioning alternative receiving servers.
They do not directly improve outgoing sender reputation, prevent spam complaints, or guarantee primary-inbox placement.
For cold email teams, correct MX routing matters because replies must reach a monitored mailbox. But successful outbound delivery also depends on authentication, sending behavior, recipient quality, provider policies, and reputation.
How many MX records can one domain have?
DNS does not impose a universal practical recommendation such as exactly two or five MX records.
The correct number depends on the receiving mail architecture.
A domain might use:
One MX record for a managed email provider.
Several records for provider-managed receiving clusters.
A primary and secondary MX server in a custom setup.
Multiple equal-priority MX hosts within a coordinated infrastructure.
More records do not necessarily make the system more reliable.
How Multiple MX Records Work: Priority, Failover and Load Distribution
There are three common design patterns worth understanding.
1. Primary and backup MX records
Consider this configuration:
The primary mail server has priority 10.
The backup has priority 20.
Because lower values are preferred, the sending server normally tries the primary destination first.
If that destination is unavailable, another eligible destination can be attempted.
A properly designed backup MX server may accept and queue messages temporarily before relaying them to the primary mail system.
However, backup MX is not simply a DNS setting.
The backup server also needs:
Authorization to accept mail for the domain.
A reliable route to the final receiving system.
Appropriate recipient validation.
Spam and abuse protection.
Secure mail handling and operational monitoring.
Without these controls, a backup MX record can create routing failures or become an unnecessary security exposure.
2. Equal-priority MX records
A domain may also publish two MX records with the same priority.
When destinations have equal preference, SMTP clients randomize their selection.
This allows multiple receiving servers to participate in delivery attempts.
But equal priority does not guarantee a perfect traffic split.
Different sending systems, retry behavior, DNS caching, and server availability can affect the actual distribution.
Both receiving servers should be configured to handle the domain's intended mail.
3. Multi-level failover
Larger organizations may use several levels of receiving infrastructure.
For example:
This configuration expresses a preference order.
It does not automatically create geographic redundancy or disaster recovery.
The actual resilience depends on whether those servers operate independently and can accept or relay mail correctly.
MX priority comparison table
Configuration | Expected behavior | Best use |
|---|---|---|
One MX at priority 10 | Single published destination | Managed email service |
MX at 10 and 20 | Preferred and alternative destinations | Supported failover |
Two MX records at 10 | Equal-preference destinations | Coordinated receiving cluster |
MX at 5, 10 and 20 | Multiple preference levels | Custom routing architecture |
Google and Microsoft MX records mixed without routing rules | Potentially inconsistent delivery | Not recommended |
Key rule: MX priority is a preference value, not a percentage.
Priority 20 does not mean that server receives 20% of incoming email.
MX Record Priority: What Do 0, 1, 5, 10 and 20 Mean?
MX priorities are nonnegative numeric preference values.
The lower the value, the more preferred the mail exchanger.
For example:
The specific numbers do not have a universal meaning beyond their relative order.
A server with priority 0 is not inherently faster or more secure than one with priority 10.
If a domain has only one MX record, its priority does not affect selection among multiple MX destinations because there are no alternatives.
For managed email services, use the exact values supplied by the provider.
How to Set Up MX Records for Multiple Domains
Configuring MX records across several domains is manageable when you follow a consistent process.
The most important principle is to treat every domain as an independent receiving-mail configuration.
Step 1: Identify your authoritative DNS provider
First, determine where your domain's DNS zone is managed.
Common providers include Cloudflare, GoDaddy, Namecheap, Hostinger, Amazon Route 53, and other DNS hosting platforms.
The company where you registered your domain may not be the company hosting its DNS.
For example, a domain purchased through GoDaddy might use Cloudflare nameservers.
In that case, the MX changes belong in Cloudflare's DNS dashboard.
You can check the delegated nameservers using:
On Windows:
If you are unsure which service is authoritative, confirm the domain's delegation before editing records.
Step 2: Create a domain and mailbox inventory
Before changing anything, document the current configuration.
Domain | Email provider | DNS provider | MX status |
|---|---|---|---|
example.com | Google Workspace | Cloudflare | Configured |
example.net | Microsoft 365 | GoDaddy | Needs verification |
example.org | Private mail server | Route 53 | Primary and backup |
outreach.example.com | Custom routing | Cloudflare | Pending setup |
For larger organizations, also record:
Domain owner.
MX hostnames and priorities.
TTL values.
Mailbox administrator.
Date of last successful test.
Migration or change history.
Whether replies are actively monitored.
This inventory is especially useful when dozens of outreach domains are involved.
Step 3: Get the correct MX records from your email provider
Never invent MX destinations.
Different mailbox providers use different routing architectures.
A Google Workspace domain should use Google's supported MX configuration.
A Microsoft 365 domain should use the tenant-specific Exchange Online MX destination.
A custom mail server may require several MX records.
The correct values must come from the actual receiving provider.
Step 4: Open the DNS management dashboard
Find the DNS records or DNS zone section for the domain.
Create or edit an MX record using the fields supplied by your DNS host.
A typical record might look like this:
Here, @ usually represents the root domain.
Some DNS interfaces use a blank field or the full domain name instead.
Follow the formatting expected by your provider.
Step 5: Remove conflicting or obsolete MX records
When changing email providers, old MX records can direct delivery attempts to an unintended system.
For example, a domain migrating from Google Workspace to Microsoft 365 should not leave unrelated Google MX records active indefinitely unless a documented coexistence design requires them.
Before changing MX records, confirm that the new provider is ready to receive mail.
Create the required users and mailboxes first.
If only some users are moving to another provider, configure supported split delivery or connectors rather than assuming multiple MX records will divide mailboxes correctly.
Step 6: Choose an appropriate TTL
TTL stands for Time to Live.
It tells DNS resolvers how long a response may be cached.
Common operational choices include:
TTL | Typical use |
|---|---|
300 seconds | Planned migration or active testing |
900 seconds | Shorter-term operational changes |
3600 seconds | Common stable configuration |
14400 seconds | Longer caching interval |
These are operational examples, not mandatory MX standards.
Lowering TTL before a planned change can reduce how long old DNS answers remain cached.
However, changing TTL at the moment of migration does not instantly invalidate responses already cached under the previous TTL.
Step 7: Verify the MX records
After saving, inspect the public DNS response.
For Linux or macOS:
For Windows:
To inspect an authoritative nameserver directly:
Replace the example nameserver with the domain's actual authoritative server.
Check that:
The expected MX records appear.
Their priority values are correct.
No obsolete destination remains.
Each mail exchanger hostname resolves appropriately.
The receiving provider recognizes the domain.
Step 8: Test real incoming email
A DNS lookup alone cannot confirm successful mailbox delivery.
Send an email from an external account to a mailbox on the configured domain.
Confirm that it arrives in the intended inbox.
Then reply to the test message and verify that the conversation works in both directions.
Repeat this process for every newly configured domain.
Google Workspace MX Records: Current and Legacy Configurations
Google Workspace supports a simplified MX configuration for newer setups.
The current standard configuration uses:
Some older Google Workspace domains use a legacy five-record configuration.
Priority | Legacy MX destination |
|---|---|
1 | ASPMX.L.GOOGLE.COM |
5 | ALT1.ASPMX.L.GOOGLE.COM |
5 | ALT2.ASPMX.L.GOOGLE.COM |
10 | ALT3.ASPMX.L.GOOGLE.COM |
10 | ALT4.ASPMX.L.GOOGLE.COM |
Google continues to support existing legacy configurations.
Do not assume an older five-record setup is incorrect simply because a newer account uses one record.
Always check the Google Admin console and current official instructions for the specific domain.
For detailed Google-specific configuration, see our Google MX setup guide.
Microsoft 365 MX Records: How to Configure Exchange Online
Microsoft 365 uses an MX destination associated with the organization's domain and tenant configuration.
A typical Exchange Online destination follows this pattern:
The exact value must be obtained from the Microsoft 365 admin center.
To locate the settings:
Sign in to the Microsoft 365 admin center.
Open Settings and select Domains.
Select the relevant domain.
Review the domain's DNS records.
Copy the MX destination and priority specified for Exchange Online.
Add the record at the authoritative DNS provider.
Verify the record and test incoming delivery.
Important: Microsoft advises preparing users and mailboxes before switching MX routing to Exchange Online.
When the MX record changes, new incoming messages can begin arriving at Microsoft 365 while historical messages remain with the previous provider unless separately migrated.
For more detailed instructions, see our Microsoft 365 MX record configuration guide.
Teams evaluating mailbox provisioning can also compare Microsoft 365 business inboxes and pre-warmed Microsoft 365 email accounts.
Hostinger MX Records with Multiple SMTP Servers
One common search question is:
Can Hostinger MX records be configured for multiple SMTP servers?
The answer depends on whether those servers are intended to receive incoming mail or submit outgoing mail.
Hostinger can act as a domain registrar, DNS host, web host, or email provider depending on the services purchased.
A domain managed through Hostinger may receive email through Hostinger Email, Google Workspace, Microsoft 365, or another external provider.
To configure the domain:
Open the domain's DNS management settings in Hostinger.
Identify the actual email provider.
Retrieve the correct MX records from that provider.
Remove conflicting records only after checking migration requirements.
Save the changes.
Verify public MX results and test incoming messages.
MX records vs multiple SMTP servers
An MX record specifies where external mail systems should deliver incoming email.
An SMTP submission server is the server that an email client or application uses to send outgoing messages.
For example:
Setting | Purpose |
|---|---|
MX record | Incoming mail destination |
SMTP host | Outgoing mail submission |
SMTP port 587 | Common authenticated submission port |
IMAP host | Mailbox access and synchronization |
SPF | Sending authorization checks |
Adding two MX records does not automatically configure two outgoing SMTP servers.
If your application needs multiple sending providers, configure those providers at the application or mail transport layer.
Can One Email Address Have Multiple MX Records?
This question often appears in searches for one email address multiple MX records.
Technically, MX records are published for a domain or DNS name, not for an individual mailbox.
Consider:
All three addresses normally use the MX records published for example.com.
The receiving email system determines which mailbox should receive the message.
MX records do not contain rules for individual usernames.
You cannot use MX priorities alone to tell external senders that sales@example.com belongs to Google Workspace while support@example.com belongs to Microsoft 365.
For that arrangement, use provider-supported split delivery, mail forwarding, transport rules, or a routing gateway.
Multi-Domain Email Routing: Three Practical Architectures
Businesses operating several domains usually choose one of three approaches.
Architecture 1: One provider for several domains
A company may host several domains with the same email provider.
For example:
Each domain publishes the provider's required MX records.
The provider handles the internal mapping between domains, users, and mailboxes.
This arrangement can simplify administration and monitoring.
Architecture 2: Different providers for different domains
An organization may use separate providers for separate domains.
For example:
This is a legitimate multi-domain design.
Each domain has its own receiving configuration.
It is different from publishing unrelated Google and Microsoft MX records for the same domain without a coexistence plan.
Architecture 3: Custom primary and backup mail infrastructure
Organizations running their own mail servers may use a coordinated MX cluster.
For example:
The secondary server may accept messages when the primary is unavailable.
This design provides greater control but requires appropriate mail relay configuration, security controls, monitoring, and operational maintenance.
Which architecture should you choose?
Requirement | Suitable approach |
|---|---|
Simple business email | Managed provider |
Several domains using one platform | Multi-domain managed provider |
Different domains on Google and Microsoft | Separate provider configuration per domain |
Different users on one domain across providers | Supported split-delivery design |
Custom receiving server redundancy | Primary and backup MX architecture |
Large agency domain portfolio | Standardized per-domain configuration and monitoring |
How to Manage MX Records for 10, 50 or 100 Domains
The main challenge of multi-domain email routing is consistency.
A configuration that works for one domain can become difficult to maintain across dozens of domains.
Imagine an agency with 40 outreach domains.
Thirty-eight domains have correct MX records, but two still point to an old mailbox provider.
The agency may continue sending messages successfully from all 40 domains while missing replies on the two incorrectly configured domains.
This creates an operational problem that cannot be identified from aggregate sending metrics alone.
Use a domain-level configuration inventory
Maintain a record of each domain's MX destination, provider, TTL, DNS host, mailbox owner, and last successful inbound test.
Standardize approved DNS templates
Create separate templates for Google Workspace, Microsoft 365, and any custom mail systems.
Do not use one universal MX destination for every provider.
Automate checks where practical
DNS monitoring can compare published MX records against expected configurations.
An automated check might flag:
Missing MX records.
Unexpected destination hostnames.
Changes in MX priorities.
Mail exchangers that no longer resolve.
DNS lookup failures.
Domains that have not passed a recent inbound test.
Roll out changes gradually
For a large migration, test a small group of domains first.
Confirm that mailboxes receive messages and that forwarding or routing rules work correctly.
Then expand the migration in controlled stages.
This approach helps identify problems before they affect the entire domain portfolio.
How to Check MX Records for a Specific Domain
Searches such as weaveintelligence.io MX records, outsourceddoers.com MX records, metapack.com.mx NS records, vortiq.sbs MX records, and cordonblue.pro MX records usually indicate a domain-specific DNS lookup task.
The correct process is to query the domain's current DNS records rather than rely on an old screenshot or cached article.
For example:
For the nameserver query:
These commands are examples of how to perform a lookup. They do not represent verified live results for those domains.
How to interpret the results
An MX lookup normally returns one or more priority and hostname pairs.
For example:
This means the domain publishes two receiving destinations, with mx1.example.net preferred.
An NS lookup returns the nameservers delegated for the domain.
For example:
NS and MX records answer different questions.
NS records identify authoritative DNS servers. MX records identify receiving mail exchangers.
What if the lookup returns no MX records?
Do not immediately assume that all email delivery is impossible.
SMTP standards permit a limited implicit MX fallback when no MX record is published and suitable address records exist.
However, this is not a reliable substitute for the explicit MX configuration required by most modern managed email providers.
If your provider expects an MX record, configure it according to its instructions.
What if the MX record is 0 .?
A null MX record indicates that the domain does not accept email.
This is different from an accidentally missing MX record.
Do not replace a deliberate null MX configuration unless the domain is supposed to receive messages.
MX Records vs SPF, DKIM and DMARC
MX records are frequently mentioned alongside email authentication records, but each serves a different purpose.
Record | Function | Primary concern |
|---|---|---|
MX | Identifies receiving mail exchangers | Incoming routing |
SPF | Authorizes sending hosts for an SPF identity | Sending authentication |
DKIM | Verifies cryptographic email signatures | Message authentication |
DMARC | Evaluates aligned authentication and publishes policy | Domain authentication policy |
A/AAAA | Resolves hostnames to IP addresses | Network addressing |
NS | Identifies authoritative nameservers | DNS delegation |
A correctly configured MX record does not automatically configure SPF, DKIM or DMARC.
Similarly, passing SPF or DKIM does not prove that replies can reach the sender's mailbox.
For a reliable business email setup, verify routing and authentication separately.
Read our SPF, DKIM and DMARC setup guide for the authentication side of the configuration.
Common MX Record Problems and How to Fix Them
Even small DNS errors can disrupt incoming mail.
1. Incorrect MX priority
Problem: An unintended server is preferred.
Cause: Priority values do not match the intended routing architecture.
Fix: Compare the published records against the provider's documented settings and correct the preference values.
2. MX record points directly to an IP address
Problem: The MX destination is an IP address instead of a hostname.
Fix: Replace it with a properly configured mail exchanger hostname.
3. MX destination is a CNAME alias
Problem: The exchanger name resolves through a CNAME rather than the expected address records.
Fix: Point the MX record to a suitable hostname with direct address records.
4. Old MX records remain after migration
Problem: Messages are attempted against an obsolete provider.
Fix: Complete the migration preparation, then remove old records according to the provider's migration instructions.
5. Backup MX server rejects mail
Problem: The secondary server is published in DNS but is not configured to accept the domain's messages.
Fix: Configure recipient handling and relay correctly, or remove the unsupported backup.
6. MX hostname does not resolve
Problem: The destination hostname has no usable address records.
Fix: Correct the destination or repair its address records.
7. DNS caching delays changes
Problem: Some resolvers still return an older MX configuration.
Fix: Compare authoritative and recursive DNS responses, review TTL values, and allow existing caches to expire.
8. Hosting control panel uses the wrong routing mode
Problem: A hosting server treats email as local even though the MX records point to an external provider.
Fix: Review the hosting panel's local, remote, or backup mail exchanger settings.
For example, cPanel installations may require a remote mail exchanger setting when email is handled externally.
9. The mailbox does not exist
Problem: MX routing reaches the correct provider, but the destination rejects the recipient.
Fix: Confirm that the user, alias, or mailbox exists and is licensed or provisioned correctly.
10. SPF, DKIM or DMARC is misconfigured
Problem: Outgoing messages fail authentication checks even though incoming MX routing works.
Fix: Inspect authentication separately rather than changing MX records unnecessarily.
11. SMTP submission settings are confused with MX settings
Problem: An application cannot send outgoing messages, so the administrator changes incoming MX records.
Fix: Verify the application's SMTP host, port, credentials, encryption, and provider permissions.
12. Reply-to address is not monitored
Problem: Incoming messages arrive successfully but are not seen by the outreach team.
Fix: Check the Reply-To address, mailbox access, forwarding rules, and inbox monitoring workflow.
This issue is particularly important for multi-domain cold email operations.
How to Troubleshoot MX Records with dig, nslookup and Online Tools
DNS command-line utilities help determine whether the problem is in DNS or the receiving mail system.
Check MX records with dig
Check authoritative nameservers
Check the destination hostname
Check a specific DNS resolver
Trace DNS resolution
Check MX records on Windows
Use online tools
If you prefer a graphical interface, you can use MXToolbox or Google Admin Toolbox to inspect published DNS records.
However, DNS lookup tools do not replace an actual delivery test.
A complete troubleshooting process should include both DNS verification and a message sent from an external account.
How Multiple MX Records Affect Cold Email Campaigns
Cold email teams often focus on outgoing sending limits, mailbox warm-up, and authentication.
Incoming routing deserves equal operational attention because replies are a critical campaign outcome.
Consider a company using 20 outreach domains.
If one domain has incorrect MX settings, the company may continue sending messages from that domain while failing to receive some replies.
This can create misleading campaign reporting.
A low reply rate might reflect poor messaging, but it might also indicate that responses are being rejected or delivered somewhere the team is not monitoring.
Separate your primary business domain when appropriate
Some organizations use separate domains for outreach to reduce direct operational exposure of their primary corporate email domain.
For example:
Each domain should have its own valid DNS configuration and receiving mailboxes.
Separate domains can help organize infrastructure, but they do not guarantee reputation isolation. Mail providers can associate sending behavior across related infrastructure and accounts.
Verify every sending domain
Before launching a campaign:
Confirm the domain's MX records.
Verify SPF, DKIM and DMARC.
Send an external test email to the mailbox.
Confirm that the message arrives.
Reply to the message.
Check that the outreach platform or monitored inbox displays the conversation.
Review provider policies and sending limits.
Do not use MX records as a reputation workaround
Changing MX destinations does not reset the reputation of an outgoing sending domain.
If emails are being filtered because of spam complaints, poor targeting, or policy violations, adding more MX records will not solve the underlying problem.
For a broader infrastructure overview, read our cold email infrastructure guide.
MX Record Monitoring and Change Management
MX configuration is not a one-time task for organizations managing many domains.
DNS records can change because of migrations, provider updates, expired domains, administrative mistakes, or unauthorized modifications.
A useful monitoring process includes:
DNS consistency checks: Compare published MX records with the approved configuration for each domain.
Hostname resolution checks: Confirm that mail exchanger destinations resolve to usable IP addresses.
Delivery testing: Periodically send messages to test mailboxes.
SMTP error monitoring: Review temporary and permanent rejection codes.
Mailbox monitoring: Confirm that replies are reaching the intended inbox or reply-management system.
Change logging: Record who changed the DNS settings and why.
For high-volume operations, automated alerts can identify unexpected MX changes before they disrupt important communication.
Example operational checklist
Check | New domain | After migration | Ongoing |
|---|---|---|---|
Correct MX destination | Yes | Yes | Periodically |
Correct priority | Yes | Yes | After changes |
Hostname resolves | Yes | Yes | Periodically |
External inbound test | Yes | Yes | Periodically |
Reply-to mailbox monitored | Yes | Yes | Regularly |
SPF/DKIM/DMARC checked | Yes | Yes | After changes |
DNS inventory updated | Yes | Yes | After changes |
How LiteMail Helps Teams Manage Email Infrastructure
As a team expands from a few business inboxes to dozens of outreach accounts, domain and mailbox provisioning can become repetitive.
LiteMail offers business email infrastructure options, including Google Workspace inboxes, Microsoft 365 inboxes, and pre-warmed mailbox products.
For teams evaluating their infrastructure, relevant options include:
Cold Email Infrastructure — an overview of LiteMail's email infrastructure offering.
Bulk Email Inboxes — for teams comparing larger mailbox deployments.
Google Workspace Inboxes — for Google-based business email accounts.
Microsoft 365 Inboxes — for Microsoft-based mailbox provisioning.
Pre-Warmed Microsoft 365 Email Accounts — for teams evaluating accounts with existing warm-up history.
Managed provisioning can reduce repetitive setup work, but it remains important to verify MX routing, mailbox functionality, authentication, administrative access, and provider-specific requirements.
Pre-warmed inboxes do not guarantee inbox placement, prevent account restrictions, or eliminate the need for responsible sending practices.
Frequently Asked Questions About Multiple MX Records
Can a domain have multiple MX records?
Yes. A domain can publish multiple MX records with equal or different priority values. The receiving servers must be configured to accept and route the domain's messages correctly.
What happens if two MX records have the same priority?
Sending mail servers randomize among equally preferred destinations. This may distribute delivery attempts, but it does not guarantee an exact 50/50 split.
Do multiple MX records improve email redundancy?
They can provide alternative receiving destinations when those servers are properly configured. Simply publishing extra records does not create functional redundancy.
What MX priority should I use?
Use the values specified by your provider. Lower numbers have higher preference. For custom configurations, select values that express the intended receiving order.
Can one email address have multiple MX records?
MX records apply to the domain, not to individual email addresses. Multiple addresses on one domain normally share the same MX lookup.
Can I use Google Workspace and Microsoft 365 MX records together?
Not as a simple method of assigning different users to different providers. Use supported split delivery, forwarding, or transport connectors when both systems must handle mail for one domain.
Can Hostinger use multiple MX records?
Yes, if the receiving email architecture requires them. The correct configuration depends on whether the domain uses Hostinger Email, Google Workspace, Microsoft 365, or another provider.
Are MX records the same as SMTP settings?
No. MX records direct incoming email. SMTP submission settings determine how email clients and applications send outgoing messages.
What is the difference between MX priority 10 and 20?
Priority 10 is preferred over priority 20. These numbers indicate preference, not the percentage of traffic sent to each server.
How do I check MX settings?
Run dig MX example.com or nslookup -type=mx example.com. Compare the results with your provider's instructions and send an external test message.
What happens if a domain has no MX record?
SMTP supports an implicit fallback to address records in some circumstances. However, managed email services typically require explicit MX configuration. A deliberate null MX record means the domain does not accept email.
Can multiple domains use the same MX server?
Yes. A receiving server or managed email provider can handle multiple domains if it is configured to recognize and accept mail for them.
Do MX records affect SPF, DKIM and DMARC?
They are separate DNS functions. MX determines incoming mail routing, while SPF, DKIM and DMARC are used for email authentication and domain policy.
How long do MX changes take to update?
It depends on DNS caching, TTL values, and provider processing. Some changes become visible quickly, while existing cached answers can persist until their TTL expires.
Can I add backup MX records to Microsoft 365?
Do not add arbitrary backup MX destinations. Follow Microsoft's supported Exchange Online and mail-flow configuration guidance.
Why am I not receiving replies to cold emails?
Possible causes include incorrect MX records, missing mailboxes, rejected recipients, forwarding problems, or unmonitored Reply-To addresses. Verify DNS and perform a real inbound delivery test.
Final Thoughts: Build Reliable Multi-Domain Email Routing
Multiple MX records are useful when they support a correctly designed receiving mail system.
They can provide alternative mail destinations, enable equal-preference receiving clusters, and support custom failover arrangements.
However, more MX records are not automatically better.
For Google Workspace, Microsoft 365, and other managed email services, the safest approach is to use the provider's documented configuration.
For businesses managing multiple domains, maintain a domain inventory, verify every MX destination, test incoming delivery, and monitor changes over time.
And for cold email operations, remember that MX records are only one part of the infrastructure. Mailbox provisioning, authentication, sender reputation, compliance, and reply monitoring all require separate attention.
Building or expanding your outreach infrastructure? Explore LiteMail's cold email infrastructure and business inbox options to compare suitable mailbox setups for your team.
References and Further Reading
RFC 5321 — Simple Mail Transfer Protocol — SMTP delivery behavior, MX preference and mail exchanger selection.
RFC 7505 — A Null MX No Service Resource Record for Domains That Accept No Mail — Null MX configuration.
RFC 2181 — Clarifications to the DNS Specification — DNS rules relevant to MX target hostnames.
Google Workspace — Set Up MX Records — Current Google Workspace MX setup and legacy configurations.
Microsoft Learn — External DNS Records for Microsoft 365 — Exchange Online MX, SPF and related records.
Microsoft Learn — Connect Your Domain by Adding DNS Records — Microsoft 365 DNS setup workflow.
Cloudflare — DNS MX Record Explained — Introductory MX reference.
MXToolbox — MX Lookup — Public MX record lookup.
Google Admin Toolbox — Dig — DNS lookup and troubleshooting.
