Problem:
My user is having problems receiving emails from a certain sender. Those emails are not showing up in the message log so I don't know what to do currently. I do have other users receiving emails from the same sender fine but not this particular user in my domain.
Explanation:
If messages aren't showing up in the message log, it's for three possible reasons ...
Either proofpoint is rejecting messages at the front door with the reputation blocking (this is unlikely if other recipients in the organisation are receiving mail fine from the same source)
>> OR <<
You have a filter rule that hides messages from the log (less likely but has happened). In those cases you should check your filter rules and make sure to change the "hide from log" statement to "hide from log except administrators" instead ...
>> OR <<
The emails were bounced originally trying to deliver to your user and the SENDER put the destination on a suppresion list (a delivery blacklist) because they got too many bounces. (troubleshooting below)
So the question is - why was the sender getting bounces to your user?
Often this happens if the user is a recent hire and when the mailbox was provisionned on Office365/Exchange (or whatever mail server you use), the user wasn't populated yet in proofpoint so messages sent to that user from the cloud service they are expecting mail from started bouncing.
Unfortunately, many of the cloud services that do suppressing have the bounces go to [email protected] and there's nobody paying attention to that mailbox.
Workaround:
Normally to ascertain if there's an attempt at delivery or not, we (vircom) have to escalate to proofpoint to check their back-end logs to see if 550 rejects were sent out to attempts to deliver to [email protected]. This process can take a little while so before escalating to us, here's a trick you can do to see if the recipient in your organisation was blacklisted by the sender (suppressed)
Let's say your user is [email protected].
1. Just create an alias on the backend mail server (ie: office365, exchange) called [email protected].
2. Make sure the alias is populated in proofpoint.
3. Wait at least an hour before trying to use it!
4. On whatever cloud service they use that they are expecting mail from that they aren't getting, change the destination email address to the aliased address ([email protected] in the example)
If it starts working, then you know it was a suppression case.
At this point you can (a) live with the alias or (b) open a ticket with the service you are using to have the original address unsupressed.
IF the alias trick doesn't work ...
Then it's worth escalating to us to see what's going.