Internal bounce message does not conform to domain settings
Problem reported by CLEBER SAAD - 1/15/2026 at 5:23 AM
Submitted
Hi everyone,

I'd like to know if anyone else has experienced this situation. Bounce messages generated internally by SM are being rejected when trying to be delivered to a Gmail account, for example, because they don't have the DKIM for the domain.

I'll explain what's happening:

- If you try to deliver a message to an account that has a forwarding address to another account that doesn't exist, a bounce will be generated. If the sender is an account from the same domain, the bounce is successfully delivered. If the sender is an external account, the bounce will not be delivered because the DKIM will not be present in the message, for example.

How to test:

1) Create an account like test@yourdomain.com and in the forward address field, enter existingaccount@yourdomain.com and nonexistentaccount@yourdomain.com.

2) Send an external message to test@yourdomain.com. It will be successfully delivered to existingaccount@yourdomain.com and a bounce will be generated when delivering to nonexistentaccount@yourdomain.com.
3) The bounce must be delivered to the sender. In the case of Gmail, if the domain has DKIM, the bounce must also comply. If it does not, the bounce message will be rejected.

Detail: the bounce has the sender as noreply@yourdomain.com (default of the new SM), however when making the delivery, the mail from will be <> and not noreply@yourdomain.com

Using the latest version of SM 9504 in Linux (Windows has the same situation)

Douglas Foster Replied
All of this confirms why forwarding should require approval of the forwarding system's system manager, a feature which SM and possibly all other products lack.

I did not follow your notation completely, so I will rewrite it as:
user1@domain1 sends to user2@domain2 forwards to user3@domain3
but user3@domain3 is invalid.

Your server is harmed multiple ways by this mistake.   Domain3 perceives your message as a directory harvesting attack.   If the volume is non-trivial, domain3 may also perceive you as a DoS attack.   If the bounce is delivered, User1@Domain cannot possibly make sense of a message that says "Your message to user3@domain3 cannot be delivered", because he never sent a message to users3@domain3.  But you said that the bounce is not delivered, possibly because SM does not handle this unusual situation perfectly, so now Domain1 has raised  your risk score.

Now imagine that User3@Domain3 does exist, but it is incorrect because of a typo when the forwarding rule was created.  User3@Domain3 complains to his admin and causes your server and domain to be blocked by his organization, and maybe your server and domain ends up on the SpamHaus block list.    Now all of your domains are having delivery problems to multiple destinations, and you have no idea how you got blacklisted in the first place.   

Or maybe User2 is forwarding to his personal account, where company secrets and privacy-regulated data become exposed  to Google's email sniffing engine.

Or maybe User2 is malicious or compromised), so his forwarding rule is exfiltrating data to an external entity.

Assuming that you feel unable to disable forwarding completely, a fallback strategy would be to the new feature for redirecting bounce messages.   Send bounce messages to your admin account instead of user1@domain1.    Then you can investigate why messages are being sent to invalid addresses.   Maybe its a one-time typo by an internal user.   Maybe its an invalid forward like your example.   Maybe its an infected account doing a blast attack.   Whatever the cause, you find out, and you can manually notify anyone else that needs to know, after you have identified the root cause.
CLEBER SAAD Replied
Douglas,
Thnaks a lot. I agree to you. I see today that mail from: <> it's not a best practices. If use "the new" noreply@domain.tld, this message/bounce need to be with configuration of the domain in SM (like dkim)

In our case, it's the same domain the foward address.

Sender (external): teste@anotherdomain.com (external from SM)
Domain: cleber.com.br (in SM)
Account: teste@cleber.com.br with foward to cleber@cleber.com.br (exists) and saad@cleber.com.br (not exists).

The bounce created by SM from because the delivery failed to saad@cleber.com.br need to be sent to teste@anotherdomain.com. This bounce don't has mail from and another configuration of domain cleber.com.br and will be denied by service provider (like gmail in our case)
Douglas Foster Replied
Open a ticket to have them investigate the missing signature in this unusual situation.
terry fairbrother Replied
Not sure if it's related, but I wasn't able to email support or sales on Wednesday


CLEBER SAAD Replied
Terry, not related. ;-)

Reply to Thread

Enter the verification text