Overview of Mailchimp’s DKIM Configuration
Mailchimp’s implementation of DomainKeys Identified Mail (DKIM) relies on a shared key architecture, wherein all users are directed to configure DKIM records using selectors k2 and k3, which resolve via CNAME to dkim2.mcsv.net and dkim3.mcsv.net, respectively. The corresponding DNS TXT records for these keys can be queried as follows:
# DKIM record for dkim2.mcsv.net
dig TXT +noadditional +noquestion +nocomments +nocmd +nostats dkim2.mcsv.net. @8.8.8.8
dkim2.mcsv.net. 14400 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv2aC2KjGKLOwTweBY5A9RpjsxaBXR9r7OAU6U8/zn92ivImI75naUujWbItRI/QmL1jy5PWGqLwoUA0b90ObWaLDc+i9MtTNmGeWO009hr20fIxhGg6XBT2kjZ1DTThopSe1nAndsupmcBwlQ5Q6LJ+ZAxLcujnPIxM0ZBLmgpkv8u6RfY4eFP8OLvdAW3oSuB0DyLDigQX4Sj8wBO4YIdQH6AAmBeOsidsKAFNFUCpc3vCxtBDR12U+cBg724l3sBkMQ8evnz6idnqxq9QAVYh8k4kJ+RP+6cqTdy7LjIm8xY/bQNpQIpGUAuDo2DjLcCDun9DAI4Q/3z+Q0o9QuQIDAQAB;"
# DKIM record for dkim3.mcsv.net
dig TXT +noadditional +noquestion +nocomments +nocmd +nostats dkim3.mcsv.net. @8.8.8.8
dkim3.mcsv.net. 14400 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsYGiMSn7fsUqSvfSX40x9R1OlRtbNiCY80lHRIlcKx3XDIR7257aUx+q9CSIARdfTL6KCuLGNFx5g9TgVr6png4ajcieSQGtOehBgxnkDN8aAA5TX0FmFrcefJU0JoxLOF09EKgXxhSSHCk/ekVb0PXSboHXoZ9+EI404F1qhcwXXIgHXTaUthHTut2P6BBZhIXIgvDe/w49GchR7MRJqjNb7neEBbYHbgWuBTvvHCg7Gy6m6n9krYK+ROWq3dVvXy9plAGK3ygM+HtjIiMt7arRGMOF0WgDTz7YdN9BGpt6BvXxLnjiQcgS5T9n+cIyPZgiWzDMXNlaEEdKTEKxrwIDAQAB;"
Log in to Mailchimp. Go to Account -> Settings -> Domains, then click on the Verify Domain
These records point to Mailchimp’s universal public keys, which are paired with private keys stored within Mailchimp’s infrastructure. This centralized approach introduces significant security vulnerabilities, as outlined below.
Systemic Risks of Shared DKIM Keys
Mailchimp’s use of a single set of private keys for all senders creates a critical single point of failure. A compromise of these keys—through mechanisms such as a targeted cyberattack, insider threat, or exploitation of a system vulnerability—would enable an attacker to forge DKIM-signed emails from any domain that has published the k2 or k3 DKIM records. As these selectors are standard for all Mailchimp-authenticated domains, such a breach would have global implications, affecting virtually all Mailchimp users.
Forged emails would pass DKIM verification, as the CNAME records (k2._domainkey.senderdomain.com and k3._domainkey.senderdomain.com) resolve to Mailchimp’s public keys, which are paired with the compromised private keys. This vulnerability could facilitate large-scale phishing, spoofing, or business email compromise (BEC) attacks, undermining the integrity of email authentication across Mailchimp’s user base.
In contrast, a domain-specific key model confines the impact of a breach to a single domain, significantly reducing the attack surface.
Exploiting DKIM Key Compromise for DMARC-Passing Email Delivery
A compromise of Mailchimp’s shared DKIM private keys, would enable an attacker to craft forged emails that pass DMARC verification, massively amplifying the risk of phishing or spoofing attacks. DMARC (Domain-based Message Authentication, Reporting, and Conformance) fundamentally works on an OR basis, not AND. Even with strict alignment (aspf=s and adkim=s), an email only needs to pass either SPF or DKIM with proper alignment to pass DMARC. This would allow a threat actor to deliver convincing phishing emails to recipients’ inboxes, bypassing spam filters and exploiting the trust associated with DKIM and DMARC validation.
Constraints on Sender Key Management
Mailchimp’s architecture does not permit senders to manage or rotate the private keys, as these are exclusively controlled by Mailchimp’s infrastructure. This lack of control precludes adherence to cryptographic best practices, such as periodic key rotation, which is essential for mitigating risks when a key is suspected to be compromised. The absence of sender-initiated key management further exacerbates the vulnerability introduced by the shared key model.
Proposed Mitigation Strategies
To address these deficiencies, Mailchimp could adopt a more robust DKIM implementation, drawing on established practices from platforms like Amazon Simple Email Service (SES). The following recommendations outline a path toward enhanced security:
1. Domain-Specific Key Pairs
SES generates unique public-private key pairs for each verified domain, utilizing randomized selectors (e.g., token1._domainkey.example.com). This approach ensures that a compromise of one domain’s keys does not affect others, isolating potential breaches and minimizing systemic risk.
2. Support for Key Rotation
SES enables users to rotate DKIM keys by generating new key pairs and updating corresponding DNS records. Implementing a similar mechanism would allow Mailchimp users to proactively manage key lifecycles, reducing the window of opportunity for attackers in the event of a suspected compromise.
3. Bring-Your-Own-DKIM (BYODKIM) Option
SES offers advanced users the ability to upload their own RSA key pairs, granting full control over key management while leveraging SES’s signing infrastructure. Mailchimp could introduce a comparable feature, enabling security-conscious users to implement custom key management strategies tailored to their operational needs.
Conclusion
No publicly reported incidents have yet compromised Mailchimp’s shared DKIM keys, and to be fair, the company may employ internal mechanisms for key generation and rotation. However, breaches in 2022 and 2023, involving social engineering attacks that exposed customer data, highlight vulnerabilities in Mailchimp’s infrastructure that could theoretically risk DKIM private key exposure.
The centralized key model poses a significant OpSec risk. Adopting domain-specific keys, key rotation, and a Bring-Your-Own-DKIM option would align with best practices, eliminate this single point of failure, and enhance sender control. Mailchimp should prioritize these improvements, and senders may explore platforms like Amazon SES for robust DKIM implementations.