Diagnose SMTP 554 failures by preserving the enhanced code and provider text, identifying the SMTP stage, and separating routing, policy, reputation, content, and configuration causes.
SMTP 554 is a permanent negative response commonly rendered as “transaction failed.” It means the server refused the current request, but 554 alone does not identify the cause. The enhanced code and diagnostic text can point to routing, policy, reputation, content, malware, authentication, sender authorization, or a provider-specific condition.
What a complete 554 error looks like
554 5.7.1 Message rejected due to policy. Reference ABC123
│ │ │ └─ provider evidence ID
│ │ └─ human/provider diagnostic
│ └─ enhanced status code
└─ SMTP reply code
Also retain: command stage, envelope sender, recipient domain, outbound IP,
message ID, UTC timestamp, provider route, and whether other recipients passed.RFC 5321 assigns 554 to transaction failure and also allows it as an initial connection response when a server refuses the connection. A 554 after the greeting is a different scope from a 554 after RCPT TO or after message data. The stage tells you whether the server evaluated the connection, sender, recipient, or complete message.
Common SMTP 554 variants
Generic permanent failureThe text and provider documentation carry most of the useful detail.
Network or routing statusCan indicate routing, DNS, next-hop, loop, or provider-specific routing policy. Preserve the exact remote wording.
Routing loop detectedInspect MX, forwarding, connectors, transport rules, and Received headers rather than retrying.
Delivery not authorized or policy rejectionA broad security/policy class covering sender, recipient, relay, reputation, and content rules.
Security or policy scopeCheck authentication, alignment, IP/domain reputation, complaints, message content, and provider-specific identifiers.
Provider-specific diagnosticDo not force an unfamiliar code into a standard meaning; consult the operator that issued it.
Find the SMTP stage first
- Greeting or connection: the server rejected the connecting IP or service before a normal transaction. Investigate endpoint, policy, network reputation, and receiver requirements.
- EHLO or STARTTLS: inspect protocol identity, TLS policy, certificate behavior, and supported capabilities.
- MAIL FROM: inspect envelope-sender syntax, sender authorization, SPF-related identity, relay policy, and submission account.
- RCPT TO: inspect recipient existence, domain routing, relay permission, recipient policy, and whether the failure is one address or the whole domain.
- DATA command: the server refused to begin message transfer, often because the transaction state or policy already failed.
- End of DATA: the server evaluated headers, body, links, authentication, content, size, malware, reputation, or policy before rejecting the complete message.
- Later delivery-status notification: an upstream server accepted the message, then another hop returned the 554. Correlate the attached diagnostic and original recipient.
554 5.4.0 routing and DNS failures
A 5.4.x enhanced status concerns network and routing status. Check whether the recipient domain has usable MX records, each MX target resolves, the next hop is reachable, connectors point to the correct tenant, and forwarding has not created a loop. Review Received headers from the delivery-status notification to see which systems already handled the message.
dig MX recipient.example
dig A mx1.recipient.example
dig AAAA mx1.recipient.example
dig TXT sender.example
# Then compare authoritative and recursive answers, connector settings,
# routing logs, and the full provider diagnostic. DNS alone is not the verdict.554 5.7.1 policy and reputation failures
A 5.7.1 result says delivery was not authorized under a security or policy rule, but it does not name one universal blacklist. Inspect the visible From, envelope sender, DKIM signing domain, SPF result, DMARC alignment, outbound IP, PTR/EHLO, recipient permission, complaint source, volume change, and links. Separate Gmail, Microsoft, Yahoo, and private-domain outcomes because each receiver applies its own evidence.
- Authenticate every legitimate sending platform and remove unknown or obsolete authorizations.
- Stop purchased, scraped, stale, compromised, or unexpectedly high-volume traffic before requesting remediation.
- Identify whether the rejection affects one recipient, one domain, one IP, one DKIM domain, one tenant, or every stream.
- Check provider and official blocklist tools using the exact outbound asset; do not pay an unrelated third party for guaranteed delisting.
- Use the receiver's support path only after fixing the cause, with timestamps, message IDs, IPs, domains, complete errors, and corrective actions.
Content, size, and malware-related 554 failures
A receiver may wait until the end of DATA to scan the complete message. Preserve the MIME source and compare a failing message with a minimal legitimate control message through the same route. Inspect attachment type and encoded size, malformed boundaries, URLs, redirectors, compromised websites, executable content, unsupported encodings, and security-tool findings. Do not evade scanning; remove the risky component and fix the underlying asset.
A safe 554 troubleshooting sequence
1 Capture complete reply, enhanced code, stage, UTC time, message ID
2 Determine scope: recipient, domain, stream, IP, account, or all mail
3 Stop unchanged retries and isolate harmful or compromised traffic
4 Verify address, routing, MX, connectors, and provider endpoint
5 Inspect SPF, DKIM, DMARC, PTR/EHLO, TLS, From, and Return-Path
6 Compare message content, links, MIME, attachments, and encoded size
7 Review consent, complaints, bounces, volume, and recent changes
8 Fix the cause, test one controlled message, then resume gradually
9 Suppress a permanently invalid recipient; do not suppress a whole domain blindlyWhat not to do
- Do not rotate domains or IPs to bypass a recipient's policy without fixing the traffic that caused the rejection.
- Do not remove authentication because a malformed setup failed; correct the authorized sender and alignment.
- Do not suppress every recipient at a provider based on one address-specific failure.
- Do not call every 554 a blacklist. Verify exact external evidence and receiver-specific diagnostics.
- Do not resend obsolete password resets, alerts, or invoices after a long incident merely because the transport recovers.
Frequently asked questions
Is SMTP 554 temporary?
No. The 5xx class is permanent for the current request. A future, corrected request may succeed after a routing, configuration, content, authorization, or reputation issue is fixed, but the original request should not be retried unchanged.
Does 554 mean the email address is invalid?
Not necessarily. Invalid recipients more commonly include a 5.1.x enhanced code, while 554 can occur for connection, routing, policy, content, or transaction-wide reasons. Use the enhanced code, text, and SMTP stage.
Is 554 the same as 550?
Both are permanent 5xx replies, but their standard descriptions and usage differ. Either can carry provider-specific enhanced status and text. Preserve the complete response instead of building recovery around the first three digits alone.