How to Fix Missing or Incorrect MX Records

MX records, or Mail Exchange records, are an important part of a domain’s email configuration. They tell other mail servers where messages addressed to your domain should be delivered. When MX records are missing, incorrect, duplicated, outdated, or pointing to the wrong mail server, your domain may experience problems receiving email.

Typical symptoms include emails not arriving, senders receiving bounce messages, mail being delivered to an old provider, email verification tools reporting that a domain has no mail server, or mail systems reporting DNS-related errors.

Fortunately, most MX record problems can be diagnosed and corrected by checking the current DNS configuration, confirming the correct values with the email provider, and then updating the authoritative DNS records.

Understanding MX Records

An MX record identifies the mail server responsible for receiving email for a domain.

For example, a simplified configuration might look like this:

example.com MX 10 mail.example.com

The first part identifies the domain, MX identifies the record type, 10 represents the priority, and mail.example.com is the mail server receiving messages.

A domain can have multiple MX records. For example:

example.com MX 10 mail1.example.com

example.com MX 20 mail2.example.com

The lower numerical priority is preferred. In this example, mail servers normally try mail1.example.com before mail2.example. Multiple MX records can provide redundancy when more than one mail server is configured. (Cloudflare)

It is important to understand that an MX record is primarily responsible for inbound email routing. Having a working MX record does not by itself guarantee that a particular mailbox exists or that outbound messages will reach recipients’ inboxes.

Common Signs of Missing or Incorrect MX Records

The first step in fixing an MX problem is recognizing the symptoms.

One of the most obvious signs is that your domain cannot receive email. You may be able to send messages from your mailbox, but messages sent to your domain never arrive.

Another common symptom is a bounce message. A sender may receive an error indicating that the destination domain could not be found, that there was no mail exchanger, or that the destination mail server could not be reached.

Email verification tools can also report problems. For example, an email verification service may classify a domain as having no MX records or an invalid mail configuration.

Other signs include:

• Email continues going to an old email provider after a migration.
• Only some incoming messages are affected.
• Your mail server is unreachable.
• An MX record points to a hostname that no longer exists.
• Your MX record points to the wrong provider.
• An MX target resolves to the wrong IP address.
• A mail hostname is incorrectly proxied through a service that does not proxy SMTP.
• Multiple conflicting DNS configurations exist.
• DNS changes appear correctly in one location but incorrectly somewhere else.
• A newly added MX record does not appear immediately in every DNS lookup.

Identifying the exact symptom helps determine whether the problem is the MX record itself, the hostname it references, DNS propagation, or another part of the email system.

Step 1: Confirm Which DNS Provider Is Authoritative

Before changing an MX record, determine where your domain’s authoritative DNS is managed.

This is important because changing an MX record in the wrong dashboard will not change the DNS information that other mail servers see.

For example, your domain could be registered with one company, have its website hosted by another company, use Cloudflare for DNS, and use Microsoft 365 or Google Workspace for email.

The company where the domain was purchased is not necessarily the company controlling the DNS zone.

Check the domain’s nameservers and determine which DNS provider is authoritative. Then make the MX changes in that provider’s DNS management system.

If nameservers have recently been changed, this is especially important. A domain may appear to have the correct MX record in one dashboard while the public internet is still receiving DNS information from a different authoritative nameserver.

Step 2: Check the Current MX Records

Before making any changes, check what the internet currently sees.

One simple command is:

dig example.com MX +short

Replace example.com with your domain.

The command should return the MX records currently visible through the DNS resolver you queried. Cloudflare also recommends using dig example.com mx +short when troubleshooting email configuration

On Windows, you can also use:

nslookup -type=mx example.com

The result should show the mail servers associated with the domain.

You can compare this result with the MX records shown in your DNS provider’s dashboard.

If the DNS dashboard shows one set of records but the public lookup returns another set, investigate the nameservers, caching, delegation, or DNS configuration before assuming that the MX record itself is wrong.

Step 3: Check Whether the MX Record Is Missing

If the lookup returns no MX records, the domain may not have an MX record configured.

For example, if:

dig example.com MX +short

returns nothing, there may be no MX record available to the resolver.

A missing MX record can prevent normal inbound email delivery.

The solution is usually to obtain the correct MX values from your email provider and add them to your authoritative DNS zone. Cloudflare’s email troubleshooting documentation similarly recommends checking whether dig returns MX results and adding the missing records when appropriate.

