Warning: DNS\/Email nerdery below.<\/p>\n
For my sins, one of the things I had to do recently was complete DNS domain authentication, DKIM, and DMARC for some email domains at work in Mailchimp. Mailchimp is the spamming engine<\/strike> mass email system of choice, and to be fair, they’re responsible and force compliance with good practice. They also try to increase the chances of your spam<\/strike> legitimate mass email being deliverable, which is where this comes in.<\/p>\n
The big email providers such as Yahoo, Hotmail\/Outlook, and Gmail now insist<\/a> that if you send over a certain threshold, you:<\/p>\n * Send from a domain you own This is all part of the spam arms race: electronic means to detect spam are less effective, so this is an attempt to stop the problem at source by making sure the email is coming from where it claims to: spoofing email is trivial, so this effectively adds a signature.<\/p>\n Well, we already had the domain, and SPF, we don’t actually<\/em> spam people, and Mailchimp handles the unsubscribe, so that left DKIM and DMARC. This actually isn’t that hard, just involving publishing a few records in DNS that match up with the email servers. The DMARC is little more than a published policy of what people should do if the mail seems to be unathenticated- and “take no action” is acceptable. The actual authentication is done by DKIM, where you publish a public key in DNS, and the email is signed by your outgoing server with a corresponding private key. If the encryption key matches, the mail is deemed as being legitimate.<\/p>\n So, I went ahead and did all this for our own infrastructure, as it seems silly to set it all up only for the mass mailing. Pretty simple, too, in the end.<\/p>\n Now, obviously, if someone (Mailchimp) is sending mail for you, you need to publish their<\/em> key for DKIM. The logical way to do this is for them to publish it, and then for you to alias an entry in your DNS (with what is called a CNAME record). That way, if they change the key, it keeps working without changes to your DNS. Here’s where the problem came in: I created the CNAME aliases as instructed, but it failed to verify, repeatedly. Mailchimp support were less than helpful, suggesting the records weren’t propagating (they were, and I proved it), but what they didn’t know (and I didn’t realise for a while) was that our DNS provider had something called CNAME flattening<\/a>. This is a feature that speeds up a CNAME lookup- which usually involves a referral to another server by definition- by taking the record, caching it, and returning the data directly in a single step, as if the alias wasn’t there. <\/p>\n Sadly, Mailchimp doesn’t like this. The data may be correct, but it wants a CNAME and nothing else. If it sees what looks like a TXT record- even if you didn’t enter a TXT record, and the CNAME alias points to a TXT record- it bombs.<\/p>\n People wonder why I don’t like new features that mess with long-established tech! A more normal, less featured DNS would simply not entertain such frivolity, and it would have worked first time. Admittedly, they also woudn’t have the DDOS protection etc as well, though.<\/p>\n The TLDR: turn off CNAME flattening for records below the root<\/a> if you want Mailchimp domain authentication to work. Happy Spamming!<\/p>\n","protected":false},"excerpt":{"rendered":" Warning: DNS\/Email nerdery below. For my sins, one of the things I had to do recently was complete DNS domain authentication, DKIM, and DMARC for some email domains at work in Mailchimp. Mailchimp is the spamming engine mass email system of choice, and to be fair, they’re responsible and force compliance with good practice. They … Continue reading Flat Out<\/span>
\n* Configure DKIM, SPF, and DMARC
\n* Don’t send shitloads of actual spam
\n* include a one-click unsubscribe<\/p>\n
\n<\/p>\n