2026 Google Workspace SMTP Relay Test Emails Rejected: What to Do?

Check the SMTP response first: if Google Workspace SMTP Relay rejected the message, compare the actual egress IP, allowed sender, authentication path, and HELO/EHLO identity with the current rule; if it accepted the message, investigate later delivery and inbox classification. A relay acceptance is not proof that the message reached a readable test inbox.

This guide is for developers sending their own product’s notifications or verification emails through Google Workspace SMTP Relay.
It also helps QA engineers collect repeatable receipt evidence and engineers responsible for the sending host, network egress, or relay rules.

Google Workspace SMTP Relay test emails rejected: read the failure stage

Treat the failure as a sequence of observable handoffs, not as one vague “email failed” state. Your application may report an error before connecting, fail during SMTP negotiation, receive a rejection from the relay, or report success after the relay accepts the message even though the recipient never sees it.

The distinction matters because each stage needs different evidence. A TCP connection only shows that a network path was available. An SMTP response shows what the server said during the mail exchange. A positive response after the message content is accepted means the SMTP server has taken responsibility for delivery or reporting failure; it does not guarantee inbox placement. RFC 5321 defines the SMTP 250 response in this acceptance context.

For one test run, retain the application event, SMTP transcript or mail-library response, sending host and environment, intended recipient, and a unique test marker. Redact credentials and personal data before sharing logs. A UI message such as “sent” is not enough to identify which handoff succeeded.

Observed result	What it establishes	Next evidence to collect
No SMTP server response	The application has not confirmed an SMTP handoff. It may have a connection, DNS, firewall, or TLS problem.	Connection logs, resolved relay host, negotiated TLS details, and the server’s last response, if any.
SMTP relay returns a rejection	The relay did not accept the message in that transaction.	Full SMTP response, session stage, actual source IP, sender settings, and authentication path.
Relay accepts the message, but no visible email appears	The relay accepted the submission; visible receipt remains unconfirmed.	Recipient address, later delivery records, controlled mailbox search, and spam or other categories.
Message appears in spam or another category	The receiving service has a message to classify, but it is not in the expected location.	Raw message details and the receiving service’s classification or delivery evidence.

A registered IP does not prove the current connection is allowed

An allowlisted address only helps if the SMTP connection actually comes from an address covered by the current Workspace relay rule. A developer laptop, preproduction host, and CI runner can leave through different network paths. A NAT gateway change, VPN, proxy, or hosting configuration can also make the live source differ from the one recorded in an earlier setup.

Check the source address associated with the failing SMTP session. Do not assume that an IP observed in development applies to a hosted test, or that an IP configured for preproduction also covers CI. Compare the address with the relay rule in the Workspace account that handles this message. Google’s SMTP relay setup documentation describes the available relay configuration options; the account’s active rule and the current session log determine which one applies to your test.

If the response points to an unrecognized IP or an account-domain mismatch, preserve the exact response and verify the rule before editing it. Google’s Gmail SMTP error-code guidance can help interpret the reported error, but do not map a vague application exception to a specific relay cause without the SMTP response itself.

Sender identity and authentication must match the selected rule

An allowed connection source does not settle whether the message’s sender is permitted. Compare the rule’s allowed sender types with the actual sender identities used in your SMTP session. Check the visible From header, the SMTP envelope sender in MAIL FROM, and the authentication method. They are related, but they are not interchangeable fields.

Google Workspace relay configurations can use different verification paths, including IP-based verification and SMTP AUTH, depending on the account’s settings. Do not apply the assumptions for one path to the other. For example, the presence of SMTP credentials in application configuration does not prove that the active relay rule expects or accepts that path. Likewise, an allowed source IP does not by itself prove that the sender identity matches the rule.

Review the HELO or EHLO identity as well as MAIL FROM. Confirm that your sending software presents identities your own domain and relay rule can recognize. Avoid inventing a sender domain for a test simply because it is easy to type; it can produce a mismatch that obscures the original problem. Use the Google error description and your account’s current rule to interpret the rejection, then change one relevant setting and repeat the controlled test.

Connection and TLS failures happen before relay acceptance

A connection error is not the same as a relay-policy rejection. Start with the SMTP library’s logs and determine whether it resolved the relay host, opened a connection, negotiated TLS or STARTTLS as configured, and received a server response. If the process stops before an SMTP response, changing sender permissions is unlikely to fix the immediate failure.

Google documents smtp-relay.gmail.com and supported connection options in its Workspace relay instructions. Those instructions include port and security choices; verify the current combination against the account and client you are testing. Do not copy a port or TLS assumption from another environment and treat it as universal. A TCP connection on a given port does not establish that the client completed the expected SMTP and TLS exchange.

Separate the log outcomes:

• Name resolution or connection timeout: investigate DNS, firewall rules, routing, and the chosen host.
• TLS negotiation failure: compare the client’s TLS behavior and configured security mode with the current Google instructions.
• Authentication failure: verify the credentials and whether the active relay rule uses SMTP AUTH.
• Relay policy rejection: inspect the response and compare the session with the rule’s IP and sender requirements.

