DMARC: Please Be Careful!

(Cross posted from Spam Resource.)
Every couple of days, somebody new pops up on the DMARC-Discuss mailing list to ask some question or share an observation. It’s great to see people interested and joining the conversation. Clearly, DMARC interest and adoption are growing. What’s really frustrating, though, is that for about a quarter of the new subscribers, their first mailing list message goes to the spam folder in my Gmail account. It has become sort of an intelligence test I apply to new subscribers — I’ve stopped digging those messages out of the spam folder. I’m figuring that if they can’t figure out how to implement a DMARC record, or they don’t understand that it’s not really compatible with mailing lists nor is it meant for hobbyist domains, then I think perhaps they’ve got some things they’ve got to figure out before they’re ready to join the discussion.
To that end, let me take a moment to jot down some recommendations for folks who are considering implementing DMARC.

  1. Testing and monitoring is very important. When you sign up to DMARC-Discuss, please also create a Gmail account, and subscribe that address to the list as well. If your list messages go to the spam folder, take a look at your DKIM or DMARC settings– my experience is that when this happens, you’ve probably got something set wrong, or your policy/configuration choice is overreaching (and perhaps poorly considered). Keep in mind that you’re making it harder for people to read your posts and respond to them. Not everybody’s going to go to the trouble of whitelisting you or clicking “not spam” every time you post.
  2. Remember that DMARC doesn’t play nice with mailing lists. DMARC is all about preventing misuse of your domain name, and it is very strict, by design. It’s very easy for mailing lists posts from a DMARC-using domain name to fail a DMARC check, because most mailing lists rewrite the return path or make other changes to the message, potentially invalidating a DKIM signature. Some folks would say that DMARC really has no place for usage on a domain with real, live users. That’s open to debate, but certainly, operational complexity increases.
  3. Remember that DMARC wasn’t really intended for use on hobbyist domains. If your domain name only has three valid users, and this includes your wife and dog, then you probably aren’t a valuable phishing target. I see a lot of people struggle to configure DMARC, spending effort on implementing it on domains that just do not need it. (Though I understand the desire to learn by testing it on your own domain name, or a small domain name, before implementing it on some large known-brand domain name you manage.)

It amazes me how many people have never thought of signing up for a Gmail or other account to see how their own messages are being handled by a large ISP. Please, please, please consider doing that.

Related Posts

Gmail shows authentication data to the recipient

Yesterday Gmail rolled out some changes to their interface. One of the changes is that they are now showing end users authentication results in the user screen.
It’s really the next step in email authentication, showing the results to the end user.
So how does Google do this? Google is checking both SPF and DKIM. If mail is authenticated and the authentication matches the from address then they display the email as:
mail from steve to me
If we click on “details” for that message, we find more specific information.
full details of message showing signing domain and spf domainIn this case the mail went through our outgoing mailserver to gmail.
Mailed-by indicates that the message passed SPF and that the IP address is a valid source of mail from wordtothewise.com.
Signed-by shows the domain in the DKIM d=. In this case, we signed with the subdomain dt.wordtothewise.com. That’s what happens when you sign using the domain in the From address (or a subdomain of it).
For a lot of bulk senders, though, their mail is signed using their ESP’s domain instead.  In that case Gmail shows who signed the mail as well as the from address.

And when we click on “details” for that message we see:
3rd party signature detailsThis is an email from a sender using Madmimi as an ESP. Madmimi is handling both the SPF authentication and the DKIM authentication.
As an aside, this particular  sender has a high enough reputation that Gmail is offering me an unsubscribe option in their interface.
Gmail is distinguishing between first party and third party signatures in authentication. If the mail is authenticated, but the authentication appears to be handled by a separate entity, then Gmail is alerting recipients to that fact.
What does this mean for bulk senders?
For senders that are signing with a domain that matches their From: domain, there is no change. Recipients will not see any mention of your ESP in the headers.
However, if you are using an ESP that is signing your mail with a domain they own, then your recipients will see that information displayed in the email interface. If you don’t want this to be displayed by Gmail, then you will need to move to first party signing. Talk to your ESP about this. If they’re unsure of how to manage it, you can point them to DKIM Core for an Email Service Provider.
Gmail blogpost about the changes
Gmail help page about authentication results

Read More

Gmail and the via

I was hoping to have a detailed post up today about the conditions where gmail presents the user with a “via” but time seems to have gotten away from me. But I can give you the conclusions.

Read More

New player in the DMARC space

Over on the DMARC-Discuss list, Comcast announced they had turned on DMARC validation and companies that publish DMARC records should start receiving reports from Comcast.

Read More