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:

  • Reject the submitted mail, passing the problem to the owner of the rejective email address and their ISP’s support staff
  • Use a From: address in a domain the list operator controls instead, making sure the author’s rejective email address is clearly included (perhaps in the “friendly from” comment)
  • Use a From: address in a domain the list operator controls, including the author’s rejective address in the Reply-To: field
  • Use ARC, Authenticated Received Chain. It’s not quite ready for use, yet, but it’s a great time to be developing support for it, and testing it at ARC interoperation days

If you’re an ESP with customers who want to send mail from rejective addresses you have fewer options. Sending from a domain you control, with a Reply-To containing the rejective address is one option. Encouraging your users to use an email provider that isn’t rejective – either by moving mail providers or, for companies and organizations rather than originals, buying their own domain and email service – is another.
Whatever you choose to do as an ESP you should make it as clear as possible in your user interface for user with rejective addresses that their using them may cause issues, and what changes you recommend or will take automatically. Being clear that the issue is due to a policy decision by their ISP rather than any ESP policy or technical limitation might reduce your support overhead.
(If you’re in New Orleans for the EEC conference, say “Hi!” to Laura).

Related Posts

A brief history of TXT Records

txt
When the Domain Name System was designed thirty years ago the concept behind it was pretty simple. It’s mostly just a distributed database that lets you map hostname / query-type pairs to values.
If you want to know the IP address of cnn.com, you look up {cnn.com, A} and get back a couple of IP addresses. If you want to know where to send mail for aol.com users, you look up {aol.com, MX} and you get a set of four hostname / preference pairs back. If you want to know the hostname for the IP address 206.190.36.45 you look up {45.36.190.206.in-addr.arpa, PTR} and get a hostname back.
There’s a well-defined meaning to each of those query types  – A is for IP addresses, MX is for mailservers, PTR is for hostnames – and that was always the intent for how DNS should work.
When DNS was first standardized, though, there was one query type that didn’t really have any semantic meaning:

Read More

February 2016: The Month in Email

Happy March! Here’s a look back at our last month of email adventures.
Feb2016forBlogIt was a busy few weeks for us with the M3AAWG meeting in San Francisco. We saw lots of old friends and met many new people — all in all, a success, despite the M3AAWG plague we both contracted. Hot topics at the conference included DMARC, of course, and I took the opportunity to write up a guide to help you determine if you should publish a DMARC policy.
On the subject of advice and guidance, Ask Laura continues to be a popular column — we’ve had lots of interesting questions, and are always looking for more general questions about email delivery. We can’t tackle specifics about your program in this column (get in touch if we can help you with that directly) but we can help with questions like “Will our ESP kick us off for mailing purchasers?” or “Help! I’m confused about authentication.
Continuing on the authentication front, I noted that Gmail is starting to roll out some UI to indicate authentication status to users. It will be interesting to see if that starts to affect user (or sender) behavior in any way. In other interesting industry news, Microsoft has implemented an Office 365 IP Delisting page. I also wrote a followup post to my 2015 overview of the state of ESPs and purchased lists — it’s worth checking out if this is something your business considers.
I wrote a post about security and backdoors, prompted by both the FBI/Apple controversy and by Kim Zetter’s talk at M3AAWG about Stuxnet. These questions about control and access will only get more complicated as we produce, consume, store, and share more data across more devices.
Speaking of predictions, I also noted my contribution to a great whitepaper from Litmus that explores the state of Email Marketing in 2020.
As always, we looked at some best practices this month. I wrote up some of my thoughts about data hygiene following Mailchimp’s blog post about the value of inactive subscribers. As always, there isn’t one right answer, but there’s a lot of good food for thought. And more food for thought: how best practices are a lot like public health recommendations. As with everything, it comes down to knowing your audience(s) and looking at the relationship(s), which, as you know, is a favorite subject around here.

Read More