Do not simply invent an MX hostname. The correct value depends on the email service you use.

Step 4: Get the Correct MX Values From Your Email Provider

This is one of the most important steps.

Every email provider has its own DNS configuration requirements. The correct MX records for one provider may be completely different from those required by another.

For example, a business using a hosted email platform will normally receive specific MX hostnames and priority values from that provider.

If you recently moved from one email provider to another, the old MX records may still be present.

Instead of guessing, log in to your email provider’s administration area and find its domain or DNS setup instructions.

You should normally confirm:

• MX hostname
• MX priority
• Number of MX records required
• Whether old MX records should be removed
• Whether additional DNS records are required
• Whether the provider requires an A, AAAA, CNAME, TXT, SPF, DKIM, or DMARC record
• Whether the domain needs verification

Provider-specific values can change, so always use the current instructions supplied by the provider.

Step 5: Correct an MX Record Pointing to the Wrong Provider

One of the most common problems occurs after changing email providers.

Suppose your business previously used Provider A and then moved to Provider B.

Your DNS zone may still contain:

MX 10 old-provider.example

while Provider B expects a completely different MX destination.

In this situation, incoming mail may continue being directed toward the old provider.

The solution is to compare your current MX records with the new provider’s official DNS requirements.

Remove obsolete MX records when the provider instructs you to do so and add the correct new records.

Do not leave old and new providers mixed together unless your email architecture specifically requires that arrangement.

Incorrectly combining mail systems can result in unpredictable routing.

Step 6: Check MX Priority Values

MX priority determines which mail server is preferred.

For example:

MX 10 mail1.example.com

MX 20 mail2.example.com

Here, the server with priority 10 is preferred over the server with priority 20.

A common mistake is assuming that the larger number has greater priority. With MX records, the lower numerical value represents the higher preference.

If your provider gives you specific priorities, enter them exactly as instructed.

Do not change the values simply because another number appears more logical.

If your provider has two or more MX servers, make sure each one has the correct priority.

Step 7: Check the MX Hostname

An MX record does not normally contain an IP address directly. It points to a mail server hostname.

For example:

example.com MX 10 mail.example.com

You should then verify that mail.example.com resolves appropriately.

For example:

dig mail.example.com A +short

or:

dig mail.example.com AAAA +short

If the MX target does not resolve, mail delivery can fail even though the MX record itself exists.

This is why fixing a missing MX record sometimes requires checking the DNS record behind the MX target as well.

Step 8: Check for Incorrect CNAME Usage

An MX record should point to the appropriate mail hostname, and the DNS configuration behind that hostname needs to follow the provider’s requirements.

A common configuration is:

example.com MX 10 mail.example.com

with:

mail.example.com A 192.0.2.10

The exact configuration depends on the email provider.

If you manage your own mail server, make sure the mail hostname resolves correctly to the server responsible for receiving mail.

Avoid creating unusual DNS chains simply to make the configuration work. Follow your provider’s documented DNS structure.

Step 9: Check Cloudflare Proxy Settings

If your domain uses Cloudflare, pay special attention to the hostname referenced by your MX record.

Mail protocols such as SMTP, IMAP, and POP3 do not work through Cloudflare’s normal HTTP proxy. The hostname used for mail should generally resolve directly rather than through the HTTP proxy. Cloudflare specifically recommends setting mail-related hostnames to DNS-only when appropriate

For example, you might have:

example.com MX 10 mail.example.com

and:

mail.example.com A 192.0.2.10

The mail.example.com record should normally be configured as DNS only when it is being used for mail traffic.

The MX record itself is DNS information, but the hostname it points to must also resolve to a usable mail destination.

Cloudflare can also generate _dc-mx responses in certain configurations where an MX record points to a proxied hostname. These records can be confusing during troubleshooting, so investigate the underlying proxy configuration rather than deleting the automatically generated record blindly. (Cloudflare Docs)

Step 10: Check Whether Email Routing Is Active

Some DNS platforms provide email forwarding or email routing services.

If such a service is enabled, it may automatically manage MX records.

This can create a conflict when you are also trying to use another email provider.

For example, you may intend to use one provider for business email while an email-routing feature has automatically added different MX records.

In that situation, determine which service is supposed to receive your email.

