Mailchimp SPF record: what it does, and what it does not

If you take one thing from this: for Mailchimp, the record that matters is the DKIM CNAME, not an SPF include. Mailchimp sends with its own bounce domain in the envelope, so SPF is evaluated against *Mailchimp's* domain, and your SPF record is not consulted for alignment at all. DMARC passes because Mailchimp signs with a key published under your domain.

The record that does the work

Mailchimp's domain authentication is CNAME-based. In your DNS:

Take the exact host and target from Mailchimp's *Website → Domains* (or sending-domain) screen, because the selector can differ between products and accounts — Mandrill, for example, uses different selector names. The CNAME approach means Mailchimp rotates the underlying key for you; you never touch the public key yourself.

Verify it resolves through the CNAME to a real key:

dig +short CNAME k1._domainkey.yourdomain.com
dig +short TXT k1._domainkey.yourdomain.com

The second command should return a v=DKIM1; k=rsa; p=... value even though you published a CNAME — that is the chase working. If it returns nothing, the CNAME is wrong, missing, or your DNS host has appended your domain to the host field twice.

Where SPF does and does not matter

Mailchimp has historically documented include:servers.mcsv.net. Before you add it, look at an actual delivered message:

Return-Path: <bounce-mc.us1_...@mail123.suw14.mcsv.net>
Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=mail123.suw14.mcsv.net;
  dkim=pass header.i=@yourdomain.com;
  dmarc=pass header.from=yourdomain.com

Read that carefully. SPF passed — for mcsv.net, not for your domain. That pass does not align with your From domain, so it contributes nothing to DMARC. The dkim=pass header.i=@yourdomain.com line is the entire reason DMARC passed. Adding an include to your own SPF record changes neither line.

So the include is not harmful in principle, but it is not free either: SPF allows a maximum of 10 DNS-querying mechanisms per evaluation, and exceeding that returns PermError, which means SPF fails for *all* your mail, including the mail that needs it. If your SPF record is already crowded with a mailbox provider, a transactional service and a helpdesk, spending a lookup on an include that does not align is a bad trade.

Five things people believe about this that are wrong

"An SPF record for Mailchimp guarantees delivery." SPF is an authorisation check. It says a server may use a domain. It says nothing about content, list quality, complaint rates or whether anyone wants your mail. Passing all three authentication checks is the entry requirement, not the outcome.

"Set it once and forget it." Providers change infrastructure, services get retired, and the record you wrote three years ago may now contain an include that resolves to nothing — which counts against SPF's limit of two void lookups. Audit the record whenever you add or drop a sending tool.

"Only large senders need this." Google and Yahoo's February 2024 requirements apply to bulk senders, but DMARC enforcement at receivers applies to everyone, and spoofing a small domain is easier than spoofing a large one precisely because small domains skip this.

"Authentication makes you immune to spam filters." Filters weigh reputation, engagement, URL reputation and content. Authentication only establishes who you are, so that reputation can be attached to you at all. It is the prerequisite for building reputation, not a substitute.

"SPF is all the authentication I need." SPF breaks on forwarding — the forwarding server is not in your record — while DKIM survives it. DMARC needs at least one aligned pass. For hosted platforms, that pass is nearly always DKIM.

SPF qualifiers, since you are editing the record anyway

Each mechanism carries a qualifier that tells the receiver what to do on a match:

v=spf1 include:_spf.google.com ~all is a sensible production record. v=spf1 +all is an open invitation and some receivers treat it as a spam signal on its own.

The setup, in order

1. Add the DKIM CNAME from Mailchimp's dashboard and wait for the dashboard to confirm authentication.
2. Send a campaign to a test mailbox on Gmail and one on Outlook. Read Authentication-Results in both.
3. Confirm dkim=pass with header.i=@yourdomain.com.
4. Only then decide whether your SPF record needs touching at all.
5. Publish or review DMARC: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1, and tighten later.

What not to do

• Do not create a second v=spf1 record. Two SPF records produce PermError and disable SPF.
• Do not add every provider's include "just in case". Count your lookups.
• Do not use a free-mail From address such as a gmail.com or yahoo.com address for campaigns. Those domains publish p=reject, and your mail will be rejected by DMARC-enforcing receivers no matter how clean your own DNS is.
• Do not delete the CNAME when you pause your account. Re-authenticating later is slower than leaving it.

MailPilot checks SPF, DKIM and DMARC on your sending domain and measures real inbox placement per provider with a seed-inbox network, which is the part a DNS checker cannot tell you: whether a correctly authenticated campaign is actually landing in the inbox.