Verizon Retiring Inactive Email Addresses

Oracle Marketing Cloud's Kevin Senne reports that Verizon is telling subscribers that verizon.net 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

In November, 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 isemail.info 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.

Is my DKIM key Insecure?

Various folks have been asking lately if their DKIM key might be "insecure." At least one ISP out there is failing working keys with "verification failed; insecure key" as the error. A number of small, second or third tier ISPs note that the DKIM validation passed, but with a warning: "1024-bit key; insecure key."

After talking to folks and doing a bit of investigation, I think that ISP should not be failing the the DKIM signature in question. The key passes perfectly fine elsewhere, and my suspicion is that the ISP in question is running an out of date version of OpenDKIM. I myself have had issues with "insecure" warnings from OpenDKIM -- when that happens, what it's actually complaining is that the sending entity hasn't implemented DNSSEC. As I mentioned in my prior post, yeah, DNSSEC is a good thing and something to look at, but I would posit that it's really not appropriate to level an error (or a big scary warning) in email header over this, because a great number of perfectly fine entities have yet to implement it.

Indeed, the specification governing DKIM signatures (RFC 6376) mentions DNSSEC in passing but does not list it as a requirement.

TL;DR? "Insecure key" just means a sender is not running DNSSEC; it's not common or appropriate to fail a DKIM signature for this reason.

Update: A friend asks, what if the "verification failed" and "insecure key" messages are unrelated? This quite possibly could be the case. Data's a bit thin, but if so, it would still suggest to me that the ISP in question is potentially using a broken or out of date install of OpenDKIM. I am noting that it is likely OpenDKIM due to the "insecure" message and I am suggesting "broken or out of date" due to failing a DKIM key that is working when tested elsewhere. I'll provide an update if/when I learn more about this issue.

DMARC: Gmail "p=reject" policy is coming

First Yahoo. Then AOL. Recently, additional Yahoo domains. Next up? Gmail. DMARC.org announced today that Gmail will move to publish a more restrictive DMARC policy in 2016. Read more over on Word to the Wise. (H/T WTTW)