Troubleshoot a broken junk mail folder

  • Article

I recently worked on a very interesting case that I wanted to share. This organization had set EOP to deliver all spam messages to end users junk mail folder.

This worked great for most users, but a small number experienced EOP delivering spam messages directly to their inbox, as if they weren’t being scanned at all. Very peculiar indeed. Let’s go through the troubleshooting process to figure out what’s happening here.

Troubleshooting

Note that I’m limiting my troubleshooting here to a single impacted user.

First I want to verify that the mailbox actually exists in Exchange Online and not on-premises. The reason being, is that if the mailbox exists on-premises, two additional transport rules need to be created on-premises if the content filter in EOP is set to deliver spam to the junk mail folder. For details on this see Spam Action. For this case, the mailbox was indeed located in Exchange Online and so these transport rules are not needed. Let’s move on.

Next let’s take a look at the message headers for one of the spam messages that landed in this users inbox. This is to verify that EOP is correctly marking the message as spam. Here’s what we see.

x-forefront-antispam-report: CIP:xx.xx.xx.xx;CTRY:EU;IPV:NLI;EFV:NLI;SFV:SPM;SFS:(6009001)(6039001)…;
DIR:INB;SFP:;SCL:5;SRVR:BLUPR07MB915;H:factor27.plexbankingsystem.work;
FPR:;SPF:None;PTR:27.178.serverel.net;A:1;MX:1;LANG:en;

Two things I look for here, SFV (Spam Filter Verdict) and SCL (Spam Confidence Level). Here we see SFV:SPM and SCL:5, which indicates that this message was indeed marked as spam by the EOP content filter. If instead I saw SFV:SFE and SCL:-1, this would indicate that the sender was on the recipients Safe Senders List, and this would have been the reason for the message being delivered to their inbox (see Anti-spam message headers). Since I don’t see that, let’s continue troubleshooting.

Next up is verifying the content filter settings. For this case there was only a single content filter, so we don’t need to figure out which one is being used.


 
Looking into the settings of this content filter we can see that both spam and high confidence spam actions are set to junk mail folder.


 
So far from what we’ve seen, this message should have been moved to the recipients junk mail folder.

Next I wanted to verify that a client side Outlook rule isn’t at play here. What could be happening is EOP delivers the message to the junk mail folder, and then the Outlook client side rules run which moves the message to the inbox. I ran an Extended Message Trace (allows me to download a very detailed trace in the form of a CSV file) on EOP to determine which folder EOP was delivering the message to.

For this particular user, I see a blank cell under recipient_status for the DELIVER event_id, which tells me that EOP delivered the message to their inbox.

If EOP was properly delivering the message to the recipients junk mail folder, I would see something like this in the extended trace for the DELIVER event_id.

Bonus learning: A blank space, or a semi colon (;) in recipient_status column means the message was delivered to the inbox (for the DELIVER event_id). If there’s anything else it’s the name of the folder where the message was delivered.

I also investigated server side rules, but the recipient in question did not have any. So far nothing has obviously stood out in our troubleshooting. There are two more tasks in my troubleshooting toolbox.

Next up it’s time for some PowerShell. I would like to confirm that the recipients Junk Mail Folder configuration is enabled, and the only way to verify this is through the following PowerShell.

Get-MailboxJunkEmailConfiguration

Running this returns the following.


 
Bingo. We finally find what the problem was. This users Junk Email Configuration was set to false. For this particular customer, their mailboxes had been migrated from on-premises to Exchange Online, and my guess is that for some users, their Junk Email Configuration was disabled on-premises before the migration and so was migrated along with the mailbox to Exchange Online.

This setting can easily be re-enabled with the following PowerShell. 

Set-MailboxJunkEmailConfiguration <alias> -enabled $true

Now let’s do another Get to verify the change


 
This organization had less than 1000 mailboxes, so the following PowerShell was used to mass change all mailboxes that had this disabled, to re-enable.

Get-Mailbox | Get-MailboxJunkEmailConfiguration | ? {$_.Enabled -eq $false} | Set-MailboxJunkEmailConfiguration -Enabled $true

In this particular case, there were only about 11 mailboxes that had their junk mail configuration set to False.

Once the impacted users had their Junk Email Configuration set to enabled, we observed spam messages correctly being delivered to their junk mail folder.

What if the impacted users Junk Email Configuration had been enabled? My next step would have been to use MFCMAPI to delete the impacted users Junk Email Rule, which would have caused it to be re-created by Exchange Online. The steps for accomplishing this are beyond the scope of this article.

I hope you have found this useful.

Comments

  • Anonymous
    March 14, 2015
    Great stuff
    Thanks
  • Anonymous
    June 02, 2015
    Your PowerShell didn't work, but this does:

    Get-MailboxJunkEmailConfiguration * | ? {$_.Enabled -eq $false} | Set-MailboxJunkEmailConfiguration -Enabled $true
  • Anonymous
    June 12, 2015
    Well that's embarrassing. Thanks Kevin! The problem with what I had posted is that I used "false" instead of "$false"

    Thank you for sharing your script as well which also works.
  • Anonymous
    June 22, 2015
    The comment has been removed