If the external email provider should handle incoming mail, make sure the routing service is not overriding or conflicting with the provider’s required MX configuration.

Cloudflare notes that Email Routing can manage MX records and that those records can conflict with another mail provider’s configuration.

Step 11: Remove Obsolete MX Records

After migrating email providers, old records can remain in the DNS zone.

For example, you might see:

MX 10 oldmail.example.net

MX 20 newmail.example.net

If the old provider is no longer supposed to receive mail, keeping the old record may cause unnecessary routing attempts.

Do not remove records solely because they look unfamiliar, however.

First determine what each record does.

Some organizations intentionally use multiple mail servers for redundancy or specialized routing.

The correct approach is to compare the entire MX configuration with the intended email architecture.

Step 12: Check for Duplicate or Conflicting DNS Configurations

Sometimes the problem is not duplicate MX records but duplicate DNS management.

For example, you may believe Cloudflare is authoritative while the domain’s nameservers actually point somewhere else.

You might then add the correct MX record to Cloudflare and see no change on the public internet.

This happens because the internet is using another DNS provider’s records.

Check the domain’s authoritative nameservers and confirm that your DNS changes are being made at the correct provider.

Cloudflare notes that if a domain’s nameservers no longer point to the expected Cloudflare nameservers, DNS records managed in Cloudflare may no longer control public resolution.

Step 13: Allow Time for DNS Changes

DNS changes are not necessarily visible everywhere immediately.

After changing an MX record, some DNS resolvers may continue returning an older cached response until the relevant cache lifetime expires.

This is why one computer may show the new MX record while another system still sees the old configuration.

Negative caching can also matter. If a resolver previously received a response indicating that a hostname did not exist, it may temporarily retain that negative result even after the record has been created

Therefore, do not repeatedly change your MX records simply because one lookup still shows an old result.

Make sure the authoritative DNS server has the correct configuration, then allow the appropriate caching period to pass.

Step 14: Query the Authoritative DNS Server

If you are unsure whether the problem is caching, query the authoritative nameserver directly.

First determine the nameservers:

dig example.com NS +short

Then query one of the authoritative servers for the MX record.

For example:

dig @ns1.example-dns.com example.com MX

This can help distinguish between:

• Incorrect DNS configuration
• Resolver caching
• Negative caching
• Incorrect nameserver delegation
• Propagation differences

If the authoritative server returns the correct MX record but another resolver still returns an old result, the problem may be caching rather than the DNS configuration itself.

Step 15: Check the Mail Server Behind the MX Record

A valid MX record is only part of the email delivery chain.

Suppose you have:

example.com MX 10 mail.example.com

You should also check whether mail.example.com resolves correctly.

Then verify that the mail server is actually running and accepting connections.

This is particularly important if you operate your own mail server.

A DNS configuration can be technically correct while the mail server is offline, misconfigured, blocked by a firewall, or not listening on the expected SMTP port.

In such cases, changing the MX record will not solve the underlying server problem.

Step 16: Check Firewall and Server Configuration

If your MX record points to your own mail server, investigate the server after confirming DNS.

Check whether:

• The mail service is running.
• SMTP is listening on the expected port.
• The firewall permits appropriate inbound connections.
• The server has the correct public IP.
• NAT or port forwarding is configured correctly where applicable.
• The mail server recognizes the domain.
• The domain is configured as an accepted recipient domain.
• The server can receive connections from external mail systems.

This is especially important when an MX lookup appears correct but external senders still receive connection errors.

Step 17: Remember That MX Records Do Not Validate Individual Mailboxes

One of the most important distinctions in email troubleshooting is the difference between a domain-level MX check and mailbox-level verification.

Suppose:

example.com MX 10 mail.example.com

This tells you that the domain has a mail-routing destination.

It does not prove that:

john@example.com

actually exists.

The mailbox may have been deleted, disabled, or never created.

Therefore, if your MX records are correct but a particular address still bounces, investigate mailbox configuration and SMTP response codes rather than repeatedly changing the MX record.

Step 18: Check SPF, DKIM, and DMARC Separately

Fixing an MX record does not automatically fix every email problem.

MX records primarily control inbound routing. Other DNS records help authenticate outbound email and establish policies for receiving servers.

SPF identifies authorized sending infrastructure.

DKIM provides cryptographic authentication for messages.

DMARC establishes policy and alignment rules around SPF and DKIM.

