Using AdBlock? Using Yahoo! Mail?

Not for long, you're not. Looks like Yahoo is testing code on Yahoo! Mail that would disallow AdBlock users from accessing their webmail platform. Read more over at the Consumerist.

Verizon Retiring Inactive Email Addresses

Oracle Marketing Cloud's Kevin Senne reports that Verizon is telling subscribers that email addresses unaccessed for 180 days will be deleted. This is yet another reminder that you (senders) can't sit on email addresses for years and still expect them to be valid. I have no clue if Verizon ever repurposes dead email addresses into spamtraps, but it's not something I would want to risk.

Gmail to flag unencrypted email connections

Last week, Google indicated that they're working on a warning indicator to be shown inside of Gmail, indicating when an email message was transmitted over an unencrypted connection.

What does it mean when an email message was sent without using an encrypted connection? It means that your MTA (mail transfer agent-- aka a server sending email messages) wasn't using TLS (Transport Layer Security) when communicating over SMTP (Simple Mail Transport Protocol).

It doesn't mean your message was intercepted by bad guys. And mail servers had been communicating with each other in an un-encrypted fashion for many years. But in this modern age, where individuals (and even big companies) have begun to raise concerns over who has access to an individual's online information, Gmail is taking a stand to say, we want everybody to encrypt email delivery connections so prevent (or at least reduce the chances of) those messages from being intercepted or copied in transit.

If you work for an email service provider or email platform, you know that any time a major ISP or webmail platform puts up an alert over a certain type of message or scenario, your customers are going to be concerned. Even if this notice doesn't really indicate a failure condition, they're going to be worried that it does suggest that to their end subscribers. In short, they won't want this alert to show up for emails they send.

It's quite a savvy move on Google's part. I am sure that email platforms and email service providers that don't already universally support TLS are figuring out how quickly they can implement it.

Does TLS improve email deliverability? No, not directly. But, consider this: if mail delivered without using TLS is going to throw up a big red flag in the Gmail user interface, that's going to cause an issue with subscriber confidence. Calls to customer services. Incorrect assumptions that a message isn't safe or might be fraudulent. These are not concerns you want associated with your email marketing program.

A Useful Email Validation Tool

Hey, if you're looking to test whether or not an email address is syntactically valid, I think I've stumbled across just the tool for that. Check out the very cool by Dominic Sayers.

This doesn't connect to a remote server nor does it try to determine if the email address is actually deliverable. It tells you if there are too many dots in the wrong places or otherwise contains something that isn't allowed in an email address.

If an address fails the validation process, it tells you exactly why that address failed; what is in it that is disallowed, and why is that disallowed. Very, very kind of Dominic to have taken and distilled the RFCs down to something you can actively test against.

(Of course there are some email addresses that violate RFC specs but are still deliverable and otherwise "valid." But that's a problem for a different day.)

Use this ONE WEIRD TRICK when implementing a DMARC record

The one thing, the absolute most important thing to keep in mind when setting up a DMARC p=reject policy is: You have to know all of the sources of all legitimate, desired mail that uses your domain name, before you proceed. If you don't, here's what happens: You turn on p=reject, and suddenly offer letters to new employee candidates start bouncing. Why? Because you didn't know that your human resources department uses a third-party service provider to handle applications and offers. It sends its own email, from its own server, and it's either that the mail is not being authenticated with DKIM, or that it's sending IP addresses are not included in your SPF record.

I've seen it happen more than once.

What other things are important considerations when planning to move forward with a p=reject DMARC policy? Share in comments and I'll wrap them into a future post.