# MX record

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/mx-record

## Quick definition

An MX record is like the address that email senders look up to find the correct email server for a domain. It tells the internet where to deliver email for people at that domain. MX records also include a preference number to indicate which server to use first if there is more than one. Without MX records, email systems would not know where to send your messages.

## Simple meaning

Think of the internet as a giant postal system for data. When you send a physical letter, you write the recipient's street address on the envelope. For email, that address is the domain name after the @ symbol, like "example.com." But the email system needs more than just the domain name, it needs to know which specific mail server handles incoming mail for that domain. That is exactly what an MX record provides: it is the official mailing address for a domain's email.

Imagine you want to mail a package to a company with multiple branch offices. You would need to know which office receives packages first, and which one is the backup. MX records work the same way. Each MX record has a priority number. A lower number means higher priority. When someone sends you an email, their email server looks up your domain's MX records. It tries to deliver the message to the mail server with the lowest priority number. If that server is down or unreachable, it tries the next lowest priority. This creates a failover system that helps keep email flowing even if one server fails.

So in plain English: an MX record is simply an entry in the DNS that says, "For emails addressed to @example.com, deliver them to mail.example.com with priority 10, and if that is not available, use backup.example.com with priority 20." The process is automatic and happens every time someone sends an email. It is a core part of how email works, and it is essential for IT professionals to understand because a misconfigured MX record can cause email to bounce or go to the wrong server.

## Technical definition

An MX record is a type of DNS resource record defined in RFC 1035 and later updated by RFC 974 and RFC 5321. It is used by the Simple Mail Transfer Protocol (SMTP) to route email messages to the correct mail server for a given domain. The record consists of several components: a name (the domain name being queried), a type (MX), a class (typically IN for Internet), a Time-To-Live (TTL) value, a preference number, and an exchange value (the hostname of the mail server).

When an SMTP client wants to deliver an email to user@example.com, it first performs a DNS query for the MX records of example.com. The DNS resolver returns a list of MX records, each containing a preference number (also called priority) and a canonical hostname. The SMTP client sorts these records by preference, with the lowest number being the highest priority. It then attempts to establish an SMTP connection to the hostname of the highest-priority server. If that server is unreachable or returns a temporary failure, the client retries with the next-highest priority server. This process repeats until delivery succeeds or all servers fail, at which point the message is queued for later retry.

MX records must point to hostnames that have corresponding A or AAAA records, not directly to IP addresses. This is important because the SMTP protocol expects to resolve the mail server hostname to an IP address before connecting. Wildcard MX records are allowed but generally discouraged because they can cause unexpected behavior, such as sending email for non-existent subdomains to unintended servers. The preference value ranges from 0 to 65535, with lower values indicating higher priority. A common practice is to use multiple MX records with different preferences to provide redundancy and load balancing.

From a security perspective, MX records are also relevant to email authentication technologies like SPF, DKIM, and DMARC. While the MX record itself does not authenticate email, it works in conjunction with SPF records to authorize which servers are allowed to send email for a domain. In configurations where the MX record points to a third-party email service (like Office 365 or Google Workspace), the SPF record must include that service's IP ranges to prevent legitimate email from being marked as spam. MX records are also critical for email routing in scenarios involving multiple domains, forwarding services, or complex hybrid environments where on-premises and cloud mail servers coexist.

## Real-life example

Imagine you move into a new apartment building and want to receive packages. You give the post office your building's address: 123 Main Street. But the building has a mailroom in the basement and a package locker in the lobby. Packages delivered to the wrong spot might get lost. So you need to tell the post office exactly where to deliver packages for you.

Now, an MX record is like an instruction card you tape to your building's front door. The card says: "For all mail addressed to Apartment 4B, please deliver to the mailroom in the basement first. If the mailroom is closed, please use the package locker in the lobby as a backup." The post office reads this card every time they have a package for you. They always try the mailroom first. Only if that fails do they use the locker.

In this analogy, your domain is the building address, and the email server is the mailroom. The MX record is the instruction card. The priority numbers (preferences) tell the email sending server which server to try first and which to try next. If you only have one mailroom and it is closed, your mail piles up outside. Similarly, if you only have one MX record and that mail server goes down, you will lose incoming email. That is why IT professionals often set up multiple MX records with different priorities, just like you would want a backup delivery location for your packages.

