Bounce and error codes

554 5.7.1: the words after the code decide the fix

Last updated 2026-09-01

The scanner in the corridor stopped emailing PDFs, or an app stopped sending invoices, and the log says 554 5.7.1 followed by a few more words. The code alone points two ways: a DMARC fix for one bounce and a blocklist removal form for another. Both fixes are right, and each one answers a different bounce that carries the same number. The table below sorts the four rejections by the text your server printed. Work the row that your bounce matches and skip the rest, because three of the four have nothing to do with your DNS.

Which 554 5.7.1 you have: read the words after the code

Keep the bounce open. Everything below keys off the words the server printed after the code.

The words after the code	Which system refused, and why	Where to go
<user@example.com>: Relay access denied	The server that answered will not carry mail to that recipient for your client.	Relay access denied, below
Service unavailable; Client host [x.x.x.x] blocked using ...	A DNS blocklist named your sending IP.	Blocked using, below
<user@example.com>: Recipient address rejected: Access denied	A rule inside the system that answered matched.	Access denied, below
Text naming DMARC or a failed check	The receiver read the check results and refused the message.	DMARC rarely, below

Row 1 carries the word Relay, and row 3 does not. In row 1 the server refused to carry your message onward at all. Row 3 carries Sender address or Recipient address instead, and the word before rejected names what the rule matched. Your DNS records affect only the last row. The receiver settles the other three before it looks a record up at all.

Relay access denied means your client did not authenticate

Relay access denied is Postfix wording. Postfix builds it in reject_unauth_destination, which refuses a recipient the server does not relay for:

The 554 comes from relay_domains_reject_code, which postconf(5) documents with a default of 554. Exim's shipped configuration file rejects the same case with the text relay not permitted, so the wording above points at Postfix or at a gateway built on it.

Two situations produce it. In the first, your client submitted mail to a server that does not relay for it. That client is usually something that nobody has logged into for years: the scanner in the corridor, the invoicing app, the backup job that mails its own report. In the second, a hop in front of you handed mail to a server that does not accept that recipient's domain. A printer that submits without SMTP AUTH lands in the first situation, unless the server it points at relays for that printer's IP.

Postfix ships smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination, and smtpd_check.c gives that deferring form the reject code minus 100 and the DSN 4.7.1. On a current Postfix the shipped default therefore answers 454, not 554. A server that answers a hard 554 either carries an older configuration, or it sits behind a stricter gateway. That gateway refuses outright rather than holding the mail. That server answers your next message the same way. Work the client settings now.

Work the client settings in order

1. Read the host and port out of the client. Microsoft's client SMTP submission takes smtp.office365.com on port 587, with port 25 as the alternative and TLS required. A device that recommends or defaults to port 465, in Microsoft's words, "doesn't support the required versions of TLS for client SMTP submission".
2. On Google Workspace, check the relay host. Google's SMTP relay service takes smtp-relay.gmail.com on port 587 with TLS. Without TLS it accepts port 25, 465 or 587, and then it authenticates the IP address instead of a login.
3. Confirm SMTP AUTH is switched on at all. Security defaults disable SMTP AUTH for the whole tenant, Set-TransportConfig -SmtpClientAuthenticationDisabled $true does it by hand, and a per-mailbox setting overrides the tenant one. Microsoft has scheduled Basic authentication for client submission for deprecation. It points devices at OAuth instead, or at an on-premises server that relays for them. A printer you fix today with a mailbox password needs a second visit later.
4. Check the credentials the device stores. A rotated mailbox password or a retired app password breaks the AUTH exchange. Devices differ in what they do next. Some report the failed login, and some send anyway and collect Relay access denied. A firewall blocking the port produces a timeout instead, with no SMTP reply at all.
5. If your own Postfix refused the mail, the client sat outside mynetworks and did not authenticate. Fix the client, and leave the restrictions alone. Deleting reject_unauth_destination or widening mynetworks to the whole office range turns the server into an open relay. An open relay carries other people's spam, and the blocklists in the next section add your IP for sending it.

One command tests the host and port you just read:

I ran that against Gmail on 2026-08-20. It prints the certificate chain, then the 250- lines the server offers, then an SSL error on the way out. Gmail answered 250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH. The error at the end is openssl complaining about how the connection closed rather than a failed check. Swap in your own host and port. No AUTH line means the server takes no credentials there, so it treats everything you send over that port as unauthenticated.

Blocked using names the list that refused you

When the text carries blocked using and a domain name, a DNS blocklist decided this, and the receiver relayed the verdict. Postfix prints it from a template that postconf(5) publishes as default_rbl_reply:

maps_rbl_reject_code defaults to 554, and $rbl_class prints what the list named: Client host, Helo command, Sender address or Recipient address. Trend Micro's knowledgebase quotes one out of a customer's MTA logs. The published copy has lost the IP address, so here is the same line in the shape of the template:

Microsoft prints the same shape for its own list, with a delisting address inside the reply:

