SMTP Error 554: Transaction Failed. What It Means and How to Fix It

Of all SMTP reply codes, 554 is the most generic and therefore the most confusing. The definition in the SMTP standard is short: "transaction failed". In the same standard it is also the reply a server sends in place of its greeting when it has no SMTP service for you at all. Real servers use it for a dozen different problems: your IP address is on a block list, the content looks like spam, the sender failed an authentication check, the server will not relay for you, a loop was detected, or a policy forbids the message. The code alone tells you that the server refused permanently. The text and the enhanced status code tell you why. This guide shows how to read them, groups the common 554 messages by cause, and gives the fix for each. If you are in a hurry, find the exact text of your bounce in the tables below and jump to the matching section.

What 554 means in the standard

RFC 5321 defines 554 as "Transaction failed (Or, in the case of a connection-opening response, No SMTP service here)". It is a permanent negative reply, so the sending server will not queue the message for a retry. It can appear at several points in the conversation. At the very start, in answer to the connection, it means the server refuses to talk to you at all, which is usually a block of your IP address. After MAIL FROM or RCPT TO, it means the sender or recipient was refused for a policy reason. After DATA, it means the message content or its authentication was refused. Knowing the point where it appeared is a big clue, and your logs or a manual test (see how to test an SMTP connection) will show it.

Read the enhanced status code

Most servers add an enhanced code such as 5.7.1 after the number. The enhanced codes are defined in RFC 3463: the first digit says permanent (5) or temporary (4), the second digit gives the subject, and the third the detail. Subject 7 is "security or policy status", which accounts for most 554 replies. The following table lists the combinations you are likely to see.

Group 1: your IP or domain is blocked

The text usually names a list: "blocked using zen.spamhaus.org", "listed at ...", "poor reputation", or it mentions a network block. The receiving server asked a block list about your sending IP and received a positive answer. Fixing this means identifying why the IP was listed and removing the cause before you ask for delisting. Check the listing with the steps in how to check blocklists, and follow the delisting guide. The common causes are a compromised account or website form, a shared IP with a bad neighbour, a sudden spike on a new IP, or a list with many invalid addresses. If you use a shared IP from a provider, send the full bounce to their support team, because only they can act on the IP.

Group 2: spam or content rejection

Messages such as "rejected as spam", "message content rejected" or "spam detected" mean a filter scored the message as too suspicious. Content is only one input. The filter also considers the sender's reputation, authentication, URLs in the message and even the proportion of image to text. Run the message through a spam checker, look at the links (shortened or newly registered domains raise scores), remove attachments that are often blocked, and make sure there is a plain-text part. The guides on content and spam filters and spam checkers explain what to look for. If only one campaign was rejected and others were fine, compare them: the difference is usually a link, a phrase or a segment.

Group 3: authentication and policy

Receivers increasingly reject mail that fails authentication. A 554 5.7.1 or 5.7.9 that mentions SPF, DKIM, DMARC, "unauthenticated", or "policy" points here. Check that SPF includes the sending service, that DKIM signs the message with your domain and that DMARC alignment holds. The usual repair is covered in rejected due to DMARC policy and authenticating your sending domain. Mailbox providers also publish bulk-sender requirements, for example one-click unsubscribe and a low complaint rate; see the Gmail and Yahoo requirements. Check the reverse DNS record of your IP, too, because a missing or mismatched PTR record is a frequent reason for policy rejections: see reverse DNS and PTR.

Group 4: relay refused

If the text says "Relay access denied", the server was asked to forward mail for a domain it does not host, from a client it does not trust. Authenticate, use the right submission server and port, or add your trusted address. The causes and the fixes for each mail server are in Relay access denied and unable to relay.

Group 5: loops and malformed messages

Hop count exceeded (5.4.14) means the message passed through too many servers because two systems keep forwarding it to each other: for example, a mailbox that forwards to an address that forwards back, or a catch-all that sends to itself. Look at the Received headers in the returned copy to see the path (see how to read email headers), then remove the circular forward. A 5.6.0 reply or text about invalid headers, a missing Message-ID, a duplicate header, or a bad MIME boundary points to a message that does not follow the format standard. Application code that builds messages by hand is the usual source; see MIME and multipart messages explained. Also check that every line ends with CRLF and that no header line is longer than the limit.

Group 6: no SMTP service

If the 554 arrives in place of the greeting, the server refused the connection before any commands. Your IP is on a deny list at the connection level, you are connecting to a host that does not accept mail from the Internet, or you are connecting to the wrong port. Check the IP against block lists and confirm the host and port. A few servers also use this reply when they are overloaded or in maintenance; if the same server accepts connections from another IP address, the first explanation is the likely one.

A fast diagnosis process

1. Copy the full bounce. Note the exact text, the enhanced code, the receiving server and the time.
2. Decide the group using the tables above: blocklist, content, authentication, relay, loop or no service.
3. Check one thing at a time: the IP on block lists, the authentication results in a test message, or the server settings.
4. Fix the cause. Do not resend the same message to the same recipient until you have changed something.
5. Test with a new message to a mailbox you control at the same provider.
6. Record the cause and the fix so that the next 554 takes minutes instead of hours.

When to contact the receiving provider

If you have checked authentication, reputation and content and still get a 554, use the provider's sender support channel, which is often linked in the bounce. Include the sending IP addresses, the domain, the exact error with timestamps, example message identifiers and a summary of the changes you made. Avoid asking them to "unblock" without details. Large providers respond to requests that show you understand and fixed the cause.

Prevent 554 errors

Most 554 rejections are predictable. Authenticate every sending source. Keep complaint rates low and your list clean. Warm up new IPs and domains instead of starting at full volume. Watch your delivery logs for the first rise in rejections, because a rising rate is a warning, and respond before the block becomes broad. Keep marketing and transactional mail on separate streams so that a campaign problem cannot stop receipts and password resets: see separating mail streams. Read SMTP reply codes explained and how to read a bounce code so your team can handle future bounces quickly.

References and further reading

• RFC 5321: Simple Mail Transfer Protocol
• RFC 3463: Enhanced Mail System Status Codes
• IANA: Enhanced Status Codes registry