New Requirements for Bulk Senders

UPDATE: You need to authenticate with both DKIM and SPF.

Google are circulating a new set of requirements for bulk senders on their blog.

So are Yahoo. It’s almost like postmasters talk to each other or something.

If you dig through the links in the Gmail blog post you can find this summary of what they’ll be requiring from bulk senders by February:

  • Set up SPF or DKIM email authentication for your domain.
  • Ensure that sending domains or IPs have valid forward and reverse DNS records, also referred to as PTR records. Learn more
  • Keep spam rates reported in Postmaster Tools below 0.3%. Learn more
  • Format messages according to the Internet Message Format standard (RFC 5322).
  • Don’t impersonate Gmail From: headers. Gmail will begin using a DMARC quarantine enforcement policy, and impersonating Gmail From: headers might impact your email delivery.
  • If you regularly forward email, including using mailing lists or inbound gateways, add ARC headers to outgoing email. ARC headers indicate the message was forwarded and identify you as the forwarder. Mailing list senders should also add a List-id: header, which specifies the mailing list, to outgoing messages.

And for anyone sending more than about 5,000 emails a day, also:

  • Set up DMARC email authentication for your sending domain. Your DMARC enforcement policy can be set to none. Learn more
  • For direct mail, the domain in the sender’s From: header must be aligned with either the SPF domain or the DKIM domain. This is required to pass DMARC alignment.
  • For subscribed messages, enable one-click unsubscribe with a clearly visible unsubscribe link in the message body. Learn more

These all seem very reasonable. They’re things that have been best practice for a long time, that everyone should be doing (and that I’d have guessed large mailbox providers were soft-enforcing already).

I’ve been chatting with folks on slack, and worked out some clarifications. Google will be publishing DMARC p=quarantine for at least gmail.com and googlemail.com. That means that anyone sending a small business or personal newsletter with their @gmail.com or @yahoo.com email address in the From: header needs to stop doing that pretty sharpish.

The one-click unsubscribe requirements mean that all bulk mail should be using List-Unsubscribe: and List-Unsubscribe-Post: headers to handle in-MUA unsubscription (ideally, anyway, but you can probably get away with just List-Unsubscribe: with a mailto: URL). You should also have a visible unsubscribe link in the body of your message (and that should link to a page that makes it easy for a recipient to unsubscribe from all mail by clicking a big, obvious button). Having a valid List-Unsubscribe-Post requires that your mail be DKIM signed, so that’s another reason not to rely solely on SPF for authentication.

And if you’re not using DMARC yet, it’s time to publish a record with p=none, and start making sure that your authentication is aligned.

These are all good practices, and the large consumer mailbox providers are giving you a nudge towards implementing them. Soon. Make it your New Years Resolution.

Related Posts

Email predictions for 2015

Welcome to a whole new year. It seems the changing of the year brings out people predicting what they think will happen in the coming year. It’s something I’ve indulged in a couple times over my years of blogging, but email is a generally stable technology and it’s kind of boring to predict a new interface or a minor tweak to filters. Of course, many bloggers will go way out on a limb and predict the death of email, but I think that’s been way over done.
ChangeConstant
Even major technical advancements, like authentication protocols and the rise of IPv6, are not usually sudden. They’re discussed and refined through the IETF process. While some of these changes may seem “all of a sudden” to some end users, they’re usually the result of years of work from dedicated volunteers. The internet really doesn’t do flag days.
One major change in 2014, that had significant implications for email as a whole, was a free mail provider abruptly publishing a DMARC p=reject policy. This caused a lot of issues for some small business senders and for many individual users. Mailing list maintainers are still dealing with some of the fallout, and there are ongoing discussions about how best to mitigate the problems DMARC causes non-commercial email.
Still, DMARC as a protocol has been in development for a few years. A number of large brands and commercial organizations were publishing p=reject policies. The big mail providers were implementing DMARC checking, and rejection, on their inbound mail. In fact, this rollout is one of the reasons that the publishing of p=reject was a problem. With the flip of a switch, mail that was once deliverable became undeliverable.
Looking back through any of the 2014 predictions, I don’t think anyone predicted that two major mailbox providers would implement p=reject policies, causing widespread delivery failures across the Internet. I certainly wouldn’t have predicted it, all of my discussions with people about DMARC centered around business using DMARC to protect their brand. No one mentioned ISPs using it to force their customers away from 3rd party services and discussion lists.
I think the only constant in the world of email is change, and most of the time that change isn’t that massive or sudden, 2014 and the DMARC upheaval notwithstanding.
But, still, I have some thoughts on what might happen in the coming year. Mostly more of the same as we’ve seen over the last few years. But there are a couple areas I think we’ll see some progress made.

Read More

June 2014: The month in email

Each month, we like to focus on a core email feature or function and present an overview for people looking to learn more. This month, we addressed authentication with SPF.
We also talked about feedback mechanisms, and the importance for senders to participate in FBL processes.
In our ongoing discussions about spam filters, we took a look at the state of our own inboxes and lamented the challenge spam we get from Spamarrest. We also pointed out a post from Cloudmark where they reiterate much of what we’ve been saying about filters: there’s no secret sauce, just a continuing series of efforts to make sure recipients get only the mail they want and expect to receive. We also looked at a grey area in the realm of wanted and expected mail: role accounts (such as “marketing@companyname.com”) and how ESPs handle them.
As always, getting into the Gmail inbox is a big priority for our clients and other senders. We talked a bit about this here, and a bit more about the ever-changing world of filters here.
On the subject of list management, we wrote about the state of affiliate mailers and the heightened delivery challenges they face getting in the inbox. We got our usual quota of spam, and a call from a marketer who had purchased our names on a list. You can imagine how effective that was for them.
And in a not-at-all-surprising development, spammers have started to employ DMARC workarounds. We highlighted some of the Yahoo-specific issues in a post that raises more questions.
We also saw some things we quite liked in June. In the Best Practices Hall of Fame, we gave props to this privacy policy change notification and to our bank’s ATM receipts.
We also reviewed some interesting new and updated technology in the commercial MTA space, and were happy to share those findings.

Read More

Affiliate marketing overview

Most retailers have realized that sending unsolicited email is bad for their overall deliverability. Still, the idea they can send mail to people who never heard of them is seductive.
Enter affiliate email. That magical place where companies hire an agency, or a contractor, or some other third party to send email advertising their new product. Their mail and company reputation is protected because they aren’t sending the messages. Even better, affiliates assure their customers that the mail is opt-in. I’m sure some of them even believe it.
The reality is a little different from what affiliates and their customers want to believe.

Read More