The last remarks from Plusnet were on the 15/02/2025 when the multi destination failures involving Microsoft's family of outlook, live, hotmail msn etc were acknowledged.
Since then this thread has extended on a daily basis with various views exchanged, but no progress.
For some this may a novelty topic, for others, like us, it remains a considerable nuance with no end in sight.
Looking back over our rejection headers I see repetition of responses with X-CM-Score` and `X-CNFS-Analysis`,
not knowing the meaning of any of the headers I had not spotted the recurrence of sm=1
I used Gemini AI to give me a clue what this might mean ( words in bold below are as is from response ) :
The email headers you provided, specifically X-CM-Score and X-CNFS-Analysis, are not standard headers defined by RFCs. Instead, they are proprietary headers added by a third-party anti-spam engine, specifically Cloudmark Authority.
Here's a breakdown of what these headers mean and why the email was likely rejected:
- This header is a spam score assigned by Cloudmark Authority.
- The score is typically a numerical value, where a lower score indicates a higher likelihood of the message being legitimate ("ham").
- A score of 0.00 means the email was considered to be "good mail" and not spam by the Cloudmark engine itself.
- X-CNFS-Analysis: v=2.4 cv=FYuUx4+6 c=1 sm=1 tr=0 ts=68add125 a=...
- This is the core analysis header from Cloudmark. It's a verbose breakdown of the tests the email went through.
- v=2.4: The version of the Cloudmark engine used.
- cv=FYuUx4+6: A unique identifier for the analysis.
- c=1: This likely means the email was classified as "Clean" by Cloudmark's content analysis.
- sm=1: This likely means the email was classified as "Spam" by Cloudmark's sender-based analysis. This is the critical part. Cloudmark has a unique fingerprinting system that can identify messages from known spam-sending sources. Even if the content of a single message looks fine, if the sender's pattern (e.g., domain, IP address, message format) matches a known spam campaign, it will be flagged.
- tr=0: This likely indicates the message did not trigger any "Tarpit" rules, which are used to delay known spammers.
- ts=68add125: The timestamp of the analysis.
- a=...: The rest of the string is a series of codes and hashes. These are internal Cloudmark "fingerprints" of the email's content and characteristics. They are used for a variety of tests, and while they can't be decoded without Cloudmark's proprietary tools, the presence of these numerous "a=" codes indicates that the engine performed a detailed analysis.
Conclusion: Why the email was rejected
The most likely reason for the rejection is the combination of the X-CM-Score: 0.00 and sm=1 in the X-CNFS-Analysis header. This suggests a conflict in the spam analysis:
- The content of the email itself (X-CM-Score) was rated as non-spam (a score of 0.00 is good).
- However, the sender, the sending IP address, or a characteristic of the email's format was identified by Cloudmark's unique sender reputation system (sm=1) as belonging to a known spam source.
Microsoft, particularly for its Hotmail and Outlook services, has used Cloudmark Authority for spam filtering for many years. When an email is rejected by Microsoft, it's not just because of a single failed check. It's a combination of factors, and in this case, the negative sender reputation assigned by Cloudmark's engine likely overrode the clean content score, leading to the rejection.
To resolve this, the sender should:
- Check their IP address and domain reputation on major blacklists (e.g., Spamhaus, MXToolbox).
- Ensure their email authentication is perfect (SPF, DKIM, and DMARC are all correctly configured and passing). A DKIM fail, in particular, would make the message much more likely to be identified by Cloudmark as a spoof or a forged message from a high-volume spammer.
- If they are a high-volume sender, they should sign up for Microsoft's Smart Network Data Service (SNDS) to monitor their reputation and check for any potential issues.