Therefore, after fixing MX records, review your email provider’s requirements for SPF, DKIM, and DMARC.

Cloudflare’s current troubleshooting guidance notes that missing SPF, DKIM, or DMARC records can contribute to email delivery problems even when MX records are correct.

Step 19: Test Incoming Email

After correcting the MX records, send a test message from an unrelated external email account.

For example, send a message from a personal email account to:

test@example.com

Do not test only from one mailbox within the same provider.

An external test provides a better indication of whether public DNS and external mail delivery are working.

Check:

• Whether the message arrives.
• How long delivery takes.
• Whether the sender receives a bounce.
• Whether the message arrives in spam.
• Whether the correct mailbox receives it.
• Whether the sending server reports a DNS or SMTP error.

Step 20: Check the Bounce Message

If the test email fails, save the complete bounce message.

The bounce may identify the actual problem.

For example, it may indicate:

• No MX record
• DNS resolution failure
• Connection timeout
• Connection refused
• Host not found
• Mailbox unavailable
• Recipient rejected
• Temporary delivery failure
• Permanent delivery failure

The exact SMTP response is often more useful than simply knowing that an email did not arrive.

A DNS problem and a mailbox problem can produce very different error messages.

Common MX Record Problems and Their Solutions

Missing MX Record

Problem: No MX record exists for the domain.

Solution: Obtain the correct MX values from the email provider and add them to the authoritative DNS zone.

Wrong MX Provider

Problem: The MX record still points to an old email provider.

Solution: Replace obsolete records with the new provider’s required configuration.

Incorrect Priority

Problem: MX records have the wrong priority values.

Solution: Compare them with the provider’s instructions and correct the priority values.

MX Target Does Not Resolve

Problem: The MX hostname has no usable A or AAAA record.

Solution: Correct the DNS record for the mail hostname or use the provider’s correct MX hostname.

Mail Hostname Is Proxied

Problem: A mail hostname is routed through an HTTP proxy.

Solution: Configure the mail hostname as DNS-only where required. Standard HTTP proxying does not support SMTP, IMAP, or POP3 traffic.

Old MX Records Remain

Problem: Old provider records remain after migration.

Solution: Remove obsolete records after confirming they are no longer required.

DNS Managed in the Wrong Place

Problem: You changed the record in a dashboard that is not authoritative.

Solution: Identify the active nameservers and update the DNS zone controlled by those nameservers.

DNS Has Not Updated Everywhere

Problem: Some resolvers still show old information.

Solution: Verify the authoritative record and allow cached information to expire.

Email Routing Conflicts With Your Provider

Problem: An email-routing service has created MX records that conflict with your intended provider.

Solution: Review the routing configuration and ensure only the intended email-routing architecture is active.

A Practical MX Troubleshooting Workflow

A simple troubleshooting sequence can save considerable time.

Start by identifying your email provider.

Next, determine your authoritative DNS provider.

Then run:

dig example.com MX +short

Compare the result with the email provider’s required MX records.

If the records are missing, add them.

If they are incorrect, correct them.

If they point to an old provider, remove or replace them as appropriate.

If the MX hostname does not resolve, investigate its A or AAAA record.

If you use Cloudflare, check whether the mail hostname is DNS-only.

After making changes, query the authoritative nameserver.

Then allow appropriate DNS caching time.

Finally, send an external test email and examine any bounce message.

This process helps separate DNS problems from mail-server and mailbox problems.

Mistakes to Avoid When Fixing MX Records

One common mistake is copying MX records from another domain. Two domains using the same email provider may still have different provider-specific values.

Another mistake is deleting every existing MX record without first determining why the records exist.

You should also avoid changing MX records repeatedly during a DNS propagation period. Frequent changes can make troubleshooting more complicated because different resolvers may temporarily return different configurations.

Another mistake is assuming that a working website means email DNS is correct. Website DNS and email DNS can be configured independently.

A domain can have a perfectly functioning website while its MX records are missing.

Similarly, changing website hosting does not necessarily mean you need to change your email MX records.

What to Do After Fixing MX Records

Once the MX configuration is correct, review the rest of your email DNS configuration.

Check SPF, DKIM, and DMARC according to your provider’s requirements.

If you use a custom mail server, verify its SMTP configuration.

If you use a hosted email service, confirm that the domain is verified and all required DNS records are present.

