Is 554 5.7.1 a hard bounce or a soft bounce?

554 5.7.1 is a permanent failure (a hard bounce): the receiving server won't accept this message if you send it again unchanged. But the cause is not the recipient's address, so treat it differently from a 'user unknown' bounce.

554 5.7.1 Error: Meaning and Fix

Q: Should I remove the contact after a 554 5.7.1 bounce?

Not automatically. Don't suppress over a blocklist or relay error; the address is probably fine. Fix the sending side, then retry. If the text clearly says the recipient refuses your mail, stop emailing them.

What 554 5.7.1 means

554 is 'transaction failed' and 5.7.1 is 'delivery not authorized'. Postfix, the most common open-source mail server, uses 554 5.7.1 for two very common rejections: 'Client host [IP] blocked using [blocklist]' when your sending IP is on a DNS blocklist, and 'Relay access denied' when the server isn't the destination for the recipient's domain and won't forward for you.

Commercial filters use 554 5.7.1 for spam and policy blocks too. As with 550 5.7.1, the text after the code is what matters.

What the bounce looks like

The wording providers document for this code. Your bounce may add an IP address, a session ID or a help link after it.

Common wording

554 5.7.1 Service unavailable; Client host [IP] blocked using zen.spamhaus.org

Postfix's standard DNS-blocklist rejection.

Common wording

554 5.7.1 <[address]>: Relay access denied

Postfix's standard rejection when it won't relay for that domain.

Why cold emailers see 554 5.7.1

Your sending IP is listed on a DNS blocklist such as Spamhaus ZEN, often because it's a shared or recycled IP, or because of spam traps hit by an old list.
You're sending through the wrong server, e.g. directly to an MX that isn't responsible for the recipient domain, or an SMTP server that requires authentication you didn't provide.
The recipient's filter (Proofpoint, Mimecast, Barracuda and others) classified the message as spam.

How to fix 554 5.7.1

If a blocklist is named, look up your IP on that list, fix the cause (compromised account, bad list, open relay), then request removal.
If you use a shared SMTP provider, give them the bounce; they need to rotate or delist the IP.
For 'Relay access denied', authenticate to your outgoing SMTP server (port 587 with credentials) instead of sending unauthenticated.
For spam-filter rejections, review content and targeting, and test with the same recipient domain once fixed.

Retry or suppress?

Don't suppress over a blocklist or relay error; the address is probably fine. Fix the sending side, then retry. If the text clearly says the recipient refuses your mail, stop emailing them.

Reading the code

The basic code 554 means "Transaction failed (permanent)" under RFC 5321. In 5.7.1, the 5 is the class (permanent failure) and the 7 is the subject (security or policy). The detail number 1 is registered in RFC 3463 / the IANA registry as "Delivery not authorized, message refused".

Class 5: Permanent failure; Resending the same message won't work. Something about the message, the recipient or the sender has to change first.
Subject 7: Security or policy; A security or policy decision: spam filtering, authentication, blocklists, permissions.
Detail 5.7.1: Delivery not authorized, message refused

Check the rest of your setup

Paste the headers of a message that did get through into the email header analyzer to confirm SPF, DKIM and DMARC pass, and check your domain with the SPF, DKIM & DMARC checker. The deliverability checklist covers the rest of a healthy sending setup.

Got a different bounce? Paste it into the SMTP error code lookup to decode it.

554 5.7.1: Rejected: blocklist or relay denied