Gmail rejected my email during SMTP
Use this guide when Gmail refuses the message during delivery or your sending platform records a bounce. Start with the complete SMTP response: it identifies whether the failure is temporary, permanent, authentication-related, or policy-related.
Confirm that this is an SMTP rejection
A rejection appears in the sending server log, queue event, or bounce notice. The response normally includes a three-digit SMTP status and often an enhanced status code plus explanatory text.
If Gmail accepted the message and the recipient found it in Spam, there is no SMTP rejection to repair. Diagnose inbox placement and reputation instead.
- Gmail accepted the message but sent it to spam — diagnose inbox placement and reputation
- The response says 550-5.7.1 unauthenticated email — diagnose SPF, DKIM, DMARC, and alignment
Copy the complete Gmail response
Do not troubleshoot from a shortened dashboard label such as "blocked" or "delivery failed." Copy the remote server name, SMTP status, enhanced status code, explanatory text, timestamp, and the recipient domain.
The same top-level status can accompany different causes. The text after the code often distinguishes authentication, reputation, rate limiting, DNS identity, or message policy.
Temporary 4xx deferrals versus permanent 5xx failures
A 4xx response is temporary. The sending server should normally keep the message in its queue and retry according to its delivery policy. Investigate repeated deferrals, but do not treat the first temporary response as a final bounce.
A 5xx response is permanent for that delivery attempt. Correct the stated cause before resending. Repeatedly retrying an unchanged message after a permanent policy rejection does not resolve the underlying issue.
Map the response to the right diagnostic layer
Authentication or DMARC wording points to SPF, DKIM, and alignment. Reputation or unsolicited-mail wording points to domain/IP history, list quality, and blacklist evidence. Reverse-DNS, HELO, or hostname wording points to the sending server identity. TLS wording points to transport negotiation.
Rate or traffic wording calls for queue and volume analysis. Content-policy wording calls for a controlled comparison of the message body, links, and attachments.
Check the sender identity and transport evidence
Verify the sending IP has the expected reverse DNS, the SMTP HELO/EHLO name is valid and consistent with that identity, and the sending platform is using the domain and credentials you intended.
Check SPF, DKIM, and DMARC when the response mentions authentication. Check blacklist status and recent sending behaviour when the response points to reputation. Test TLS only when the response or transport log supports that path.
Retest after the cause is corrected
Make one targeted change, allow any DNS update to propagate, and send a new controlled test. Preserve the old and new SMTP responses so you can verify that the failure changed rather than merely disappeared from one dashboard.
If the code changes, follow the new evidence. If the same permanent response returns, re-check the exact identity used by the real sending platform rather than only the records for the visible From domain.
Frequently asked questions
What is the difference between a Gmail bounce and spam placement?
A bounce records an SMTP rejection before delivery. Spam placement means Gmail accepted the message and then placed it outside the inbox.
Should I retry a Gmail 4xx response?
A 4xx response is temporary and a correctly configured sending server normally retries it. Investigate when deferrals repeat or the queue eventually expires.
Should I retry a Gmail 5xx response?
A 5xx response is permanent for that attempt. Fix the cause described by the server before sending another controlled test.
Which part of a bounce matters most?
Keep the full SMTP response, including the three-digit code, enhanced status code, explanatory text, remote server, recipient domain, and timestamp.