You can also periodically monitor MX records for important domains, particularly after DNS migrations, email-provider changes, or major infrastructure updates.

Final Thoughts

Fixing missing or incorrect MX records usually begins with identifying where DNS is managed and determining what MX records are currently visible on the public internet.

The most important steps are to check the current MX records, compare them with the correct configuration from your email provider, correct missing or outdated records, verify the MX target, check proxy and routing settings, and test external email delivery.

Remember that an MX record tells other mail servers where to deliver email for a domain. It does not by itself prove that an individual mailbox exists, and it does not guarantee successful outbound inbox placement.

When troubleshooting carefully, avoid guessing at DNS values. Use the exact configuration supplied by your email provider, verify the authoritative DNS response, allow for caching, and investigate the mail server or mailbox separately when the MX configuration is already correct.

Here is the case-study version, with practical scenarios, troubleshooting lessons, and comments, without source links.

How to Fix Missing or Incorrect MX Records – Case Studies and Comments

Missing or incorrect MX records are among the most common reasons a domain stops receiving email correctly. An MX record tells sending mail servers where email for a domain should be delivered. When the record is missing, points to the wrong mail provider, has an incorrect priority, or references a mail hostname that does not work, incoming messages can fail.

The following case studies show how different MX problems can occur in real-world situations and how they can be identified and corrected.

Case Study 1: A Business Stops Receiving Email After Changing DNS

A small business moved its website to a new hosting provider. The website worked normally after the nameserver change, but employees suddenly stopped receiving new emails.

The business initially assumed that the email accounts had been deleted. However, the mailboxes were still active with the existing email provider.

The problem was that the new DNS zone did not contain the previous provider’s MX records.

The solution was to add the correct MX records to the new authoritative DNS zone. After the records became visible publicly, incoming email began working again.

Comment

Changing nameservers does not automatically mean that email accounts have been deleted. DNS controls how other systems find the mail service, so MX records need to be recreated at the new DNS provider when necessary.

Case Study 2: Email Still Goes to the Old Provider

A company moved from one email service to another. The new mailboxes were created successfully, but messages from customers were still being delivered to the previous provider.

The website and new email accounts appeared to be working, so the company initially suspected a problem with the new provider.

An MX lookup revealed that the domain was still publishing the old provider’s MX records.

The company replaced the obsolete records with the new provider’s required MX configuration.

Comment

When changing email providers, always check the live public MX records. Creating new mailboxes at the new provider does not automatically change DNS.

Case Study 3: The MX Record Exists but Points to the Wrong Hostname

A company had an MX record configured, but incoming messages were bouncing.

The MX record looked approximately like this:

example.com MX 10 mail.example.net

However, mail.example.net no longer existed.

The domain therefore had an MX record, but the destination was not usable.

The administrator corrected the MX target using the hostname supplied by the current email provider.

Comment

An MX record existing in DNS does not necessarily mean that it is correct. Always check the hostname referenced by the MX record as well.

Case Study 4: A Typo in the MX Hostname

An administrator manually entered an MX record and accidentally typed:

mail.exmaple.com

instead of:

mail.example.com

The DNS system accepted the record because the syntax was valid, but the hostname did not resolve to the intended mail server.

Incoming mail consequently failed.

The administrator compared the record against the provider’s official configuration and corrected the spelling.

Comment

A single character can make an MX record unusable. Copy provider values carefully instead of typing them manually whenever possible.

Case Study 5: Incorrect MX Priority

A company had two mail servers:

mail-primary.example.com

and

mail-backup.example.com

The administrator intended the first server to be primary but accidentally assigned it priority 20 and the backup server priority 10.

Because lower numerical values have higher preference, the backup server was preferred.

The administrator corrected the priority values so that the intended primary server had the lower number.

Comment

MX priority can be confusing because a smaller number means higher preference. Always check the provider’s specified priority values before changing them.

Case Study 6: The Mail Hostname Does Not Resolve

A business had:

example.com MX 10 mail.example.com

However, mail.example.com did not have a working A or AAAA record.

The sending mail server could find the MX record but could not determine where the mail server actually was.

The administrator restored the correct DNS record for the mail hostname.

Comment

Troubleshooting should not stop after checking the MX record. The hostname inside the MX record must also lead to a usable mail server.

Case Study 7: Cloudflare Proxy Causes Mail Problems

