Mailchimp/Office365 DKIM issues

Website, Application, Performance DNS & Network
1

Hi,
I recently spotted poor deliverability on my email so tried updating my DKIM settings within Cloudflare. For reference, I use Mailchimp along w/ Office365 for the domain tradablepatterns.com.

I’ve been confused w/ different recommendations online on what CNAME and TXT records to add.

Relating to Mailchimp, this is what I currently have:

CNAME
k1._domainkey
dkim.mcsv.net

CNAME
k2._domainkey
dkim2.mcsv.net

CNAME
k3._domainkey
dkim3.mcsv.net

Some sites say to just have the k1._domainkey, while others say to have the other 2 instead. Does it hurt to have all 3?

I also have a TXT record (default._domainkey) w/ the following content:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuoL9wubkjWF0zaZx3fwqtziyGgTJbBC3rWF2ElwXAzwuolFyFzOPCD+YnC39P5qX8o6cdHUON+KL1oV9rGS3wcehp72HGFxVEIojqcAk+/gNAyzkQGYKk4OlgYbucN4qZ7VDWK0L+ZX9sHOOIEESdEeaSIYK1+VwmV0LEy/pyylaYiRyViKkID92KljQyI2iVTMzWQjDDXImu7ID99BzqgCZ2GggC1gpBPMQgk3tp0bJX1tRGZB9GbYAdG2QKJWUPiSn6YMfqB3bjYixwtSLEGh5UD3Qs70iYeQiJU2sWowiltmGth5cbNqp/IYlv9ScdFJ3i6rEJ8axghakbeGjOQIDAQAB;

I previously also created 2 separate CNAME entries relating to the sending of emails from Office365, but have also read that Office365 takes care of the DKIM automatically if just using Office365 for sending from 1 domain. Either way, I was never sure what values to include into these 2 Office365 CNAME records.

CNAME
selector1._domainkey
selector1-tradablepatterns-com._domainkey.netorg634545.onmicrosoft.com

CNAME
selector2._domainkey
selector2-tradablepatterns-com._domainkey.netorg634545.onmicrosoft.com

On my SPF, I have:

v=spf1 +ip4:52.44.47.113 +include:spf.protection.outlook.com +include:servers.mcsv.net +include:spfa.mailendo.com ~all

I have servers.mcsv.net for Mailchimp, Outlook for Office365 and mailendo for some other mail sending software.

Does it appear like I’m missing anything or have any conflicts? I have the Grey cloud (DNS only for the CNAME records above).

Thanks in advance!
Darren

4

It could be as simple as that the creator(s) made their tutorial(s) sometime in the past, where Mailchimp maybe only suggested to use the first one alone, or maybe the first two.

It could also be the creator of this site that haven’t done their work properly.

To dig deeper in to the reason to that, you would have to ask the website owner(s).

It doesn’t hurt to have all the three record(s) added, even if Mailchimp chooses to only rotate between e.g. the first two.

DKIM records are technically TXT records, - however, if you added a TXT record on your own domain, and that your provider, e.g. Mailchimp or Microsoft’s Office 365 decided to change (e.g. rotate) the key they sign the messages with, then your TXT record would be rendered useless.

Therefore, you will often see suggestions to add either CNAME or NS records, when dealing with third parties to send messages on your behalf.

The benefit with these, rather than direct TXT records, would be that your provider can take care of the maintenance of the record, without needing your own interference every time they may need to change something.

The ip4: you are listing in your SPF:

If you’re actually sending outbound email messages directly through that IP address, then you have another problem.

The Reverse DNS (PTR) points to whmlogin, and that A record is currently Proxied (:orange:).

If you are sure you are sending directly to third parties through that IP address, I would change the whmlogin A record to Unproxied (:grey:) / DNS-only.

Except from the comments above, it sounds perfectly fine, and without any kind of conflicts.

1 Like
5

Thanks for the quick and detailed response!

Would you also recommend that I remove whatever CNAME records that I had created for the sending out of emails by Office365?

The following URL (
How to use DKIM for email in your custom domain | Microsoft Learn) suggests:

You can choose to do nothing about DKIM for your custom domain too. If you don’t set up DKIM for your custom domain, Microsoft 365 creates a private and public key pair, enables DKIM signing, and then configures the Microsoft 365 default policy for your custom domain.

I previously saw posts explaining sending via Office365 requiring the inputting of selector1._domainkey and selector2._domainkey.

For selector1._domainkey, I have provided a value of:

selector1-tradablepatterns-com._domainkey.netorg634545.onmicrosoft.com

I don’t even think this is right, as this value was based off some examples I previously found online, as opposed to the value produced by the Office365 webpages (which don’t seem able to reproduce this CNAME value).

For selector2._domainkey, I have inputted a value of:

selector2-tradablepatterns-com._domainkey.netorg634545.onmicrosoft.com

Also for Office365, I had created a TXT record ms._domainkey with the following value:

k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCdoJhIiYETjpaEbwodIWZlpeyXwtC4wutu0dnXiFNbjtdaA2L60qcdawdWB+IQ8LqnWYM29m+NccdNhBuzzId1Q34966QtLw3gdqWrcbMzSqjlDZqjvCu1IJ6fJps5tyY3SyUrQWN7qoNk0GnRJiaLiA7z6Gt7Hz90oao7ghOghQIDAQAB