Also, imagine your building changes its mailroom to a new location. You would have to update the instruction card. In IT terms, if you change email providers, you must update your MX records. Otherwise, senders' email servers will still try the old mail server and your email will not arrive at the new provider. This is a common source of email migration problems.

## Why it matters

MX records are fundamental to the functioning of email on the internet. Without them, no one could reliably send email to a domain. Every organization that uses email, which is nearly every organization, must have correct MX records configured in their DNS. For IT professionals, managing MX records is a daily responsibility, especially during email provider migrations, when setting up new domains, or when troubleshooting email delivery issues.

A misconfigured MX record can have immediate and serious consequences. If you accidentally delete the MX record, all inbound email to your domain will bounce. If you set the priority incorrectly, email might go to the backup server first, which may not be the intended primary. If you mistype the hostname, email will try to deliver to a non-existent server and fail. These failures can result in lost business communications, missed customer inquiries, and frustrated users. For system administrators, verifying MX records using tools like nslookup, dig, or online MX lookup tools is part of standard troubleshooting.

MX records also play a role in security and compliance. Combined with SPF records, they help prevent spammers from forging your domain in email headers. Email servers receiving messages often check that the sending server matches the domain's MX records or SPF records. Incorrect MX configuration can lead to legitimate outgoing email being rejected as spam. In compliance-heavy industries like finance or healthcare, email routing must be precise to ensure data stays within approved jurisdictions. MX records help control where email ends up.

Finally, understanding MX records is essential for anyone working with cloud email services. Services like Google Workspace, Microsoft 365, and Zoho all require you to update your domain's MX records to point to their servers. The step-by-step setup guides for these services are heavily focused on creating or modifying MX records. Without that knowledge, even a basic email migration becomes impossible. That is why MX records are one of the first topics taught in networking and system administration courses.

## Why it matters in exams

MX records appear in a wide range of IT certification exams, including CompTIA Network+, CompTIA Security+, Cisco CCNA, AWS Solutions Architect, Microsoft 365 Certified: Messaging Administrator Associate, and various DNS-specific certifications. For Network+, MX records are part of the DNS objectives under domain 1.5 (Explain common networking protocols, ports, and services). You should know that MX records use UDP port 53 for DNS queries and that they point to a mail server hostname, not an IP address. Security+ may include MX records in the context of email security, SPF, DKIM, and DMARC, especially regarding anti-spoofing measures.

In Cisco CCNA, MX records are not a primary focus but can appear in DNS-related questions, particularly those dealing with network services and application layer protocols. For AWS Solutions Architect, understanding MX records is important for Route 53 configurations, especially when setting up email routing for domains hosted on AWS. You might be asked to choose the correct record type to route email traffic to an Amazon SES endpoint. The Microsoft 365 Messaging Administrator exam (MS-203) has a heavy emphasis on MX records because configuring hybrid mail flow and migrating to Exchange Online requires precise MX record setup.

Exam questions about MX records typically fall into several categories. The most common is identifying the correct record type: given a scenario about email delivery, you must select MX from a list of DNS record types. Another frequent question type asks about priority/preference: which server will be contacted first when multiple MX records are present. A third category involves troubleshooting: why is email not arriving at a domain? The answer often involves checking the MX record. You may also see questions that test your knowledge of MX record restrictions, such as the fact that MX records cannot point directly to an IP address. In scenario-based questions, you might be asked to configure MX records in a DNS management console or to identify the correct MX record syntax for a specific exam simulation.

Because MX records are relatively simple compared to other DNS concepts, examiners often use them to test attention to detail. Watch out for questions that mix up MX with CNAME, A, or AAAA records. It is also common to see a question that presents several MX records with the same priority but different hostnames, the correct answer is that the client will try one of them (usually randomly) because equal priorities indicate equal preference. Mastering these nuances can help you pick up easy points on exam day.

## How it appears in exam questions

Exam questions involving MX records are often scenario-based or direct knowledge checks. A common scenario question goes like this: "A company has two email servers. The primary server is mail.example.com and the backup is backup.example.com. They want all email to try the primary first. Which DNS records should they create?" The answer is two MX records, one with preference 10 pointing to mail.example.com and one with preference 20 pointing to backup.example.com. Another variation asks which server will be used first when multiple MX records have the same preference, the answer is that the sending server randomly picks one of the equal-preference servers.