Microsoft files that text under 550 rather than 554. Its article prints the enhanced code with no three-digit code in front of it.

Read the domain after blocked using and go to that list. Only the list that named you can remove the listing. 550 permanent failure runs the lookup and the removal request, including what belongs in the reason field.

Fixing your records will not shorten this. A list judges the IP address you send from, and it never reads your DNS to decide. Send it again and the same list refuses it from the same IP. File the removal request first, and hold the mail until the list answers.

Access denied after Sender or Recipient is a local rule

Postfix writes this one when an access table matches and the table carries no message of its own:

The 554 comes from access_map_reject_code, which postconf(5) also defaults to 554, and 5.7.1 is the default enhanced code for a REJECT action. Sender address rejected means your domain or address matched their list. Recipient address rejected can also mean the address is not a valid recipient there, which is what Trend Micro tells its own customers to check first.

A filtering gateway in front of your own outbound mail prints the same shape. You fix that one yourself. Trend Micro Email Security refuses outbound mail from an IP that is not listed under the domain's Outbound Servers, and its knowledgebase gives both strings verbatim:

Add the sending server's public IP to that domain's Outbound Servers list and the next message goes through.

Broadcom's knowledgebase for Symantec Messaging Gateway lists six 554 5.7.1 texts its customers see coming back, and each one names a different rule at the far end:

• 554 5.7.1 You are not allowed to connect
• 554 5.7.1 Rejected message by MTA, EHLO domain does not exist in DNS
• 554 5.7.1 This message has been blocked because it contains a banned word
• 554 5.7.1 Rejected message by MTA, RDNS record for connecting IP has no matching 'A' or 'MX' records
• 554 5.7.1 Delivery not authorized
• 554 5.7.1 Bad senders system address

Two of those are worth fixing on your side even though the rule belongs to the far end. Give your sending host an EHLO name that resolves in public DNS, and give its IP a PTR record whose hostname resolves back to the same address. Each one takes a single DNS record, and Symantec Messaging Gateway rejects on both.

The banned-word line is a content rule at the receiver, and no DNS record touches it. For that one and the rest, one company is refusing you while everyone else takes your mail. An admin there can lift the rule. Send your contact the bounce text, and their mail admin can find the refusal in the gateway log from the time you sent and the IP you sent from.

DMARC rarely produces a 554 5.7.1

A receiver that refuses your mail on a failed check usually says so. It also picks a narrower code. Gmail prints 550 5.7.26 for unauthenticated mail, including the variant that names your DMARC policy. Microsoft returns 5.7.509 when DMARC evaluation fails, and 5.7.515 when a sending domain misses its bulk sender requirements.

Google's published list of Gmail SMTP errors carries no 554 5.7.1. Every 5.7.1 row on it is a 550, including the policy line: "The user or domain that you are sending to (or from) has a policy that prohibits the email that you sent." The list does carry 554 rows for other codes, 5.4.6, 5.6.0 and 5.7.0, so Gmail does emit 554 replies. Google documents no 554 5.7.1 though, so if that is your string, look past Gmail's own servers before you touch a DNS record.

Three pages cover the rejections that really do come from a failed check:

• 550 5.7.1 rejected per DMARC policy, when the bounce says DMARC, or names a policy published on your own domain.
• Message blocked, for the Gmail family, including the reputation and unsolicited-mail lines.
• 550 permanent failure, for the dotted-code table across all of them.

If the text does name a failed check, read your own records before you edit one. Our SPF, DKIM and DMARC checker resolves all three from DNS in one submit and needs no account. The alignment guide covers the case where DKIM verifies and DMARC still fails.

554 is permanent, so your server stops trying

RFC 5321 files a reply that opens with the digit 5 as a permanent negative completion, and it directs the sending client not to repeat that request. Your server drops the message and writes you the bounce. The RFC defines 554 itself as "Transaction failed". It gives 554 a second job: a server may answer the opening connection with 554 instead of 220. In that position the code means "No SMTP service here".

Check which command the 554 answered. A 554 on RCPT TO is a verdict about one recipient. A 554 in place of the greeting is a verdict about your connection, and it usually pairs with the blocklist section above.

Send the same message again and the same refusal comes back. Change the thing the text named, then send. 550 permanent failure covers the rest of the permanent class, including the dotted codes that carry their own fixes.

DomainCanary is our product, and I wrote this paragraph to sell you a subscription. Whichever of the four rejections you have, the reply on your screen never reaches us. Receivers report message counts and alignment results for your domain, and they never forward the bounce text your server collected. We read those reports and turn them into one email a week, host by host, with a verdict on each. On a paid plan we mail you the day a report first names a failing host your domain has not used before, and the day a host that had been passing starts failing. Pro costs $19 a month for 5 domains, and we fold every domain that shares a digest address into the same email. You can tell us to keep a clean week on your dashboard rather than mailing it. We store at least 12 months of report history for each source, on the free plan too. Your first domain is free, and the alert on a failing host we have not seen before needs a paid plan.