We use Mailchimp for sending email campaigns. Our SPF record is below (omitting some other “includes”):
v=spf1 includes:servers.mcsv.net ~all
The only thing in there that doesn’t match Mailchimp’s recommended SPF setup is that we use ~all instead of ?all. In our dashboard I see this explanation for why Mailchimp is failing SPF:
SPF is not possible as MailChimp uses their own domain in the bounce address.
I chatted with a support rep at Mailchimp this morning and he confirmed that this is the case and that they don’t have a workaround at this time.
Does anyone have any suggestions about what to do in this case? I’d like to tighten our DMARC policies, but I’m worried that doing so will cause our Mailchimp marketing campaigns to start being rejected.
ESPs like MailChimp often make use of their own addresses in the mail-from (from which the domain is used for SPF authentication) in order to do things like processing bouncebacks, rejections, and probably some other returned-mail situations for your campaign. For the most part you probably want them to do this, so you must rely on the other DMARC authentication leg to be able to pass DMARC: DKIM.
In taking this approach, your raw SPF cannot fail - the domain in use for SPF authentication is not yours. The raw SPF result will be a ‘pass’ against servers defined by the SPF record at the servers.mcsv.net location. DMARC-SPF will fail due to misalignment (the SPF auth domain does not match the From: header domain), but as long as you set up DKIM then the traffic will pass on that basis (DMARC-DKIM). Check your dmarcian account to make sure that DMARC reporting shows your MailChimp traffic is completely passing DMARC on the basis of DKIM.
With that set up, the only situation under which messages from the campaign would fail DMARC should be when the target account improperly forwards the message. I suppose you’ll need to assess your target audience to determine the risk there. Once at reject, I expect that 1 campaign would show you the impact on metrics.
A further note on SPF with MailChimp: since they do not use your domain in the MailFrom of messages they send, their entry in your SPF record is completely useless to authenticate SPF. It’s an illegitimate use of SPF. They ask that you put it there to authenticate your use of the domain with them, and some setup cases such as configuration of DKIM on their platform. Check with them, but I believe that once you have those items done, you can remove the entry and save yourself the SPF lookups.
Thanks for clarifying all of that. I’ll ask them for clarification on adding that SPF entry and if it’s still needed after authentication. If these emails will continue to pass DMARC, then I’ll feel a lot better about tightening things up. I would feel even better though if Mailchimp would allow adding a custom Return-Path. But I guess we’ll see what the future holds.
@Tomki I’d like to ask a related question, since I’m not an expert in mail sending (I know enough to get me by when sending email from a web application). Is the “MailFrom” set automatically by the sending web server and unable to be adjusted, or is it set when the Return-Path header is set? I’m asking in case Mailchimp adds a custom Return-Path feature in the future. Would such a feature matter if the MailFrom itself is what’s causing the misalignment rather than the Return-Path header (assuming one doesn’t cause the other to be changed)?
Verifying that Mailchimp says the SPF entry shouldn’t matter after custom domain authentication in our account is complete, for the same reason you gave.
Am I correct in assuming that ESPs can achieve DMARC-SPF alignment pass by requiring a CNAME record pointing to the ESP’s servers (e.g. whatever. customer. net CNAME bounce. ESP .com) instead of asking for a SPF include?
The ESP can then set a return-path like customer.ID[@]whatever.customer.net, and still be able to handle bounces. SPF will be checked against the record at whatever. customer. net (which is controlled by the ESP at bounce. ESP .com, and separate from yet aligned with SPF at customer. net).
We have the SPF issue with them, but it was fine because DKIM was working correctly.
Apparently somethings changed and they haven’t been DKIM signing correctly with their mcsignup.com servers. Many of our confirmation emails for signup are being rejected because of that. Their helpdesk doesn’t appear to understand that.
Thanks for mentioning that. Looking at our dashboard, the DKIM DMARC field says “fail-unaligned”, but the DKIM RAW field says “pass”. @smirza, your emails are being outright rejected because of that?
@Tomki, do you have anything to add to that? Is DKIM RAW a “pass” because they’re at least signing with a DKIM key, even if they’re not using the one they assigned us when we went through their domain authentication steps?
Yeah, all the ones that “fail-unaligned” were dropped. We got so many emails from people saying they never got the confirmation emails. One person even showed the us an entry on their systems that the message was blocked due to DMARC. Not good on MailChimp’s part. Why are some being signed using our domain and others are not, especially when the messages are coming from the same servers.
Yes, “DKIM raw” pass means that there is a passing signature which used the domain indicated in the “DKIM d=” column. The DKIM d= is reported in DMARC XML as the dkim domain, comes from the message header DKIM-Signature d= tag, and is the domain of the DKIM key which was used to generate that specific signature. If that domain does not match up with the From: header of the message, that is an alignment failure.
To note, and continue that thought: correct DMARC parsers do check for multiple DKIM-Signature headers, and for all found list them (I’ve seen up to 10) in the XML report. If one passes and also matches alignment, then your DMARC-DKIM leg is successful.
The Detail Viewer “DKIM DMARC” column exists in RUA XML as the policy_evaluated - dkim level, and actually only has legal entries of ‘pass’ or ‘fail’. Anything else which appears in the column is a dmarcian assessment added to hopefully help with viewer understanding, e.g. if the DKIM-raw passed and actual DMARC-DKIM is ‘pass’, it’s a nice green ‘aligned’ instead of simply ‘pass’.
