Don’t Be Afraid to Say Buh-Bye

Over on the Bronto Blog, Waynette Tubbs reports shares a client's experience with email list stagnation, re-engagement, and how to deal with letting go. It's a smart marketer that can delete 30% of the email list the right way and end up seeing positive gains!

Get rid of that dead weight! They're not untapped marketing opportunities; they're deliverability anchors subtly sinking your inbox rates.

Here's why I unsubscribed

I really like my 2014 Lincoln MKZ. It's sort of the one flashy thing I own. I don't have a big house or wear fancy clothes, but I enjoy my nice ride. And I was really happy with my purchasing experience at Napelton Lincoln in Glenview, just outside of Chicago.

Since I have since moved to Minnesota, I obviously have had to find a new dealer to take the car to for service and maintenance. Well, the new dealer uses some system that sends automated email notifications. It keeps emailing me to tell me it's time for 35,000 mile maintenance. But there is no 35,000 mile scheduled maintenance for this car. Lincoln's own website says the next maintenance is due at 40,000 miles.

But I can't get their system to stop telling me to come in, and I don't see any way to update them or give them feedback about it. And if I even did call them on the phone, do you think they're going to have some way to update their marketing automation campaign just for me? Probably not.

So...I am forced to unsubscribe. Sorry, local Lincoln dealer, but I guess the honeymoon is over and the mismatched maintenance schedule in your marketing automation program is to blame.

Mail.ru announces additional DMARC domain restrictions

Mail.ru just announced that they're moving the domains mail.ua and corp.mail.ru to a restrictive "p=reject" DMARC policy on March 29, 2016.

They previously announced that they were moving domains to "p=reject," beginning with the domain my.com this month. They indeed have moved my.com to a "p=reject" DMARC policy.

Future Mail.ru domains to be updated include bk.ru, inbox.ru, list.ru and mail.ru. Stay tuned.

What is an ISP Feedback Loop (FBL)?

Back in January, spam/abuse fighting industry group M3AAWG published an excellent overview of exactly what constitutes a feedback loop, and they even included a helpful list sharing all of the feedback loops that they are aware of at the time of publishing.

Images off by default?

Dear readers, what email clients still block images by default?
  • Gmail shows images by default. 
  • Yahoo Mail shows images by default.
  • Microsoft Outlook.com (Hotmail) shows images by default.

Who doesn't show images by default nowadays? What percentage of recipients use clients or providers that block images by default? The data I and others have handy seems to be pretty dated.

What's your experience? Feedback welcome; please leave a comment! And thanks.

How to Optimize Your SPF Record


Steve Atkins of Word to the Wise just released a cool new tool: SPF Minimizer. Over on the Word to the Wise blog, he explains how it works and provides an extremely insightful explanation of do's and don'ts when it comes to SPF, aka Sender Policy Framework.

Yahoo Mail not accepting inbound mail

I'm seeing multiple reports of this today-- it sounds pretty widespread. Mail to Yahoo is being deferred due to an internal system issue on the Yahoo side of the connection. My own MTA logs are filling with "451 4.3.2 Internal error reading data" errors.

Reports on the Mailop mailing list suggest that the issue started around 7:00 am US central time on Sunday, March 20th.

Update: As of 1:50 pm US central time, I see that some mail must be getting through for some folks. My primary Yahoo seed mailbox is populated with a new message every few minutes or so. But volume is a lot lower than usual and mail is still backed up on my sending server.

Final update: Multiple sites are reporting that as of about 2:00 pm US central time, Yahoo seems to be accepting all mail again. My queues are empty and all of my earlier-sent test messages have now been delivered to my Yahoo seed mailbox.

New: Check Auth Status with XNND

Need to check the authentication status of your email sends? Wondering if you've got TLS, DKIM, and SPF configured properly? Here's an easy way to tell. Using your email platform or email service provider, send a message to [email protected]. Then, after a few minutes have passed, your email message will be added to the list of messages over on the XNND Authentication Page at http://xnnd.com/authentication/ and you'll be able to see whether or not your mail message was signed with a working DKIM signature, whether or not it passed SPF authentication, and whether or not TLS was used during mail transport. Any questions or feedback? Feel free to drop me a line in email or in comments.

Yep, that's about right.


H/T: @mattindy77

Sender ID Doesn't Matter in 2016

Sender ID didn't actually come on a cassette tape.
Once upon a time, Sender ID was a sort of Hotmail-specific version of Sender Policy Framework (SPF). It used to be valuable and necessary to maximize your chances at getting solid inbox deliverability at Hotmail. There used to be these tricks you had to do; like, if mail was being silently discarded at Hotmail, you'd have to manually submit your Sender ID record to them via a webform, and we knew that this would eventually lead to improved deliverability.

But that's all super old news at this point. Hotmail -- I mean Outlook.com -- has long switched over to checking DKIM and SPF like so many other large email and webmail providers.

There's no harm if you're still publishing a Sender ID record, but if you're planning to set one up when configuring your new domain, don't bother. SPF and DKIM are where it's at in 2016.

The spam map of the United States

Over on Betanews, Ian Barker asks: "What do California and New York have in common? They're both major centers of spam email according to new research, between them accounting for almost half of spam sent in the US."

Over here on Spam Resource, I ask: What do Utah and Michigan have in common?  Two things.

