Recent Posts

Authentication and Repudiation

Email Authentication lets you demonstrate that you sent a particular email.
Email Repudiation is a claim that you didn’t send a particular email.

SPF is only for email authentication¹
DKIM is only for email authentication
DMARC is only for email repudiation

¹ SPF was originally intended to provide repudiation, but it didn’t work reliably enough to be useful. Nobody uses it for that now.

Mistakes happen

As happens every Tuesday, the Magill Report was blasted into mailboxes all over the Internet. This Tuesday was extra special for some recipients, though. These recipients received a dozen or more copies of the newsletter.
Ken knows best practices and implements them rigidly in regards to his sending. He’s one of the very few standalone publishers that uses confirmed opt-in, for instance. But even with the best practices in place, sometimes bad stuff happens. From what little I’ve seen, this looks like some bit of software fell over somewhere.
In this case, there isn’t a lot to do. Sure, people are talking about it, but I don’t think anyone is treating this as anything other than an aberration or a software glitch. Ken doesn’t need to send out an apology and I suspect that he’s not lost a single subscriber due to this. People are willing to cut a sender a break when they have a long history of sending. I do expect we’ll see something about this in next week’s newsletter, possibly concluding with him looking for a new ESP.
Sending failures happen all too frequently. Some are embarrassing, some cause significant business problems. The biggest issues are when a send goes to addresses that shouldn’t be mailed, either unsubscribes, or bounces or inactives. These kinds of mistakes can drive blocks at ISPs and get the sender noticed by some blocklists.
The good news is that if it’s truly a one-off, then delivery may not be affected at all. And in cases where delivery is affected, problems tend to disappear quickly. Filters adjust and don’t take too much notice of a very short term aberration when there is a long term history of wanted email.

Where's AOL?

I hear almost nothing about AOL from clients and potential clients these days. I hear a lot from AOL users who are confused and don’t understand that I am not AOL support (I’m not. Really. I can’t help you.). But I hear almost nothing from clients.
There are three possibilities I can think of for this.

Salesforce and DKIM

Last month I wrote about how Salesforce was implementing the ability to sign emails sent from Salesforce CRM with DKIM. The Spring 15 update is now live as is the ability to use an existing DKIM key or allow Salesforce to create a new one for you.
Setting up DKIM within Salesforce is straightforward. A Salesforce Administrator would go to Setup->Email Administration->DKIM Keys.
sf-dkim-step0
You can either allow Salesforce to create you a new DKIM key or you can import an existing key. For this example, I am going to create a new DKIM key for the domain wttwexample.com with a DKIM selector of 2015Q1.
Step 1 – Creating a new key within Salesforce, you enter the Selector for the key (2015Q1), the domain for the key (wttwexample.com), and the strictness of the key allowing either the exact domain only, subdomains of the domain only, or Exact domain and subdomains.
sf-dkim-step1
Step 2 – The next screen will display both the Public Key and the Private Key.
sf-dkim-step2
Step 3 – With the key being created, we need to store the Public Key within our DNS for the domain by created a TXT record with a hostname of 2015Q1._domainkey.
sf-dkim-step3
Using a DKIM check tool like ours http://tools.wordtothewise.com/authentication, we can see if the DKIM key is in the DNS and if the key is valid.
Step 4 – Once we have confirmed the key is valid and in DNS, we can go back to Salesforce and activate the key.
Step 5 – Emails sent from the Salesforce CRM Sales Cloud will now be signed with the new DKIM key and the emails will have a new header added called DKIM-Signature.
Signing with DKIM allows us to tell the recipient ISP that “yes, I sent this email” and this allows the ISP to track our reputation by the domain instead of just by the IP address. This means that some fraction of our good reputation will be associated with these emails that are sent from Salesforce CRM. If we have not established any reputation yet, signing with DKIM is a good key to enable services like feedback loops as it includes the proof that you’re sending the FBL reports to someone responsible, not a random third party.
If you have plans to consider utilizing DMARC, you need to have ALL of your sources of mail authenticated. DMARC looks for a passing SPF or DKIM validation during its evaluation of the message. Utilizing both SPF and DKIM for DMARC validation is recommended.
Having emails signed with DKIM, having a valid SPF, setting up sensible reverse DNS, having good hostnames all show that you are doing your part to send legitimate and valid mail. Signing with DKIM does not give you a free pass to send spammy emails, it just tells the receiving party who is taking responsibility for sending the message.

Sparkpost: Momentum in the Cloud

Today MessageSystems announced the launch of SparkPost: the world’s most advanced cloud email delivery service. Using the Momentum engine, SparkPost lets small and medium size companies have access to the tools previously reserved for larger companies.

