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.

Yahoo DMARC articles worth reading
Yahoo Statement on DMARC policy

Related Posts

Problems with Yahoo FBL

There are a couple problems I’ve been alerted to with the Yahoo FBL today.
The first comes from Michael Ellis and is about broken FBL reporting at Yahoo.

Read More

Yahoo now auctioning domain names

This summer Yahoo shook up the email ecosystem by publicly announcing they were recycling usernames. The shakeup wasn’t so much that they were recycling usernames, but that they did it in a way that compromised user information and account security. Any user that had an account tied to a recycled Yahoo account is at risk for having their PII leaked. Folks are still dealing with the fallout, both Yahoo and the companies who are trying to meet customer needs by sending emails and protect customer emails by not sending emails.
On top of that, Yahoo announced they’re selling off a number of domains that they’ve accumulated over the years. Some of these are pretty high value domains like webserver.com, sandwich.com and other real words.
I don’t think Yahoo used any of these domains for email, and even if they did any addresses should have bounced off years ago. Still, it does bring up some broader policy issues.
Many, many things online, from bank accounts to social media accounts to blog commenting systems treat email addresses as a unique identifier for that account. Many of these databases were developed with the underlying assumption that people wouldn’t change their email addresses and that it was a static value. This wasn’t a true assumption 10 years ago and it’s certainly not true now. This mistaken assumption is a problem, and one that more and more companies are going to have to address moving forward. This isn’t about email and it isn’t about delivery, it’s about simple data accuracy and hygiene.
Companies must start thinking and addressing email address impermanence. These issues are not going away.

Read More

Fixing discussion lists to work with new Yahoo policy

Al has some really good advice on how to fix discussion lists to work with the new Yahoo policy.
One thing I would add is the suggestion to actually check dmarc records before assuming policy. This will not only mean you’re not having to rewrite things that don’t need to be rewritten, but it will also mean you won’t be caught flat footed if (when?) other free mail providers start publishing p=reject.

Read More