← Back to Blog

Gmail "550 5.7.1 very low reputation" rejection: what it means and how to fix it in the right order

Gmail "550 5.7.1 very low reputation" rejection: what it means and how to fix it in the right order

Read the bounce before you touch anything

Gmail's rejection is not one error. It is several different problems that all get shortened to "550 5.7.1" in conversation, and the exact enhanced status code plus the sentence after it tells you which one you actually have.

"550-5.7.1 ... Our system has detected that this message is suspicious due to the very low reputation of the sending domain" means Gmail evaluated your domain's sending history and decided it looks enough like a spam source that it will not accept mail from it right now. This is a domain reputation problem, and Google Postmaster Tools built that record over time.

A close cousin, "low reputation of the sending IP address," is the same rejection scoped to the IP instead of the domain. If you send through Google Workspace, that IP belongs to Google, not you, so the block usually points to something else on shared infrastructure, or to a third-party server whose IP carries a bad history that has nothing to do with your domain.

A third message, "550-5.7.26, This mail is unauthenticated," is not a reputation problem at all. Gmail could not verify SPF or DKIM for that specific message and rejected it outright rather than judging it on reputation. That is Google's sender authentication requirement doing its job: since February 2024, every sender needs SPF or DKIM to pass, and bulk senders, roughly 5,000 messages a day or more to personal Gmail addresses, need both to pass plus a DMARC record.

Save the full bounce, not just the headline. It usually carries a link to Google's own explanation and, more importantly, the exact code that tells you whether you are dealing with reputation, authentication, or something else entirely. Treating "unauthenticated" as a reputation problem burns weeks on a warmup plan that was never going to fix it.

Step 1: authenticate everything, then check alignment

Before assuming reputation is the culprit, rule out authentication. Domains that used to pass SPF and DKIM drift out of compliance the moment a new tool starts sending on their behalf, an invoicing platform, a CRM, a marketing tool, without being added to the SPF record or given a DKIM selector.

Check three things on the domain the bounce names:

  • SPF: the TXT record has to include every service sending on your behalf, and it has to resolve to a pass for the IP that is actually sending the message.
  • DKIM: outbound mail needs a valid signature that verifies against the public key published at the matching selector._domainkey TXT record. On Google Workspace, DKIM is off by default per domain until you generate and publish that key in the Admin Console.
  • DMARC: the domain needs a DMARC record, even p=none, and the visible From header has to align with either the SPF domain or the DKIM signing domain. Gmail's bulk sender rules only require one of the two, but aiming for both is the safer target.

Send a real test message to a Gmail address you control, open it, choose "Show original," and read the Authentication-Results header for that exact send. Confirm SPF=pass, DKIM=pass, and DMARC=pass. Fix whichever one fails before you spend any time on reputation, because a broken authentication record sitting under a reputation problem makes the bounce reason shift unpredictably between the two.

Step 2: check what Postmaster Tools actually says

If authentication is clean and you are still bouncing, Google Postmaster Tools is the only place that shows Google's own view of your sending history. It needs domain ownership verification and a real volume of DKIM or SPF authenticated mail to Gmail addresses before the dashboards populate, so sign up now if you have not.

Two dashboards matter here. Domain reputation and IP reputation are each rated High, Medium, Low, or Bad. Google defines High as "a history of very low spam rates" that complies with the sender guidelines, and Bad as "a history of sending a high volume of spam regularly," where mail is "almost always marked as spam or rejected by the receiving server." If your domain sits at Low or Bad, that rating, not anything visible from your own inbox, is producing the 550 5.7.1 bounce.

Spam rate is the percentage of your messages that reach an engaged recipient's inbox and then get manually marked as spam. Google's guidance is to stay under 0.10% and treat 0.30% as a hard ceiling. Cross it and you lose eligibility for Google's own delivery mitigation support until you hold under 0.30% for seven consecutive days.

Google has also flagged that the IP Reputation and Domain Reputation tabs specifically will eventually be deprecated, with no firm date given. Treat spam rate and authentication as the more durable signals to build your monitoring around going forward.

Step 3: stop the bleeding before you try to fix reputation

