Yahoo Mail/Gmail 2024 Easy Sender Compliance Guide: Click here

Finding DMARC when it isn't there?


If you're running a mailing list manager, or dealing with a reply-handling mail system, like many ESPs have in place, you've learned that DMARC adds a number of challenges to this process. To deal with that, you have probably modified your software to watch for any domain that has a p=reject DMARC policy and you special case those, rewriting the from address and perhaps preserving the original sender information elsewhere in the message.

This works great...until it doesn't. I've started to notice that message forwarding can be problematic for some domains that don't actually publish a restrictive DMARC policy. AOL and Yahoo's consumer webmail domains already have a p=reject policy in place, but Microsoft and Google don't have similar restrictions applied to gmail.com and hotmail.com/outlook.com.

But, you might as well start treating them as if they had p=reject, because ISPs practically seem to be doing that already. Mailing list messages from users at those domains fail authentication, and in many cases, end up blocked or diverted to the spam folder, for that authentication failure alone. It almost seems as if Google, in particular, watches for any sort of DMARC policy (even p=none) and treats a message more harshly if authentication or DMARC checks fail, for any of those domains.

So what I've done in my mailing list manager a bit more aware. If a domain has ANY type of DMARC policy in place, it will rewrite the from header, to minimize chances of any issue with delivery of that mailing list message.

I also spent a few minutes today compiling a list of "MAGY" domains. What are MAGY domains, you might ask? I think I got this term from Return Path -- it's shorthand for "Microsoft, AOL, Google, and Yahoo" and is a good way to quickly refer to the top webmail providers. I took that list of corporate and webmail domains for those companies, some of which have p=reject in place, and some do not, and set that up so that I'll just proactively special case mail from those domains, rewriting from addresses as if the domain had a restrictive p=reject DMARC policy, to save myself the headache of wondering how the end hop ISP is going to treat mail from that domain.

So far, my treating any DMARC policy as if it is p=reject is working fine for me. It might not be a good solution for everyone, but it has saved me some troubleshooting. Will it help to add in the MAGY primary domain list and treating all of those domains similarly? Time will tell.

Post a Comment

Comments policy: Al is always right. Kidding, mostly. Be polite, please and thank you.

Previous Post Next Post