Trusted sender keeps on ending up in SPAM
One of the most common complaints we get from our clients has to do with allow/whitelist policies and to make the long story short this happens because of the way your service provider configured ExchangeDefender. The long story, technical background, and best practices are outlined at https://www.exchangedefender.com/docs/whitelist. It usually sounds like this:
“I keep whitelisting this email address that sends me my OTP password / password reminder / login code / transaction confirmation / newsletter and they keep on ending up in SPAM!”
This happens for clients that configure ExchangeDefender to block email forgeries and spoofing.
You see, the email address that is showing up in ExchangeDefender and your Outlook/Gmail is not the actual email address that the message was sent from. Large volume emails (OTP, password reminders, notifications) are not sent by humans, they are computer generated and there is a random email address for every notification they sent out (so when/if it bounces they can track it).
These automated email addresses tend to have a long randomly generated identifier in them and generally look like this:
010001890676a389-ee862f60-d7ea-4ba1-a113-f16935e2afeb-000000@amazonses.com
But in your Outlook/Gmail the spoofed/faked email appears to have come from DoNotReply@someotpsite.cz which has the domain you trust and attempt to allow/whitelist. If you pull up the SMTP headers from the quarantined email you can see this email address in the envelope-from field:
Received: from inbound10.exchangedefender.com (65.99.255.114) by
owa.exchangedefenderdemo.com (10.10.10.5) with Microsoft SMTP Server (TLS) id 14.3.498.0;
Thu, 29 Jun 2023 05:23:03 -0400
Received-SPF: pass (inbound10.exchangedefender.com: domain of 010001890675c389-ee862f60-d7ea-4ba1-a113-f16935e2afeb-000000@amazonses.com designates 54.240.77.69 as permitted sender) receiver=inbound10.exchangedefender.com; client-ip=54.240.77.69; helo=a77-69.smtp-out.amazonses.com; envelope-from=010001890676a389-ee862f60-d7ea-4ba1-a113-f16935e2afeb-000000@amazonses.com; x-software=ExchangeDefender SPF;
Authentication-Results: inbound10.exchangedefender.com; dmarc=pass (p=quarantine dis=none) header.from=someotpsite.cz
Authentication-Results: inbound10.exchangedefender.com;
dkim=pass (1024-bit key) header.d=someotpsite.cz header.i=@someotpsite.cz header.b=”QPv3HP79″;
dkim=pass (1024-bit key) header.d=amazonses.com header.i=@amazonses.com header.b=”MsX8RGl7″
Received: from a77-69.smtp-out.amazonses.com (a77-69.smtp-out.amazonses.com
[54.240.77.69]) by inbound10.exchangedefender.com (8.14.7/8.14.7) with ESMTP
id 35T9M86a030204
<demo@exchangedefenderdemo.com>; Thu, 29 Jun 2023 05:22:09 -0400
From: <DoNotReply@someotpsite.cz>
To: <demo@exchangedefenderdemo.com>
Subject: ConnectWise Manage Security Code
…
Solving this issue requires your ExchangeDefender admin to decide how permissive they want to be of email forgeries and fakes. ExchangeDefender provides two ways to manage this in the ExchangeDefender Domain Admin app at https://admin.exchangedefender.com (see documentation)
Option 1: Allow email from the bulk email network
ExchangeDefender enables you to automatically pass through messages coming from specific bulk/spam mail providers. It’s located at https://admin.exchangedefender.com under Advanced Features > Bulk Mailer Policy:
In our example SMTP header the message came from AmazonSES so if you change the policy from Scan to Allow, ExchangeDefender will simply deliver these messages to your mailbox without quarantining it as a forgery/spoof (which it is).
Option 2: Choose a relaxed From: policy
This is a less secure option that will allow forgeries and effectively lowers your security level to that of M365/Office365 – and we strongly discourage you from doing that. However, if the client requires it you can get it done under Advanced Features > From: Policy:
Summary
If you’re seeing notification emails in your SPAM quarantine even though you’ve trusted the sender repeatedly, it’s doing so because the message is being spoofed and your admin has configured ExchangeDefender to block that activity. You can relax the security restrictions by choosing to either allow the bulk mail network or you can build your trust rules on the less-secure From: address.
Our team is always here to help but they aren’t allowed to guess without seeing the SMTP headers first – so if you ever run into an issue that you’d like us to take a look at grab the headers and provide them at https://support.exchangedefender.com and we’ll advise from there.
