SMTP

SMTP Error 542

"SMTP Error 542" isn't a real RFC 5321 reply code. Learn what mail servers actually return, how to read the real code from logs, and how to fix the underlying rejection.

Updated Jul 1, 2026

The short answer

"SMTP Error 542" is not a reply code defined in RFC 5321 — the SMTP standard assigns no 542 code, and its second digit ("4") falls in an unassigned group. It circulates on email blogs as a vague "bad connection / rejected" label. To fix a real rejection, read the actual 3-digit code and enhanced status (RFC 3463) from your mail logs and act on that — commonly a 5xx TLS, auth, or reputation failure.

Is "SMTP Error 542" a real SMTP code?

No. There is no reply code 542 in the SMTP standard. RFC 5321 §4.2.3 lists every reply code the protocol defines, and 542 is not among them. The structure of the code is also a giveaway: in RFC 5321 §4.2.1–4.2.2 the first digit is the outcome (2yz success, 4yz transient failure, 5yz permanent failure) and the second digit is the subject group — x0z syntax, x1z information, x2z connections, x5z mail system. The second digit 4 (as in 542) is unassigned in the standard, so a spec-compliant server does not emit it.

"542" appears on a number of email-tooling blogs labeled "bad connection," but none cite an RFC or a mainline provider (SendGrid, Amazon SES, Mailgun, Postmark) that actually returns it. Treat the label as noise. A few servers or anti-spam filters may put the digits 542 inside a custom rejection string (e.g. 542 Rejected), but that is a vendor-specific message, not a standard reply code — and the fix depends entirely on the human-readable text that follows it.

How do I fix the rejection behind "SMTP Error 542"?

Stop searching for "542" and find the real code your server logged.

  1. Read the full server response. Look in your SMTP transcript or provider logs for the complete line, e.g. 550 5.7.1 ... or 421 4.7.0 .... The first digit tells you whether to retry: 4yz is transient (retry later), 5yz is permanent (fix and resend). The trailing dotted number is the RFC 3463 enhanced status code (e.g. 5.7.1 = delivery-policy/authorization failure).
  2. Match the code to its real cause. Common permanent rejections that get mislabeled as a generic "bad connection":
  3. 550 5.7.1 / 554 5.7.1 — policy or reputation block. Authenticate your mail with SPF, DKIM, and DMARC, and check whether your sending IP/domain is on a blocklist.
  4. 530 5.7.0 (RFC 4954 §6) — authentication required. Supply valid SMTP credentials.
  5. TLS negotiation failures — connect on port 587 (STARTTLS) or 465 (implicit TLS); both are valid per RFC 8314. Neither port is deprecated.
  6. For Gmail / Google Workspace SMTP, authenticate with an App Password (requires 2-Step Verification) or OAuth2. Google removed "Less Secure Apps" access in 2022 — do not rely on it.
  7. If it's a vendor 542 Rejected string, act on the words after the number and consult that product's docs; it is a local policy decision, not a protocol error.

With Courier

When you send email through Courier, the downstream provider's real SMTP response and status code are surfaced in your message logs. Use that code — not a generic "542" — to diagnose. A 5xx permanent failure means fix authentication, content, or reputation before resending; a 4xx transient failure is safe to retry.

FAQ

Common questions

No. RFC 5321 §4.2.3 does not define a 542 reply code, and the second digit '4' falls in an unassigned group. It is a non-standard label seen on email blogs, not a code mainstream mail servers or providers return.

One API, every provider

Stop debugging raw provider errors

Courier connects to your email, SMS, and push providers, handles retries and failover, and surfaces delivery errors in plain language.

Reply-code definitions per RFC 5321 §4.2.1–4.2.3. Last reviewed Jul 1, 2026. Courier is not affiliated with third-party providers; error behavior may vary by implementation.