Reputation is backward looking. Every message you keep sending into a block adds another bad data point to a history Google is already unhappy with. Before anything else:

  • Pause or sharply cut Gmail-bound volume, especially on any list you cannot prove is opted in and currently engaged.
  • Pull anyone who has not opened or clicked in the last 90 to 180 days off active sending. Stale lists are the most common driver of a rising spam rate, because recipients who no longer recognize the sender are the ones most likely to hit "report spam" instead of unsubscribing.
  • Look for a leftover send that is still running: a scheduled campaign, an automation, a compromised account relaying spam through your domain. A reputation collapse that lines up with one specific date is usually one identifiable sender behaving badly, not a slow organic decline.
  • If you qualify as a bulk sender, add the one-click unsubscribe headers Google requires, List-Unsubscribe and List-Unsubscribe-Post, so recipients who no longer want the mail have an easy way out that is not the spam button.

Step 4: rebuild it deliberately

Once the bad signal is removed, Google's own advice for recovering reputation matches its advice for any new sender: start with low volume to your most engaged recipients and increase it slowly, avoiding sudden spikes. Google has not published a day-by-day schedule, so treat any "14-day warmup calendar" you find elsewhere as someone's estimate, not policy. What stays consistent across sources is the direction: small volume to people who open and reply, watched closely, expanded only when the spam rate and reputation dashboards hold steady or improve, not on a fixed calendar.

Expect this to take weeks, not days. The reputation dashboards in Postmaster Tools are historical, so one clean week does not erase a bad month.

When the reputation problem is not yours to fix directly

If you send through Microsoft 365, Zoho, or shared hosting SMTP, the IP behind your mail may be shared with hundreds of other tenants. Google's own guidance is direct about this: "The activity of any senders using a shared IP address affects the reputation of all senders" on it. If Postmaster Tools shows IP reputation at Low or Bad while domain reputation looks fine, someone else on that shared IP is the likely cause. The fix is working with the provider to isolate or rotate the IP, or moving to a setup where you control, or can request, a dedicated sending path. Domain reputation is the lever you fully control. IP reputation on shared infrastructure often is not.

New domains start with no reputation, not bad reputation

A brand-new domain, or one that has never sent meaningful volume to Gmail, does not have a low-reputation bounce waiting for it. It has no reputation at all, which Postmaster Tools may simply show as no data yet. Sending a large batch through a new domain on day one looks identical to an attacker spinning up a throwaway domain to send spam, and Gmail treats it accordingly. The fix is the same slow-start principle as a recovery: authenticate first, send small and consistent volume to real recipients, and let the domain build a track record before you rely on it for anything time-sensitive.

How Guanacos Tech helps

Most 550 5.7.1 cases we see are a mix of two or three of the causes above stacked on top of each other, a DKIM selector that quietly stopped verifying, a marketing tool nobody added to SPF, and a stale list someone kept mailing anyway. We run the diagnosis (authentication, Postmaster Tools reputation, spam rate history, list hygiene), fix the DNS and sending practices in the right order, and stay on the reputation recovery through the warmup period so you are not guessing at when it is safe to send at normal volume again. If you want a second set of eyes on your specific bounce, book a reputation review call.

Sources

Frequently asked questions

How long does it take to fix a Gmail 550 5.7.1 low reputation bounce?

Plan for weeks, not days. Postmaster Tools reputation is built from historical sending data, so a clean week of mail does not erase a bad month. Most domains see reputation shift within 2 to 4 weeks once the bad sending signal is removed and volume is reintroduced slowly.

Is 550 5.7.1 always about domain or IP reputation?

No. Gmail also uses related codes for unauthenticated mail (550-5.7.26), policy blocks, and formatting problems. Read the full bounce text, not just the summary, since the exact wording tells you whether you have a reputation, authentication, or content issue.

Can I fix a shared IP reputation problem myself?

Not directly. If you send through Microsoft 365, Zoho, or shared hosting, the IP's reputation depends on every other sender using it. You can move to a platform with dedicated sending, ask your provider to isolate or rotate the IP, or focus on keeping your own domain reputation clean, since that part you fully control.