SMTP Error 554

SMTP reply code 554 is defined in RFC 5321 §4.2.3 as "Transaction failed" (or, when returned in place of the 220 greeting on connection, "No SMTP service here"). Because the first digit is 5, it is a Permanent Negative Completion reply — the receiving server has rejected the message for a reason it considers permanent, so a well-behaved sender should not retry the same message unchanged.

554 is the least specific of the permanent codes. Unlike 550 ("mailbox unavailable") or 552 ("storage exceeded"), 554 is the server's catch-all "I refuse this transaction." That means the actionable information is almost never in the number 554 itself — it is in the enhanced status code (RFC 3463, e.g. 5.7.1) and the free-text message that follow it.

What causes SMTP error 554?

The 554 line you received falls into one of a few distinct buckets. Identify yours from the text after the code:

• 554 5.7.1 ... relay access denied / not permitted — relay/authorization refusal. The server will not relay mail for you. Per RFC 5321 this is the classic "you are not an authorized sender for this hop." Usually SMTP AUTH is off or wrong, or you're sending to a domain the server doesn't accept (e.g. an Exchange host whose Accepted Domains list doesn't include the recipient).
• 554 5.7.1 / 5.7.0 ... blocked, policy, spam, or reputation. The message passed auth but the receiver's content/anti-spam/policy layer rejected it. Sender IP or domain reputation, blocklisting, failing DMARC alignment, or spammy content are typical triggers.
• 554 5.7.1 after DATA with "no valid recipients." RFC 5321 lets a server answer DATA with 554 when every RCPT TO was already rejected — i.e. the recipient address was bad or refused.
• 554 5.3.4 Message too big for system — size limit. The message exceeds the receiver's maximum.
• 554 with no enhanced code ("Mail refused"). Providers like SendGrid return a bare 554 Mail refused as a generic permanent failure; treat it as a bounce and suppress that recipient.

How do I fix SMTP error 554?

1. Read the full response line first. Capture everything after 554 — the enhanced code and text are the diagnosis. Steps below map to the buckets above.

2. If it says relay access denied / not authorized: turn on SMTP authentication in your client or app and send valid credentials over a submission port — 587 (STARTTLS) or 465 (implicit TLS); both are valid per RFC 8314. For Gmail / Google Workspace, use an App Password (with 2-Step Verification) or OAuth2 — Google removed "Less Secure Apps," so basic password auth will not work. If you run your own server, confirm the recipient domain is in its accepted/relay domains.

3. If it's a policy / reputation / spam block: authenticate your domain end-to-end — publish a valid SPF record, sign with DKIM (RFC 6376, using SHA-256 per RFC 8301 — avoid the deprecated rsa-sha1), and ensure DMARC passes with alignment (RFC 9989, which obsoletes the older RFC 7489). Check your sending IP/domain against blocklists with MXToolBox and request delisting where warranted. Warm up new IPs, prune unengaged recipients, and review content for spam triggers.

4. If it names a bad/invalid recipient: verify the address for typos and remove dead addresses; never re-send to an address that returned a permanent 554.

5. If it's 5.3.4 too big: reduce attachment/message size or host large files behind a link.

6. Don't auto-retry. 554 is permanent. Fix the underlying cause, suppress the address, and only re-send after the root cause is resolved.