Gmail DMARC Update 2017
Posted 11th December 2016 at 01:27 PM by sendizo
If youve been keeping up with news in the email world, youve probably heard some of the chatter around Gmails upcoming DMARC changes. For most senders, this change will have little or no impact on their day to day sending. For others, it will require a little effort to avoid serious interruption. Either way, its worth understanding exactly what changes are being made and what the implications are for the email ecosystem.
Side Note: If DMARC is still a foreign concept to you, you arent alone.
What is Gmail changing?
In early 2017, Gmail will change its DMARC policy from p=none to p=reject. This means any message sent using gmail.com in the from address, will have to originate from Gmails infrastructure.
What does this mean for me?
It depends. If you have any mail streams that send messages using gmail.com in the from address, you will have to make changes before June, or risk having those messages filtered or blocked outright.
If you only send email using your own domain or another domain that you control, you have nothing to worry about. However, its not uncommon for some applications or websites to send messages using their users email addresses. For example, if a user wants to send a message to their friend using your platform, it could make sense to send the message using their personal email address. If their email address happens to be a gmail.com address, this message will no longer deliver once these changes take place. A good alternative to sending mail from your users email address is to use their name in the friendly from. A friendly from is when you use a name to appear as the from address, instead of the email address itself:
exampleuser@yahoo.com can be sent as Example User <message@yourdomain.com>
This way your recipients still recognize the individual that sent the message, and youre no longer at risk of violating Gmails DMARC policy.
Action plan
Sending mail from an external domain, like gmail.com, is more common than you might think. Carefully audit all of your mail streams to ensure you arent using gmail.com in your from addresses. If you are, you have until early 2017 to get these changes in place or you risk having this portion of your email traffic filtered (or blocked completely).
Side Note: If DMARC is still a foreign concept to you, you arent alone.
What is Gmail changing?
In early 2017, Gmail will change its DMARC policy from p=none to p=reject. This means any message sent using gmail.com in the from address, will have to originate from Gmails infrastructure.
What does this mean for me?
It depends. If you have any mail streams that send messages using gmail.com in the from address, you will have to make changes before June, or risk having those messages filtered or blocked outright.
If you only send email using your own domain or another domain that you control, you have nothing to worry about. However, its not uncommon for some applications or websites to send messages using their users email addresses. For example, if a user wants to send a message to their friend using your platform, it could make sense to send the message using their personal email address. If their email address happens to be a gmail.com address, this message will no longer deliver once these changes take place. A good alternative to sending mail from your users email address is to use their name in the friendly from. A friendly from is when you use a name to appear as the from address, instead of the email address itself:
exampleuser@yahoo.com can be sent as Example User <message@yourdomain.com>
This way your recipients still recognize the individual that sent the message, and youre no longer at risk of violating Gmails DMARC policy.
Action plan
Sending mail from an external domain, like gmail.com, is more common than you might think. Carefully audit all of your mail streams to ensure you arent using gmail.com in your from addresses. If you are, you have until early 2017 to get these changes in place or you risk having this portion of your email traffic filtered (or blocked completely).
Total Comments 0
