From address: Don't use an invalid domain name

Here's a common question that I get asked somewhat regularly: "I don't really want to receive or deal with replies to my email messages. Can't I just use a fake email address?"

You should never, ever use a fake email address (or an email address with a fake domain name) as your from or reply-to address. Why not?

1. There's indirect evidence that some ISPs treat a sender better if they note that subscribers actually respond to your messages. Encourage interactivity. Or at least work with your email platform or email service provider to allow people to unsubscribe by replying. The evidence is soft, but I think it helps at least a little bit to keep you in the inbox.

2. Using a fake domain name or non-existing domain name will definitely cause deliverability issues. Big ISPs are likely to bulk or block your mail if you send from a domain name that doesn't exist. Lots of smaller ISPs are definitely going to block your mail. Brian Krebs recently reported on how a well-known company was recently identified as using a fictional, unregistered domain name to respond to HR queries. If you applied for work there and they never responded to your job application, maybe it is because your ISP probably blocked their response, assuming it was as spam.

Side note to email nerds: Your domain name has to resolve. Trying to use a domain name that doesn't resolve is going to cause unexpected deliverability issues. It'll do more than just keep you from getting replies. Don't work this way! The most common mail server platforms in the world, Postfix and Sendmail, both have switches to turn on that will reject mail from unresolvable domain names. Many, many, many system administrators turn those flags on. Your mail will never get delivered to a site with that check enabled.

3. If you really don't want to deal with replies, I suppose you could use an email address that bounces. I don't recommend this. But if you do it, make sure it's an email address truly under your control, at a domain you control. Don't use a webmail address. Don't use an email address at some internet service provider. You'll get tripped up in authentication and DMARC-related issues.

DMARC lets domain owners specify a policy, published to the world, that can tell other ISPs to filter or reject messages that purport to be from a user at their domain, if the message fails authentication checks. AOL and Yahoo are two big ISPs that have implemented this type of policy. Gmail is going to implement it in 2016. Other ISPs are sure to follow. What should you take away from this? You need to use your own domain name in your from address today. You can't use your AOL, Yahoo, Gmail, or other webmail or ISP email address in your from address any more. Even if DMARC weren't the big issue (and it is), your mail would still be more likely to get bulk foldered.

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 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.