Gmail 550 5.7.1 unsolicited or suspicious: what to check first
Gmail's 550 5.7.1 means a reputation or spam block, not a DNS typo. Match the exact bounce text, then check domain, IP, content and complaints in that order.
On this page(10 sections)
- What does 550 5.7.1 mean at Gmail?
- Which 5.7.1 message did you get?
- Question: Is my DNS the problem?
- Question: Is the sending domain new or ramping too fast?
- Question: Is the sending IP the problem?
- Question: Is the message itself the problem?
- Question: Are recipients marking my mail as spam?
- What should I do right now?
- Where does Koltrix fit?
- Bottom line
A Gmail 550 5.7.1 bounce with the words "likely unsolicited" or "suspicious" means Gmail judged your message to be spam-like, or judged the sender's reputation too low, and refused it outright. It is not a DNS syntax error, and retrying the same message will not fix it. The sentence after the code tells you whether Gmail blames the message, the sending IP or the sending domain, and that decides what you check first.
What does 550 5.7.1 mean at Gmail?
550 is a permanent failure and 5.7.1 is the generic "delivery not authorized, message refused" status from RFC 3463. Large providers reuse it for many policy decisions, so the code alone says very little. Google's Gmail SMTP error reference lists several different messages under 5.7.1, and the ones that matter for a normal sender are the reputation and spam ones.
Our general guide to Gmail 4xx and 5xx rejections covers the whole family. This post is only about the 5.7.1 family.
Which 5.7.1 message did you get?
Match the text in your bounce to this table. The wording comes from Google's error reference at the time of writing, and Google can change it.
| Text in the bounce | What Gmail is telling you | Check first |
|---|---|---|
| "This message is likely unsolicited email." | The message looked like spam | Content, links, complaint history |
| "This message is likely suspicious due to the very low reputation of the sending domain." | Your From or sending domain has a poor record | Domain age, volume ramp, complaints |
| "This message is likely suspicious due to the very low reputation of the sending IP address." | The IP you send from has a poor record | Shared vs dedicated IP, blocklists |
| "This message does not meet IPv6 sending guidelines regarding PTR records and authentication." | An IPv6 sender without PTR or authentication | Reverse DNS and SPF/DKIM on IPv6 |
| "Messages missing a valid Message-ID: header are not accepted." (and other header messages) | A malformed message, not reputation | The raw headers you generate |
If your bounce is in the last two rows, you have a configuration problem and the fix is mechanical. The first three are reputation problems, and those take longer.
Question: Is my DNS the problem?
Usually not, but verify in a minute. Gmail's sender guidelines require SPF or DKIM for every sender, and DMARC for bulk senders. Missing authentication normally produces a 5.7.26 bounce instead, which we cover in Gmail 550 5.7.26: three bounces, three fixes. A 5.7.1 with reputation text means Gmail could read your message and still did not want it.
Still, confirm that a delivered copy shows passing results. Send the same message to a Gmail address you control, choose "Show original," and read the Authentication-Results header (how to read it). You want spf=pass or dkim=pass with the domain aligned to your From address. If that is clean, stop looking at DNS.
Question: Is the sending domain new or ramping too fast?
Domain reputation is the most common cause of the "very low reputation of the sending domain" text. A new domain that sends a few hundred messages on day one has no history, and Gmail treats a sudden jump in volume as a risk signal. Start small, send to people who expect your mail, and raise volume in steps. Our new domain warm-up guide and the Gmail-specific 421 4.7.28 ramp guide give concrete schedules.
Domain and IP reputation are tracked separately, and a clean IP does not rescue a poor domain. See domain vs IP reputation for how to tell which one Gmail is judging.
Question: Is the sending IP the problem?
If the bounce names the IP, check three things:
- Shared IP neighbors. On a shared pool, another sender's behavior can drag the pool down. Ask your provider which pool you are on and whether they can move you.
- Blocklists. Look the IP up on the major lists and follow the blocklist delisting playbook if it is listed.
- Reverse DNS. The IP should have a PTR record, and the name it resolves to should resolve back to the same IP. See the Gmail PTR requirement.
Question: Is the message itself the problem?
For "likely unsolicited email," look at what you sent. These are the usual triggers, in rough order of how often they cause trouble:
- A list that includes people who never asked for the mail, or old addresses that now hit spam traps.
- Link shorteners, mismatched link text and destination, or a link domain with no history.
- A large image with almost no text, or an HTML-only message with no plain-text part.
- A subject that overpromises or looks like a phishing template.
- No easy unsubscribe on bulk mail. Gmail and Yahoo require one-click unsubscribe for bulk senders, and the rules are summarized in our Gmail and Yahoo bulk sender requirements post.
Send a plain, short, text-first version of the same message to a Gmail test address. If the plain version is accepted and the designed version is not, the content is your lever.
Question: Are recipients marking my mail as spam?
Complaints are the strongest reputation input you control. Google's sender guidelines ask bulk senders to keep the user-reported spam rate below 0.10% and to never reach 0.30%. You can only see that rate in Google Postmaster Tools, and only once your volume is high enough for it to show data. If your volume is low, see what low-volume senders can do instead.
Without Postmaster data, use your own signals: replies versus silence, unsubscribe rate, and bounces from other providers. A list that people are not opening is a list that people will eventually report.
What should I do right now?
Work through this checklist in order and stop at the first item that explains the bounce.
- Copy the full bounce text, including the line after the code, and identify the row in the table above.
- If it is a header or IPv6 message, fix the message or reverse DNS and resend.
- Confirm SPF or DKIM passes and aligns on a delivered copy.
- Check whether the domain is new, or whether volume jumped recently. If so, cut volume and ramp again.
- Check the sending IP against blocklists and confirm its PTR record.
- Remove unengaged and unverified addresses from the list and make unsubscribing effortless.
- Resend a small, plain test to a few Gmail addresses you control before you resend to everyone.
Do not loop a retry on every bounced recipient. Treating a permanent 5xx as temporary only adds more rejected attempts to your record. Our hard vs soft bounces post explains why a 5xx should be suppressed, not retried.
Where does Koltrix fit?
Koltrix gives each custom domain SPF, DKIM (a per-domain 2048-bit key) and DMARC records to publish, so the authentication checks above are quick to confirm. The reputation work, meaning list quality, volume ramp and complaint handling, stays with whoever sends the mail. The Koltrix docs cover domain setup.
Bottom line
A Gmail 550 5.7.1 with "unsolicited" or "suspicious" is a reputation or spam decision, not a typo in DNS. Read the sentence after the code, decide whether Gmail is blaming the message, the domain or the IP, and fix that one thing. Slow down, send to people who want your mail, and let reputation rebuild before you scale volume again.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