So if I understand you correctly, it’s safe for me to remove this above TXT record?

On the Reverse DNS (PTR), you mentioned it points to whmlogin. I previously created an A record for whmlogin (as this is a subdomain) that should point to the same IP address as for my domain. Should I have created a CNAME for this subdomain as opposed to an A record? I saw some resources/posts saying that subdomains can have either A or CNAME records created for them. What’s the main reason I’d want to use a CNAME instead of an A record for a subdomain?

Thanks again for your patience and feedback in advance!
Darren

6

If you still use Office 365 to send out emails, then no, then I would keep them.

Choosing to do nothing is an option you can take, if you wish.

However, more and more providers are taking further steps to enforce proper domain authentication, which means that it may be less a good idea today, to sit back and do nothing regarding DKIM and SPF, compared to e.g. yesterday, or even last year.

Office 365 does indeed mandate that you use selector1 and selector2.

Some providers let you choose a custom selector, others are very specific, which Office 365 is here.

That one does seem useless, as Office 365 mandates selector1 and selector2.

A quote from the link you shared:

Yes, according to the above quote, “ms” would be useless in regards to Office 365.

So unless that “ms” originates from another provider, that you actively use, then I would remove it.

But the Proxy status is set to Proxied (:orange:), so the public will never see the IP behind it, but an IP address of Cloudflare’s Proxy.

That would be an issue, if you send emails directly to third parties (e.g. MX records) from this IP address.

If as mentioned above, that you are actually sending emails directly to third parties, then don’t use a CNAME. use A with the Proxy status set to Unproxied (:grey:) / DNS-only.

A CNAME is a canonical name, which is asking DNS resolvers to follow from the query they made towards your domain over to e.g. the Office 365 domain in the above example you demonstrated.

It will unfortunately mean multiple DNS lookups (first your domain, then Office 365’s), but it would mean that Office 365 would be able to maintain the contents of the DNS record for you, without you have to interfere in any way.

The benefit of the CNAME in the demonstrated example can therefore be administrative ease.

The consequence would be that the other end would have to spend two (or even more) DNS lookups, when following the CNAME chain, which means extra round trips and overhead, in order to gather the requested information.

If it is some server you’re maintaining on your own, I would normally go for the AAAA (IPv6) and A (IPv4) records directly.

However, when you are dealing with a third party, like e.g. above with Office 365, that has the potential of changing something out of the blue, without you noticing, it could be much more beneficial, to take their suggestion of e.g. CNAME or other ways that follows to something under their administration.

7

Tks for the thorough and prompt feedback! Apologies for my delayed response as I missed the notification of you responding.

I’ve taken your suggestion and deleted the TXT record ms._domainkey. I can’t remember where I had been provided this TXT record to add, and was assuming until recently that ms stood for Microsoft and perhaps was a requirement relating to the sending out of emails via Office365.

I’ve also switched whatever subdomains I had from being A records to being CNAME records.

I now have created 3 A records pointing to my IP address, and have them all proxied as prompted for the A records. 1 A record is for my domain, another is for my hostname (server.tradablepatterns.com), and a 3rd is for my mail server (whmlogin.tradablepatterns.com) as specified in the Mail HELO. Is there some way for me to update my Mail HELO server name from within WHM so that I call it the same as my hostname server.tradablepatterns.com? I added an A record for this current mail server name (whmlogin.tradablepatterns.com) but it appears to still be pointing to some old IP address (w/ a previous web host).

This is the error I get from within WHM on the REVERSE DNS (PTR):

The system sends the domain “whmlogin.tradablepatterns.com” in the SMTP handshake for this domain’s email. “whmlogin.tradablepatterns.com” resolves to “172.67.180.156” and “104.21.51.129”, not “52.44.47.113”.

To fix this problem, create a DNS “A” record for “whmlogin.tradablepatterns.com” whose value is “52.44.47.113”.

I created the above recommended A record about an hour ago but the same REVERSE DNS (PTR) test still reveals the same above error.

On proxying, this link (Proxy status · Cloudflare DNS docs) suggests enabling Cloudflare’s proxy for all A , AAAA , and CNAME records. I have read though somewhere to not proxy CNAME records that relate to the sending of email by 3rd parties (like Mailchimp or Office365). Would you agree to not proxy these Mailchimp or Office365 related CNAME records?

Another question I have relates to my SPF record(s). Should I have 2 separate SPF records - one for my server that sends out emails (i.e. server.tradablepatterns.com), as well as one for just my domain (tradablepatterns.com) for handling email that goes out from Mailchimp and Office365? Or should I somehow combine these 2 SPF records and have them for server.tradablepatterns.com only?

This is the SPF I originally had for tradablepatterns.com:

v=spf1 +ip4:52.44.47.113 +include:spf.protection.outlook.com +include:servers.mcsv.net +include:spfa.mailendo.com ~all

Lastly, in some posts, I see that there’s a plus sign in front of include, and w/ others, they don’t use +.

Thanks again in advance!
Darren

8

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.