SMTP error 556
Domain does not accept mail (null MX).
Updated Jul 1, 2026
SMTP 556 means "domain does not accept mail". Per RFC 7504, a relay returns 556 (enhanced status 5.1.10) when the recipient domain publishes a null MX record (RFC 7505) declaring it accepts no email. It is a permanent failure caused by the recipient domain, not by your message. Confirm the recipient address and domain are correct. The domain cannot receive mail until its owner publishes valid MX records.
Verify the recipient domain; only its owner can publish valid MX records.
What it means
556 is a permanent negative completion reply defined in RFC 7504, paired with enhanced status 5.1.10 ("recipient address has null MX"). A relay returns it when a DNS lookup shows the recipient domain has declared it accepts no email, often before any connection to a target host is even attempted. The declaration is a null MX record from RFC 7505: a single MX record with the root "." as the exchange at preference 0, written as "example.com. IN MX 0 .". That is a domain owner saying the domain sends and receives no mail, so the sending server refuses delivery and surfaces 556. It is close to 521 ("server does not accept mail"), which a target host returns on connection, while 556 is returned by the relay ahead of any connection based on the DNS record. One correction worth stating plainly: 556 is not a "message too large" error. Size rejections use 552, not 556.
Common causes
An MX record of "0 ." per RFC 7505 means the domain genuinely accepts no mail. This is common for parked domains, send-only brand domains, and domains used only for a website or identity.
A typo that happens to resolve to a null-MX domain produces 556 even though you expected a live mailbox.
A domain whose owner published a null MX, by choice or by mistake, instead of valid mail-exchanger records during a move.
How to fix it
- Confirm the recipient address is correct
Re-check the domain for typos. A 556 on a domain you expected to be live often means the mail went to the wrong domain.
- Verify the null MX with a DNS lookup
Run "dig +short MX example.com". A null MX answers with just "0 .". If you see that, the domain is intentionally refusing all mail and nothing on your side changes it. Reach the recipient through another channel.
- If it is your domain, publish real MX records
Replace the leftover null MX with valid mail-exchanger records pointing at your inbound provider, for example "example.com. IN MX 10 mx1.yourprovider.example." and "example.com. IN MX 20 mx2.yourprovider.example.", then wait for DNS propagation and TTL before retrying.
- If you send via an API or provider, treat it as a hard bounce
When 556 shows up in Courier, SendGrid, SES, or Mailgun logs, suppress the address, validate it, and do not retry. Retries against a null-MX domain keep failing permanently.
Paired code
A real bounce often shows both a 3-digit code and an enhanced code together. This one commonly pairs with:
Common questions
Does SMTP 556 mean my email was too large?
No. That is a common misconception. A message over the size limit is rejected with 552 ("exceeded storage allocation"). Per RFC 7504, 556 means the recipient domain publishes a null MX record and accepts no mail at all.
What is the difference between SMTP 556 and 521?
Both mean a domain does not accept mail, but 521 is returned by the target host itself on connection, while 556 is returned by a relay before any connection, based on the null MX record in DNS.
How do I check if a domain has a null MX record?
Run "dig +short MX example.com". If the only answer is "0 .", the domain has a null MX and accepts no email until its owner publishes valid MX records.