Gmail Will Use a Strict DMARC Record Beginning in 2016. How Will This Affect Your Email?

Update 6/15/2016: Google has indefinitely postponed it’s move to p=reject for the gmail.com domain. Google will continuously reevaluate the (negative) impact of this change and when they believe the consequences have been reduced to a tolerable level they will proceed with the implementation.

Update 10/03/2023: Google has announced updated plans to implement a restrictive DMARC policy on the gmail.com domain.  In a press release Google has stated they will implement a p=quarantine policy on gmail.com in 2024.  

—

Today Google announced plans to join both Yahoo and AOL and become the third major mailbox provider to implement a relatively new email anti-spoofing technology called DMARC.  DMARC, which stands for Domain-based Message Authentication, Reporting & Conformance, allows domains to instruct mail servers to reject messages using that domain in the From address, if the message did not originate from that domain’s own mail server.  In short, Gmail will soon tell everyone not to accept email messages with @gmail.com addresses if they didn’t originate from Google’s own servers.  You can read the full announcement here.

In April of 2014, Yahoo was the first major service provider to implement such a strict policy, which is also referred to as a “p=reject” DMARC policy.  Yahoo chose to change their policy after persistent attacks on their users lead to large scale user complaints.  While this solved many abuse issues in the short term, it caused a significant volume of valid messages to fail or bounce.  This resulted in a great deal of confusion for anyone using any third party service, like SocketLabs, to send messages on-behalf of their Yahoo email address.  

There wasn’t much surprise when AOL followed in Yahoo’s footsteps implementing a strict DMARC policy after a similar wave of attacks on AOL users by hackers spoofing compromised aol.com addresses.  After these two major providers had implemented DMARC, we figured it was only a matter of time until all the providers followed suit.  Today, Google’s announcement of a DMARC policy on gmail.com further solidifies the more restricted future of the free email systems.  

The good news is that Google has provided a timeline for the DMARC implementation plan.  Unlike the other service providers who issued no warning about DMARC policy changes, Google will make a serious effort to inform their users about these upcoming changes.  The target date for Google’s move to p=reject is June of 2016.

At SocketLabs, our function as an email relay service makes it impossible for us to address the root issue in the message generation process. In most cases, our customers are generating the email message contents including the from address. While we’ve always had a policy against our customers sending messages from a domain they did not own or control, we have made exemptions for specific use-cases.  At this time, SocketLabs cautions against sending any email through our service from any domain that you do not own or control, including but not limited to other major service providers domains like Gmail, Outlook.com, etc.  For anyone who has not already made changes to account for From addresses being protected by DMARC, it will now be more critical than ever.  Google’s Gmail is the single largest provider of mailboxes and the impact to your messages could be substantial.  Suggesting that your users to switch to a provider that does not implement DMARC currently is not a recommended solution.  Here are some common ways to resolve the issue:

Web Forms

If you are sending email messages generated by a web form such as a “share via email” page or “contact us” page, we suggest replacing the from address with a static value at your own domain. Then use the from address form value in the “Reply To:” field. For example here is how the header of a message would look:

From: noreply@YourOwnDomain.[tld]
To: info@YourOwnDomain.[tld]
Reply-to: [email protected]

CRM Platforms

If you are sending email messages generated by a CRM system, we suggest that you provide your users with personalized addresses at your own domain and again utilize the reply-to field for the customers real email address. Here is an example of what the header of a message might look like:

From: PersonalizedPerUserValue@CRMplatform.[tld] 
To: DoesNotChange@anydomain.[tld]
Reply-to: [email protected]

Another option would be to require all users of the CRM platform to utilize an email address at their own domain. This may be difficult for some CRM system users, but it will prevent further issues with from addresses.

Need more help?

Try our free DMARC Generator to ensure that your emails are secure and that you are preventing address spoofing.

If you need more information about how DMARC is affecting the delivery your messages, SocketLabs Email Experts are here to help. Don’t hesitate to reach out to [email protected] for advice on overcoming issues as a result of Google’s new DMARC policy.