Configuration-type questions might present a partial zone file or a DNS management console screenshot and ask you to identify the error. For example, an MX record pointing to an IP address instead of a hostname is incorrect. Another common mistake exam questions test is confusing the MX record's exchange value with the domain name itself. Sometimes a student might think an MX record points to a domain like example.com, when it actually points to a specific hostname like mail.example.com. Questions about syntax also appear: you might be asked to select the correct format for an MX record in BIND zone files, such as "@ IN MX 10 mail.example.com."

Troubleshooting questions often describe a scenario where users cannot receive email from external senders. The troubleshooting steps include checking whether the MX record exists, whether it resolves to a valid IP address, and whether the mail server is reachable on port 25. Some questions combine MX with SMTP: "After migrating to a new email provider, external senders get a 'no mail exchanger' error. What is most likely the problem?" The answer is that the MX record was not updated to point to the new provider's server. Another type presents a dig output of MX records and asks you to interpret the priority and exchange values.

Multiple-choice questions on MX records may include distractors like "CNAME record" or "A record" in the options. For example, "Which DNS record is used to specify a domain's mail server?" The correct answer is MX. A slightly more advanced question might ask about the maximum number of MX records allowed for a domain (there is no limit, but practical considerations apply). You might also encounter questions about the TTL value: a short TTL (like 300 seconds) is used during migrations so that changes propagate quickly, while a longer TTL (like 86400) is used for stable configurations. Understanding these exam patterns helps you focus your study on the most likely question formats.

## Example scenario

You are an IT support specialist at a medium-sized company called GreenLeaf Inc. The company's domain is greenleaf.com. Currently, the email is hosted on their own server named mail.greenleaf.com. The CEO reads an article about cloud email and decides to switch to Microsoft 365. The CEO asks you to make the switch by next Friday.

You create a Microsoft 365 tenant and get the new mail server hostname: greenleaf-com.mail.protection.outlook.com. Now you need to update the DNS records for greenleaf.com to point email to the new server. You log into the domain registrar's DNS management console and find the current MX record: it points to mail.greenleaf.com with a preference of 10. You add a new MX record for greenleaf.com with preference 10 pointing to greenleaf-com.mail.protection.outlook.com. You also lower the TTL to 300 seconds so the change propagates quickly. But you forget to remove the old MX record.

After the change, some users report that they are receiving email on the old server and some on the new server. The problem is that you have two MX records with the same preference (10). Some email servers send to the old server, others to the new one. The fix is to reduce the preference of the old record to 20 (making it a backup) or remove it entirely once you confirm all email is flowing through the new server. After you set the old record to preference 20, email consistently goes to Microsoft 365 first. This example shows why careful attention to MX priority is crucial during migrations.

## Common mistakes

- **Mistake:** Pointing the MX record directly to an IP address instead of a hostname.
  - Why it is wrong: The SMTP protocol and DNS standards require that MX records contain a hostname, not an IP address. The sending server first resolves the hostname to an IP via an A or AAAA record. Direct IP addresses are not valid in MX records.
  - Fix: Create an A record for the mail server hostname first, then point the MX record to that hostname.
- **Mistake:** Setting all MX records with the same priority when one is intended as a backup.
  - Why it is wrong: When multiple MX records have the same priority, sending servers treat them as equal and may randomly choose any of them. The backup server will receive some traffic even when the primary is working, defeating the purpose of a backup.
  - Fix: Assign a lower priority number to the primary server (e.g., 10) and a higher number to the backup (e.g., 20) to enforce order.
- **Mistake:** Forgetting to remove or lower the priority of the old MX record after migrating to a new email provider.
  - Why it is wrong: If the old MX record remains with the same or lower priority, some email may still be routed to the old server, causing messages to be lost or creating split delivery.
  - Fix: During migration, either remove the old MX record entirely or change its priority to a much higher number (e.g., 50) so the new server is always tried first.
