In 2024 Gmail and Yahoo started to require a DMARC policy for bulk email senders, that is organizations that send a large number of emails to Gmail and Yahoo accounts. You can read more details in our dedicated article.
For now, both providers only require a DMARC record containing a policy of (at least) none
(for example: v=DMARC1; p=none;
). This policy means “take no action” when authentication checks fail, effectively leaving the decision to block non-compliant emails to email providers.
Such a lax policy opens the door to email spoofing and doesn’t help in preventing spammers and phishers from abusing your domain name, so many are wondering if Google or Yahoo are going to enforce a stricter DMARC policy at some point.
Other than none
, there are two other DMARC policies:
quarantine
means move messages that fail authentication checks to the spam folder of the recipient.reject
means reject messages that fail authentication checks at the SMTP level, without delivering them to the destination mailbox.
Are Google or Yahoo going to enforce one of these two stricter polices?
What we know
The answer, for now, is that it’s possible, or even likely, that a stricter policy will become a requirement, but we don’t really know for certain and certainly don’t know when it will happen (remember that it took almost ten years to require a policy of none
).
The most direct hint was given my Marcel Becker, a Yahoo executive, who said, in a webinar:
This is the beginning. A DMARC policy of
none
obviously cannot be the end goal.There’s a reason why we want you to have a DMARC policy, and the first one should be
none
but it doesn’t mean it must benone
. It helps you monitor the traffic, that’s the phase where you’re concentrating on the “R” in DMARC. It stands for reporting, to identify issues in your setup or identify whether somebody might be abusing your domain.
And, most importantly:
The end goal is obviously, ideally a policy of
reject
. That’s what DMARC is for. Ensuring that your domain cannot be spoofed and protecting our mutual customers from abuse. That’s where we are heading.
This means that at least for Yahoo the plan is indeed to have a requirement of p=reject
at some point in the future.
As for Google, I haven’t found similar announcements, but we can assume that the two companies will coordinate future enforcement actions as they did between 2023 and 2024.
Mailgun, the email service provider, published some “2024 email predictions” where they say they think it’s likely that both Gmail and Yahoo will require a stricter policy of reject
by the end of 2024. That hasn’t happened so far though, and it’s unclear on what basis they’re making that hypothesis.
Potential impact
One thing to keep in mind is that a policy of none
is often considered a transient phase for situations where you first want to monitor your setup to ensure that all your sources are compliant, before moving to a stricter policy.
Read Guide to DMARC compliance for more details on this approach.
If Gmail and Yahoo start to require a stricter policy in all situations for bulk senders, it would be harder for new senders to gradually rollout the DMARC policy, as a policy of none
wouldn’t be considered enough by Gmail and Yahoo and would cause emails to go to spam or be rejected.
A stricter policy requirement would also affect organizations that have a simple DMARC record, like v=DMARC1; p=none;
, with no DMARC monitoring in place.
Judging from my analysis of hundreds of domains, this seems to a common situation. Keep in mind that this should be considered a wrong way to solve the problem: the time to start monitoring your DMARC report is now, before a stricter policy becomes a requirement.
To confirm that, Google says:
We recommend you set up DMARC reports so you can monitor email sent from your domain, or appears to have been sent from your domain.
And Yahoo says:
Including a “rua” tag, which is properly set up to receive reports, is strongly recommended to allow monitoring during initial setup.
At DMARCwise, we help you with that: we provide a platform to gain visibility in your email sending configuration, to easily find and fix SPF and DKIM authentication issues, and to enforce stricter DMARC configurations with confidence.
You can learn more about DMARCwise on our website.