What caused the Gmail bounce error '550-5.7.1 our system has detected that this message is likely unsolicited mail' and what should I do?
Updated on 24 Oct 2026: We corrected Gmail spam-rate guidance and clarified how to investigate policy bounces before resending.
The Gmail bounce error 550-5.7.1 with "our system has detected that this message is likely unsolicited mail" means Gmail made a final policy decision and rejected the message during SMTP. The reply does not identify one cause. Check sender reputation, authentication, message content, sending patterns, and recipient complaints before attributing it to a Gmail filtering incident.
Do not confuse it with 550 5.1.1 or a 'No Such User' bounce. Those usually point to a missing, deleted, misspelled, disabled, or unprovisioned mailbox. This 550-5.7.1 error points at Gmail's policy scoring for the sender, message, or sending path.
The practical answer is: treat it as a hard block for that delivery attempt, stop resending blindly, confirm whether the issue is isolated to personal Gmail accounts ending in @gmail.com or @googlemail.com, and compare any Google Workspace failures separately. Then check SPF, DKIM, DMARC, rDNS, TLS, message format, IP reputation, and domain reputation before sending a small controlled test. Gmail does not deliver that rejected copy later if filtering behavior changes.
Handle this error differently from a mailbox-full bounce or a malformed-address bounce. A mailbox error points at the recipient. This one points at how Gmail scored the sender and message. Google's own Gmail SMTP errors documentation separates policy, authentication, rate, content, and message-format responses for that reason.
What the error means
This is the kind of bounce text you see in the delivery status notification:
Example Gmail bouncetext
550-5.7.1 [1.2.3.4 12] Our system has detected that this message is 550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to 550-5.7.1 Gmail, this message has been blocked. 550 5.7.1 for more information. gsmtp
The first number matters. SMTP 550 is a permanent failure class. The enhanced status code 5.7.1 usually means a policy or security rejection. In plain language, Gmail accepted the connection far enough to evaluate the message, then decided not to accept that message for that recipient.
That does not prove the message was malicious. It proves Gmail's system scored it as too risky to accept at that moment. A legitimate newsletter, password reset, invoice, or one-to-one email can hit this if Gmail sees enough negative signals together.
Do not treat 550 as a normal retry
Some systems retry after any bounce, but this response is not the same as a 421 temporary deferral. If your platform already marked the message as bounced, resending the same campaign at full size can make the reputation problem worse.
Read the full Gmail reply
Do not diagnose on 550 5.7.1 alone. Save the complete response and use the most specific enhanced code and wording Gmail returned. Nearby codes identify faults that need different fixes.
|
|
|
|---|---|---|
5.7.1 | Unsolicited mail or another policy rejection | Full diagnostic wording |
5.7.25 | PTR or forward DNS failure | IP hostname mapping |
5.7.26 | Authentication or DMARC policy failure | SPF, DKIM, and DMARC results |
5.7.27 | Bulk sender SPF failure | MAIL FROM authorization |
5.7.28 | Unusual unsolicited rate | IP traffic and complaints |
5.7.29 | Bulk mail sent without TLS | SMTP transport |
5.7.30 | Bulk sender DKIM failure | Signature and selector |
5.7.40 | DMARC record or policy missing | DMARC policy tag |
Common permanent Gmail policy codes
The suffix also narrows the owner of the decision. gsmtp identifies Google's SMTP response. gcdp identifies a custom domain policy for a Google Workspace destination, so the recipient's Workspace administrator needs to review that policy. Keep the diagnostic URL and identifier from the final line when escalating the case.
Common causes of Gmail 550-5.7.1
The main cause is Gmail's anti-abuse system deciding that the specific message, sender, or sending stream looked unsolicited. The causes split into sender identity, reputation, content, recipient engagement, forwarding behavior, message format, and operational anomalies.
- Authentication: SPF, DKIM, or DMARC fails, uses the wrong domain, or changes suddenly after a DNS edit.
- Reputation: The sending IP, domain, or subdomain has weak history, recent complaint spikes, or a blocklist (blacklist) listing.
- Volume: A new sender, cold list, new IP, or large unplanned campaign sends more mail than Gmail expects.
- Content: The message has risky links, URL redirects, heavy image reliance, poor text quality, or reused spam-like templates.
- Recipients: The list has stale addresses, weak consent, spam complaints, or little recent engagement. Open rates alone do not establish the cause.
- Message format: The message lacks a valid Message-ID or From address, repeats a single-instance header, or contains malformed headers that break RFC 5322 formatting.
- Forwarding: The forwarding IP is not authorized by the original SPF record, or the forwarder changes the body or headers protected by DKIM.
- Incident: A confirmed Gmail incident can affect otherwise normal mail. A brief bounce cluster alone does not establish a Gmail outage.
The hardest cases are mixed cases. SPF and DKIM can both pass while neither authenticated domain matches the visible From domain under DMARC. A DKIM signature using a shared provider domain does not cause DMARC failure if a passing SPF result uses a matching domain. An old recipient segment can also generate complaints even when authentication passes.
|
|
|
|---|---|---|
Personal Gmail only | Gmail policy scoring | Pause Gmail volume |
All domains | Sender issue | Audit DNS and headers |
New campaign | Content or list | Test variant |
New IP | Low history | Throttle sends |
Forwarded mail | Forwarding path | Check SRS and DKIM |
gcdp suffix | Workspace admin policy | Contact recipient admin |
Common Gmail 550-5.7.1 cause patterns
How to troubleshoot Gmail 550-5.7.1
Establish whether the error is broad or narrow before changing DNS, switching IPs, or resending a campaign. A narrow problem needs careful isolation. A broad problem needs a sending pause and a root-cause review.
Gmail 550-5.7.1 troubleshooting flowchart showing authentication checks, reputation review, and a controlled delivery test.
- Capture: Save the full bounce and the original rejected message, including its headers and body. Record the SMTP reply, sending IP, timestamp with timezone, recipient domain, and message ID.
- Segment: Compare personal Gmail bounces with Google Workspace and non-Google bounces for the same send window and campaign.
- Authenticate: Check SPF, DKIM, DMARC domain matching, reverse DNS, HELO identity, TLS, and whether forwarding changed signed headers.
- Format: Confirm one valid From address, a valid Message-ID, unique single-instance headers, and RFC 5322-compliant syntax.
- Reputation: Check for IP or domain blocklist listings, complaint spikes, and sudden volume changes.
- Test and resume: Use a consenting Gmail test recipient and the same sending route. Change one variable at a time, such as the template or a suspect link, and restore volume gradually after rejections stop.
For a quick baseline, use Suped's domain health checker and send a message through Suped's email tester. DNS checks confirm published records. A message test shows authentication and formatting at that test receiver; it does not prove Gmail will accept the message.
Inspect the original message and outbound SMTP logs. Authentication-Results headers on the delivery status notification describe the bounce itself, unless they are inside the attached original message. Results recorded by an intermediate relay do not prove what Gmail evaluated.
Low-volume senders often have too little personal Gmail traffic for stable reputation data. In that case, the raw bounce pattern, DMARC reports, authentication headers, and small controlled tests become the primary evidence.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Pause sending without suppressing valid addresses
Your first move depends on the pattern. If the error affects only a few personal Gmail recipients during a short window and delivery returns to normal, document it, pause affected deliveries, and reconcile the logs before any resend. A 5.7.1 policy rejection does not establish that the address is invalid, so do not permanently suppress it solely for this response. If the error continues, pause Gmail-targeted volume and fix the sender signals before trying again.
Brief rejection cluster
- Scope: Personal Gmail rejections clustered in one short window; this alone does not identify the cause.
- Trend: Delivery recovers without DNS or content changes.
- Action: Reconcile logs before resending affected mail.
Likely sender-side issue
- Scope: Rejections persist at Gmail or affect multiple recipient domains.
- Trend: Bounces continue across new campaigns.
- Action: Pause sending and fix authentication, list quality, or reputation.
For one-to-one mail, a recipient can add the sender to contacts or mark an earlier delivered message as not spam. Treat that as a secondary trust signal. It cannot reverse a message that Gmail already rejected during SMTP, and it does not fix a sender-wide authentication or reputation problem.
A common mistake is to resend the exact same newsletter to everyone who bounced. If the cause is unresolved, another full campaign adds more rejected traffic. If the original event was temporary, the resend can still create duplicates for recipients who received a retry from your own sending platform.
Resend only after reconciliation
Check your platform's delivery logs first. Some mail systems retry after temporary failures, but a Gmail 550-5.7.1 rejection is normally stored as a failed delivery. After correcting the cause, resend only to addresses with confirmed non-delivery and start with a small batch. Review policy-bounce suppression rules before restoring a valid address.
Authentication checks that matter
SPF, DKIM, and DMARC do not guarantee inbox placement, but broken authentication or a domain mismatch gives Gmail an easy reason to distrust a message. The check is not only whether records exist. DMARC requires a passing SPF or DKIM result whose authenticated domain matches the visible From domain. Relaxed mode accepts the same organizational domain; strict mode requires an exact domain match. Check aspf and adkim in the DMARC record.
For mail to personal Gmail accounts, every sender needs SPF or DKIM, valid forward and reverse DNS, TLS, RFC 5322 message formatting, and a spam rate below 0.3%. A sender that reaches close to 5,000 messages to personal Gmail within 24 hours needs SPF and DKIM, DMARC with at least p=none, DMARC domain matching, and one-click unsubscribe for marketing or subscribed mail. Gmail counts traffic across the same primary domain, and a domain that reaches the bulk threshold remains classified as a bulk sender. Enforcement against non-compliant traffic has included temporary and permanent rejections since the November 2025 ramp-up. See Google's sender guidelines for the requirements.
Illustrative authentication records, replace placeholdersdns
example.com. TXT "v=spf1 include:send.example.net -all" selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=PUBLICKEY" _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
These records show syntax, not a configuration to copy. Replace the example domains and DKIM public key with values supplied by your sending provider, and use a reporting address you control. Merge authorized senders into the existing SPF record rather than adding a second SPF record at the same name.
Move beyond p=none only after reports show that legitimate sources pass DMARC domain checks. Suped's DMARC monitoring helps identify sources to verify and authentication failures to investigate before changing policy.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
In Suped, review the domain's authentication diagnostics and follow the issue-specific remediation steps. Compare those findings with outbound logs to investigate SPF lookup limits, missing DKIM selectors, or DMARC domain mismatches.
Best practical baseline
- SPF: One valid SPF record per evaluated domain, authorizing the actual outbound route and staying within the limit of 10 DNS-lookup-causing terms, including nested includes.
- DKIM: A current key for each sender, with a signing domain that matches the visible From domain under DMARC. Gmail requires RSA keys of at least 1024 bits and recommends 2048 bits.
- DMARC: Reporting enabled, legitimate sources verified, and policy staged only after domain matching is healthy.
- Transport: TLS enabled, valid PTR records, and forward DNS that resolves back to the sending server.
- Message format: A valid Message-ID and From address, with each single-instance header present only once.
- Reputation: Monitor IP and domain blacklist status alongside other reputation evidence before campaigns go out.
Forwarded mail needs its own check
Forwarded messages can trigger the same Gmail 550-5.7.1 text even when direct mail to the same Gmail address works. The forwarding host becomes part of the message path. SPF can fail because Gmail sees the forwarder's IP instead of the original sending IP. Changes to MIME boundaries, the subject, or the body can also break DKIM.
- DKIM preservation: Preserve the body and signed headers whenever possible. DKIM is especially important because SPF commonly breaks when a forwarder sends from its own IP.
- SRS: Sender Rewriting Scheme (SRS) can let SPF pass for the forwarder's rewritten envelope domain. That result does not normally match the original From domain for DMARC, so preserve a valid DKIM signature using a matching domain.
- Forwarding headers: Add X-Forwarded-For or X-Forwarded-To so Gmail can identify the forwarded path.
- Traffic split: Filter spam before forwarding and use a separate forwarding IP or domain when possible to protect direct sending.
If only forwarded mail fails, test the same original message direct to Gmail and through the forwarder. A direct pass with a forwarded failure points at the forwarding path, not the sender's whole domain. Fix forwarding before changing unrelated SPF, DKIM, or DMARC records.
Reputation and content checks
Once authentication and message format are clean, look at reputation and content. Gmail can reject authenticated mail if recipients ignore it, complain about it, or if the sender changes behavior too quickly. Reputation is attached to the IP, domain, subdomain, URLs, and sometimes the pattern of a specific message stream.
Gmail user-reported spam-rate guidance
These bands describe recipient spam reports, not SMTP bounce rates.
Recommended target
Below 0.1%
Keep the daily user-reported spam rate below this level.
Investigate complaints
0.1% to below 0.3%
Review consent and reduce unwanted marketing traffic.
High spam rate
0.3% or higher
Avoid reaching this level; address complaints before restoring volume.
Google recommends a user-reported spam rate below 0.1% and requires it to remain below 0.3%. These are complaint thresholds, not safe bounce-rate thresholds. See Google's sender guidelines. Compare policy bounces with your normal traffic and investigate persistent or sudden increases regardless of percentage. A clean blocklist (blacklist) result does not establish good Gmail reputation.
- Links: Remove suspicious redirects, URL shorteners, broken domains, and tracking links with poor history.
- List: Remove purchased, rented, or scraped contacts without valid opt-in. Honor opt-outs and complaints, and review stale recipients using consent and recent engagement rather than opens alone.
- Template: Test a simpler HTML version with more real text, fewer images, and a clear plain-text part.
- Unsubscribe: For bulk marketing or subscribed mail, include a visible unsubscribe link and RFC 8058 one-click headers: List-Unsubscribe with an HTTPS URL and List-Unsubscribe-Post: List-Unsubscribe=One-Click. Honor requests within 48 hours; a body link or mailto header alone is insufficient.
- Cadence: Reduce Gmail volume, send to recently engaged users first, and rebuild volume over several sends.
- Listings: Use blocklist monitoring to catch IP or domain blacklist changes before the next send.
Blocklist checker
Check your domain or IP against 144 blocklists.
If the same bounce includes references to low reputation, read it alongside guidance for low IP reputation. If you are comparing related SMTP failures, the broader 550, 571 and 554 breakdown helps separate policy blocks from other delivery failures.
Where Suped fits
Suped is our DMARC reporting and email authentication platform. Use its source-level reports and authentication diagnostics to investigate whether a legitimate sending service began failing checks around the bounce window.
Compare source changes and authentication failures with the timestamps in your SMTP logs. DMARC aggregate reports are authentication evidence, not a complete delivery log or an explanation of Gmail's spam decisions.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Use Suped's issue-specific remediation steps when a diagnostic identifies a defect, such as a missing DKIM selector or an SPF lookup-limit failure. Confirm the change through the same sending route before increasing volume.
Evidence from sending logs
- Record the exact SMTP response and the outbound IP used for each failure.
- Compare accepted and rejected messages by campaign and route.
- Confirm non-delivery before selecting recipients for a resend.
Checks in Suped
- Review DMARC reports for source-level authentication failures.
- Investigate SPF and DKIM diagnostics for a confirmed configuration defect.
- Compare blocklist changes with the incident window.
Should you resend the bounced mail?
Do not assume Gmail will deliver the bounced messages later. Once your sending system receives a permanent 550 response, the message is usually marked failed. Gmail does not come back later and convert that failure into a delivered message for you.
|
|
|
|---|---|---|
Known non-delivery | After remediation | Confirm the fix, then test a small batch |
Unknown status | Wait | Reconcile logs |
Content risk | No | Revise copy |
Reputation issue | No | Fix the cause, then reduce volume |
Resend decision guide
If the message was time-sensitive, create a resend segment only from recipients with confirmed failed delivery, not every Gmail recipient from the original send. Confirm the original message is still useful, correct the identified cause, and use lower volume. Changing the subject alone does not repair reputation or authentication. Send to recently engaged recipients first, then expand only if bounces remain normal.
When not to resend
Do not resend if authentication is failing, if the same URL appears in multiple rejected campaigns, if Gmail bounce rates remain elevated, or if an unresolved blacklist (blocklist) listing affects your sending route. Fix the cause first.
When to contact your sending provider
Escalate persistent rejections after correcting authentication and message-format defects. With a shared outbound IP, other senders can affect its reputation, and the provider controls the sending pool and PTR records. Successful delivery through one route does not establish that every route is healthy.
- Send support the complete Gmail reply, timestamp with timezone, message ID, outbound IP, affected recipient domains, and a recent original message with headers.
- Ask whether rejected messages used a different outbound relay, shared IP, or IPv6 path. Check the PTR, forward DNS, and authentication of the IP Gmail actually saw.
- Request a review of the shared sending pool and recent routing changes. Provide both accepted and rejected examples when failures are intermittent.
- For a Google Workspace rejection containing gcdp, ask the recipient administrator to review the custom rule. For personal Gmail, have your sending provider review Google escalation options after confirming sender compliance.
Use Google's sender guidelines and the complete SMTP reply as the support checklist. Authentication compliance and a support request do not guarantee acceptance or a fixed recovery time.
Views from the trenches
Best practices
Capture full SMTP replies before changing DNS, volume, content, or suppression rules.
Separate Gmail-only spikes from broad failures before deciding whether to pause all mail.
Reconcile delivery logs before resending, especially when opens and clicks look low.
Common pitfalls
Treating a 550 policy block as a transient deferral can trigger a damaging resend.
Assuming valid SPF and DKIM guarantee acceptance ignores engagement and reputation.
Suppressing every bounced Gmail user permanently can remove valid subscribers from lists.
Expert tips
Compare the bounce window with DNS edits, list imports, URL changes, and volume jumps.
Retest with a smaller engaged Gmail segment before restoring full campaign volume.
Keep DMARC reports and bounce logs together so source-level changes are visible.
Marketer view
Marketer from Email Geeks says a sudden cluster of the same Gmail 550-5.7.1 response across senders points first to scope confirmation, not rushed DNS edits.
2022-02-16 - Email Geeks
Marketer view
Marketer from Email Geeks says delivery returning to normal does not prove bounced messages were delivered, so logs should be reconciled before any resend.
2022-02-16 - Email Geeks
