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.

Validity Charging for Feedback Loop Emails
When Asking a Question

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

What kind of mail do filters target?

All to often we think of filters as a linear scale. There’s blocking on one end, and there’s an inbox on the other. Every email falls somewhere on that line.
Makes sense, right? Bad mail is blocked, good mail goes to the inbox. The bulk folder exists for mail that’s not bad enough to block, but isn’t good enough to go to the inbox.
Once we get to that model, we can think of filters as just different tolerances for what is bad and good. Using the same model, we can see aggressive filters block more mail and send more mail to bulk, while letting less into the inbox. There are also permissive filters that block very little mail and send most mail to the inbox.
That’s a somewhat useful model, but it doesn’t really capture the full complexity of filters. There isn’t just good mail and bad mail. Mail isn’t simply solicited or unsolicited. Filters take into account any number of factors before deciding what to do with mail.

Read More

Gmail showing authentication results to endusers

A bit of older news, but worth a blog post. Early in August, Gmail announced changes to the inbox on both the web interface and the android client. They will be pushing authentication results into the interface, so end users can see which emails are authenticated.

These are not deliverability changes, the presence or absence of authentication will not affect inbox delivery. And the gmail Gmail support pages clarify that lack of authentication is not a sign that mail is spam.
This isn’t a huge change for most ESPs and most senders. In fact, Gmail has reported more than 95% of their mail is authenticated with either SPF or DKIM. Now, Gmail does a “best guess” SPF – if it looks like an IP should be authorized to send mail for a domain (like the sending IP is the same as the MX) then it’s considered authenticated.
It’s good to see authentication information being passed to the end user.

Read More