Hey there! Want to help me with a fun project? Sure you do!
I'm tracking different emails from different brands, senders, companies, and email services providers. Want to help give me more samples to play with?
Just add my new special address sample2018box@gmail.com to your list, your client's list, or submit it on various websites you visit. I won't report the mail as spam. I'll probably even open and read some of the mail. Maybe even click on a link or two.
Sign it up for a newsletter. Register it for a rewards account. Use "forward to a friend" to send it something. Do whatever you want.
That address again is sample2018box@gmail.com and thanks in advance for adding it to email lists!
Google moves gmail.com to "quarantine" DMARC policy (for subdomains)
Gmail warned us that a more restrictive DMARC policy was coming, didn't they? That warning came all the way back in 2015. They said that "p=reject" was coming. Maybe it still is -- we're not there yet, but this appears to be a step in the right direction.
Today's update: For subdomains under gmail.com and googlemail.com, they've implemented a "quarantine" DMARC policy.
Still, this change has a significant impact on senders. If you send mail with from address of (something)@gmail.com or (something)@googlemail.com through an outside (non-Gmail) email platform like an ESP, that mail is likely to get delivered to the spam folder. I jumped the gun a bit on this one -- today, this doesn't affect your sending as (something)@gmail.com.
They're not the first to implement a DMARC "quarantine" policy for some part of their domain. Apple did the same thing back in July. Mail.ru went to "p=reject" back in March. And of course OATH (AOL and Yahoo) started this trend, implementing a "p=reject" policy for their main domains way back in 2014.
Edit: Ha ha, fingers sometimes move faster than brain. To clarify, this applies to subdomains of gmail.com -- i.e. bounces.gmail.com, server.gmail.com, etc. The DMARC policy for the top level of gmail.com and googlemail.com is still p=non.
Today's update: For subdomains under gmail.com and googlemail.com, they've implemented a "quarantine" DMARC policy.
They're not the first to implement a DMARC "quarantine" policy for some part of their domain. Apple did the same thing back in July. Mail.ru went to "p=reject" back in March. And of course OATH (AOL and Yahoo) started this trend, implementing a "p=reject" policy for their main domains way back in 2014.
Edit: Ha ha, fingers sometimes move faster than brain. To clarify, this applies to subdomains of gmail.com -- i.e. bounces.gmail.com, server.gmail.com, etc. The DMARC policy for the top level of gmail.com and googlemail.com is still p=non.
Topics:
authentication,
dmarc,
gmail,
google,
p=reject
The 250ok Deliverability Guide
Email deliverability monitoring firm 250ok just released "the 250ok Deliverability Guide" and it provides a solid getting started point for the concepts behind deliverability, email authentication, sending reputation and best practices. It's a free download and you can find it here.
Apple Moves to "Quarantine" DMARC Policy
If you monitor these things, you might have noticed that Apple's consumer email domains (iCloud domains) -- mac.com, me.com and icloud.com -- have moved to a "p=quarantine" DMARC policy. This means that if you have an email address in these domains, your ability to send outbound mail using an email service provider or other, non-Apple email platform to send mail, deliverability won't look so good. Mail may not be blocked outright (Apple didn't move to "p=reject") but moving to "p=quarantine" means it's much more likely that your mail could end up in the spam folder.
What to do if you have a mac.com, me.com or icloud.com email address: Continue to send mail, but only from your proper email client on your Mac or iOS device.
What not to do: Don't try to use an ESP to send mail with a from address in the mac.com, me.com or icloud.com domains. It'll fail necessary authentication checks and Apple's DMARC policy will drive most ISPs to put your mail in the spam folder.
I think this is a good move for Apple and a good move for people who hate phishing and spoofing. Making it harder for bad guys to misuse your domains is a good thing.
What to do if you have a mac.com, me.com or icloud.com email address: Continue to send mail, but only from your proper email client on your Mac or iOS device.
What not to do: Don't try to use an ESP to send mail with a from address in the mac.com, me.com or icloud.com domains. It'll fail necessary authentication checks and Apple's DMARC policy will drive most ISPs to put your mail in the spam folder.
I think this is a good move for Apple and a good move for people who hate phishing and spoofing. Making it harder for bad guys to misuse your domains is a good thing.
Subscribe to:
Posts (Atom)