MX Record Troubleshooting: Why Email Is Not Arriving

When inbound email disappears, the fastest diagnosis follows the delivery path in order: DNS delegation, MX records, mail-host address records, SMTP connectivity, receiving-server policy, and message logs.

Do not begin by changing every DNS record. First identify the exact layer where delivery stops.

Confirm the active DNS zone

Check the domain's delegated nameservers at the registrar. Then query those authoritative servers directly. If you edited records at a DNS provider that is no longer authoritative, the public internet will never see the change.

Use Duck Cloud's [MX Lookup](/tools/mx-lookup) to review the published mail exchangers, then compare the result with the provider's required configuration.

Read MX priorities correctly

An MX record contains a priority and a hostname. Lower numbers are preferred. Sending servers normally try the lowest-numbered reachable host first, then fall back to higher-numbered hosts.

Common mistakes include:

• pointing an MX record to an IP address instead of a hostname;
• pointing it to a CNAME when the mail provider requires a direct host;
• leaving obsolete backup MX records active;
• publishing the provider hostname at the wrong domain level;
• mixing records from two mail providers during migration.

Resolve every mail hostname

Each MX hostname must resolve to an A or AAAA address. Follow the record from the recipient domain to the MX hostname and then to its address.

If an AAAA record exists but the server is not reachable over IPv6, some senders may experience delays or failures. Make IPv6 mail delivery work correctly or remove the unusable AAAA record.

Test SMTP reachability

Inbound SMTP normally uses TCP port 25. Confirm the receiving host is reachable from outside your network and that a firewall, security group, hosting provider, or ISP is not blocking the connection.

A successful TCP connection is only the beginning. The server must present a valid SMTP banner, accept the intended recipient domain, and complete the conversation without policy rejection. Review the exact SMTP status code returned to the sender.

Separate routing from authentication

• MX tells senders where to deliver inbound mail.
• SPF lists systems authorized to send mail for a domain.
• DKIM adds a cryptographic signature to outgoing messages.
• DMARC tells receivers how to evaluate aligned SPF and DKIM results and where to send reports.

A broken MX record can prevent delivery before SPF, DKIM, or DMARC matters. Authentication failures more often cause rejection, spam placement, or reputation damage.

Check provider status and message logs

Search by sender, recipient, timestamp, and message ID. Determine whether the message was rejected, quarantined, routed to another mailbox, delayed, or accepted and filtered later.

Ask the sender for the full bounce message. Enhanced SMTP codes such as 5.1.1, 5.7.1, or 4.4.1 are more useful than a screenshot saying delivery failed. Temporary 4xx responses should be retried; permanent 5xx responses usually require configuration or policy changes.

Migration checklist

1. Inventory mailboxes, aliases, groups, and automated senders.
2. Add and verify the domain at the new provider.
3. Publish required SPF and DKIM records without removing valid senders too early.
4. Lower DNS TTLs ahead of the cutover.
5. Change MX records during a monitored window.
6. Keep the old service available while cached MX answers expire.
7. Test inbound and outbound delivery with multiple external providers.
8. Review DMARC reports and delivery logs after the change.

Email delivery is a chain. Diagnose it in order and preserve the evidence from each step; that is faster and safer than repeatedly editing DNS records without knowing which layer failed.