MX Records: Setting Up Email for Your Domain
4 min read
## MX Records: Setting Up Email for Your Domain
If you want to receive email at addresses like `[email protected]`, your domain needs MX records. Mail Exchange records tell the global email system which mail servers are responsible for accepting messages sent to your domain. Without them, email addressed to your domain bounces immediately.
## How MX Records Work
When someone sends an email to `[email protected]`, their mail server does not know where to deliver it. It performs a DNS lookup:
1. Query: "What are the MX records for `example.com`?"
2. DNS returns one or more MX records listing mail server hostnames and priorities
3. The sending server connects to the highest-priority (lowest number) mail server and delivers the message
The key insight: MX records point to **hostnames**, not IP addresses. Those hostnames must themselves resolve to A (or AAAA) records. A common mistake is pointing an MX record at an IP address — this will fail.
## MX Record Anatomy
An MX record has four fields:
| Field | Example | Purpose |
|-------|---------|---------|
| Name | `@` | The domain receiving email (`@` = root) |
| Type | MX | Record type |
| Priority | `10` | Lower = higher preference |
| Value | `mail.example.com` | Hostname of the mail server |
The priority field (also called "preference") is an integer. Mail servers try the lowest number first. If that server is unreachable, they fall back to the next-lowest.
## Setting Up a Single Mail Server
If you run your own mail server at `mail.example.com` with IP `203.0.113.10`, you need:
```
example.com. MX 10 mail.example.com.
mail.example.com. A 203.0.113.10
```
The A record for `mail.example.com` is required — without it, senders cannot resolve the MX hostname and email delivery fails.
## Multiple MX Records for Redundancy
Pointing email at two or more servers provides failover:
```
example.com. MX 10 mail1.example.com.
example.com. MX 20 mail2.example.com.
```
Sending servers try `mail1` (priority 10) first. If it is unavailable, they try `mail2` (priority 20). Senders will retry for up to 5 days before bouncing the message, so temporary downtime on the primary server rarely causes lost email.
If two records share the same priority number, senders choose randomly between them — effectively load-balancing:
```
example.com. MX 10 mail1.example.com.
example.com. MX 10 mail2.example.com.
```
## Google Workspace MX Records
Google Workspace (formerly G Suite) requires these MX records:
| Name | Priority | Value |
|------|----------|-------|
| `@` | 1 | `aspmx.l.google.com` |
| `@` | 5 | `alt1.aspmx.l.google.com` |
| `@` | 5 | `alt2.aspmx.l.google.com` |
| `@` | 10 | `alt3.aspmx.l.google.com` |
| `@` | 10 | `alt4.aspmx.l.google.com` |
After adding these, Google will verify domain ownership via a TXT record before activating email. Remove any existing MX records that point elsewhere before adding Google's records.
## Microsoft 365 MX Records
Microsoft 365 uses a single, tenant-specific MX record:
| Name | Priority | Value |
|------|----------|-------|
| `@` | 0 | `yourtenant-com.mail.protection.outlook.com` |
The exact value is shown in the Microsoft 365 admin center under "Domains." Each tenant has a unique hostname.
## Subdomain Email
By default, MX records on `@` only handle email for `@yourdomain.com`. If you want `[email protected]` to work as an address, add an MX record specifically for the `mail` subdomain:
```
mail.example.com. MX 10 mail.example.com.
```
This is unusual in practice — most setups use the root domain for email and subdomains only as server hostnames.
## Common MX Mistakes
**Pointing MX at an IP address.** MX values must be hostnames. `MX 10 203.0.113.10` is invalid. Create an A record for a hostname and point MX there.
**Leaving old MX records.** When migrating email providers, remove the old MX records. Split MX configuration (old and new records coexisting) causes some mail to land at the old server.
**Not adding SPF, DKIM, and DMARC records.** MX records get mail delivered *to* you; SPF/DKIM/DMARC ensure mail *from* you is trusted. Without these, your outgoing email lands in spam. See TXT Records: SPF, DKIM, and DMARC Explained for the full setup.
**Forgetting the A record for the MX hostname.** If `mail.example.com` has no A record, senders cannot resolve it and email bounces.
## TTL Recommendations
Set MX TTL to 3600 seconds (1 hour) for stable configurations. Before a mail migration, lower it to 300 seconds (5 minutes) at least 24 hours in advance so the change propagates quickly.
## Verifying MX Records
Use the DNS Record Helper tool or run:
```bash
dig example.com MX
```
A healthy response looks like:
```
;; ANSWER SECTION:
example.com. 3600 IN MX 10 aspmx.l.google.com.
example.com. 3600 IN MX 20 alt1.aspmx.l.google.com.
```
You can also test email delivery directly with:
```bash
# Connect to the mail server manually (Telnet/OpenSSL)
telnet aspmx.l.google.com 25
```
## Next Steps
With MX records in place, complete your email DNS setup:
- TXT Records: SPF, DKIM, and DMARC Explained — authenticate outgoing email and prevent spoofing
- Understanding DNS Propagation — understand why changes take time and track progress
- DNS Troubleshooting Guide — diagnose and fix common DNS and email issues
Use WHOIS Lookup Tool to confirm nameserver delegation is working before debugging MX records.