- **Mistake:** Confusing MX records with CNAME records when setting up email routing.
  - Why it is wrong: CNAME records alias one domain name to another and are not used for specifying mail servers. Using a CNAME for mail delivery will not work because SMTP clients specifically look for MX records.
  - Fix: Always use an MX record to define the mail server for a domain. Use CNAME only for aliasing hostnames, not for email routing.
- **Mistake:** Leaving the TTL too long during a planned email server change.
  - Why it is wrong: A long TTL (e.g., 86400 seconds = 1 day) means DNS resolvers cache the old MX record for up to 24 hours. Users cannot receive email at the new server until the cache expires.
  - Fix: Before the migration, reduce the TTL to 300 seconds (5 minutes) so changes propagate quickly. After migration is complete, you can increase the TTL again.

## Exam trap

{"trap":"An exam question presents a scenario where a domain has two MX records: one with priority 10 pointing to server A, and another with priority 20 pointing to server B. The question asks: 'Which server will receive email if server A is down?' The trap answer is 'server B.'","why_learners_choose_it":"Learners think that if the primary is down, the sending server automatically tries the next priority. While that is partly true, many exam questions test the nuance that the sending server will retry the primary server multiple times before moving to the lower-priority server. The answer is not simply 'server B' but rather 'the sending server will queue the message and retry server A multiple times before attempting server B.'","how_to_avoid_it":"Read the question carefully. If it says 'server A is down,' the sending server will attempt delivery, fail, and then retry server A several times over a period of hours. Only after exhausting retries will it try server B. So, if the question asks 'which server receives email immediately?' the answer could be 'neither' or 'the message is queued.' Understand SMTP retry behavior, not just DNS lookup order."}

## Commonly confused with

- **MX record vs A record:** An A record maps a hostname to an IPv4 address. An MX record maps a domain to a mail server hostname and includes a priority. They serve different purposes: A records are for general hostname resolution, MX records are specifically for email delivery. (Example: If you want to visit a website, you use an A record. If you want to send an email, you use an MX record. They are both in DNS but do different jobs.)
- **MX record vs CNAME record:** A CNAME (canonical name) record aliases one domain name to another. It is used for web servers, not for email. An MX record must not point to a CNAME because older SMTP servers may not follow CNAMEs correctly; MX should point directly to an A or AAAA record. (Example: Using a CNAME for email is like putting a forwarding address on a package but the forwarding address is itself a PO box that still needs to be resolved. It adds unnecessary complexity and can fail.)
- **MX record vs SPF record:** An SPF (Sender Policy Framework) record is a TXT record that lists which servers are authorized to send email for a domain. An MX record tells the world where to deliver incoming email. They work together but are different record types with different functions. (Example: The MX record is your front door for mail delivery. The SPF record is a list of who is allowed to use your address as the return address when sending mail. Both are needed for proper email operation.)

## Step-by-step breakdown

1. **User composes and sends an email** — The sender's email client (like Outlook or Gmail) passes the message to their outgoing SMTP server. The destination address is user@domain.com. The SMTP server needs to find the mail server for domain.com.
2. **SMTP server performs DNS query for MX records** — The sending SMTP server sends a DNS query for MX records of domain.com. The query goes to the DNS resolver (often configured by the ISP or network admin), which starts a recursive lookup if the answer is not cached.
3. **DNS returns list of MX records with preferences** — The authoritative DNS server for domain.com returns a set of MX records. Each record contains a preference number and a hostname. For example, preference 10 for mail.domain.com and preference 20 for backup.domain.com.
4. **Sending server sorts MX records by preference** — The SMTP server sorts the records by preference value from lowest to highest. Lower numbers are tried first. If multiple records share the same preference, they are treated as equal and the server can choose randomly among them for load balancing.
5. **Server attempts SMTP connection to highest-priority host** — The sending server resolves the hostname from the top MX record (e.g., mail.domain.com) to an IP address via an A or AAAA record. It then attempts to establish an SMTP connection on TCP port 25 to that IP address.
6. **Delivery or failover** — If the connection succeeds, the email is transferred. If it fails (timeout, server unreachable, etc.), the sending server will retry the same server multiple times over several hours. Only after exhausting retries on the primary does it move to the next MX record in the sorted list.

## Practical mini-lesson

