MX Records & DNS Mail Routing Guide — IndiaMail

When you send an email, it arrives at the recipient’s inbox in a matter of seconds, travelling across vast global server networks. But how do sending mail servers know exactly which physical server in the world is responsible for handling emails sent to a specific domain name?

The answer lies in the Domain Name System (DNS), specifically a record type known as the Mail Exchanger (MX) record.

Understanding MX records and their associated security headers is crucial for system administrators, developers, and webmasters. In this ultimate guide, we will demystify how mail routing works under the hood and show you how to troubleshoot delivery failures in seconds.

---

1. What is an MX Record?

An MX record is a type of DNS record that specifies the mail server responsible for accepting email messages on behalf of a domain name.

Unlike standard A records (which map a domain name directly to a web server’s IP address), MX records map your domain's email routing to a fully qualified domain name (FQDN) of a mail server, which is then mapped to an IP address.

The Priority System

A domain can have multiple MX records to guarantee high availability. Each record is assigned a preference/priority number:

• Lower numbers represent higher priority (primary servers).
• Higher numbers represent backup or secondary servers.

When a sending mail server queries your domain's DNS, it always attempts to deliver the email to the server with the lowest priority number first. If that server is offline or busy, it falls back to the next lowest priority server.

---

2. Common MX Configurations: Industry Examples

Different email hosting providers require specific MX configurations. Setting up these records incorrectly will halt your email delivery. Here are standard configurations for popular services:

Google Workspace:

Google Workspace handles redundancy using a single high-priority endpoint that distributes load dynamically, or legacy multi-server structures:

• Host: @ | Value: SMTP.GOOGLE.COM. | Priority: 1 (or 10)

Microsoft 365:

Microsoft uses a single custom subdomain string pointing directly to their Exchange servers:

• Host: @ | Value: yourdomain-com.mail.protection.outlook.com. | Priority: 10

iCloud Mail (Custom Domains):

Apple utilizes two servers with different priorities to buffer custom domain inboxes:

• Host: @ | Value: mx01.mail.icloud.com. | Priority: 10
• Host: @ | Value: mx02.mail.icloud.com. | Priority: 10

Crucial Tip: Always include the trailing dot (.) at the end of the server value in your registrar's DNS panel if required. This prevents the registrar from appending your domain name onto the end of the mail server value (e.g., smtp.google.com.yourdomain.com).

---

3. MX Time to Live (TTL) & Propagation Delays

When you modify your domain's MX records, the changes do not take effect globally instantly. This delay is determined by the TTL (Time to Live) parameter set on the record.

TTL represents the number of seconds that recursive DNS servers (like Cloudflare's 1.1.1.1 or Google's 8.8.8.8) are allowed to cache your DNS record before querying your authoritative nameservers for updates.

• If your TTL is set to 86400 (24 hours), resolving servers will cache old MX data for up to a full day, meaning emails will continue routing to your old mail host during this window.
• Best Practice: If you plan to migrate email hosts, lower your MX record TTL to 300 (5 minutes) a few days before the migration. This guarantees that your changes propagate globally within minutes of the cutover.

---

4. The SMTP Delivery Process Under the Hood

According to the IETF RFC 5321 Specification for SMTP, mail transfer agents (MTAs) follow a strict, automated lookup path:

1. User Sends Email: You send a message to user@example.com.
2. DNS Query: The sending mail server queries DNS servers for example.com looking for MX records.
3. MX Selection: DNS returns the list of MX servers (e.g., mail-primary.example.com with priority 10 and mail-backup.example.com with priority 20).
4. IP Resolution: The sending server queries DNS again for an A record of the primary server name (mail-primary.example.com) to get its physical IP address.
5. SMTP Handshake: The sending server opens a TCP port 25 connection to that IP and delivers the email.

If no MX records are found, many MTAs will fallback to querying the domain’s standard A record as a legacy route, but modern email providers frequently reject this as insecure.

---

5. Crucial Email Security Records

Simply setting up an MX record is not enough to secure your domain's email. To prevent email spoofing, phishing, and protect your domain's sending reputation, you must configure three core validation protocols:

A. SPF (Sender Policy Framework)

An SPF record is a TXT DNS record that lists all authorized IP addresses allowed to send emails on behalf of your domain. Incoming mail servers check this list to reject unauthorized senders.

B. DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic digital signature to the headers of outgoing emails. The recipient server validates this signature against a public key published in your DNS to verify the email content has not been altered in transit.

C. DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC ties SPF and DKIM together. It instructs receiving servers exactly what to do if an email fails SPF or DKIM checks (e.g., allow, quarantine, or completely reject the message).

---

6. Decoding SMTP Error Codes Relating to DNS

If your MX records are broken, sending servers will reply with bounce messages containing standard SMTP status codes. Understanding these codes helps you debug issues instantly:

• 550 5.1.1 User Unknown: The recipient domain's MX records resolved correctly, but the specific mail server reports that the user mailbox does not exist.
• 554 5.7.1 Access Denied: Often caused by an SPF or DKIM validation failure, causing the receiving MX server to reject the inbound SMTP packet.
• 451 Temp Failure (DNS lookup failed): The sending server encountered a temporary network timeout while querying your domain's DNS. It will retry periodically for up to 5 days before bouncing permanently.

---

7. How to Troubleshoot Mail Delivery Issues

If your domain is not receiving emails or outgoing messages are bouncing, follow this troubleshooting checklist using the diagnostic tools on IndiaMail:

Step 1: Query Current MX Records

Go to the MX Lookup Tool. Input your domain name and click query. Verify that the listed primary mail servers and priorities match your mail host's specifications.

Step 2: Validate SPF & DKIM Headers

Check that your outbound authorization records are valid and formatted correctly:

• Run an SPF diagnosis with the SPF Checker.
• Validate your outbound signature public key with the DKIM Checker.

Step 3: Run a General DNS Checkup

Perform a complete health check for A, AAAA, CNAME, and TXT records using the DNS Checker. This ensures there are no general network propagation issues blocking your mail servers.

Ensure absolute reliability for your domain and audit your DNS settings with our MX Lookup Tool today!