Oops
Bad SPF can hurt your reputation
Can a bad SPF record ruin your delivery, even though all your mail still passes SPF?
Yes, it can.
One of our clients had issues with poor delivery rates to the inbox at gmail and came to us with the theory that it was due to other people using their domain to send spam to gmail. This theory was based on ReturnPath instrumentation showing mail “from” their domain coming from other IP addresses, and a plausible looking correlation between that mail being sent and their problems at gmail.
Checking their bounce handler, we see a lot of bounces coming in suggesting that someone is sending poor quality mail using their bounce domain from quite a few IP addresses, including a suspicious number scattered in small blocks across 69.64.0.0/8.
Their question they had was whether they should publish DMARC records to fix the problem, and whether they should use a DMARC policy of p=reject or p=none. They’re a good candidate for DMARC – their domains are used purely for bulk or transactional mail, they have a tightly controlled mail infrastructure for their marketing domains, and they’re already publishing SPF records and signing all the mail they send with DKIM.
I was half way through writing up my normal answer about DMARC deployment for customers with this sort of mail infrastructure – “It won’t help with delivery problems directly, but publishing with p=none and analyzing the reports you get back will give you insight into your mail flows, and provide the data you need to decide whether using DMARC p=reject is appropriate for your business model and mail flows.” – when I realized that something just didn’t make sense.
Gmail, perhaps more than most other mailbox providers, base their delivery decisions on data they gather mechanically from all their mailboxes. And they really understand domain-based reputation and the difference between authenticated and non-authenticated email. Why on earth would non-authenticated email from an unrelated IP address be damaging the domain reputation, and hence the delivery of authenticated legitimate email? That makes no sense.
Meanwhile, over in our slack channel, Josh was double-checking their infrastructure…
Oops. They have a small block of 8 IP addresses from which they send most of their email. When setting up their SPF records they inadvertently used ip4:69.20.20.48/8 instead of ip4:69.20.20.48/29 for that block of addresses. A /8 isn’t eight IP addresses – it’s every one of the 16,777,216 IP addresses that begins with “69.”.
Suddenly everything makes sense.
The SPF thinko means that all mail claiming to be from the client domain that’s sent from any IP address beginning with “69.” passes SPF – including the deluge of spam coming from the snowshoe spammers in 69.64.*.
Gmail (and other ISPs) don’t see a difference between the legitimate email and the SPF authenticated spam – they’re just seeing a high volume of authenticated email from the client domain, a large fraction of which is spam. That’s damaged the reputation of the client domain, causing their legitimate email to end up in the spam folder.
(The reality of filtering is more than just domain reputation, of course, but a terrible domain reputation is definitely going to cause you problems.)
The immediate action to take is simple – fix the SPF record so only legitimate mail will be authenticated. That’ll take effect within a couple of hours, as the old SPF record has a short TTL, and ISPs will start seeing the correct SPF record and begin rejigging their reputation.
We’ll keep monitoring delivery rates, check how long ISPs take to notice reputation changes, potentially reach out to some ISPs to see if it’s appropriate for them to do a one-time reputation reset for the affected domains, but we’re hoping things will begin to improve in the next few days.
What can you do to avoid or mitigate this sort of problem?
Mailbox preview and HTML content
I just received a slightly confusing email.
The From address and the Subject line are from Sony, but the content looks like it’s from email analytics firm Litmus. What’s going on here?
Opening the mail it looks like a fairly generic “Oops, we lost a class-action lawsuit, have $2 worth of worthless internet points!” email from Sony; no mention of Litmus at all. My first thought is that Mail.app has managed to scramble it’s summary database and it’s pulling summaries from the wrong email, as I am on a Litmus mailing list or two, but nothing else looks off.
Digging around inside the source of the mail I do find a bunch of tracking gifs from emltrk.com, which is a Litmus domain so there is a Litmus connection there somewhere. Curious.
Finally, about two pages in to the HTML part of the mail I find this:
Brief DBL false positive
A code glitch in a new DBL sub-zone known as 'Abused-Legit' caused the new Abused-Legit zone to list ".net." for 60 minutes from 08:35 UTC.
Read More
Images, again
It’s a new year, but an old problem. Email with unloaded images.
Sure, you should be including critical content as text, and/or including alt-text as a normal part of your creative design process, but at the bare minimum you should look at what your mail looks like without images.
The last thing you want to do is send out email with just one strong call to action – the unsubscribe link.
Know your target audience…
… and the device they’re probably going to read your email on.
@lauter from MailChimp points and laughs at an advertising email from Blackberry-the-company that’s completely unreadable when read on Blackberry-the-device.
That’s really bad marketing on a bunch of different levels.
SpamAssassin Problems
The default SpamAssassin configuration considers any date far in the future to be extremely suspicious, which is pretty reasonable.
However, as @schampeo points out, it also seems to consider any date later than 2009 to be “far in the future”.
That means that until the SpamAssassin folks roll out a fix, and that gets deployed by SpamAssassin users pretty much all email will get an additional 2-3.5 spamminess points. That’s likely to cause a lot of content-based blocking over the next few weeks, until fixed rules are deployed both by SpamAssassin users and by all the various spam filtering appliances that use SpamAssassin rulesets.
(If you’re a SpamAssassin user, add “score FH_DATE_PAST_20XX 0.0” to your local.cf file to disable that rule).
EDIT: Mike has some more background on the bug.
EDIT: Fix it out on the spamassassin homepage.