The target email is not gmail. How can we reach your support privately?
Unfortunately we are not able to separate out forwarders by recipient ASN at this time, so all forwarded emails are treated the same and subject to the same filtering. If you would like to find ways to reduce the likelihood that an email is viewed as spam, you can check the headers of the inbound email for more information, at least for what our inbound filters caught. Roundcube is a good example to do this in:
From there you click Show source. You’ll get a full view of the email source, and you’ll want to look for something like this:
You can see from my example that 2 points went to “HEADER_FROM_DIFFERENT_DOMAINS” here. In this case, the sender could have reduced the chances of this being viewed as spam by having consistent headers in their outbound email. This email was not viewed as spam. However, if it were, and I desperately wanted it to not be viewed as spam on inbound (thus reducing the chance of it being viewed as spam on outbound), I could do this:
- Log in to cPanel.
- Click Spam Filters.
- Click Show Additional Configurations (bottom of page)
- Click “Calculated Spam Score Settings”
- Click “Add A New ‘scores’ item”
- Select HEADER_FROM_DIFFERENT_DOMAINS from the dropdown box, set a score of 0 in the box to the right
- Click “Update Scoring Options.”
None of this is guaranteed to ensure that we will forward a particular email. If you want to ensure that you receive all emails with 100% consistency, we ask that you not use email forwarding.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
In your specific case, one of the major impacting factors of the emails not being forwarded is this rspamd rule:
MISSING_MID
This means that your email has no message ID header. You can read more about that here:
Our outbound filter will check that emails are properly formatted, with the correct headers in place. Emails sent from our service will not have such issues.
There is no HEADER_FROM_DIFFERENT_DOMAINS in the email source. What else to look for? Those emails are just transaction emails like new order emails which we need to forward to other emails.
Only a few emails can not be forwarded but other same type emails don’t have this problem. How can we reach you privately so we can send the source of problem emails to you? Thanks.
That was just an example of what I could do with the email that I opened up to use as an example. The steps will be relative to your situation, but not identical.
We cannot forward 100% of emails received without it resulting in far less outbound emails being delivered. These are the demands of companies like Google, Yahoo, Microsoft, etc. We must filter outbound email, and sometimes emails that you want to receive will be caught by that filter, because legitimate emails can and will be viewed as spam by these recipient services. The best way to ensure that this does not happen is to use our service directly.
You should never hit these filters when sending legitimate email yourself, and please let me know if you ever do. Forwarding is when you should hit the filter sometimes, and that can unfortunately include some times that you will not want it to.
If this is unacceptable, we will gladly provide a refund.
You can find the above message containing the source of this particular issue, though I cannot accurately instruct you on how to fix it, this is something that should be done by the application that you are sending with.
We use your cPanel do the email forwarding. In this case how can you check it for us? This is pretty urgent. We never send spam emails and as you can see, we only send less then 10 emails a day. We really don’t want to miss any email and email forwarding.
The email is not generated by cPanel, it is generated by an email client. The email client you are sending from is not adding a message-id header, which is an accepted standard for sending email. This is not something I am able to influence or directly advise on, as I do not know anything about the application you are using to send email.
Per RFC-2392 and RFC-5322, your emails should have a message-id header. If you send email from our webmail or any major email application, this is correctly added to your email. The application you are sending from is not conforming to this standard. If you are not able to correctly add a message-id header to your emails, we would be happy to refund.
Ok, I think those emails are sent by our Magento site. I will try to add message id and have some more check.
It’s strange that if we use your cpanel smtp info to send email, it will not have message id and etc. If we use a 3rd party smtp service, it will have a lot more fields like message id and etc.