Who's publishing DMARC?

DMARC is a way for a domain owner to say “If you see this domain in a From: header and it’s not been sent straight from us, please don’t deliver the mail”. If a domain is only used for bulk and transactional mail, it can mitigate a subset of phishing attacks without causing too many problems for legitimate email.
In other cases, it can cause significant problems. Some of those problems impact discussion lists, but others cause problems for ESPs servicing small companies and individuals. ESP customers use their email addresses in the From: field; if they’re a small customer using the email address provided by their ISP, and that ISP publishes a DMARC record with p=reject, a large chunk of the mail they’re sending will bounce. When that happens recipients will stop getting their email, they’ll be removed from the mailing list due to bounces, and there’s some risk of blocks being raised against the sending IP address.
Because of that, it’s good to be able to see what consumer ISPs are doing with DMARC.
I’ve created a tool at dmarc.wordtothewise.com that regularly checks a list of large consumer ISPs and webmail providers and sees what DMARC records they’re publishing.
There are two main variants of DMARC records.
One is policy “reject” – meaning that mail that isn’t authenticated (or for which authentication has been broken in transit) will likely be rejected.
The other is policy “none” – meaning that the ISP publishing the record doesn’t want recipients to change their delivery decisions, but are asking for feedback about their mailstream, and how much of it fails authentication. That can mean that the ISP is evaluating whether or not to publish p=REJECT, or is in the process of deploying p=REJECT. Or it can just mean that they’re using DMARC to monitor where mail using their domain in the From: address is being sent from. There’s no way to tell which is the case unless they’ve made an announcement about their plans.
Hopefully this will be a useful tool to monitor DMARC deployment by consumer ISPs, and to help diagnose delivery problems that may be caused by DMARC.

Related Posts

Is gmail next?

I’m hearing hints that there are some malware or phishing links being sent out to gmail address books, “from” those gmail addresses. If that is what’s happening then it’s much the same thing as has been happening at Yahoo for a while, and AOL more recently, and that triggered their deployment of DMARC p=reject records.
It’s going to be interesting to see what happens over the next few days.
I’ve not seen any analysis of how the compromises happened at Yahoo and AOL – do they share a server-side (XSS?) security flaw, or is this a client-side compromise that affects many end users, and is just being targeted at freemail providers one at a time?
Does anyone have any technical details that go any deeper than #AOLHacked and #gmailhacked?

Read More

Yahoo Statement on DMARC policy

Yesterday Yahoo posted a statement about their new p=reject policy. Based on this statement I don’t expect Yahoo to be rolling back the policy any time soon. It seems it was incredibly effective at stopping spoofed Yahoo mail.

Read More

Dealing with DMARC for Mail intermediaries

I’ve been getting some mail and calls from folks looking for help on resolving the issue of DMARC bouncing. Some of these calls are from ESPs, but others are from SAAS providers who have users that have signed up with yahoo.com addresses and are now dealing with mail from those users bouncing, even when mail is going back too those users.
None of the solutions are really great, but here are a couple options.
1) Prohibit users users from sending with @yahoo.com header-from addresses. This will be challenging for some companies for all sorts of reasons. I have seen a number of people suggest switching to @hotmail.com or @gmail.com addresses. This only works as long as Gmail and Hotmail/Outlook don’t start publishing p=reject policies. It’s unclear if they’re even considering this at all, but it may happen.
2) Rewrite the header-from address from @yahoo.com to something you control. One thing I’ve been suggesting to customers is set up a specific domain for rewriting, like @yahoo.ESP.com. This domain would need to forward mail back to the @yahoo.com users, which does add another layer of complexity as these addresses will become spam magnets. Thus the forwarding IP should be on a distinct and separate IP, to prevent interference with other systems. Note, too, that any users sending to these reply addresses from a domain protected by DMARC p=reject will bounce.
If you have questions or want to ask specifically about what to do in your setup, I’ve blocked out some time in my schedule next week for companies. If you want more information about this please contact me to for available times, information requirements and pricing.

Read More