3
Trusted Sender - User, failed DKIM
Problem reported by Charles Verrette - 5/27/2019 at 8:31 AM
Not A Problem
Hi,

Some of our clients are having trouble receiving important emails even after identifying them as trusted senders. Here's an example of a trusted sender that was sent to the junk folder. This particular client missed an order of a couple thousand dollars because of this :

X-Microsoft-Antispam-Message-Info: quUX4jSEIARKGE/KbM1NtAZWvL7ghI1EbCfqbix85jNaibbH6wl98dJleTSBU0hcikNSchNhrffKc7FvVgij2I2+zxYMHEP4BTFP5YUxmScKf7TEcvycI0mJzJb398YnyCu3o4JTUU2ybnjc/aY6rywTu86KYUTrjtYK9x6wsRMjC3DPcFlDWtpBi5gqQfuounxCTEtrmYvDbMo6tbqhrH2VjO7dY6yDMYrEfghiXC0Il4IMPth2MXyAyYSGZetT/Mm2jPDg0QvB046RsViietNUT5WNoLuuucueCrS+bjNbfmLj5QHa2gHLwDHseST3wlxdSSBxhm7gzbPcO/1WxSE6O2AfEZa3gPnT2oiJnPNIcNH5dd8GCr2p/GSeRdJKVCseqpzfrQqFZhFO8dtq3ttFQ1kUZpW2/nPiSNAh9Ws=
X-OriginatorOrg: premiertech.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 May 2019 20:12:11.6369
(UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 3563b5a0-a7aa-4171-b1f7-08d6e0841b43
X-MS-Exchange-CrossTenant-Id: bf3289d6-ee43-4e0d-9204-110b7e9003dc
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bf3289d6-ee43-4e0d-9204-110b7e9003dc;Ip=[207.61.253.219];Helo=[NAEXCHSRV2.na.premiertech.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR14MB3059
X-CTCH-RefId: str=0001.0A020208.5CE85021.0082,ss=1,re=0.000,recu=0.000,reip=0.000,vtr=str,vl=0,cl=1,cld=1,fgs=0
X-CTCH-AVLevel: Unknown
X-SmarterMail-Spam: Message Sniffer [code:0]: 0, ISpamAssassin [raw:5]: 8, SPF [Pass]: 0, DK [None]: 0, DKIM [Fail]: 20
X-SmarterMail-SpamDetail: 0.4 MIME_HTML_MOSTLY Multipart message mostly text/html MIME
X-SmarterMail-SpamDetail: 2.2 MIME_HTML_ONLY Message only has text/html MIME parts
X-SmarterMail-SpamDetail: 0.0 HTML_MESSAGE HTML included in message
X-SmarterMail-SpamDetail: 2.1 HTML_IMAGE_ONLY_20 HTML: images with 1600-2000 bytes of words
X-SmarterMail-SpamDetail: 0.7 HTML_SHORT_LINK_IMG_3 HTML is very short with a linked image
X-SmarterMail-SpamDetail: 0.0 T_IMAGE_MISMATCH Contains wrong image format for MIME header
X-MessageSniffer-ResultCode: 0
X-SmarterMail-TotalSpamWeight: 28 (Trusted Sender - User, failed DKIM)

And the logs extract from this transaction :

[2019.05.24] 16:08:27.824 [07141] Delivery started for ptae@premiertech.com at 4:08:27 PM
[2019.05.24] 16:08:30.829 [07141] Added to SpamCheckQueue (1 queued; 1/30 processing)
[2019.05.24] 16:08:30.829 [07141] [SpamCheckQueue] Begin Processing.
[2019.05.24] 16:08:30.938 [07141] Starting Spam Checks.
[2019.05.24] 16:08:33.329 [07141] Spam check results: [REVERSE DNS LOOKUP: 0,Passed], [_MESSAGESNIFFER: 0,code:0], [_INTERNALSPAMASSASSIN: 5:8], [_SPF: 0,Pass], [_DK: 0,None], [_DKIM: 20,Fail], [HOSTKARMA - BLACKLIST: 0,passed], [HOSTKARMA - BROWNLIST: 0,passed], [HOSTKARMA - WHITELIST: 0,passed], [SORBS - ABUSE: 0,passed], [SORBS - DYNAMIC IP: 0,passed], [SORBS - PROXY: 0,passed], [SORBS - SOCKS: 0,passed], [SPAMCOP: 0,passed], [SPAMHAUS - PBL: 0,passed], [SPAMHAUS - PBL2: 0,passed], [SPAMHAUS - SBL: 0,passed], [SPAMHAUS - XBL: 0,passed], [SPAMHAUS - XBL2: 0,passed], [SURBL: 0,passed], [SURBL - ABUSE BUSTER: 0,passed], [SURBL - JWSPAMSPY: 0,passed], [SURBL - MALWARE: 0,passed], [SURBL - PHISHING: 0,passed], [SURBL - SPAM ASSASSIN: 0,passed], [SURBL - SPAM COP: 0,passed], [UCEPROTECT LEVEL 1: 0,passed], [UCEPROTECT LEVEL 2: 0,passed], [UCEPROTECT LEVEL 3: 0,passed], [URIBL - BLACK: 0,passed], [URIBL - GREY: 0,passed], [URIBL - MULTI: 0,passed], [URIBL - RED: 0,passed]
[2019.05.24] 16:08:33.329 [07141] Spam Checks completed.
[2019.05.24] 16:08:33.329 [07141] Removed from SpamCheckQueue (1 queued or processing)
[2019.05.24] 16:08:33.829 [07141] Added to LocalDeliveryQueue (0 queued; 1/50 processing)
[2019.05.24] 16:08:33.829 [07141] [LocalDeliveryQueue] Begin Processing.
[2019.05.24] 16:08:33.829 [07141] Starting local delivery to cimentge@cimenteriegenest.com
[2019.05.24] 16:08:33.875 [07141] Delivery for ptae@premiertech.com to cimentge@cimenteriegenest.com has completed (Delivered to Junk Email) Filter: Spam (Weight: 28), Action (Global Level): MoveToFolder
[2019.05.24] 16:08:33.875 [07141] End delivery to cimentge@cimenteriegenest.com (MessageID: <OF2249237A.9772D780-ON85258404.006EF883-85258404.006EFA88@premiertech.com>)
[2019.05.24] 16:08:33.875 [07141] Removed from LocalDeliveryQueue (0 queued or processing)
[2019.05.24] 16:08:36.829 [07141] Removing Spool message: Killed: False, Failed: False, Finished: True
[2019.05.24] 16:08:36.829 [07141] Delivery finished for ptae@premiertech.com at 4:08:36 PM	[id:311254907141]

How can I prevent this from ever happening again? Contacting premiertech.com to ask them to fix their DKIM is not an option. I need to make sure that the next emails from @premiertech.com won't be intercepted by our SPAM filters. 

Thanks

2 Replies

Reply to Thread
0
Kyle Kerst Replied
Employee Post
RDNS (Reverse DNS), SPF, and the associated DKIM keys are always checked on delivery, regardless of the Trusted Sender status. This is to prevent spammers from leveraging the Trusted Senders system to deliver spam to your users. As such, these types of failures will always cause delivery issues, and I would be surprised if this end user is not having trouble delivering mail to many email servers due to the nature of DKIM. DKIM typically instructs receiving mail servers to NOT accept mail if it comes from an IP not included in the DKIM/SPF setup. The one thing you could likely do here is to decrease the spam weight associated with failed DKIM checks, but this defeats the purposes of these spam checks and is not recommended. This is done under Settings>Antispam>Spam Checks
Kyle Kerst System/Network Administrator SmarterTools Inc. (877) 357-6278 www.smartertools.com
1
Charles Verrette Replied
Ok thanks for the answer. While were on the subject of trusted senders, I've had a couple of spoofing cases where the sender was using the recipient's own email to bypass the SPAM filters. When this happened before it was usually because our customers had manually added themselves or their own domain as trusted senders and all I had to do was to remove them from their trusted senders list to block those spoofed messages.

However since about a year, users own email addresses are automatically considered as trusted senders because of the global address list. More so, I can't event remove them from their global address list as it seems to be automatically generated and I can't delete them manually. 

How can I prevent this from happening? 

Reply to Thread