550 Domain Has No Mail — MX Record Missing
Symptômes
- Email bounces with "550 5.1.2 No MX records for domain" or "556 5.1.10 Domain does not accept mail"
- The recipient's domain website works fine (A record exists), but email delivery fails
- `dig MX recipient.com` returns NOERROR with an empty answer section
- Multiple different senders report being unable to email the same domain
- Newly registered or recently transferred domain — DNS records not fully set up
- The recipient's domain website works fine (A record exists), but email delivery fails
- `dig MX recipient.com` returns NOERROR with an empty answer section
- Multiple different senders report being unable to email the same domain
- Newly registered or recently transferred domain — DNS records not fully set up
Causes profondes
- Domain has never had an MX record configured (common for domains bought for apps, not email)
- MX record deleted accidentally during a DNS zone cleanup or migration
- Domain recently transferred and MX records not copied to the new DNS provider
- Typo in the MX record hostname (e.g., missing trailing dot in FQDN)
- Null MX record (MX 0 .) explicitly configured per RFC 7505 to indicate no mail is accepted
Diagnostic
**Step 1 — Check MX records for the recipient domain**
```bash
dig MX recipient.com +short
# Expected output (if properly configured):
# 10 mail.recipient.com.
# 20 mail2.recipient.com.
# Empty output means no MX record — mail delivery is impossible
# NXDOMAIN means the domain itself doesn't exist
```
**Step 2 — Check for a null MX record**
```bash
dig MX recipient.com
# A null MX looks like this in the ANSWER SECTION:
# recipient.com. 3600 IN MX 0 .
# This is RFC 7505 — domain explicitly refuses all mail
```
**Step 3 — Check if MX hostname resolves**
```bash
# Even if MX exists, the target must resolve
dig MX recipient.com +short
# Then verify the mail server hostname resolves:
dig A mail.recipient.com +short
# No A record = unreachable mail server despite valid MX
```
**Step 4 — Check your own sending domain's PTR record**
```bash
# Some receivers also check sender PTR before accepting
dig -x YOUR_SENDING_IP +short
# Should return a FQDN matching your sending hostname
```
```bash
dig MX recipient.com +short
# Expected output (if properly configured):
# 10 mail.recipient.com.
# 20 mail2.recipient.com.
# Empty output means no MX record — mail delivery is impossible
# NXDOMAIN means the domain itself doesn't exist
```
**Step 2 — Check for a null MX record**
```bash
dig MX recipient.com
# A null MX looks like this in the ANSWER SECTION:
# recipient.com. 3600 IN MX 0 .
# This is RFC 7505 — domain explicitly refuses all mail
```
**Step 3 — Check if MX hostname resolves**
```bash
# Even if MX exists, the target must resolve
dig MX recipient.com +short
# Then verify the mail server hostname resolves:
dig A mail.recipient.com +short
# No A record = unreachable mail server despite valid MX
```
**Step 4 — Check your own sending domain's PTR record**
```bash
# Some receivers also check sender PTR before accepting
dig -x YOUR_SENDING_IP +short
# Should return a FQDN matching your sending hostname
```
Résolution
**Fix 1 — Add MX records at your DNS provider (if you own the domain)**
For Google Workspace:
```
Type: MX Name: @ Priority: 1 Value: aspmx.l.google.com
Type: MX Name: @ Priority: 5 Value: alt1.aspmx.l.google.com
Type: MX Name: @ Priority: 5 Value: alt2.aspmx.l.google.com
```
For Microsoft 365:
```
Type: MX Name: @ Priority: 0 Value: yourdomain-com.mail.protection.outlook.com
```
For self-hosted Postfix:
```
Type: MX Name: @ Priority: 10 Value: mail.yourdomain.com
```
**Fix 2 — Remove an accidental null MX record**
If you find `MX 0 .` and did not intend to block email, delete that record and add the correct MX entries.
**Fix 3 — As a sender, contact the recipient via another channel**
If you don't control the recipient's domain, there is nothing you can do — notify them that their domain does not accept email. Include the `dig MX` output as proof.
**Fix 4 — Wait for DNS propagation after adding MX**
```bash
# Check propagation from an external resolver
dig MX yourdomain.com @8.8.8.8 +short
dig MX yourdomain.com @1.1.1.1 +short
# Allow up to 48 hours for full global propagation
```
For Google Workspace:
```
Type: MX Name: @ Priority: 1 Value: aspmx.l.google.com
Type: MX Name: @ Priority: 5 Value: alt1.aspmx.l.google.com
Type: MX Name: @ Priority: 5 Value: alt2.aspmx.l.google.com
```
For Microsoft 365:
```
Type: MX Name: @ Priority: 0 Value: yourdomain-com.mail.protection.outlook.com
```
For self-hosted Postfix:
```
Type: MX Name: @ Priority: 10 Value: mail.yourdomain.com
```
**Fix 2 — Remove an accidental null MX record**
If you find `MX 0 .` and did not intend to block email, delete that record and add the correct MX entries.
**Fix 3 — As a sender, contact the recipient via another channel**
If you don't control the recipient's domain, there is nothing you can do — notify them that their domain does not accept email. Include the `dig MX` output as proof.
**Fix 4 — Wait for DNS propagation after adding MX**
```bash
# Check propagation from an external resolver
dig MX yourdomain.com @8.8.8.8 +short
dig MX yourdomain.com @1.1.1.1 +short
# Allow up to 48 hours for full global propagation
```
Prévention
- When setting up a new domain, always add MX records before announcing the email address — you cannot receive email without them
- Before domain migration, export all DNS records and verify them at the new provider before cutting over nameservers
- Set a low TTL (300s) on MX records before any migration so changes propagate in minutes, not hours
- Test email deliverability after any DNS change using https://mxtoolbox.com/MXLookup.aspx or `mail-tester.com`
- Use a DNS audit checklist that includes MX, SPF, DKIM, and DMARC for every new domain you register
- Before domain migration, export all DNS records and verify them at the new provider before cutting over nameservers
- Set a low TTL (300s) on MX records before any migration so changes propagate in minutes, not hours
- Test email deliverability after any DNS change using https://mxtoolbox.com/MXLookup.aspx or `mail-tester.com`
- Use a DNS audit checklist that includes MX, SPF, DKIM, and DMARC for every new domain you register