A company used Cloudflare for DNS and had:

example.com MX 10 mail.example.com

The administrator had enabled Cloudflare’s proxy on mail.example.com.

The website worked correctly, but mail clients and external mail servers could not communicate with the mail server properly.

The mail hostname was changed to DNS-only.

Comment

Cloudflare’s standard HTTP proxy is not designed to proxy normal SMTP, IMAP, or POP3 traffic. A mail hostname used for these services generally needs to resolve directly rather than through the HTTP proxy. (Cloudflare Docs)

Case Study 8: Email Routing Conflicts With the Mail Provider

A company used a third-party email provider but had previously enabled an email-routing feature at its DNS provider.

The routing service had created its own MX records.

The company then added the new provider’s MX records without reviewing the existing configuration.

As a result, the DNS zone contained records associated with two different email-routing systems.

The administrator determined which service should handle incoming email and removed the conflicting configuration.

Comment

Do not assume that every MX record in a DNS zone belongs to the current email provider. Automated email-routing services can create or manage MX records.

Case Study 9: An Old Backup MX Record Remains

A company migrated its email service but removed only the primary MX record.

An older backup MX record remained in DNS.

Under normal circumstances, the new provider received email. However, when the primary route was temporarily unavailable, some sending systems attempted the old backup server.

That server was no longer maintained.

The administrator removed the obsolete MX record.

Comment

Review the entire MX configuration after an email migration. An outdated backup record can create problems even when the primary MX record appears correct.

Case Study 10: The Website Works but Email Does Not

A business owner reported that the domain was working perfectly.

Customers could visit the website, forms could load, and the site was accessible from different networks.

However, emails sent to the company never arrived.

The investigation showed that the website had a correct A record but the domain did not have the appropriate MX configuration.

Comment

Website DNS and email DNS perform different jobs. A functioning website does not prove that the domain’s email configuration is correct.

Case Study 11: A New Domain Has No MX Records

A startup registered a new domain and connected it to a website.

The owner then created an email address such as:

contact@example.com

However, the domain had never been connected to an email provider.

There were no MX records.

The company selected an email provider, followed its domain setup instructions, and added the required MX records.

Comment

Buying a domain does not automatically create a complete email system. The domain, website, and email service are separate components that must be configured appropriately.

Case Study 12: MX Records Were Added to the Wrong DNS Provider

A company believed that its DNS was managed through Provider A.

The administrator added the correct MX records there.

Nothing changed.

An investigation showed that the domain’s nameservers were actually pointing to Provider B.

The correct MX records were added to Provider B instead.

Comment

Always confirm the authoritative nameservers before changing DNS. Editing the wrong DNS dashboard will not change the records that the rest of the internet sees.

Case Study 13: DNS Migration Removes Email Records

A company moved its DNS from one provider to another.

The website records were recreated successfully, but the administrator forgot to recreate the email records.

The result was immediate disruption to inbound email.

The administrator restored the required MX records and then reviewed SPF, DKIM, and DMARC records as well.

Comment

Before changing nameservers, make a complete inventory of DNS records. MX is particularly important because email may stop working even when the website migration appears successful.

Case Study 14: Some People Can Send Email, Others Cannot

A company reported an unusual situation.

Some customers could send messages successfully, while other customers received errors.

The company assumed the problem could not be related to DNS because email was working for some senders.

The administrator discovered that the MX configuration had recently changed. Some DNS resolvers were still returning cached information while others were seeing the updated configuration.

Comment

Different DNS resolvers can temporarily return different information after a change. When troubleshooting a recent DNS update, compare authoritative results with public resolver results before making additional changes.

Case Study 15: The MX Record Is Correct but the Mailbox Does Not Exist

A customer sent email to:

john@example.com

The domain’s MX records were completely correct, but the message bounced.

The administrator checked the mailbox and discovered that john@example.com had never been created.

Comment

An MX record identifies the mail system for a domain. It does not prove that every possible address at that domain exists.

This distinction is particularly important when using MX records as part of email verification.

Case Study 16: MX Records Are Correct but the Mail Server Is Offline

A company checked its MX records and found that they matched the provider’s configuration.

However, incoming messages were still failing.

The problem was eventually traced to the mail server itself. The server was unavailable and was not accepting incoming SMTP connections.

Comment

