Brand indicators in email

laura
Industry
April 10, 2018

A number of companies in the email industry have been working on a way to better identify authenticated emails to users. One proposal is Brand Indicators for Message Identification (BIMI). A couple weeks ago, Agari announced a pilot program with some brands and a number of major consumer mail providers. These logos should be available in the Yahoo interface now and will be rolling out at other providers.

What is it?

BIMI leverages modern email authentication techniques, and DNS to present users with visual indicators in the mailbox that a message is really from the brand it says. During the pilot program, only the brands enrolled in the program will have their logos presented. If the pilot works out, other brands will be able to take advantage of the technology.
In order for a brand logo to be displayed, the brands must authenticate email using DMARC. This is a much higher bar than simply using SPF or DKIM. There’s also a provision in the standard for a 3rd party to verify the logo ownership.

Why do we need it?

I am not sure we need it, but there are a couple reasons to do something like this. The biggest is to use marketers to help drive adoption of DMARC. Implementing DMARC is not trivial. It takes a lot of work inside a company to identify all the mail streams, make sure they’re all properly authenticated and authorized. Even more, there needs to be process to create new streams. It’s a good thing to do, don’t get me wrong, but it’s a non-trivial amount of work.
One of the ideas behind BIMI is if we can get companies to see an actual marketing benefit to authentication we can get them on board with authentication faster. It’s a reasonable idea. BIMI gives free brand impressions in the inbox in return for securing email the way people think it should be secured.

What are the benefits?

I don’t think I can do better than just quoting Agari’s press release on the pilot program
BIMI offers strong benefits to CMOs and marketing organizations, including:

It will provide brands with billions of free brand impressions
It will let brands publish (and thus control) their logos themselves, ending cumbersome manual coordination with internet application providers to update logos
Updates to the brand logo will be picked up automatically by email and mobile app platforms
Different brand logos may be used in email associated with different product lines, specified for different groups of customers or changed seasonally
It has safeguards to prevent impersonation attempts, meaning the brand is shown only when associated with communication that is actually authenticated as being from your business

Where can I learn more about BIMI?

BIMI launches to add trusted logos to emails (from Martech Today)
BrandIndicators has a video on how it works. You can also sign up for the beta here.
Agari’s press release on the BIMI pilot program.
It doesn’t stop with email.

Fun with opinions

Over the last few weeks I’ve seen a couple people get on mailing lists and make pronouncements about email. It’s great to have opinions and it’s great to share them. But they’re always a little bit right… and a little bit wrong.

What to expect in 2016