Repeatedly resending the same message can produce more noise without identifying the cause. Preserve one failing trace, make a targeted change, and record the result of the next attempt. If you cannot tell whether the client reached an SMTP server, do not label the issue “relay denied” yet.

Accepted by the relay, missing from the test inbox

Once the SMTP response indicates acceptance, move your investigation downstream. First verify the exact recipient address sent by the application, not just the address displayed in a form. Then inspect any available receiving-side message records, raw message details, and spam or other mailbox categories. Search using the unique marker from the test run so that an old email cannot be mistaken for the latest attempt.

Google’s Email Log Search guide explains how administrators can look for message records. Use the evidence available to your receiving account and distinguish these statements in your report: “the relay accepted the message,” “the receiving service recorded or delivered it,” and “the tester could read it in the expected mailbox.” They describe different outcomes.

If the message appears in spam, that is not the same failure as an SMTP rejection. Check the message’s receiving-side classification and authentication details rather than changing the relay’s allowed IP list without evidence. Google’s SMTP relay spam and abuse guidance is relevant when the relay accepted a message but later handling or spam policy may be involved.

A useful QA record contains the test marker, recipient, sending environment, SMTP result, and receiving-side observation. Redact personal information when retaining or sharing that record. RelayTmp’s privacy notice can help you assess privacy considerations for test data, but it does not replace checking the actual receiving service’s records.

A controlled test closes the application-level loop

Consider a preproduction registration flow that reports “verification email sent.” The SMTP library logs a successful submission, but the QA engineer cannot find the email. Calling the test passed at that point would conflate relay acceptance with receipt. The next check is not to rerun the UI blindly; it is to find the message using a controlled recipient and a marker tied to that run.

For a repeatable test of your own product or an authorized environment:

• Choose a controlled recipient that the test team can inspect. Avoid using a colleague’s personal inbox as a substitute for a test plan.
• Add a unique, non-sensitive marker to the test message or its subject so the send event can be matched to the receiving-side record.
• Capture the environment, recipient, sender configuration, and SMTP result. Store secrets separately and redact them from diagnostic output.
• If the relay rejects the message, compare the actual source IP, rule, sender, authentication method, and SMTP identities before changing configuration.
• If the relay accepts it, search the controlled inbox and any available message records; check spam and other categories before concluding that delivery failed.
• Open the verification link or trigger the intended notification action in the authorized test environment. Record whether the application reaches the expected state, not merely whether the message is visible.
• Keep the send-side and receive-side evidence together, with personal data removed where possible.

This approach has a clear benefit: each failure points to a narrower handoff. It also has a cost: a controlled recipient and readable evidence must be maintained, and a received message alone cannot prove that the application’s verification logic works. The QA result should say exactly which checks passed and which remain unverified.

For a broader discussion of what a temporary inbox can and cannot establish, review RelayTmp’s service boundaries. A temporary address can be useful for keeping test traffic separate from a primary mailbox, but do not use it for accounts that need long-term recovery, ongoing correspondence, or a permanent audit trail. Confirm the current service page before relying on any particular receiving feature.

Frequently asked questions

What should I check first after a relay denied response?

Capture the complete SMTP response and identify which stage returned it. Then compare the connection’s actual public egress IP, the configured allowed senders, the selected authentication method, and the identities used in HELO/EHLO and MAIL FROM with the current Workspace relay rule. Avoid changing several settings at once; a controlled retry after one documented change makes the result easier to interpret.

Why can a registered sender IP still be rejected?

The application may leave through a different public IP in development, preproduction, or CI, or a network change may have altered its egress path. A rule can also reject a message for a sender or authentication mismatch even when the IP is allowed. Compare the actual connection source and full SMTP reply with the account’s current relay settings rather than relying on an old registration record.

How can I confirm that an accepted test message reached the test inbox?

Use a controlled address you can inspect, and include a unique marker tied to that test run. Check the recipient address, the receiving service’s available message records or raw message details, and the spam or other mailbox categories. Record relay acceptance separately from visible receipt, then verify any application action such as completing a registration link.

How do I tell a relay configuration error from a message in spam?

A relay configuration failure appears in the SMTP session before the relay accepts the message; save the exact response and stage where it occurred. If the relay accepted it, investigate later delivery evidence and the recipient’s folders instead. A success message in your application alone does not prove inbox placement, while a message found in spam shows receipt with a classification issue rather than a relay rejection.

If the test only needs a temporary registration, a verification link, or a notification check, a separate test address can keep that traffic out of your primary inbox and avoid using personal details in test records. RelayTmp is one option to evaluate for that controlled receiving step; check its current page for the features that fit your workflow, and use a long-term mailbox whenever you need reliable account recovery or ongoing replies.

Frequently asked questions

Start a clean test run

Open a disposable inbox

Open an inbox instantly, copy the address, and refresh and read real test messages on the same page.

Open inbox