A colleague of mine pointed out last night that Outlook.com changed its DNS record from publishing no DMARC policy to publishing a record specifying “p=none; pct=100”.
In DMARC, “p=none” is used to collect feedback and gain visibility into email streams without impacting existing flows.
Earlier this spring, both Aol and Yahoo began publishing “p=reject; pct=100” on some or all of their domains’ DMARC records, causing lots of mail to be rejected at all domains that participate in DMARC – and not just spam. The change caused mail lists to break and inflicted serious deliverability damage on small businesses who’ve relied on Aol or Yahoo for their business needs for years.
Outlook.com hasn’t made any public announcements about when or if they will publish a reject record, but I take yesterday’s change as a clear sign that they’re thinking about it.
Aol announced little more than an hour ago that they’ve published a reject policy in their DMARC record, just as Yahoo did around April 6th. Batten down the hatches; here comes another bounce storm:
Today we moved to change our DMARC policy to p=reject. This helps to protect AOL Mail users’ addresses from unauthorized use.
It also stops delivery on what previously would have been considered authorized mail sent on behalf of AOL Mail users via non-AOL servers. If you’re a bulk sender on behalf of AOL addresses, that probably includes mail sent from you.
I think I’ll hit the sack early tonight. I want to be well-rested for tomorrow. Do I get credit for making the prediction just a few hours ago?
Yahoo’s big change to their DMARC policy has sparked a remarkable amount of debate among stakeholders in the email and security ecosystems. As is usually the case with these crowds, there’s a lot of religion both in support of and against the change. I’m trying to stay out of it, but I’m not sure I’m succeeding.
So, to take a small detour, I thought it might be interesting (or at least somewhat less exasperating) to advance some sort of answer to a related question I’m hearing from both sides: who in the actual heck would use an address from a free inbox provider as the From: address for their own marketing and newsletter mail? Continue reading
It’s going to be a busy Monday for many ESPs and small senders out there today.
Recently, Yahoo Mail appears to have changed its DMARC policy to “p=reject,” meaning that ESP customers who send using a Yahoo email address in the From: line are going to see a spike in hard bounces. In many cases, that will trigger support calls to their ESP’s deliverability teams.
The change doesn’t affect just mail sent to Yahoo, but to any domains that are participating in DMARC. By making the change, Yahoo is essentially instructing any receiving domain that checks Yahoo’s DMARC policy to reject mail that purports to originate from Yahoo’s domain, but that comes from an IP address belonging to someone else.
On a first take, that might sound like a perfectly reasonable security measure. However, lots of mom and pop shops and other small senders who rely on ESPs for their mail programs are using From: addresses (e.g., firstname.lastname@example.org) that are serviced by a free inbox provider, including Yahoo, Gmail, and Aol. It’s not an optimal way of doing things, but there’s nothing inherently abusive about it, either.
I’m hoping that Yahoo will consider reversing the change – and soon! – as it is very likely to result in the inadvertent rejection of a lot of wanted mail. I’ll keep you posted.
Edit: Here are samples of bounces from different large ISPs that you can use to grep your own MTA logs:
smtp;550 5.2.0 mav01n00T5PRKmP0Fav191 Message rejected due to DMARC. Please see http://postmaster.comcast.net/smtp-error-codes.php#DM000001
smtp;550 5.7.1 Unauthenticated email from yahoo.com is not accepted due to domain's DMARC policy. Please contact administrator of yahoo.com domain if this was a legitimate mail. Please visit http://support.google.com/mail/answer/2451690 to learn about DMARC initiative. 100si2781324qgv.4 - gsmtp
smtp;550 5.7.1 DMARC failure for domain yahoo.com, policy reject