More on ARC

ARC – Authenticated Received Chain – is a way for email forwarders to mitigate the problems caused by users sending mail from domains with DMARC p=reject.
It allows a forwarder to record the DKIM authentication as they receive a mail, then “tunnel” that authentication on to the final recipient. If the final recipient trusts the forwarder, then they can also trust the tunneled DKIM authentication, and allow the mail to be delivered despite the DMARC p=reject published by the sending domain.
The specification and interoperability testing are progressing nicely and it’s definitely going to be useful for discussion list operators and vanity forwarders soon. It’s not something that’s as likely to help ESPs targeting small organizations and individuals, so all y’all shouldn’t be holding your breath for that.
There’s a more information about it at arc-spec.org and they’ve just published a great presentation with a technical overview of how it works:

(If the embedded presentation above is blank, try reloading the page or read it directly on slideshare.)

Related Posts

Ask Laura: Can you help me understand no auth / no entry?

AskLaura_Heading3
Dear Laura,
I’m a little confused by the term “no auth / no entry”. Gmail and other major receivers seem to be moving towards requiring authentication before they’ll even consider delivery.
Does this just mean SPF and DKIM, or does this mean the much more stringent DMARC, as well?
Thanks,
No Shirt, No Shoes, No What Now?

Read More

December 2015: The month in email

Happy 2016! We enjoyed a bit of a break over the holidays and hope you did too. Here’s our December wrap up – look for a year-end post later this week, as well as our predictions for the year ahead. I got a bit of a head start on those predictions in my post at the beginning of December on email security and other important issues that I think will dominate the email landscape in 2016.
DMARC will continue to be a big story in 2016, and we’re starting to see more emphasis on DMARC alignment as a significant component of delivery decisions. I wrote a bit more on delivery decisions and delivery improvement here.
December in the world of email is all about the holidays, and this year was no exception. We saw the usual mix of retailers creating thoughtful experiences (a nice unsubscribe workflow) and demonstrating not-so-great practices (purchased list fails). We took a deeper look at the impacts and hidden costs of list purchasing – as much as companies want to expand their reach, purchased lists rarely offer real ROI. And on the unsubscribe front, if you missed our discussion and update on unroll.me unsubs, you may want to take a look.
Steve wrote a detailed post looking at what happens when you click on a link, and how you can investigate the path of a clickthrough in a message, which is useful when you’re trying to prevent phishing, fraud, and other spam. In other malicious email news, the CRTC served its first ever warrant as part of an international botnet takedown.
In other industry news, some new information for both ESPs and recipients interested in feedback loops and a somewhat humorous look at the hot-button issues that divide our ranks in the world of email marketing. Please share any we may have missed, or any other topics you’d like us to address.

Read More

DMARC p=reject

Mail.ru is switching to p=reject.
This means that you should special-case mail.ru wherever …
Actually, no. Time to change that script.
If you operate an ESP or develop mailing list software you should be checking whether the email address that is being used in the From: address of email you’re sending is in a domain that’s publishing p=reject (is a “rejective” email address) automatically. And you should probably do that in real time, whenever you need that piece of information, relying on DNS caching to reduce the network latency.
If you find you’re about to send an email From a rejective email address, you probably shouldn’t send it. Depending on how the recipients’ ISPs handle it, it might be discarded put in the bulk folder or rejected – potentially leading to recipients being unsubscribed.
If you’re writing mailing list software, ideally you should provide your users with several options for handling submissions from rejective email addresses, perhaps some from this list:

Read More