DNS is only one part of mail delivery. Once the MX records are confirmed, investigate the destination mail server if delivery continues to fail.

Case Study 17: A Company Uses a Third-Party Email Gateway

A business used an email security gateway to scan incoming messages before forwarding them to its mailbox provider.

The MX records intentionally pointed to the security gateway rather than directly to the mailbox provider.

A new administrator mistakenly replaced the gateway MX records with the mailbox provider’s records.

This bypassed the intended mail-filtering system.

Comment

An MX record does not necessarily point directly to the final mailbox provider. Organizations may intentionally place security gateways, filtering services, or other infrastructure in front of their mailboxes.

Case Study 18: A Mail Server Has the Wrong IP Address

A company operated its own mail server at a fixed public IP address.

The MX record pointed to:

mail.example.com

but the A record for that hostname still contained the server’s previous IP address.

The MX record itself looked correct.

The actual problem was the DNS record behind the MX target.

The administrator updated the A record to the correct server address.

Comment

When an MX record points to your own hostname, check the entire chain:

Domain → MX → mail hostname → A/AAAA → mail server.

A problem anywhere in that chain can affect delivery.

Case Study 19: The Company Changes Website Hosting but Should Keep Email Unchanged

A company moved its website to a new hosting provider.

The new hosting provider suggested changing all DNS records.

The administrator almost changed the MX records as well.

However, the company was keeping its existing email provider.

The administrator changed only the website-related DNS records and left the email configuration intact.

Comment

Moving a website does not automatically require changing email MX records. If the email provider remains the same, the MX configuration may not need to change.

Case Study 20: A Domain Has a Null MX Record

A company owned a domain used only for websites and did not want it to receive email.

The domain published a null MX configuration indicating that it does not accept mail.

Later, employees assumed the domain should receive email and began troubleshooting why messages were rejected.

The administrator explained that the DNS configuration intentionally prevented mail delivery.

Comment

Not every domain is supposed to receive email. A deliberate null MX configuration is different from an accidentally missing MX record.

Case Study 21: The MX Record Is on the Wrong Domain Name

A company wanted to receive mail at:

support@example.com

The administrator accidentally created an MX record for:

mail.example.com

instead of configuring the MX record for the domain that receives the address.

The mail system therefore did not use the intended record for example.com.

Comment

Always make sure the MX record is published at the correct DNS name. A mail record placed on a different hostname may have no effect on email sent to the main domain.

Case Study 22: A Subdomain Needs Its Own Mail Configuration

A business used:

example.com

and also wanted email addresses such as:

user@support.example.com

The administrator assumed that the main domain’s MX configuration would automatically apply to the subdomain.

The subdomain required its own appropriate mail configuration.

Comment

Email routing for a subdomain needs to be considered separately. Do not assume that a special-purpose mail subdomain automatically uses the exact same configuration as the parent domain.

Case Study 23: The DNS Record Was Deleted Accidentally

An employee was cleaning up unused DNS records and deleted an MX record without realizing that it was responsible for the company’s email.

Within a short period, incoming mail began failing.

The administrator restored the provider’s correct MX configuration.

Comment

DNS cleanup should be performed carefully. Before deleting an unfamiliar record, determine what service depends on it.

Case Study 24: The Company Fixes MX but Forgets Authentication Records

A business discovered that its MX records were incorrect.

After fixing them, employees could receive email again.

However, outbound messages were still experiencing delivery and spam-placement problems.

A second investigation revealed that SPF, DKIM, and DMARC also needed attention.

Comment

Fixing MX primarily addresses inbound routing. It does not automatically resolve every outbound deliverability problem. Email authentication should be reviewed separately.

Case Study 25: A Bulk Email List Contains Domains With Broken MX

A marketing company had a large database containing thousands of email addresses.

Before sending a campaign, the company checked the domains associated with the addresses.

Several domains had no usable MX configuration, while others pointed to outdated mail infrastructure.

The company separated these addresses for additional verification instead of assuming every address was deliverable.

Comment

MX checking can be useful as an initial domain-level screening step, but it should not be treated as proof that an individual mailbox exists.

Case Study 26: A Provider Changes Its MX Requirements

A company had maintained the same email provider for several years.

The provider later updated its recommended DNS configuration.

The company’s old MX records continued working temporarily, but the provider instructed customers to move to a new configuration.

The administrator reviewed the current provider documentation and updated the DNS records accordingly.

