Geeky MTA post alert!
I use MailChimp for my email marketing campaigns. The system is very easy to use but also extremely powerful. When I send a campaign I get a few bounce reports. This is to be completely expected. But in the case I am going to talk about this particular list contains mostly paying customers. Therefore I like to take a closer look in to why some of the emails have bounced.
Bounce Reports
Most of the bounces are easily explained and to be expected on mailing lists. Common causes are the person has left the company, the mail server was having issues (soft bounces) or the company has changed domains and not set-up any aliasing.
However I came across some interesting bounce notifications that deserve further investigation.
SMTP error from remote mail server after RCPT TO:<xxx@xxx>: host ra-don.ru [96.30.9.151]: 550 SPF: 204.197.240.55 is not allowed to send mail from mcsv186.net
Final-Recipient: rfc822; [email protected]
Original-Recipient: rfc822;xxx@xxx
Action: failed
Status: 5.0.0
Remote-MTA: dns; mail.suomicom.fi
Diagnostic-Code: smtp; 550 79.134.108.205 is not allowed to send mail from mcsv21.net
Now the MTA techies among you can probably see from the bounce notifications what has caused the problem. But the really clever MTA techies will see what really caused the problem from the second bounce notification (hence why I only obscured part of the email address).
SPF Checking
Basically in both of these cases the email has been rejected because the sending IP failed SPF checking. So the answer must be that MailChimp has not correctly configured their SPF record. Oh my god what! MailChimp have misconfigered SPF! Well actually if you follow the guidelines of SPF they haven’t. But I think they can improve deliverability even further with a simple change.
First let’s analyse one of the emails. I will take this one as it is a little easier to explain
Final-Recipient: rfc822; [email protected]
Original-Recipient: rfc822;xxx@xxx
Action: failed
Status: 5.0.0
Remote-MTA: dns; mail.suomicom.fi
Diagnostic-Code: smtp; 550 79.134.108.205 is not allowed to send mail from mcsv21.net
We can see from this that the mail has been rejected because 79.134.108.205 is not allowed to send mail from mcsv21.net (the domain used by MailChimp). Indeed if I check the SPF string
“v=spf1 mx ptr ip4:69.20.41.82 mx:mcsv21.net include:spf.trusted-forwarder.org include:servers.mcsv.net -all”
on www.dnsstuff.com (a favourite site of mine!) the result comes back as FAIL.
But this does not mean MailChimp is sending mail from an incorrect IP.
What we need to do is check the email header a little closer.
Received: by flow.magnic.com (Postfix) id BEF0F9578029; Tue, 15 Feb 2011 17:07:54 +0200 (EET)
Delivered-To: xxx@xxx
Received: from mcsv21.net (mcsv21.net [69.20.41.82])
by flow.magnic.com (Postfix) with ESMTP id AAB659578028
for <xxx@xxx>; Tue, 15 Feb 2011 17:07:51 +0200 (EET)
This header shows us that mscv21.net (the MailChimp MTA delivered the email to flow.magnic.com MTA. Now it is not possible to see what flow.magnic.com did with the email becuase that header has not been included. However from the original bounce message we can see something interesting about the final recipient
Final-Recipient: rfc822; [email protected]
Original-Recipient: rfc822;xxx@xxx
The final recipient was not the person who was originally sent the email. Therefore flow.magnic.com has forwarded the email on to the [email protected] address. Guess what the IP for flow.magnic.com is? – 79.134.108.205 the IP that failed the SPF checks. Hallelujah!
Badly Configured MTA Forwarders
So what we have here is a badly configured MTA forwarder. The recipient should have either disabled SPF checks on the receiving server (not really possible since it is Gmail) or implemented SRS: Sender Rewriting Scheme on the forwarding MTA to maintain the SPF validation (which is what MailChimp does when it first sends your campaign to validate SPF against their domain rather than yours).
Improving Deliverability with ?all
So MailChimp have not really done anything wrong. However there is a way they could improve deliverability. I have spent many years running MTA’s as a hosting provider and found what I believe to be the best and easiest solution. Use ?all instead of -all in the SPF string.
-all means if the IP does not match our SPF string then the message is not legitimate and the response is FAIL. In this case many MTA’s reject the message.
?all means if the IP does not match our string then treat the message as NEUTRAL. Basically pretend it did not have any SPF string. This has the advantage of passing when the IP matches therefore improving deliverability but not causing any issues if the receiving MTA is badly configured.
For more details see SPF Record Syntax
In fact the only time I ever use -all is on domains where no mail will ever be sent.
So in summary my advice when creating your SPF string use ?all instead of -all.