I have been unable to whitelist Marketo emails from our instance so that they can be received internally.
The main causes for the Marketo emails being rejected include ‘Rejected by header based Anti-Spoofing policy’, or that the shared IP was on a blacklist.
During implementation, I provided our company’s IT admin with the whitelisting instructions in the documentation, however nearly all Marketo emails and notifications are still being blocked internally by Mimecast. IT would prefer to whitelist without using these IPs to avoid whitelisting all other Marketo subscribers sharing these IPs.
Subsequently I sent the instructions for using Regex for whitelisting, but IT and Mimecast says this won’t work. Here is response from Mimecast regarding this:
"For Anti-Spoofing, there is no way you can use expression phrases to bypass the system. DKIM would not work as it work different to Anti-Spoofing. The only way is if make a list of the External IP addresses you see on messages blocked by Anti-Spoofing and allow those on Everyone to Everyone Take no Action Anti-Spoofing Policy."
Marketo Support says that other Marketo customers using Mimecast have been able to use regex to whitelist, though.
We are not eligible for Unique IP because we do not send over 100,000 emails monthly. I believe we are eligible for Trusted IP, which I believe would help solve the problem by providing a branded envelope for free.
It's important to note that our IT team has not setup DKIM yet but is planning to do so within the next month or two. Before applying to Trusted IP / enabling the branded return-path / branded envelope sender, I’m curious if anyone can provide some advice, especially if you’re using Mimecast with your Marketo instance.
What exactly is the anti-spoofing rule that's being triggered?
I work with lots of non-branded, standard shared-instance Marketo users and while Mimecast is frustrating — mostly because the everyday users on both sides don't realize how strict the Mimecast layer is — haven't had a problem with an anti-spoofing rule kicking in broadly.
Under email suspended cause I'm seeing "550 Rejected by header based Anti-Spoofing policy: email@example.com - https://community.mimecast.com/docs/DOC-1369#550 [8jrT4lbqOSisnWzmg8akqQ.uk64]"
I asked IT your questions and they said this is the rule that's being triggered for anti-spoofing, although this looks like a help article on how to setup the policy, not what exactly the emails are failing for:
My understanding is that the whitelist - whether it's via IP range, regex or via DKIM - should prevent Mimecast for failing these emails for both anti-spoofing or the IP blacklists. I can't find any instructions on how to go about implementing either of those whitelist approaches within Mimecast itself. IT isn't understanding how the whitelisting can be done, and I don't have access to the admin side of Mimecast.
I believe Mimecast's SPF-based bypass policies only look up the IP, checking to see if it's allowed by a certain domain's SPF record.
In essence, it uses SPF TXT records & mechanisms as a database and query language for whitelisting information. But it's slightly off-kilter from the usual use of SPF since it's not looking up the MAIL FROM: domain itself. Another way of looking at it is a custom include: mechanism dictated by the receiver.
In any case I want to see how one of these messages looks on the wire. I'm going to PM you a test address now.
OK, looking at the inbound email, it passes SPF (as is expected with a non-branded envelope). I would recommend 2 things (doing both would be great):
Thanks Sanford -
1. DKIM is in hand, but my issue is that Mimecast says there is no way to whitelist our Marketo instance via DKIM, and IT does not see a way to do it within Mimecast. I am hoping there is another Marketo customer on these forums also using Mimecast who has successfully whitelisted their instance and can share how they did it.
2. IT says this has already been done, but it's not working as it should be.