When an email fails to arrive, the conversation usually jumps straight to spam folders or content filters. Yet the very first thing that happens, long before any spam check, is a DNS lookup that decides where the message should even go. That lookup uses an MX record. If the MX record is wrong or missing, the email never has a chance to be delivered, no matter how perfect everything else is.
For QA engineers, understanding MX records turns a mysterious "email didn't arrive" bug into a concrete, verifiable problem. This article explains what MX records are, how they work, and how to check them during testing.
What Is an MX Record?
MX stands for Mail Exchange. An MX record is a type of DNS record that tells the internet which mail servers are responsible for accepting email on behalf of a domain. When someone sends a message to [email protected], the sending server performs a DNS query for the MX records of example.com. The response lists the servers that handle mail for that domain.
A few properties make MX records distinctive:
- An MX record points to a hostname, not an IP address directly.
- Each record has a priority number, and lower numbers are preferred.
- A domain can have several MX records for redundancy and load distribution.
Because MX records determine routing, they are the starting point of every delivery path.
How Mail Routing Uses MX Records
Here is the sequence a sending server follows when someone emails your domain:
- Look up the MX records for the recipient's domain.
- Sort the results by priority, lowest first.
- Connect to the highest-priority mail server and attempt delivery.
- If that server is unavailable, try the next one in order.
This is why priorities matter. A common configuration uses a primary mail server with priority 10 and a backup with priority 20. If the primary is down, mail flows to the backup instead of bouncing.
The Priority Field
The priority (sometimes called preference) is a small integer. The practical rule is that the lowest number wins. Equal priorities mean the sender may use any of them, usually distributing load. A frequent mistake is assuming a higher number means higher priority. It does not, and reversing the values can silently send mail to the wrong server.
Why QA Engineers Should Care
Email verification, password resets, and notifications all depend on mail reaching the right place. During testing you may work with staging domains, sandbox domains, or temporary inboxes, and each one needs correct MX records to receive mail at all.
Testing scenarios where MX records matter include:
- Verifying that a newly configured test domain can actually receive email.
- Confirming that a staging environment does not accidentally route to production mail servers.
- Checking that a domain used for signup confirmation has working mail routing.
- Debugging why messages sent to a test address never arrive.
If a domain has no MX record, the sending server typically falls back to the domain's A record as an implicit mail host, which may not be what you intend. Explicit, correct MX records remove that ambiguity.
Checking MX Records During Testing
You can inspect MX records directly with standard DNS tools. This is often the fastest way to confirm a test domain is ready.
# Look up the mail servers for a domain
dig MX example.com +short
# Expected output lists priority and hostname, for example:
# 10 mail1.example.com.
# 20 mail2.example.com.
# To confirm the mail host resolves to an IP address
dig A mail1.example.com +short
On Windows, the equivalent commands are:
nslookup -type=MX example.com
Both approaches reveal the priority values and the target hostnames, which is enough to confirm routing is configured as expected.
What Good and Bad Look Like
A healthy result has at least one MX record pointing to a reachable host with a sensible priority. Warning signs include:
- No MX records at all, which usually means mail cannot be delivered.
- MX records pointing to decommissioned or misspelled hostnames.
- A trailing dot missing when records were entered by hand, causing resolution failures.
- All records set to the same priority when redundancy was intended.
- A staging domain pointing to production mail servers.
Each of these is easy to verify once you know to look.
MX Records and the Rest of the Stack
MX records handle routing, but they are not the whole story. Once mail reaches the correct server, SPF, DKIM, and DMARC determine whether it is authenticated and trusted. A domain can have flawless MX records and still have its mail rejected because authentication failed. Think of MX records as the address on the envelope and authentication as the signature inside.
When you send a test message to a disposable address, you can inspect both layers. The Public Inbox shows the message content, and the raw headers reveal the authentication results produced by the receiving server. Combining an MX check with a header check gives you a complete picture of why a message did or did not arrive.
A Quick MX Testing Checklist
- Confirm the domain has at least one valid MX record.
- Verify each MX hostname resolves to an IP address.
- Check that priorities match your intended primary and backup order.
- Ensure staging domains do not route to production mail servers.
- Send a real test message to a Public Inbox to confirm end-to-end routing.
Conclusion
MX records are the first checkpoint in every email delivery, and they are simple to verify once you know what to look for. For QA engineers, a quick MX lookup can save hours of chasing phantom spam-filter bugs. Combine MX checks with a disposable inbox from Mail4QA and you can confirm routing and content in one pass.
