Are you ready for DMARC?

secure_email_blogThe next step in email authentication is DMARC. I wrote a Brief DMARC primer a few years ago to help clear up some of the questions about DMARC and alignment. But I didn’t talk much about where DMARC was going. Part of the reason was I didn’t know where things were going and too much was unclear to even speculate.
We’re almost 2 years down the line from the security issues that prompted Yahoo to turn on p=reject in their DMARC record. This broke a lot of common uses of email. A lot of the damage created by this has been mitigated and efforts to fix it continue. There’s even an IETF draft looking at ways to transfer authentication through mailing lists and third parties.
For 2016, DMARC alignment is going to be a major factor in deliverability for bulk email, even in the absence of a published DMARC record.

What’s DMARC alignment?

DMARC alignment is where either the Return Path (5321.From, Envelope From, Bounce String) or the DKIM d= value is in the same domain space as the visible from address (5322.From, sender).

Why do you think so?

I’m already seeing some delivery issues for certain domains that are unaligned, particularly at ISPs like AOL and Yahoo.

What do I do?

If you’re an ESP customer, ask your ESP about using a custom bounce string / return path so your domain aligns. You just need to add a MX record for that domain that points to the ESPs bounce handler.
If you’re an ESP customer and can’t add a MX, ask them about signing your mail with a custom DKIM key that is at your domain. You will need to do a little DNS work – either publishing your public key yourself or publishing a DNS record that points to their public key server.
If you’re an ESP, and you can’t sign with custom keys or handle custom 5321.From addresses, you need to look at your development path and figure out how fast you can do either.

I’m not publishing DMARC, so this doesn’t affect me.

ISPs are already evaluating DMARC alignment on all incoming mail.
dmarc=pass (aol.com: the domain example.com reports that SPF aligns in relaxed mode, DKIM is unaligned.) header.from=test.example.com;
It’s a short step to use that as part of their delivery decisions, particularly when there is no alignment.

My unaligned mail is delivering just fine.

I’m sure it is. I also don’t think that’s a given for the future. I think it’s wise to be looking to have as much of your mail as possible aligned sooner rather than later. 

What do you think about these hot button issues?
Holiday season

Related Posts

DMARC=BestGuessPass

Looking at the headers within the mail received with my Office365 domain I see dmarc=bestguesspass.  BestGuessPass?  That’s a new.
Authentication Results
A few days after seeing dmarc=bestguesspass, Terry Zink at Microsoft posted an explanation. Exchange Online Protection, the filtering system for Office365, is analyzing the authentication of incoming emails and if the domain is not publishing a DMARC record, EOP attempts to determine what the results would be if they did.  If an email is received that is not authenticated with either SPF or DKIM, the dmarc= results show none just as it always had.  DMARC=BestGuessPass will appear if the message is authenticated and the matching authenticated domain does not have a DMARC record.
Having this information is helpful to see what the results would be before setting up a DMARC record. If you are seeing dmarc=bestguesspass when your mail is sent to an Office365 address and you are considering DMARC, the next step would be to publish a p=none DMARC policy and begin to document where your mail is being sent from.  P=none will not have an impact on your delivery and asks the receiving mail server to take no action if a DMARC check fails.  Once you have setup SPF and DKIM for your mail, p=none policy gives you the ability to begin receiving failure reports from receiving mail servers when unauthenticated mail is sent from your domain.

Read More

September 2014: The Month in Email

September was another busy month for us, but Steve stepped up and wrote a number of really interesting posts on email history, cryptography, and current technical issues in the email landscape.
We started the month with a look at the various RFCs that served as the technical specifications for developing message transfer protocols in the 1970s. It’s really fascinating to look at the evolution of these tools we use every day 40 years later. We followed up with a second post on the origins of network email, which is a great primer (or refresher) on the early days of email.
Steve’s four-part series on cryptography and email started with an in-depth look at how the industry is evolving with respect to encryption and privacy issues. He then introduced us to Alice and Bob (or reintroduced those of us who have been following the adventures of the first couple of cryptography), and described symmetric-key and public-key encryption. His next post described message signing, and how DKIM is used to manage this. He finished up the series with a post on PGP keys.
In industry news: Spamcop is shutting down its email service. There shouldn’t be any major impact on senders, but the post has some specific notes on DMARC implications. We also noted an interesting mail routing suggestion on Twitter, and wrote a post on using Mail.app for this.
In other DMARC news, we wrote about DMARC and report size limits, which might be useful information, depending on your configuration. We also launched a new DMARC tool to help senders understand who is publishing DMARC. Let us know what you think and if you’re finding it useful.
We couldn’t let a month go by without mentioning filters. We looked at a sector we don’t usually discuss, corporate filtering, and went in-depth on a much-misunderstood topic, content filtering.
Finally, Laura offered a webinar on a favorite topic, deliverability, in conjunction with the AMA and Message Systems. If you missed it, you can watch the recorded version here, or just take a peek at some of the reaction via Twitter.

Read More

Peeple, Security and why hiding reviews doesn't matter

There’s been a lot of discussion about the Peeple app, which lets random individuals provide reviews of other people. The founders of the company seem to believe that no one is ever mean on the Internet and that all reviews are accurate. They’ve tried to assure us that no negative reviews will be published for unregistered users. They’re almost charming in their naivety, and it might be funny if this wasn’t so serious.
The app is an invitation to online abuse and harassment. And based on the public comments I’ve seen from the founders they have no idea what kind of pain their app is going to cause. They just don’t seem to have any idea of the amount of abuse that happens on the Internet. We work with and provide tools to abuse and security desks. The amount of stuff that happens as just background online is pretty bad. Even worse are the attacks that end up driving people, usually women, into hiding.
The Peeple solution to negative reviews is two fold.

Read More