Why are Gmail emails bouncing with '553 5.1.3 The recipient address is not a valid RFC-5321 address' error?
Published 1 Jul 2025
Updated 15 Oct 2026
12 min read
Summarize with
Updated on 15 Oct 2026: We clarified Gmail 553 5.1.3 troubleshooting with saved-contact fixes and safer recipient validation.
Gmail returns 553 5.1.3 when the SMTP envelope recipient is syntactically invalid. The enhanced status code identifies a permanent destination-address syntax failure, so retrying the same value will not fix it. Leading or trailing whitespace is one cause, but the full reply is needed to identify what is wrong with the address passed to RCPT TO. Gmail is rejecting the address string it receives during SMTP, not making a judgment about the person's mailbox, your domain authentication, or campaign reputation.
Treat this bounce as a data hygiene and message assembly problem first. Check how the recipient address is stored, how it is normalized before send, and what the ESP or mail server actually sends in the SMTP envelope. Google documents SMTP response classes in Gmail SMTP errors, but the clue here is already in the text: the recipient address is not a valid RFC 5321 address.
Start with the envelope
Do not start by changing DMARC policy, SPF includes, DKIM keys, DNS, or sending IPs. This rejection identifies invalid recipient syntax, and none of those changes can repair the address supplied with RCPT TO. The fastest fix is to capture the exact envelope recipient and compare it with the stored contact value.
What the error means
RFC 5321 defines the SMTP transaction, including the envelope sender and envelope recipient. That recipient is the value sent in the RCPT TO command. It is not the same thing as the visible To: header that a recipient sees in the message. A rejection at RCPT TO happens before Gmail receives the message headers or body. Header syntax is checked later and produces a different error. If the related problem is header formatting, compare it with RFC 5322 errors.
Illustrative SMTP recipient syntax exchangetext
MAIL FROM:<sender@example.com> 250 2.1.0 OK RCPT TO:<user@gmail.com> 250 2.1.5 OK RCPT TO:< user@gmail.com> 553-5.1.3 The recipient address < user@gmail.com> is not a valid 553 5.1.3 address. gsmtp
The second recipient looks visually close to the first one, but the leading space changes the SMTP argument. Gmail reads the value inside the angle brackets as the address. A space before the local part makes the address invalid for the envelope, so Gmail rejects it at recipient acceptance.
Envelope address
This controls actual SMTP delivery. Gmail evaluates this during the recipient command.
- Source: Address book, CRM field, list import, or API recipient object.
- Failure: Rejected before message body, tracking, and content checks.
Header address
This is the visible message field. It can have display names and encoded characters.
- Source: Template engine, personalization logic, or MIME library.
- Failure: Rejected under header syntax, duplicate header, or content parsing errors.
How to distinguish Gmail syntax and authentication errors
Read the three-digit SMTP reply and the enhanced status code together. The 553 reply says Gmail will not accept the address as presented, while 5.1.3 narrows the cause to bad destination mailbox syntax. Nearby codes require different checks. A generic 550 reply does not prove that a mailbox is invalid; read the enhanced status code and response text before suppressing an address.
|
|
|
|---|---|---|
550 5.1.1 | Recipient mailbox does not exist | Correct typos or suppress the mailbox |
553 5.1.2 | Recipient domain cannot be found | Check the domain and trailing punctuation |
553 5.1.3 | Recipient address syntax is invalid | Inspect the exact RCPT TO value |
553 5.1.7 | Sender address syntax is invalid | Inspect MAIL FROM, not the recipient |
550 5.7.26 | Authentication or DMARC policy rejection | Read the full response and check the named authentication failure |
Gmail syntax and authentication errors and the first corrective action
Google documents these separate failure types in its Gmail SMTP errors reference. A 550 5.7.26 rejection needs authentication troubleshooting; it is not a recipient syntax error.
Treat 5.1.3 as a hard bounce
A 5.x.x enhanced status code reports a permanent failure. Suppress the failed value from automatic retries, correct the underlying data, then test the corrected address as a new attempt. Do not suppress every address at the same domain unless evidence shows that each value is invalid.
Common causes of invalid recipient addresses
At volume, check a small set of causes before anything else. The address often looks normal in a UI because many screens trim whitespace for display while still storing the original value or passing the original value to an API.
|
|
|
|---|---|---|
Leading or trailing space | Form, CSV, or sync | Trim before save and send |
Embedded hidden or control character | Copy and paste | Reject controls and inspect hidden whitespace |
Missing @ or incomplete address | Manual entry or failed merge | Validate the completed value |
mailto: prefix or stray quote | Copied link or serializer | Store only the mailbox address |
Wrong ESP recipient mapping | API handoff | Log the SMTP envelope |
Display name or multiple addresses in one mailbox field | Address book export or recipient serialization | Parse one mailbox per recipient; keep display names separate |
Leading, trailing, or consecutive dots in an unquoted local part | Manual entry or imported contact | Reject malformed syntax without guessing a replacement |
Common causes of Gmail 553 5.1.3 recipient address bounces
Leading whitespace in a recipient address moving through stored contact data, normalization, an ESP API, and Gmail RCPT checks.
Display names belong in message headers or the sending library's separate name field, not inside the SMTP mailbox. A recipient list must become separate RCPT TO commands, not one comma-separated envelope address. If Gmail instead reports sender or header syntax errors, check abnormal characters in names and headers.
How to prove where the bad address appears
The goal is to find the first system that has the bad byte. Do not rely on a formatted UI view. Pull raw values at each boundary and compare them with the bounce text. Print values with visible delimiters, then inspect Unicode code points or UTF-8 bytes if the address still looks clean. JavaScript trim() does not remove a zero-width space (U+200B).
- Stored value: Export the raw recipient field from the contact database or source list.
- Import value: Check CSV parsing, CRM sync jobs, and API writes for whitespace preservation.
- Send payload: Log the recipient object sent to the ESP before it leaves your application.
- Envelope value: Ask the ESP for the exact SMTP envelope recipient used for a bounced sample.
- Bounce sample: Keep the full delivery status notification (DSN). Compare the failed recipient with the SMTP diagnostic, including Final-Recipient, Status, and Diagnostic-Code when present.
This example uses application-provided isValidEnvelopeAddress and logAddressFix helpers. The validator must parse one envelope mailbox using a maintained address parser. The regular expression only rejects ASCII control characters; it does not validate an email address. Syntax validation does not establish that a mailbox exists.
Normalization and validation flow with application helpersjavascript
const raw = input.email; if (typeof raw !== "string" || /[\u0000-\u001F\u007F]/u.test(raw)) { throw new Error("Recipient must be text without control characters"); } const trimmed = raw.trim(); // Application helper: parse exactly one envelope mailbox. if (!isValidEnvelopeAddress(trimmed)) { throw new Error("Invalid recipient address"); } if (raw !== trimmed) { logAddressFix({ before: JSON.stringify(raw), after: JSON.stringify(trimmed) }); } contact.email = trimmed;
After correcting the raw address, confirm one controlled send to the affected recipient through the original sending path. Then send a separate message through that sender to the address generated by Suped's email test to inspect the received message and its authentication results.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A successful Suped test confirms delivery to its test mailbox. It does not prove Gmail acceptance or validate every recipient in your list. Confirm the original recipient fix separately before resuming the affected batch.
Fix saved contacts and autocomplete in email clients
For a one-off message in Gmail or Outlook, check the saved recipient before investigating a bulk-sending integration. A contact or autocomplete suggestion can reinsert the malformed value each time you compose a message.
- Start a new message, remove the selected recipient, and type the confirmed mailbox address manually instead of choosing a suggestion.
- Check the saved contact and correct its email field. Inspect Cc and Bcc recipients as well as To.
- Remove or correct the bad suggestion where the client supports it, then send one controlled test before retrying the original message.
- If the same address works in a fresh message but fails in a reply or contact selection, compare the resolved recipient values and ask the administrator for the SMTP diagnostic.
Google's contact suggestion guidance explains how saved contacts contribute to Gmail suggestions. Correct the saved address so later messages do not reuse the malformed value.
How to fix it
The fix has two parts: clean the affected addresses already in the database, then stop invalid values from entering or leaving the system again. Treat existing bounces as proof that the source of truth needs inspection beyond the current campaign export.
Immediate cleanup
- Pause: Stop retries to affected Gmail recipients until the address is corrected.
- Export: Pull raw addresses for every 553 5.1.3 bounce in the batch.
- Normalize: Trim outer whitespace and reject empty or malformed results.
- Suppress: Keep truly invalid addresses out of future campaign segments.
Permanent controls
- Capture: Trim and validate addresses at every signup and preference form.
- Import: Reject rows with hidden control characters or invalid syntax.
- API: Log recipient values before they are sent to the ESP.
- Alert: Create a bounce reason alert for new 553 5.1.3 spikes.
Do not over-normalize
Trim outer whitespace, but reject embedded control characters rather than silently deleting them. Preserve the local part: case differences, plus tags, and apostrophes are not automatic syntax errors. RFC 5321 permits quoted local parts, including spaces within valid quoting. For non-ASCII local parts, confirm support for SMTPUTF8 throughout the sending path instead of stripping characters. If an address is unsupported, ask for a confirmed alternative rather than guessing a replacement.
Bad and good recipient valuestext
Bad: " user@gmail.com" Bad: "user@gmail.com " Bad: "user@gmail.com\u00a0" Good: "user@gmail.com"
For a one-off cleanup, run a query that finds addresses where the raw value differs from the trimmed value. For a durable fix, add the same validation to imports, form submissions, contact updates, and send-time payload construction.
Where DMARC, SPF, DKIM, and reputation fit
This bounce is not caused by DMARC, SPF, DKIM, reverse DNS, or a blocklist (blacklist) listing. The 5.1.3 status identifies recipient syntax as the failure, so authentication, DNS, and reputation changes will not fix it. Once recipient syntax is fixed, check the rest of the sending setup separately so another delivery problem does not remain hidden behind the first one.
Suped's domain health check is useful after the immediate address fix because it verifies the domain-side basics in one place. For ongoing protection, DMARC monitoring gives a source-level view of who is sending mail for the domain and whether those sources authenticate correctly.
Email tester sample report showing total score, email preview, issue summary, and per-section results
Suped's DMARC reports and alerts identify sending sources with authentication failures in the reports it receives. Recipient cleanup remains a separate task: DMARC aggregate reports do not validate mailing-list addresses or diagnose individual 553 5.1.3 bounces.
Practical Suped workflow
- Fix syntax: Clean recipient values before spending time on authentication changes.
- Test message: Confirm the corrected recipient, then send a separate test to Suped and review its report.
- Monitor domain: Use Suped DMARC reports to catch source and authentication drift.
- Alert teams: Route authentication failure alerts to the owner of the affected sending source.
Decision path for 553 5.1.3 bounces
Gmail 553 5.1.3 troubleshooting flow: read the bounce, inspect the raw recipient, trim and validate, test, and resume the batch.
Use a decision path when the bounce volume is high and several teams are involved. The key is to separate evidence from assumptions: the sender application owns stored data and payload construction, the ESP owns the SMTP handoff, and Gmail owns the rejection response.
- If brackets show spaces: If whitespace sits outside a valid quoted local part, correct the raw value at its source.
- If raw data is clean: Inspect template merge logic, API mapping, and ESP recipient handling.
- If only Gmail rejects: Keep the fix focused on standards compliance, not receiver workarounds.
- If no spaces exist: Check non-printing characters, malformed domains, and empty merge values.
A visibly malformed recipient inside the SMTP diagnostic points back to the sending path. Previous delivery does not establish that the current stored value or serializer output is identical. If the exact envelope recipient is valid but the error persists, retain the full server reply, timestamp with timezone, sending server, and message or queue identifier for your ESP or mail administrator.
Views from the trenches
Best practices
Wrap logged addresses in visible delimiters so leading and trailing spaces are obvious.
Trim at capture and at send time, then reject values that still fail envelope validation.
Keep a bounce reason dashboard that separates syntax errors from mailbox and policy bounces.
Ask the ESP for raw envelope evidence before changing DNS, IP routing, or authentication.
Common pitfalls
Treating a visible UI address as raw truth hides whitespace that the SMTP server still sees.
Retrying invalid recipient bounces creates noise and delays the required source data fix.
Blaming Gmail first slows response when the bounce text already shows a malformed address.
Cleaning only the export leaves the same bad value in the database for the next send.
Expert tips
Reproduce one failing address manually to confirm whether Gmail rejects the same RCPT value.
Check display names separately, since quote and encoding faults produce different failures.
Log the recipient value immediately before the ESP API call, not only after list import.
Keep permanent validation in every write path because contacts enter systems many ways.
Expert view
Expert from Email Geeks says Gmail rejects a recipient when a leading space is placed inside the SMTP angle brackets, so the raw stored address should be checked before blaming the receiver.
2021-01-14 - Email Geeks
Expert view
Expert from Email Geeks says earlier delivery does not prove the current envelope value is identical, so the failed attempt should be checked at each handoff.
2021-01-14 - Email Geeks