I don’t always do predictions posts, even though they’re popular. Most years I skip them because I don’t see major changes in the email space. And, I’m not the type to just write a prediction post just to post a prediction.
This year, though, I do see changes for everyone in the email space. Most of them center on finally having to deal with the technical debt that’s been accumulating over the past few years. I see ISPs and ESPs spending a lot of development effort to cope with the ongoing evolution authentication requirements.
When people started seriously looking at how to authenticate email, the first goal was getting organizations to implement the protocols. This was a practical concession; in order for a new protocol to be used it needs to be widely implemented. Phase one of authenticating email was simply about publishing protocols and getting organizations to use them.
During phase one, the organization that authenticated a mail hasn’t been important. In fact, the SPF spec almost guarantees that the ESP domain is the authenticated domain. In DKIM, the spec says any domain could sign as long as they could publish a public key in that domain’s domainkeys record.
ESPs took full advantage of this and lowered their own development overhead by taking most of the authentication responsibility on themselves. Their domains were in the 5321.from and they published the SPF records. Domains they control were in the d= and they generated and published the DKIM keys. Mail was authenticated without ESP customers having to do much.
We’ve hit the end of phase one. Most of the major players in the email space are authenticating outbound email. Many of the major players are checking authentication on the inbound. Phase one was a success.
We’re now entering phase two, and that changes thing. In phase two, SPF and DKIM are used as the foundation for user visible authentication. Neither SPF nor DKIM were designed to be user visible protocols. To understand what they’re authenticating you have to understand SMTP and email. Even now there are days when I begin talking about one of them and have to take a step back and think hard about what is being authenticated. And I use these things every day!
DMARC is the first of these end user visible protocols built on SPF and DKIM. It uses the established and widespread authentication to validate the user visible from address. This authentication requires that the d= value or the 5321.from address belong belong to the same domain in the visible from address. While you can pick whether the alignment between the visible from and the authentication is “strict” or “relaxed” you have no choice about the alignment.
Prior to DMARC no one really paid much attention to the domain doing the authentication. Authentication was a yes or a no question. If the answer was yes, then receivers could use the authenticated domain to build a reputation. But they weren’t really checking much in the way of who was doing the authentication.
In the push to deploy authentication, ESPs assumed the responsibility for authentication deployed ESPs took the responsibility and did most of the work. For many or most customers, authentication was as simple as clicking a checkbox during deployment. Some ESPs do currently let customers authenticate the mail themselves, but there’s enough overhead in getting that deployed that they often charged extra to cover the costs.
DMARC is rapidly becoming an expectation or even a full on requirement for inbox delivery. In order to authenticate with DMARC, the authenticating domain must be in the same domain space as the visible from. If senders want to use their own domain in the visible from, DNS records have to be present in that domain space. Whether it’s a SPF TXT record or a domainkeys record the email sender customer needs to publish the correct information in DNS. Even now, if you try to authenticate with DKIM through google apps, they require you to publish DNS records.
ESPs aren’t in a situation where they can effectively manage authentication alignment for all their customers. Hosting companies are in even worse shape when it comes to letting customers authenticate email. Developers are facing the fact they need to go back and rework their authentication code. Businesses are facing the fact they need to change their processes so customers can authenticate with DMARC.
It’s not just the infrastructure providers that are facing challenges with authentication. Senders are going to discover they can no longer hand authentication off to their ESPs and not worry about it. They’re going to have to get DNS records published by their own staff.
Getting DNS updates through some big companies is sometimes more difficult than it should be. I had one client a few years ago where getting rDNS changed to something non-generic took over a month. From an IT standpoint, changing DNS should require approvals and proper channels. Marketers may find this new process challenging.
And, if organizations want to publish reject policies for their domains, then they will have to publish records for every outside provider they use. Some of those providers can’t support DMARC alignment right now.
In 2016 a lot of companies will discover their current infrastructure can’t cope with modern authentication requirements. A lot of effort, both in terms of product development and software development, will need to be spent to meet current needs. This means a lot of user visible features will be displaced while the technical debt is paid.
These changes will improve the security and safety of email for everyone. It won’t be very user visible, which will give the impression this was a slow year for email development. Don’t let that fool you, this will be a pivotal year in email.

Beware the oversimplification

Setting up a DMARC record is the easy bit. Anyone can publish a record in DNS that will trigger reports to them. The challenge is what to do with those reports and now to manage them.
DMARC is a complex protocol. It builds on two other protocols, each with their own nuances and implementation issues. I’ve written in the past about what DMARC is, what you need to know to decide if you’re ready for DMARC and walking through whether or not you should publish DMARC. I’ve done talks where it’s taken me 20 minutes and dozens of slides to set up the context for explaining DMARC. Even experienced email folks can have moments where we get confused by some of the nuances.
DMARC is not a passive protocol. DMARC is an active protocol. Even with a p=none record, there is ongoing monitoring and work. Why consume reports if you’re not going to monitor them? The reports are there so that senders can monitor their authentication. If you’re not monitoring, then why waste cycles and bandwidth to receive them? Do you even know if your mail aligns? Can your mail server handle emails with attachments larger than 10MB? Does your mail server block .zip files? All of these things can cause your mail to be rejected and you won’t receive reports.
Postmark has a great post on DMARC and even has some examples of reports.
I know, I know, there’s a lot of fear mongering about how any company not publishing DMARC isn’t going to get to the inbox. We’re not there, yet. We likely won’t be there in the next few years. We may never get there. In any case, it’s much better to actually think about what you’re going to do with DMARC Plus, ISPs are already checking for DMARC style alignment even in the absence of a DMARC record. You don’t have to publish DMARC for this to happen, it already does.
I’ve said it before: publishing a DMARC record is a good idea. But every company needs to take minimal steps to figure out if publishing DMARC, even just to receive aggregate reports, is the right thing for them. It’s not right for every company or domain at the moment.