Will enabling DKIM for gsuite impact sending emails from 3rd party sender like Mailchimp

dkimemailemail-serverg-suitespamassassin

If I enable DKIM for my gsuite domain (mydomain.com) will it impact mails sent from noreply@mydomain.com via 3rd party senders like Mailchimp/Freshdesk etc?

My understanding is enabling DKIM for emails originating from gsuite, will have no impact on 3rd party senders (Mailchimp/Freshdesk) as these senders won't send a DKIM-Signature header.

I just want to make sure if I enable DKIM for gsuite email, it won't break our emails sent through Mailchimp,Freshdesk etc.

Ex:

Enabling DKIM for gsuite is a DNS TXT record for google._domainkey.mydomain.com

Enabling DKIM for mailchimp is 2nd DNS record (CNAME) k1._domainkey.mydomain.com

If I enable DKIM for gsuite, emails sent from gmail will add a DKIM-Signature header pointing to the google._domainkey record (aka selector). Emails sent from mailchimp using noreply@mydomain.com WONT include the DKIM-Signature header but will still work. To decrease the chance of mailchimp sent emails going to spam, I could Enabling DKIM for mailchimp.

Is this correct?

My current spf records:

mydomain.com.       3600    IN  TXT "v=spf1 include:_spf.google.com -all"
mydomain.com.       3600    IN  TXT "v=spf1 include:servers.mcsv.net ?all"
mydomain.com.       3600    IN  TXT "v=spf1 a include:_spf.google.com ~all"

Best Answer

This should only have an impact if you use DMARC, which I highly recommend (though that's a process. Start it slowly with p=none and only migrate to p=reject once you're confident the aggregated reports don't contain any legitimate mail).

You listed three different SPF records:

mydomain.com.       3600    IN  TXT "v=spf1 include:_spf.google.com -all"
mydomain.com.       3600    IN  TXT "v=spf1 include:servers.mcsv.net ?all"
mydomain.com.       3600    IN  TXT "v=spf1 a include:_spf.google.com ~all"

You can only have one! First, some explanation of SPF qualifiers:

  • … -all – mail from hosts not blessed by this record should be rejected
  • … ?all – mail from hosts not blessed by this record are completely neutral (as if you have no record)
  • … ~all – mail from hosts not blessed by this record should be suspected as spam

There is no purpose to ?all. You might as well not include it. There is no effective difference between -all and ~all, though they were initially intended as "hard fail (block)" and "soft fail (suspect)" respectively. This is because there was no feedback loop, so admins couldn't learn about missing servers. DMARC solves this issue, though DMARC also ignores these three.

DMARC with p=reject says that if neither SPF nor DKIM pass with alignment, reject the message. If your domain sends with valid SPF or DKIM, you will pass DMARC. If your own hosts send with valid SPF (with alignment) and you use DKIM (with alignment) via Mailchimp, you are all set.

Alignment?

DMARC requires "alignment", which means the domain in the From header of the message must match the domain used by SPF or DKIM.

Alignment ensures proper detection of domain forgeries*. If your DKIM-Signature header is signed with d=gmail.com yet your From header says rynop@example.com then that's not aligned. DMARC doesn't know whether gmail.com is allowed to send for example.com based on DMARC (though it could pass if there is an aligned SPF record).

* DMARC only protects against exact domain matches; the DMARC record for gmail.com won't help block a mail whose From header says gmall.com!

Advice

My advice to you is to use SPF and/or DKIM for the hosts you fully control (either is fine so long as you have control of all mail flowing through these hosts) and to use DKIM for hosts you share, such as via Mailchimp. This way, you'll have a reliable way of passing DMARC (which I highly suggest setting up) with minimal risk of an attacker being able to abuse your blessed mail hosts to send mail as you.

Related Topic