In practice, configuring MX records is one of the most common DNS administration tasks. When you set up email for a new domain, the first step is usually to obtain the correct MX record values from your email provider. For example, Google Workspace provides the hostname ASPMX.L.GOOGLE.COM with a priority of 1. You then create an MX record in your domain's DNS zone that points your domain to that hostname. You might also create additional MX records with higher priorities for redundancy, such as ALT1.ASPMX.L.GOOGLE.COM with priority 5.

One critical practical point is that MX records must be fully qualified domain names ending with a dot (also called fully qualified domain names or FQDNs). In BIND zone files, you write something like "@ IN MX 10 mail.example.com." The trailing dot is essential; without it, the DNS software appends the domain name, resulting in a broken record. Most modern DNS management web interfaces handle this automatically, but it is a common source of errors when editing zone files directly.

Another practical consideration is that MX records can be used for load distribution. By setting multiple MX records with the same priority, you can spread incoming mail across several servers. However, this is not true load balancing because the sending server makes the choice independently; different senders may use different servers, but a single sender will generally stay with one server for a given connection. For more sophisticated load balancing, many organizations use a single MX record pointing to a load balancer that distributes traffic internally.

Troubleshooting MX records in the real world often involves checking propagation. After making a change, you can use online MX lookup tools or the dig command (e.g., dig MX example.com) to verify that the new MX record is visible. If email is still going to the old server, it could be due to DNS caching. You can check the TTL value and the time since the change. In urgent situations, you can lower the TTL temporarily or contact the DNS provider to force a cache flush.

A common professional mistake is neglecting to monitor MX records after setup. DNS records can be accidentally deleted or modified by other administrators. Automated monitoring tools can alert you if MX records change unexpectedly. For organizations that handle sensitive data, MX records are part of the security perimeter; a misconfigured MX record that points to a non-encrypted server could expose email traffic. Therefore, best practice includes using DNSSEC to protect the integrity of DNS responses and regularly auditing DNS records, including MX, for correctness.

## Memory tip

Remember MX = Mail eXchange: the record that directs email to the correct server, with priority preferring the lowest number.

## FAQ

**Can I have multiple MX records for the same domain?**

Yes, you can have multiple MX records. This is common for redundancy and load balancing. Each record has a preference number that determines the order servers are tried.

**What happens if I delete my MX record?**

If no MX record exists for a domain, sending servers will fall back to the A record of the domain itself. However, many email servers will reject mail if there is no MX record, so email will likely bounce.

**Do MX records point to IP addresses?**

No, MX records must point to a hostname, not an IP address. The hostname is then resolved via an A or AAAA record to get the IP address.

**How long does it take for MX record changes to propagate?**

It depends on the TTL value set on the record. Common TTLs range from 300 seconds (5 minutes) to 86400 seconds (24 hours). Propagation is complete when all DNS caches have expired and updated.

**Can MX records be used with IPv6 addresses?**

Yes, the hostname in an MX record can resolve to an IPv6 address via an AAAA record. The MX record itself remains a hostname; IPv6 support comes from the underlying AAAA record.

**Why do some domains have MX records with the same priority?**

Equal priority MX records indicate that the sending server can choose among them arbitrarily. This provides load balancing and redundancy because if one server is down, the sending server can try another with the same priority.

## Summary

The MX record is a foundational element of email routing on the internet. It tells email sending servers where to deliver messages for a domain. Understanding MX records is not just about knowing their function, it requires understanding priority values, the relationship with A and AAAA records, and the importance of correct configuration during migrations. IT certification exams frequently test MX records because they are a concrete, real-world application of DNS theory.

For IT professionals, the practical takeaway is that MX records must be managed carefully. A single typo or forgotten record can disrupt email flow for an entire organization. Monitoring MX records, setting appropriate TTLs, and using multiple records for redundancy are standard best practices. In exams, the key is to remember that MX records use hostnames, not IPs, and that lower priority numbers are tried first. Watch out for traps about SMTP retry behavior and equal-priority load balancing.

Whether you are studying for CompTIA Network+, Security+, CCNA, or cloud certifications, MX records are likely to appear. By mastering this simple but critical DNS record type, you can pick up easy exam points and build a solid foundation for more advanced networking and email concepts.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/mx-record