Introduction
Email remains one of the most critical communication channels for individuals, businesses and services. Yet one small DNS misconfiguration can render an address unreachable. If a sender reports that they get a “No MX record found” error or your test message vanishes into thin air, the DNS Mail Exchanger (MX) record is usually to blame.
What does “No MX record found” mean? In plain terms it means your domain lacks a special DNS record that tells the world which servers accept incoming mail for you. Without MX records (or with incorrect ones), other mail servers may revert to legacy fallbacks or give up completely. The result? Bounced messages, lost leads, failed password resets, delayed onboarding e‑mails and a tarnished professional image.
This article explores everything you need to know about MX records: how they work, why missing them hurts deliverability, how to diagnose problems using hands‑on commands, and how to fix them across popular DNS providers. We back our explanations with relevant excerpts from the Domain Name System (DNS) and Simple Mail Transfer Protocol (SMTP) standards. Whether you’re configuring your first domain or debugging edge cases in a complex infrastructure, this deep dive gives you actionable guidance.
MX Record 101
Before we troubleshoot, we need to understand what MX records are and how they fit into the DNS and SMTP ecosystem.
What is an MX record?
An MX record is a type of DNS resource record that specifies the mail exchange host(s) responsible for accepting e‑mail on behalf of a domain. According to RFC 1034, an MX record’s RDATA consists of a 16‑bit preference value followed by the host name of a mail exchange. The preference (often called priority) is a numeric weight; lower numbers are chosen before higher numbers. If multiple MX records share the same priority, sending servers should choose one at random to distribute load.Each record also has a Time to Live (TTL) – a value in seconds that tells resolvers how long to cache the response.
Why MX instead of A/AAAA or CNAME?
When a remote mail transfer agent (MTA) wants to deliver a message to [email protected], it must discover which server accepts mail for example.com. The process is defined in RFC 5321 §5.1: the MTA first queries the DNS for MX records. If one or more MX records exist, it chooses the target with the lowest preference and resolves its A (IPv4) or AAAA (IPv6) record(s). It connects to that host to deliver the message. Only if no MX records are present should the sender treat the domain as having an implicit MX pointing to itself and attempt delivery to the domain’s A/AAAA record(s). This fallback exists for backward compatibility but is considered risky and may be ignored by modern senders.
The standards strongly discourage pointing an MX record to a CNAME. RFC 2181 clarifies that “the domain name used as the value of an MX resource record must not be an alias (CNAME)”. Using a CNAME here can cause additional queries or failures, and some resolvers will treat it as an error. Always point MX records to an FQDN that resolves directly to an A or AAAA record.
Anatomy of an MX record
An MX record has several key fields:
| Field | Description |
|---|---|
| Name | The domain or subdomain for which the record applies (often @ for the apex domain). |
| Type | The DNS type, MX. |
| Preference | A 16-bit integer; lower means higher priority. |
| Target | The hostname of the mail server. Must not be an IP address or CNAME. |
| TTL | Time to Live in seconds; controls cache duration. |
An example set of MX records for example.com:
; Name TTL Class Type Pref Target example.com. 3600 IN MX 10 mail1.example.com. example.com. 3600 IN MX 20 mail2.example.com.
In this configuration, messages are delivered to mail1.example.com first. If that server is unreachable, senders will try mail2.example.com.
MX vs A/AAAA vs CNAME
| Record type | Purpose | Allowed as MX target? |
|---|---|---|
| A/AAAA | Maps a host name to an IPv4 (A) or IPv6 (AAAA) address. Used for web servers, API endpoints, etc. | Only the target of an MX record should resolve to A/AAAA; the MX itself must not be an A/AAAA record. |
| MX | Points to the host(s) that accept mail for a domain. Carries a priority value. | Yes – this is the record we’re defining. |
| CNAME | An alias that points one domain to another. | No – RFC 2181 prohibits using a CNAME as the data in an MX record. |
How SMTP discovers MX records – a lookup flow
When an MTA wants to deliver a message, it follows a deterministic process:
┌────────────┐ 1. Query MX records via DNS ┌────────────────────┐
│ Sender │ ───────────────────────────────────▶ │ DNS resolver │
└────────────┘ └────────────────────┘
│ 2. Receive MX list and preferences
▼
┌────────────────────┐
│ Choose lowest-pref │ 3. For each MX target in order, resolve its A/AAAA records.
│ (randomly among │
│ equals) │ 4. Attempt SMTP connection; if fails, try next.
└────────────────────┘
If there are no MX records, the MTA treats the domain as having an implicit MX record with preference 0 pointing to itself. It resolves the domain’s A/AAAA records and connects to that IP. Modern MTAs may skip this fallback entirely because it’s unreliable and not required by law; the next section examines this behaviour.
How Mail Delivery Behaves With and Without MX
Normal behaviour when MX records are present
- MX lookup: The sending MTA queries the DNS for MX records and receives a list of targets with preferences.
-
Sorting: It sorts the list by increasing preference value.
- If multiple MX records share the same preference, the selection is random to distribute load.
-
Target resolution: For each target in order, it queries the DNS for A/AAAA records.
- If none exist for a target, the MTA marks that target as unusable and moves to the next one.
-
Delivery attempt: It attempts an SMTP connection on TCP port 25 to the resolved IP.
- If the connection fails (timeout, refuse, TLS problems), it tries the next MX.
- If all fail, the message is deferred or bounced depending on the error.
Fallback behaviour when MX records are missing
RFC 5321 allows a fallback: if the domain has zero MX records, the sending MTA may treat it as if it has an implicit MX of priority 0 pointing to the domain itself. It then attempts to deliver mail to the A/AAAA records of the domain. This behaviour ensured backwards compatibility with hosts that existed before MX records were introduced. However, relying on this fallback is dangerous for several reasons:
Not all MTAs implement the fallback. Many modern sending services require an MX record and will bounce messages immediately. The RFC’s language is “SHOULD” rather than “MUST,” so the fallback is optional.
A/AAAA record may point to a web server. Without an MX, senders might connect to your web server’s IP on port 25. If there’s no mail server there, the connection fails or the web server inadvertently accepts mail, creating security risks.
No priority or redundancy. Without MX records you cannot specify multiple mail servers or control failover order.
Comparison: With MX vs Without MX fallback
| Scenario | RFC behaviour | Real-world implications |
|---|---|---|
| Proper MX records present | Sender MUST use the MX list, sorted by preference. Only fallback to A/AAAA if all MX targets are unusable. | Predictable delivery, ability to set redundancy and failover. |
| No MX records | Sender SHOULD treat domain as implicit MX pointing to itself (A/AAAA). | Some senders will attempt fallback; others will bounce. Domain cannot specify multiple mail servers or priorities. |
| Null MX (see Section 7) | Explicitly refuse mail by publishing an MX with a zero-length target “.”. | Senders MUST not attempt delivery; mail is rejected cleanly. |
Common “No MX record found” Error Messages & What They Mean
When MX records are missing or misconfigured, different tools and mail servers emit different error messages. Understanding them helps narrow down the cause. Below are common variants and where they come from:
| Error message | Emitted by / context | Likely cause & fix |
|---|---|---|
| “No MX records found for domain” | Command-line tools like dig or nslookup when querying a domain. | The domain lacks MX records. Add at least one MX pointing to a valid mail server. |
| “Host or domain name not found. Name service error for name=… type=MX” | Postfix logs (server trying to send mail). | DNS resolution failed; either the domain has no MX, or the resolver returned a transient error. Check domain’s DNS and retry. |
| “DNS query returned NXDOMAIN for MX” | DNS tools when the entire domain doesn’t exist. | The queried domain is not registered or has no zone file. Register the domain or fix the authoritative DNS. |
| “Could not connect after trying all MX records. type=mx” | SocketLabs or similar sending services when none of the MX targets accepted connections. | MX records exist but the servers are unreachable. Verify your mail server is running and accessible on port 25. |
| “Mail for <domain> loops back to myself” | Postfix misconfiguration when the mail server thinks it is authoritative for the domain but has no MX; it tries to deliver locally and fails. | Remove incorrect local_transport settings and ensure your domain’s MX points elsewhere. |
| “Relaying denied due to missing MX” | Recipient MTA rejects the message because it doesn’t handle mail for the domain. | The domain’s MX points to a server that isn’t configured to accept mail; fix your mail server or point MX to the correct provider. |
How to Check MX Records
Checking MX records is the first step in diagnosing issues. Here are command‑line and programmatic methods across platforms.
CLI tools for Unix/Linux/macOS
------------------------------------------------------------ 1. dig (Domain Information Groper) ------------------------------------------------------------ Command: dig +short MX example.com Sample output: 10 mail1.example.com. 20 mail2.example.com. Meaning: dig +short returns only MX priorities + mail servers. To resolve IP: dig mail1.example.com A Full response: dig example.com MX Shows TTL, authority & additional DNS info. ------------------------------------------------------------ 2. drill / kdig (Modern dig alternatives) ------------------------------------------------------------ drill example.com MX kdig example.com MX Output similar to dig and may include DNSSEC info. ------------------------------------------------------------ 3. host ------------------------------------------------------------ Command: host -t MX example.com Output: example.com mail is handled by 10 mail1.example.com. example.com mail is handled by 20 mail2.example.com. Meaning: Prints MX priority + servers in a readable sentence. ------------------------------------------------------------ 4. nslookup ------------------------------------------------------------ Command: nslookup -type=mx example.com Meaning: Shows MX answer section. Note: Deprecated on some systems but still widely used.
Windows and PowerShell
PowerShell includes the Resolve‑DnsName cmdlet which can query MX records:
Command: Resolve-DnsName -Type MX example.com Sample output: Name : example.com QueryType : MX TTL : 3600 Section : Answer Preference : 10 NameExchange : mail1.example.com Meaning: Native Windows PowerShell DNS lookup. Shows MX preference + mail server + TTL.
Command: nslookup -type=mx example.com Meaning: Same usage as on Unix systems. Shows MX answer section and mail exchange targets.
Programmatic checks
If you need to verify MX records in code (e.g., before sending mail), you can use DNS libraries.
import dns.resolver
def check_mx(domain: str) -> None:
try:
answers = dns.resolver.resolve(domain, 'MX')
for rdata in answers:
print(f"Preference {rdata.preference}, exchange {rdata.exchange}")
except dns.resolver.NoAnswer:
print("No MX records found; fallback to A/AAAA is risky.")
except dns.resolver.NXDOMAIN:
print("Domain does not exist.")
check_mx('example.com')
Meaning:
Uses dnspython to query MX.
Handles no-answer & NXDOMAIN exceptions.
const dns = require('node:dns/promises');
async function checkMx(domain) {
try {
const records = await dns.resolveMx(domain);
records.sort((a, b) => a.priority - b.priority);
records.forEach(r => console.log(`${r.priority}\t${r.exchange}`));
} catch (err) {
console.error('No MX records found or DNS error', err.code);
}
}
checkMx('example.com');
Meaning:
Performs async MX lookup in Node.
Sorts by MX priority before printing.
package main
import (
"fmt"
"net"
)
func main() {
mx, err := net.LookupMX("example.com")
if err != nil {
fmt.Println("Error:", err)
return
}
for _, m := range mx {
fmt.Printf("%v\t%v\n", m.Pref, m.Host)
}
}
Meaning:
Uses Go standard library for MX lookup.
Prints priority and host for each MX record.
These snippets catch missing MX records and print friendly messages. They are ready to integrate into monitoring scripts.
Web tools
Several web‑based DNS lookup tools allow checking MX records via a browser. They can be convenient, but be aware that they may cache results or log your queries. For privacy and accuracy, prefer command‑line tools whenever possible.
How to Add and Fix MX Records (Provider Walk‑throughs)
Adding an MX record requires administrative access to your DNS provider. The following general steps apply to almost every provider, followed by provider‑specific notes for common services.
General principles
Ensure a valid A/AAAA record exists for your mail server. If you’re using a subdomain like
mail.example.com, create an A (IPv4) or AAAA (IPv6) record pointing to your mail server’s IP and leave it unproxied (DNS‑only) for Cloudflare or similar CDNs.Add an MX record for your domain with the host set to
@(the apex) or the desired subdomain (e.g.,mgformg.example.com). The content should be the fully qualified domain name of your mail server, not an IP address and not a CNAME. Set a preference number; commonly 10 if you have a single mail server. If you have multiple, assign lower numbers to primary servers and higher numbers to backups.Set an appropriate TTL. During migrations, a short TTL (300 – 600 seconds) accelerates propagation. For stable setups, 3600 seconds (1 hour) or more reduces DNS query volume.
Verify propagation from multiple resolvers. Check using
digwith public DNS servers (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) and from your own network.Avoid common pitfalls: do not point MX records to IP addresses or CNAMEs; do not leave stale MX records pointing to providers you no longer use; ensure the target host has valid A/AAAA records.
Cloudflare DNS
Cloudflare allows you to manage DNS records via its dashboard or API. For email routing, Cloudflare recommends creating an A or AAAA record for your mail hostname (e.g., mail.example.com) with the proxy status set to “DNS only,” then creating an MX record for your domain pointing to that hostname. The API example illustrates that an MX record object includes "type": "MX", "name": "example.com", "content": "mail.example.com", "priority": 10, and "ttl": 3600. Make sure the proxy status is disabled for mail hosts so that connections go directly to your mail server.
AWS Route 53
Although AWS documentation pages were inaccessible during research, the process mirrors other providers: open the hosted zone for your domain, choose Create record, select Record type: MX, specify @ as the record name, enter the priority and mail server hostname, choose a TTL, and save. For command‑line automation, the AWS CLI’s route53 service can create or update records via change-resource-record-sets with a JSON change batch.
Google Cloud DNS
In Google Cloud DNS, open your managed zone, click Add record set, choose MX as the record type, fill in your mail server FQDN(s) and priority values, set a TTL, and save. A tutorial notes that Google Cloud DNS supports management via the gcloud dns record-sets create command.
GoDaddy
For domains using GoDaddy nameservers, log in to your account, open the Domain Portfolio, choose your domain, and click DNS. Click Add New Record, choose MX as the type, and fill in:
Name:
@for the root domain or your subdomain.Priority: lower number for primary mail server.
Value: the mail server FQDN (e.g.,
mail.example.com).TTL: 1 hour is typical.
Save the record and allow up to 48 hours for propagation. If Domain Protection is enabled, GoDaddy may require verification to edit DNS records.
Namecheap
Namecheap’s Advanced DNS interface allows custom MX records. To configure:
Log in and choose Domain List → Manage next to your domain.
Under Advanced DNS, ensure there is no CNAME at the root (CNAMEs override MX). Select Mail Settings → Custom MX.
Enter the mail server domain under Mail Server Host Name, set the Priority, and choose a TTL (the default 3600 seconds is fine). Save your changes. DNS changes may take up to 72 hours to propagate.
DigitalOcean DNS
If you host your DNS with DigitalOcean, you can manage MX records via the control panel or API. A Mailgun help article provides a recipe: for a root domain, add two MX records (e.g., mxa.mailgun.org and mxb.mailgun.org) with priority 10 and TTL 300 seconds. For subdomains like mg.example.com, set the hostname field to mg and use the same mail servers and priority. Do not leave other MX records in place, as they may cause unpredictable delivery.
Other providers
Many other registrars and DNS services (Cloud DNS by Cloudflare, DNSimple, Hover, etc.) follow similar steps. Look for “DNS Management,” choose MX as the record type, and consult their documentation. The key principles—no CNAME targets, correct priority, and TTL—remain consistent.
Null MX (RFC 7505)
Not all domains want to receive email. For example, a web‑only property might not accept inbound mail to example.com but uses subdomains like support.example.com for customer support. Without MX records, senders will attempt fallback to the apex A record, potentially connecting to your web server on port 25 and causing delays or false alarms. RFC 7505 introduces the Null MX record to explicitly signal “do not send me mail.”
A Null MX is a single MX record with priority 0 and a zero‑length target represented by a single dot (.). It looks like this:.
example.com. 3600 IN MX 0
Per RFC 7505, domains advertising a Null MX must not publish any other MX records. When an MTA sees this record, it MUST treat the domain as not accepting email and return a 554 error immediately rather than attempting A/AAAA fallback. Use cases include:
Redirecting inbound mail exclusively to specific subdomains (e.g.,
@support.example.com), while refusing mail to the apex.Protecting web‑only domains from bogus SMTP traffic.
Preventing lead‑gen forms or sign‑ups from misaddressing email.
Why MX Matters to Deliverability & Authentication
Foundation of mail routing
MX records sit at the heart of mail routing. Without them, senders either bounce mail or attempt to deliver to an A record not designed for SMTP. This affects message acceptance and subsequently the entire authentication chain.
Relationship with SPF, DKIM and DMARC
It’s important to distinguish between MX and other email authentication mechanisms:
SPF (Sender Policy Framework) defines which IP addresses are authorised to send mail on behalf of a domain (RFC 7208). It’s published as a TXT record and evaluated during SMTP. SPF does not control inbound mail routing.
DKIM (DomainKeys Identified Mail) adds a digital signature to messages, stored in DNS via a TXT record (RFC 6376). It ensures message integrity and that the domain taking responsibility for the signature is authorised.
DMARC (Domain‑based Message Authentication, Reporting & Conformance) builds on SPF and DKIM to specify alignment and reporting policies (RFC 7489).
None of these records replace MX; they operate alongside it. However, missing or misconfigured MX records can still cause deliverability problems even if SPF/DKIM/DMARC are perfect. For example, DMARC alignment checks rely on the domain portion of the From: header. If your domain lacks an MX, some receiving systems may classify it as misconfigured and suspicious.
Additionally, protocols like MTA‑STS (RFC 8461) and TLS‑RPT (RFC 8460) depend on being able to deliver to your mail servers. These protocols help ensure encrypted transport and reporting of TLS errors. Without an MX, senders cannot retrieve MTA‑STS policies, undermining secure delivery.
Deliverability signals
Mailbox providers score domains on their technical setup. A missing MX can:
Increase bounce rates, harming sender reputation.
Signal that the domain isn’t trustworthy, affecting spam filtering.
Cause DMARC reports to show alignment failures, complicating diagnostics.
Disadvantages and Risks of “No MX record found”
Configuring a domain without MX records invites several problems:
Unreliable fallback: As explained earlier, relying on A/AAAA fallback is optional. Many MTAs skip it, causing immediate bounces.
Increased bounce/delay: Some senders queue and retry for hours when no MX exists, delaying mail and potentially hitting bounce thresholds.
Security exposure: If your web server listens on port 25 (intentionally or accidentally), you might unwittingly accept or relay mail. Attackers could exploit this to send spam or phishing.
Broken user flows: Contact forms, signup confirmations, and password resets depend on reliable inbound addresses. Without MX, users never receive messages.
Compliance issues: Many industries require a working email address for communication; missing MX may violate contractual or regulatory obligations.
Monitoring blind spots: Without a proper MX, monitoring systems that send alerts to your domain may silently fail.
Troubleshooting Playbook
The following decision trees and playbook help diagnose MX problems systematically.
┌───────────────────────────────┐
│ Query domain for MX records. │
└───────────────┬───────────────┘
│
No MX records found ───┴── Yes No ─────────► Domain has MX; see Tree B
│
Is the domain intended to receive mail? (Y/N)
│
┌──────────┴──────────┐
│ │
Y N
│ │
Create MX pointing to mail Publish Null MX
server; set priority & TTL. to explicitly refuse mail.
This tree helps administrators decide whether to add MX records or publish a Null MX. If you plan to accept mail, configure proper MX entries. If you intentionally refuse mail, use a Null MX to avoid fallback attempts.
┌───────────────────────────────┐
│ Query MX records; ensure they │
│ resolve to hostnames. │
└───────┬────────┬──────────────┘
│ │
MX points to IP? MX points to CNAME?
│ │ │ │
Yes Fix: replace with FQDN. Yes Fix: replace CNAME with A/AAAA target.
│ │
Resolve MX host to A/AAAA
│
No A/AAAA? → Add A/AAAA records.
│
Resolve again; still issues?
│
Check DNSSEC (bogus signatures?),
network firewalls, port 25 connectivity,
certificate names. If everything resolves
and connects but bounces persist, inspect
SMTP transcript and logs for application-level errors.
Common troubleshooting steps
Check DNSSEC: DNSSEC misconfigurations can make your zone appear bogus, causing resolvers to return SERVFAIL. Verify DS records and signatures.
Verify MX targets have address records: Each MX hostname must have at least one A or AAAA record. If not, the target is unusable.
Avoid CNAMEs or IP addresses: MX must point to an FQDN; the FQDN must not be a CNAME.
Test connectivity: Use
telnet mail1.example.com 25ornc -vz mail1.example.com 25to verify your server is reachable and responds with a 220 banner. Example SMTP transcript:Check firewalls and network policies: Outbound port 25 may be blocked on cloud platforms. Ensure your mail server can receive inbound connections and that your sending environment can make outbound connections.
Review MTA configuration: If you operate the mail server, ensure it is configured to accept mail for your domain and that it matches the MX records. For hosted providers (Google Workspace, Microsoft 365, Fastmail, Zoho, etc.), follow their exact MX specifications.
Wait for propagation: DNS changes can take minutes to hours. Query authoritative and public resolvers to confirm updates.
Real‑World Scenarios & Recipes
Migrating from a web host to a dedicated email provider
Many websites initially use their web host’s built‑in mail server. As volume grows, they switch to a dedicated provider (e.g., Microsoft 365, Google Workspace, Fastmail, Zoho). A migration plan might look like this:
Retrieve the provider’s MX records. For example, Google Workspace provides multiple MX entries with priorities 1, 5, 5, 10, 10. Microsoft 365 provides a single MX like
example-com.mail.protection.outlook.comwith priority 0.Lower the TTL of your existing MX records to 300 seconds at least 24 hours before the cut‑over. This ensures resolvers cache the old record for a shorter time.
Add the new provider’s MX records with the correct priorities. Keep the old ones temporarily in place to ensure continuity.
After verifying mail flows through the new provider, remove the old MX records and raise the TTL back to 3600 seconds or higher.
Monitor bounce logs and DMARC reports for any issues.
Using a subdomain for mail
Instead of hosting mail on the apex domain, many organisations use a subdomain like mail.example.com or mg.example.com. In this case:
Create A/AAAA records for
mail.example.compointing to your mail server.Set MX records on your apex domain pointing to
mail.example.comif you want addresses like[email protected], or set MX onmg.example.comif you use[email protected]for transactional emails.Ensure SPF, DKIM and DMARC records align with the subdomain.
Multi‑MX with different priorities
To build redundancy, publish multiple MX records with different preference values. Example:
Here, senders try primary.mailhost.net first. If unreachable, they try backup1, then backup2. You may choose the same or different providers for each. Make sure all backup hosts are configured to accept mail for your domain.
Temporary maintenance or failover
When performing planned maintenance on your primary mail server, you can temporarily adjust MX priorities:
Add or lower the preference of your backup MX record.
Wait for TTL to expire.
Perform maintenance on the primary server.
Restore original priorities.
Alternatively, some providers allow you to drain traffic by temporarily changing the target of your MX to a maintenance server that returns 421 (try again later) responses. Always communicate planned downtime to your users.
Quick Fix Checklist
Use this short list to resolve a “No MX record found” problem in under 10 minutes:
Verify the domain is registered and has a zone file.
Use
dig example.com MXto confirm whether MX records exist.If none exist and you want to receive mail, create an MX record with host
@and targetmail.example.com, priority 10, TTL 3600.Ensure
mail.example.comhas an A or AAAA record pointing to your mail server’s IP.Remove any CNAME or A record that conflicts with the apex (no CNAME at the root for Namecheap, etc.).
Set proxy/CDN status to DNS‑only for mail hosts (Cloudflare, StackPath, etc.).
Wait a few minutes and re‑query multiple public resolvers.
Test connectivity with
nc -vz mail.example.com 25or send a test message.Monitor bounce logs; if errors persist, proceed with the troubleshooting playbook.
If you don’t intend to receive mail, publish a Null MX (see Section 7).
Pre‑Launch DNS Readiness Checklist
Before launching a production email system (or flipping MX to a new provider), run through this readiness checklist:
❏ Domain ownership: confirm you control the domain and can modify DNS.
❏ Nameservers: verify nameserver changes have propagated and authoritative servers respond.
❏ A/AAAA records: ensure the mail host names resolve correctly and aren’t proxied.
❏ MX records: set up primary and backup MX entries with correct preference values.
❏ TTL strategy: reduce TTLs before changes; increase after stabilisation.
❏ SPF: publish SPF records covering all sending IPs (e.g., include mail provider, exclude others).
❏ DKIM keys: generate and publish DKIM public keys; configure your MTA to sign messages.
❏ DMARC policy: set a DMARC record with
p=noneinitially; adjust toquarantineorrejectafter monitoring.❏ DKIM/SPF alignment: ensure domains align or use subdomain policies.
❏ MTA‑STS/TLS‑RPT: optionally publish MTA‑STS policies and TLS reporting addresses.
❏ Reverse DNS/PTR records: configure PTR records for your outbound IPs to match your HELO/EHLO hostname.
❏ Firewall ports: open TCP 25 inbound/outbound on both the mail server and the sending environment.
❏ Monitoring: set up synthetic monitors or cron jobs to test MX resolution regularly.
❏ Backup MX: configure at least one backup server; ensure failover tested.
❏ Documentation: record DNS settings, TTLs and provider credentials for future reference.
FAQ
No MX record found for domain — what does it mean?
Short answer: your domain has no MX record, so other mail servers don’t know where to deliver emails to you.
MX (Mail Exchange) records tell the internet which mail servers accept mail for your domain. Without one, incoming emails can bounce or never arrive. Fix by adding an MX pointing to your provider (e.g., Google Workspace, Microsoft 365, Zoho).
Do I need MX records if I only send mail and never receive it?
Short answer: yes—many receivers expect the sender’s domain to publish an MX.
Even if you don’t plan to receive mail, publish an MX (to a monitored inbox or null MX as a policy signal) to avoid bounces and failed anti-abuse checks.
Is it safe to rely on A/AAAA fallback instead of publishing MX?
Short answer: no—fallback is legacy and often ignored.
RFC 5321 allows A/AAAA fallback only as a last resort. Modern MTAs may skip it, causing delays or failed delivery. Always publish MX.
Why can’t an MX record point directly to an IP address?
Short answer: MX must target a hostname, not an IP.
This enables A/AAAA lookups, load balancing, IPv4/IPv6 coexistence, and DNSSEC validation. Direct IP targets violate standards and are ignored by compliant MTAs.
Can an MX record point to a CNAME?
Short answer: no—CNAMEs are forbidden in MX targets.
Per standards, MX (and NS) must not use CNAMEs. Using them can break resolution and mail delivery. Point MX to an A/AAAA-backed hostname instead.
What TTL should I use for MX records?
Short answer: 300–600s during changes; 3600s+ once stable.
Short TTLs speed migrations; higher TTLs reduce query load in steady state. Time TTL changes with maintenance windows.
What is a Null MX and when should I use it?
Short answer: Null MX (MX 0 .) declares “we don’t accept mail.”
Use it for web-only domains or when inbound mail is intentionally refused. It’s a clear policy signal to senders.
How long does DNS propagation take after adding an MX record?
Short answer: typically 5 minutes to 48 hours.
It depends on prior TTLs, caches, and providers. Check multiple resolvers (e.g., 1.1.1.1, 8.8.8.8, ISP) to confirm.
What MX priority should I choose?
Short answer: single server: 0 or 10; multiple: lower number = higher priority.
Only relative order matters. Backups get higher numbers so primaries are tried first.
Short answer: yes—but every target must be configured for your domain.
Otherwise, messages directed to an unconfigured provider will bounce. Some vendors support split-domain routing—check docs.
Why does my tool still say “No MX” after I added records?
Short answer: usually caching, wrong zone, nameserver lag, or proxying.
Verify against the authoritative nameservers with:
dig @ns1.example.com example.com MX. Ensure you edited the apex zone and the record isn’t hidden behind a proxy/CDN.
Glossary
| Term | Definition |
|---|---|
| MX (Mail Exchanger) | DNS record specifying which host receives email for a domain. |
| SMTP | Protocol for sending email between servers (RFC 5321). |
| FQDN | Full domain ending with a dot (e.g., mail.example.com.). |
| TTL | Time DNS record stays cached (in seconds). |
| RCODE | DNS status code (NOERROR, NXDOMAIN, SERVFAIL, etc.). |
| NXDOMAIN | DNS code: Domain does not exist. |
| SERVFAIL | DNS failure (e.g., DNSSEC validation error). |
| DNSSEC | Security extensions to verify DNS authenticity. |
| STARTTLS | SMTP command to upgrade connection to TLS. |
| PTR Record | Reverse DNS (IP → hostname) record. |
| Implicit MX | If no MX exists, sender may deliver to domain A/AAAA (RFC 5321). |
| Null MX | MX 0 . — Domain explicitly refuses mail (RFC 7505). |
| MTA | Mail Transfer Agent (Postfix, Exim, etc.). |
| MTA-STS | Policy enforcing TLS for email (RFC 8461). |
| TLS-RPT | Reports TLS failures in SMTP (RFC 8460). |
Summary
In this deep dive you learned:
MX records are crucial for routing mail; they contain a preference value and a host name. Without them, senders may attempt unreliable fallback to A/AAAA records.
The MX target must be a fully qualified host name with valid A/AAAA records and must not be a CNAME. Missing or misconfigured targets cause bounce errors.
Null MX (MX 0 .) explicitly refuses mail for a domain, avoiding fallback attempts.
Checking MX records is easy with tools like
dig,host,nslookup, PowerShell, and code libraries. Use them to diagnose issues and verify propagation.When adding MX records, follow provider‑specific steps, set sensible TTLs, and test from multiple resolvers. Use decision trees and checklists to troubleshoot systematically.
Finally, always publish proper MX records even if you rarely receive mail, and monitor your configuration regularly. A small DNS entry can make the difference between lost opportunities and reliable communication.
