Mimecast, GSuite – inbound DKIM/ SPF & DMARC

4th November 2019

Hopefully this will save someone else a lot of hassle and headaches.

Setup:

Mimecast in front of GSuite

Issue:

Some incoming emails, from reputable providers (stripe.com / datto.com etc) were being hard bounced by GSuite after being processed by the inbound Mimecast filters

Error Message in Mimecast:

5.7.1 Unauthenticated email from stripe.com is not accepted due to domain’s
DMARC policy. Please contact the administrator of stripe.com domain
if this was a legitimate mail. Please visit
https://support.google.com/mail/answer/2451690 to learn about the
DMARC initiative. a3si5756714wrp.253 – gsmtp

What is actually happening?

Email arrives at Mimecast. It is “exploded”, inspected and then repacked for onward delivery to GSuite / GMail.

IF the sender has DKIM signed the email, then this “explode, inspect and repack” breaks the DKIM signature.

Looking at email headers (in this case the sender being an outlook.com address) you see this sort of thing

dkim=neutral (body hash did not verify) header.i=@outlook.com header.s=selector1 header.b=DEOq8NQm

When an email is then handed to GSuite, this broken DKIM signature / body hash will cause GSuite an issue.

GSuite, when faced with a failing DKIM signature, looks up the DMARC settings for the sender domain.

If there is no DMARC – we presume it lets it through
If the DMARC is set to “none” – GSuite lets it through
If the DMARC is set to “quarantine” – We don’t know what GSuite does. Probably rejects it (unless you’ve configured quarantine functionality)
If the DMARC is set to “reject” – then GSuite hard bounces the email and generates the 5.7.1 error that we see in the Mimecast console (see above for an example).

This “reject” option is set by people like stripe.com. It’s a sensible anti-tamper, anti-spoofing etc thing and they’re not going to change it just because we are breaking their valid incoming DKIM signed emails.

How to fix:

1- Don’t get Mimecast to “explode, inspect and repack”, so the DKIM signature isn’t broken. Kinda pointless having Mimecast at all then we’d have thought. Mimecast’s usually excellent L1 support seem to think that exempting these domains from the “inbound DNS checks” is the way to fix this. We disagree, having to explicitly whitelist domains is not where we want to be. Plus, it’s a hard bounce from GSuite, so you’ve got to phone and ask the sender to retry / resend every single time something gets caught, not a great look for an IT Support company….

2- Get GSuite to not worry about the broken DKIM and so not bother looking up the DMARC policy of the sender.

3- Get GSuite to ignore the “reject” instruction in the DMARC policy. We don’t see that ignoring an explicit “reject” instruction is a good place to be.

So – option 2 it is then.

How?

This is the bit that is absent from the Mimecast documentation that we were sent for Mimecast implementation with GSuite.

In the GSuite Admin panel:

Apps -> G Suite -> Settings for Gmail -> Advanced settings

You’re looking for the section that says “inbound gateway“.

This is the functionality that is explicitly designed for this situation.

We need to add the Mimecast IP ranges for our region.

Our settings (EU not Germany) are as following. YMMV.

Inbound gateway
Locally applied

Mimecast Europe
Gateway IP(s):�195.130.217.0/24, 91.220.42.0/24, 185.58.84.0/22, 146.101.78.0/24, 207.82.80.0/24
Require Inbound Gateway IP:�No
Require Secure (TLS) Connections:�No
Disable Gmail Spam Filtering:�No

Once set up and applied – this will (as confirmed by GSuite support) stop GSuite panicking about the broken DKIM.

This set up essentially exempts emails that arrive via Mimecast from the DKIM checks. (and presumably SPF as well)

Result:

Senders with strict “reject” DMARC policies can now successfully deliver inbound to GSuite, even though Mimecast breaks their DKIM signed emails. It’ll also help stop GSuite making a poor decision around SPF record checking.

Questions?

email us: support@astaris.co.uk and we’ll be happy to help.

Thanks to:

Rachel Offen who has been driving our GSuite + Mimecast implementation, and that’s despite sometimes feeling that we might be the first people ever to try and get GSuite + Mimecast working.