First, according to that Betanews article referencing data from Comodo Threat Research Labs, these two states both make the top five list of states as sources of spam. Utah is third and Michigan ranks fourth.

Next, both states were convinced to implement "Child Protection Registry" services over ten years ago. Register your child's email address, and all good, legal, ethical senders of mail advertising anything "grown up" in nature (think alcohol and cigarettes, for starters) will be sure to scrub those addresses out of their list. The net, it was proposed, is that minors in those two states would be spared from receiving email advertising for products they're not supposed to have access to until adulthood.
Interesting idea. Except that the implementation of it was pretty awful. "Painfully bad," wrote Return Path way back then. The scrub process cost money and was clunky. Perhaps it is still clunky, but instead of bothering with it, lots of compliance folks started suggesting just asking, at the time of signup, what state a subscriber is in, and if they answer with Utah or Michigan, don't send to them if you advertise or sell those kinds of products. So I haven't personally heard of anybody having to go through the scrub process in years. (Have you?)

The only upside was perhaps for the company chosen to run the registry in both states (Unspam) -- maybe they made some money from it.

But it didn't do a damn thing to stop spam, because, as predicted by many, only good guys who wanted to comply with the law would follow through (or avoid those two states). All the bad guy spammers who probably already break the law, who don't care about permission, they keep on spamming adults and children alike.

Correlation is not always causation, and these two data points don't really overlap. But it does seem that both states biffed it two different ways when it comes to stopping spam.

Small scale, unsolicited, and sustainable...

My friend and deliverability colleague Josie Garcia sent me this picture yesterday. It's a picture of her printout of a specific page from this blog, from sometime around a hundred years ago. Specifically, it's a post from 2007, where I replied to and rebutted a "cheeky" marketing guy who thought that whole permission thing was overrated. "It's document shredding day here, but I'm keeping this gem," Josie mentioned.

Mr. Cheeky popped up at the time to tell me that he was doing great. He indicated that his "small scale, unsolicited and sustainable" non-permission model was working wonders for him. But what about since then? Not surprisingly, he seems to have moved on to a new career; his blog is long shuttered. But my friend reminds me that what I posted back in 2007 remains solid advice now: Permission rules. If you don't respect permission, you're a spammer, dummy. Forget insults and bad feelings, no permission means you're going to have problems getting your mail delivered to the inbox reliably.

Why listen to us? Josie and I have only been doing this sort of thing for something like fifteen years. Meanwhile, every year, some new cheeky marketing dude wanders by, trying to tell everyone that, all the data and history and experience notwithstanding, permission is suddenly overrated and they've found the One True Other Way...yet mysteriously, they don't seem to be in it for the long haul.

Hmm. Wonder why.

SPF Still Matters in 2016

SPF (Sender Policy Framework) still matters in 2016. Lots of folks might be authenticating with DKIM now, but SPF is a useful fallback mechanism and in my oh-so-humble opinion, everybody sending email with their own domain name should publish an SPF record.

An SPF record is primarily used to publish a list of IP addresses or network ranges. You're telling the world that those IP addresses are allowed to send mail using that domain in the from address.

The $64,000 question: Dash all or Tilde all?

  • Ending the SPF record with "-all" tells the world "I'm confident that any other mail using my domain, coming from other IP addresses, must be forged; treat it harshly.
  • Ending the SPF record with "~all" tells the world "I'm mostly but not entirely confident that any other mail using my domain, coming from other IP addresses, is probably forged; examine it more closely."

Which is better? Using "-all" used to seem to improve deliverability a bit more than using "~all." Though I haven't personally tested that in a long time, I'd lean toward using "-all," unless you have concerns that you might have missed some of your sending IP addresses.

"But SPF is worthless," occasionally a spam fighter will cry. Not true! SPF is very useful in a whole other way: whitelisting! Run an ISP or a blacklist, and you want to make sure you don't block legitimate mail from Yahoo or Gmail outbound IP addresses? Use their SPF record as a whitelisting guide to make sure you don't reject mail from those IP addresses. SPF works very well for that.

Want to tell the world that your domain doesn't send any mail and that it's safe to assume any mail sent using this domain is forged? Publish a "v=spf1 -all" SPF record; that's exactly what it will tell anyone who checks and respects SPF records. Lots of domains publish this type of SPF record; I've found it useful as part of a domain validity check process, based on the assumption that if the domain doesn't send mail, it probably doesn't accept mail. It has served me well so far.

Useful Tools: You can use XNND to lookup an SPF record. The Authentication section on Wise Tools will help you break down that SPF record in more detail. Here's a very useful suite of SPF-related tools, published by Scott Kitterman.

(What about Sender ID? Does that still matter? No. Microsoft Hotmail / Outlook.com was the only one who cared about Sender ID, and no longer check for it.)

Edited to Add: You'll want to read Mickey Chandler's followup post, Drafted for the wrong fight.

Email inventor Ray Tomlinson dies

Without the work of Ray and so many others, would I even have a career today? Rest in peace, good sir.

Spamhaus Releases "Worst TLDs" List

Don't go rushing out to buy a domain name under the ".download" TLD (top level domain) just yet; Spamhaus says just over three quarters of registered domains under that new TLD are bad news. This kind of data tends to lead spam filterers to treat all mail from that TLD as spammy; guilt by association means good luck trying to get your mail delivered to the inbox reliably.