A series of tubes

The Internet and pundits had a field day with Senator Stevens, when he explained the Internet was a series of tubes.
I always interpreted his statement as coming from someone who demanded an engineer tell him why his mail was delayed. The engineer used the “tube” metaphor to explain network congestion and packets and TCP, and when the Senator tried to forward on the information he got it a little wrong. I do credit the Senator with trying to understand how the Internet works, even if he got it somewhat wrong. This knowledge, or lack there of, drove his policy positions on the issue of Net Neutrality.
In the coming years, I believe we’re going to be seeing more regulations around the net, both for individuals and for corporations. These regulations can make things better, or they can make things worse. I believe it’s extremely important that our elected officials have a working understanding of the Internet in order to make sensible policy. This understanding doesn’t have to be in their own head, they can hire smart people to answer their questions and explain the implications of policy.
Apparently I’m not the only one who thinks it is important for our elected officials to have a working knowledge of technology. Paul Schreiber put up a blog post comparing the website technology used by the current Presidential candidates. Do I really expect the candidate to be involved in decisions like what domain registrar or SSL certificate provider to use? No. But I do expect them to hire people who can create and build technology that is within current best practices.

Don't like opt-outs? Target your program better.

I get a LOT of spam here. Most of it is marked and trivial to get rid of. Some of it is what I would call semi-legitimate. It’s a real product, but I never asked to receive any information from this company and am not actually part of their demographic. For one time things I just hit delete and move on. Life is too short to complain or opt out of every spam I get. (Tried that, got more mail)
But sometimes if the same sender keeps bothering me, I will send back an email asking them to cease contact. I recently had an occasion where someone sent an initial email trying to sell me bulk SMS, online video and other services. I ignored it because we’re not in the market for any of these services. A week later I get a followup asking why I hadn’t provided feedback to them and if there was a better person to talk to at the company. I looked for a way to opt-out of this message stream, but there wasn’t one. I send a reply telling them we were not interested in speaking to them and to please cease all communication. (“You didn’t receive feedback because I have no interest in talking to you. Please cease all future contact.” Admittedly that was terse, but it was polite.)
My request to cease communication was not well received, nor was it honored. Mind you, they first contacted me trying to sell me services that are totally off what we offer. When I asked them not to contact me, they turned it around that we’d lost business.

Best practices … what are they?

“We follow all the best practices!” is a common refrain from many senders. But what does best practices really mean?
To me the bulk of best practices are related to permission, technical setup and identity.

March 2015: The month in email

Happy March! We started the month with some more movement around CASL enforcement from our spam-fighting friends to the north. We noted a $1.1 million fine levied against Compu-Finder for CASL violations, as well as a $48,000 fine to Plentyoffish Media for failing to provide unsubscribe links. We noted a few interesting things: the fines are not being imposed at the maximum limits, violations are not just on B2C marketing, but also on B2B senders, and finally, that it really just makes sense — both from a delivery perspective and a financial perspective — to comply with the very reasonable best practices outlined in CASL.

Old Lists and RadioShack

RadioShack is putting their assets up for sale including more than 65 million customer records and 13 million email addresses. Many are up in arms about the sale of personal data including the Texas Attorney General and AT&T who both want the data destroyed.
Part of the controversy is that RadioShack’s privacy policy states the collected data will be only used by RadioShack and its affiliates and that they will not “sell or rent your personally identifiable information to anyone at any time”. Company acquisitions happen all the time and data like this is often sold to the new owner and the sale of customer data is common. The problem with RadioShack selling the customer data is that their privacy policy states they will never sell the information.
RadioShack was one of the first companies to ask for personal information at checkout, sometimes refusing a sale without providing it and the collection of data during checkout caught on quickly. Having demographic information for retargeting of customers is extremely valuable to marketers, but only if it’s valid data. With RadioShack, people often lie about their zip code and if they are giving incorrect zip codes I’m pretty sure their email address isn’t going to be valid either. Even Kramer asks why does RadioShack ask for your phone number…
https://www.youtube.com/watch?v=WgfaYKoQxzQ
If a client asked if this was a good investment and if the list had value, I would tell them no. Sending to this list will have poor delivery because the data is dirty and the lack of a clear opt-in is going to be problematic especially since a RadioShack customer is not expecting to receive mail from you. Many ESPs have policies prohibiting sending to a purchased list and doing so will hurt your relationship with the ESP.
If a client had already purchased the list and wanted to send to it, I would tell them their reputation is going to take a significant hit and I would discourage them from sending. The list is going to be full of domains that no longer exist and contain abandoned email addresses including ones that have been turned into spam traps.
When preparing to send to a new list of email addresses, I go through this process: