Bounce notifications received from Smartermail but not when sending from Gmail

Problem reported by rishikesh Somshetti - 1/22/2026 at 6:01 AM

Not A Problem

Hello SmarterTools Team,

We are observing an inconsistency with bounce notifications for invalid recipient email addresses and would like your guidance.

Expected behavior:
When an email is sent to an invalid email ID within a domain, a bounce (NDR) notification should be delivered back to the sender.

Observed behavior:

When testing from smarter mail, sending emails to invalid email IDs correctly generates bounce notifications to the sender.
However, when performing the same test from Gmail, no bounce notification is delivered back to the sender.

Test details:

Recipient: Invalid/non-existent email ID on our domain
Sending clients tested:
- smarter mail→ Bounce received ✅
- Gmail → No bounce received ❌

As per internal guidance, we verified that bounce handling works correctly at the server level via smarter mail, but Gmail-originated emails do not appear to receive or relay the bounce notification.

Could you please clarify:

Whether this behavior is expected when emails are sent from external providers like Gmail?
If Gmail suppresses or handles NDRs differently for invalid recipients?
Whether any SmarterMail configuration is required to ensure bounce notifications are generated or relayed back to external senders like Gmail?

Looking forward to your insights.

7 Replies

Reply to Thread

Andrew Barker Replied

1/22/2026 at 7:32 AM

Employee Post

As far as SmarterMail's behavior, this is expected. Bounce messages are supposed to be generated by the last server to accept the message.

When a sending server issues a RCPT TO command during an SMTP session, the receiving server is permitted to check if it can accept mail for the specified recipient. If it cannot, then the receiving server should return an error message. In the case of a recipient who does not exist, that error would probably be something like "550 No such user". That error response indicates that the server does not accept the message for that recipient, and it then becomes the responsibility of the sending server to generate the bounce message.

I can think of three likely reasons for why you are not getting bounce messages in your test. The first is that Gmail is not requesting bounce messages. Bounce messages are failure type Delivery Status Notifications (DSNs) and must be requested during the SMTP session. This leads to the second possibility, that a server in the relay chain does not support DSNs, since support is an optional extension of the SMTP protocol. If some server between the originating server and the destination server does not support DSNs, then a DSN request will get lost. Finally, some servers that officially support DSNs may be configured to not generate failure messages specifically.

As for your final question, since it is not SmarterMail's responsibility to generate the bounce message in your scenario, there is not really any configuration change you can make to ensure bounce messages are generated.

Andrew Barker Lead Software Developer SmarterTools Inc. www.smartertools.com

Sébastien Riccio Replied

1/22/2026 at 1:45 PM

Hi,

When I'm sending a mail from gmail to an invalid user of a domain hosted on our SmarterMail instance, I'm receiving a bounce back in gmail, generated by gmail, saying the remote server responded with 550 error code saying that no such user exists.

Is that the test you're doing ?

If yes, do you have any incoming gateway in front of SmarterMail ?

You might also want to check your smartermail delivery logs and SMTP logs to capture the session related to your attempt that did not generate the bounce, to see what SmarterMail replied in the SMTP session.

Kind regards.

Sébastien Riccio System & Network Admin https://swisscenter.com

rishikesh Somshetti Replied

1/28/2026 at 6:06 AM

Hi,

We are performing the same test. However, in our case we do not receive any bounce message in Gmail when sending to an invalid user on the SmarterMail-hosted domain.

Additionally, we do not see any related SMTP or delivery log entries on our SmarterMail server for these attempts, which suggests the message may not be reaching SmarterMail at all.

rishikesh Somshetti Replied

2/13/2026 at 5:32 AM

Hi,

Following up on this test from our side.

We are performing the same test scenario; however, in our case, when sending from Gmail to an invalid user on the SmarterMail-hosted domain, we do not receive any bounce or non-delivery notification in Gmail.

Additionally, we do not see any corresponding SMTP session, rejection, or delivery log entries on the SmarterMail server for these attempts. This strongly suggests that the message may not be reaching SmarterMail at all.

Could you please help confirm the following on your end:

Whether Gmail is attempting delivery to the correct MX records for the domain
If there are any upstream filters, gateways, or DNS-level protections (e.g., firewall, spam filtering service, Google-side suppression) that could be blocking or dropping the message before it reaches SmarterMail
Whether similar behavior is observed with test emails sent from non-Google mail providers

If helpful, we can share full message headers from the Gmail side for comparison.

Looking forward to your guidance on next steps to isolate where the message flow is stopping.

Kind regards.

J. LaDow Replied

2/13/2026 at 5:56 AM

mxtoolbox.com is your friend in this case --

If you are not seeing anything in your SMTP logs from google.com servers (all google SMTP servers id themselves with a .google.com EHLO -- then the issue is most likely DNS or routing to your hosted domains/server.

MailEnable survivor / convert --

rishikesh Somshetti Replied

2/19/2026 at 10:04 PM

Hi,

Thank you for the clarification.

Based on our testing, we can confirm the following behavior from our side:

When an email is sent from Gmail to a valid and enabled mailbox on the SmarterMail-hosted domain, we can clearly see the SMTP connection from Google servers (EHLO *.google.com) in our SMTP logs, and the message is delivered successfully.
However, when an email is sent from Gmail to a disabled or deleted mailbox on the same domain, we do not see any SMTP connection or related log entries on the SmarterMail server.
In this scenario, Gmail also does not generate any bounce or non-delivery notification to the sender.

This indicates that the message is not reaching the SmarterMail server at all when the recipient address is invalid, despite using the same domain and MX records that work correctly for valid users.

Given this behavior, the issue appears to occur before the message reaches SmarterMail, potentially at the DNS, routing, or upstream handling stage on the sender side.

Please let us know if any additional tests or data (such as Gmail message headers or timestamps) would help further isolate this.

Kind regards.

Douglas Foster Replied

2/20/2026 at 10:30 AM

Your last post clarifies the issue perfectly. Your symptoms are not a bug; they are expected behavior.

Recipient verification and "Inbound SMTP" spam filtering occur while the SMTP session is active. If a problem, is detected, the adjacent system is given a failure result code. Notification of the recipient becomes the responsibility of that adjacent system.

All other tests occur after the SMTP session is closed, so there is no adjacent server to notify. Your system is responsible for generating a non-delivery report (NDR) email to notify the sender that a problem has occurred. If your system is not configured to send NDRs, the sender never finds out about the failure.

If you have an inbound gateway running SmarterMail, and configured to use SmarterMail Gateway mode, I believe it will detect both invalid accounts and disabled-no-mail accounts. (You can check with support to confirm this. For many reasons, I recommend using an inbound gateway and performing all of your spam filtering there.

Disabled accounts are detected during the delivery phase. If Recipient Verification was not performed during the SMTP session, then invalid recipients will also be detected during the delivery phase. The delivery log will have information about all of the failed deliveries.

After checking the admin interface, I notice that SmarterMail describes these messages as "Delivery Status Notifications (DSNs)", not NDRS. That term is better because it includes confirmation of receipt notices. You enable or disable DSNs as an admin using: Setttings... SMTP In... "Message limits and delivery".

If you choose to send DSNs, you should also set these options at: Settings... Antispam... Options:

Autoresponders: Require message pass SPF
Content Filter bouncing: Require message pass SPF

I have argued elsewhere that notifying senders about delivery problems will rarely benefit legitimate senders, will rarely trigger automatic subscription removal when it is wanted, but will occasionally activate subscription removal in response to a false positive. What it will do is help directory harvesters perfect their knowledge of your address list, will help attackers know that they need to change their attack strategy, will dramatically increase your volume of outbound mail, and will occasionally cause backscatter to an entity that was not involved in the attack. (The SPF requirements are intended to prevent or minimize backscatter risk.)

So I accept every message, do my own recipient verification and message filtering in Declude after the SMTP session is closed, and discard or quarantine anything that is not acceptable. Senders get silence unless the message is delivered and the recipient chooses to send a reply.

Choose the appropriate configuration for your system based on your needs and the expectations of your users.

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Enter the verification text