Comment

Email providers can change infrastructure and DNS requirements. When troubleshooting, always compare your records against the provider’s current instructions rather than relying on an old setup guide.

Common Comments About Fixing MX Records

Comment 1

“Having an MX record is not enough. The MX target also needs to be correct and reachable.”

This is one of the most important lessons in MX troubleshooting. A DNS lookup can show a record while the destination itself is unusable.

Comment 2

“I changed my nameservers and my website worked, but my email stopped.”

This is a common DNS migration problem. The new DNS provider may not automatically have all of the records that existed at the previous provider.

Comment 3

“I thought my domain registrar controlled all my DNS records.”

The registrar and DNS provider can be different companies. Always identify which nameservers are authoritative before making DNS changes.

Comment 4

“I added the new MX records but left the old ones.”

This can be problematic when the old provider is no longer part of the email architecture. Old records should be reviewed and removed when they are no longer required.

Comment 5

“My MX record looks correct, but email still does not work.”

At that point, investigate the MX target, A or AAAA records, mail-server availability, firewall configuration, routing rules, mailbox configuration, and SMTP responses.

Comment 6

“Why does my website work if my email is broken?”

Because website and email DNS are separate. The website may use an A or AAAA record while email uses MX records.

Comment 7

“Can I just copy MX records from another domain?”

It is safer to use the exact records supplied for the domain by the email provider. Do not assume that another domain has the same configuration.

Comment 8

“Does fixing MX guarantee that email will reach the inbox?”

No. MX mainly determines where inbound mail is routed. Other factors affect email authentication, reputation, spam filtering, and outbound delivery.

Comment 9

“Why is email still broken after I changed the MX record?”

DNS caching may mean that some systems still have the old information temporarily. Verify the authoritative record first before making another change.

Comment 10

“My email provider says the MX is correct, but customers still cannot send to us.”

This is a situation where the bounce message becomes particularly useful. The problem could be DNS resolution, server connectivity, recipient configuration, routing, or another mail-flow issue.

Comment 11

“Can an MX record tell me whether an email address exists?”

No. MX is a domain-level routing mechanism. It can indicate that a domain has mail infrastructure, but it does not prove that a specific mailbox exists.

Comment 12

“Should I change my MX record when I move my website?”

Not necessarily. If your email provider is staying the same, your MX records may remain unchanged. Website hosting and email hosting can operate independently.

Practical Lessons From These Case Studies

The first major lesson is to check before changing. Run an MX lookup and determine exactly what is currently published.

The second lesson is to identify the authoritative DNS provider. A correct record entered into the wrong DNS system will not solve the problem.

The third lesson is to use the email provider’s current DNS instructions. MX values should not be guessed.

The fourth lesson is to check the entire DNS chain. An MX record can be present while its destination hostname is broken.

The fifth lesson is to review old records during migrations. Outdated MX records can continue affecting mail routing.

The sixth lesson is to separate inbound routing from outbound deliverability. Fixing MX does not automatically fix SPF, DKIM, DMARC, reputation, or spam-filtering issues.

The seventh lesson is to use bounce messages as diagnostic information. The specific SMTP or DNS error can help identify whether the problem is with DNS, routing, the mail server, or the recipient mailbox.

The eighth lesson is to be careful with automated DNS services. Email-routing features can create or modify MX records and may conflict with another provider.

The ninth lesson is to avoid unnecessary DNS changes. If the website is being moved but the email provider is staying the same, changing MX records may create a problem that did not previously exist.

The final lesson is to test from outside your own environment. An external email test is a useful way to confirm that the public DNS configuration and inbound mail path are actually working.

Final Comments

Missing or incorrect MX records can look like complicated email failures, but many cases can be traced through a straightforward sequence.

First determine what email service should receive the messages. Then identify the authoritative DNS provider, inspect the current MX records, compare them with the provider’s required configuration, and check that every MX target resolves correctly.

If the MX configuration is correct, move to the next layer of troubleshooting rather than continuing to edit DNS. Check mail-server availability, SMTP connectivity, routing rules, mailbox configuration, and authentication records as appropriate.

The most reliable approach is to treat MX troubleshooting as a process rather than simply adding a new record and hoping the problem disappears. A correct MX record, a functioning target server, appropriate DNS configuration, and a properly configured mailbox all contribute to successful email delivery.