SMTP Error 556

Note: Some older references (including a previous version of this page) describe 556 as a "message too large" error. That is incorrect. A message-too-large rejection uses 552 ("Requested mail action aborted: exceeded storage allocation"), not 556. The 556 code has a specific, standardized meaning defined in RFC 7504.

What does SMTP error 556 mean?

SMTP reply code 556 — "Domain does not accept mail" is a permanent negative completion reply defined in RFC 7504. It is paired with enhanced status code 5.1.10 ("Recipient address has null MX").

An intermediate SMTP relay returns 556 when it can determine — typically from a DNS lookup, without even opening a connection to the target host — that the recipient's domain has explicitly declared it accepts no email. The mechanism for that declaration is a "null MX" record, defined in RFC 7505: a single MX record of the form

example.com.   IN MX   0   .

The . (root) as the exchange, with preference 0, is a domain owner's way of saying "this domain sends and receives no mail." When your server (or your provider's relay) sees that, it correctly refuses to attempt delivery and surfaces 556.

It is closely related to 521 ("Server does not accept mail"), which is returned by a target host itself on connection; 556 is returned proactively by the relay before any connection, based on the null MX in DNS.

What causes SMTP error 556?

Because 556 is keyed to the recipient domain's DNS, the cause is almost always on the receiving side, not your message:

• The recipient domain publishes a null MX record (MX 0 .) per RFC 7505 — it genuinely accepts no mail. Common for parked domains, send-only brand domains, or domains used only for web/identity.
• A typo'd or wrong recipient domain that happens to resolve to a null-MX domain.
• A domain mid-migration whose owner published a null MX (intentionally or by mistake) instead of valid mail-exchanger records.

Note 556 is not about your size limits, your SPF/DKIM/DMARC, or your authentication — those produce other codes (552 for size, 550/554 with 5.7.x for policy/auth). If you see 556, focus on the destination address and its DNS.

How do I fix SMTP error 556?

1. Confirm the recipient address is correct. Re-check the domain for typos. A 556 on a domain you expected to be live often means you sent to the wrong domain.

2. Verify whether the recipient domain truly publishes a null MX. Look up its MX records:

dig +short MX example.com
# A null MX answers with just:  0 .

If you see 0 ., the domain is intentionally refusing all mail. There is nothing you can change on your side — the domain owner must publish real MX records before it can receive email. Contact the recipient through another channel.

3. If it is YOUR domain returning 556 to others, you have a null MX you didn't intend (or that is left over). Replace it with valid mail-exchanger records pointing at your inbound provider, e.g.:

example.com.   IN MX   10   mx1.yourprovider.example.
example.com.   IN MX   20   mx2.yourprovider.example.

Then allow for DNS propagation/TTL before retrying.

4. If you are sending via an API/provider (e.g., Courier, SendGrid, SES, Mailgun) and see 556 in delivery webhooks/logs, treat it as a hard bounce for that recipient: suppress the address, validate it, and do not retry — retries against a null-MX domain will keep failing permanently.

Because 556 is a permanent (5.x.x) failure, automatic retries will not help; the resolution requires fixing the recipient address or the recipient domain's DNS.