Cause · impact · fix
554 5.7.1 — message rejected
554 5.7.1 is a permanent rejection. The receiving server refused your message on policy grounds — almost always failed authentication or a blocked sending IP. Here is why it happens, what it costs you, and how to clear it.
What it means
The cause.
A reply code has two parts. The 554 is the basic SMTP code from RFC 5321 — a permanent transaction failure, meaning the receiver will not accept this message and retrying as-is will not help. The 5.7.1 is the enhanced status code from RFC 3463, and it means "delivery not authorised, message refused": the sender is not authorised to send to the destination. The leading 5 marks it permanent. Together they say the receiver made a deliberate policy decision to reject you, not that anything was temporarily unavailable.
The word "authorised" is the key. In practice a receiver returns 554 5.7.1 for a handful of policy reasons: your message failed authentication (SPF, DKIM or DMARC) and the receiver does not accept unauthenticated mail; the sending IP or domain is on a blocklist or has poor reputation; your server tried to relay through a host that does not relay for you; or the content tripped a spam or security rule. The exact trigger is usually spelled out in the text that follows the code, so read the full bounce line rather than the code alone.
This is distinct from an authentication result you might see in a header. spf=fail, dkim=fail or dmarc=fail in Authentication-Results describe what the receiver measured; 554 5.7.1 is the action it took as a result. The fix is never to the result — it is to the underlying configuration or reputation that produced it.
Why it matters
The impact.
A 5xx rejection is final. The message bounces back to the sender and is not retried, so every affected recipient simply never receives it. Because the same policy applies to every message you send that way, this is not a one-off — it repeats on all mail until the root cause is fixed, and a run of hard bounces feeds back into your sender reputation and makes the next batch land in spam.
When the trigger is authentication, the 2024 Gmail and Yahoo bulk-sender rules make it worse. Both now require valid SPF, valid DKIM and an aligned, passing DMARC for anyone sending in volume; Gmail issues 5.7.1 and 5.7.26 rejections specifically for unauthenticated mail. So a message that once slipped through can now be refused outright at the door rather than quietly filtered, and the visible symptom is mail that used to deliver suddenly bouncing.
What to do
The fix, in order.
Work top to bottom, then re-check — DNS changes take a few minutes to take effect.
- 1 Read the full rejection line. The text after 554 5.7.1 names the reason — "unauthenticated", "blocked", "relay access denied", "unsolicited". That phrase tells you which of the causes below applies, so you fix the right one instead of guessing. Copy the whole line from the bounce, not just the code.
- 2 Test your authentication end to end. Send a message through the email tester. It shows whether SPF, DKIM and DMARC pass and align on a real message from your actual sending path — the single most common cause of a 5.7.1 rejection is one of these failing. Fix any that are not passing before looking further.
- 3 Check your sending IP and domain for blocklisting. If authentication is clean, the rejection is likely reputation. Look up your sending IP and domain against the major blocklists. A listing means you must request delisting and address whatever caused it — a compromised account, a misconfigured relay, or a spam complaint spike — before mail flows again.
- 4 Confirm you are authorised to relay through that server. If the reason reads "relay access denied", your client or application is sending through a server that does not relay for your address. Use your provider's authenticated submission host and port with valid SMTP credentials, or add the sending host to the allowed senders on the relay.
- 5 If content triggered it, review the message. A "message content rejected" or "unsolicited" reason points at the payload: a bad link, a flagged attachment, or spam-like wording. Remove the offending element, and if you send in bulk, honour unsubscribe requests and keep complaint rates low to stop the pattern recurring.
- 6 Re-send and confirm delivery. After each change, allow DNS and reputation updates to settle, then send a test to the same destination. A clean pass with no 554 confirms the fix before you rely on it for real mail.
Confirm the error is gone.
Run a full check on your domain — it reads SPF, DKIM and DMARC live and tells you, in plain terms, whether the thing behind this error is fixed. Free, no account.
Common questions
About this error.
Related