Now Hiring: Home Improvement Leads

A downtown Austin (TX) technology company whose focus is to connect homeowners with high-quality local contractors, Home Improvement Leads is looking to hire a a sharp, motivated, organized, and experienced Email Deliverability Specialist. This position will be working with various ESPs and ISP postmasters, as well as improving existing email marketing practices.  This role performs technical investigations into email systems, reviews message, and makes recommendations based on analysis of email programs including sender reputation and inbox deliverability.  Responsible for the company’s overall email performance as related to deliverability.  The candidate should have solid experience in the field, and truly love the fast-paced action and lots of quantifiable real-time data that comes with the territory.

Responsibilities & Qualifications
  • Complete understanding of email end-to-end delivery including IP addresses, DNS, SMTP, authentication and email headers
  • Knowledge of CAN-SPAM, CASL and other email marketing regulations as well as email best practices
  • Experience with outbound or inbound email deliverability
  • Understanding of major email authentication methods (SPF, DKIM, etc) and sender/IP reputation management.
  • Knowledge of email filtering technologies.
  • Previous experience handling ISP Relations, FBL signups, whitelisting, email block resolution
  • Reviewing data and conducting email delivery analysis
  • Investigating and addressing email delivery problems by engaging directly with relevant ISP abuse desks, email blacklists, and anti-spam technology providers.
  • Experience with email validation, deliverability and reputation management services. 
  • Experience with the management of large (1MM+ subscriber) email lists.
  • Advanced knowledge of Excel, specifically for data analysis of delivery metrics and success.
  • Work with our engineering department to help spec out business requirements as we expand our email management platform.
  • Excellent project management skills, with an emphasis on self-motivation and follow-through
  • Ability to juggle multiple projects and meet deadlines.
  • Excellent written and verbal English communication skills, analytical and problem solving skills, with a strong attention to detail.
Salary is DOE and position has quarterly bonus potential. Benefits include Healthcare, Dental, Optical, as well as a casual work environment, flexible paid time off, snacks, weekly company lunch. Note: This is a full-time salaried position open to individual candidates only.  Position is located in our office in Austin, TX.  Agencies, telecommuting, and freelancers will not be considered.

Interested? Click here to apply.

Special thanks to Leslie Huffines of Home Improvement Leads for sharing this open position.

Outlook.com Deliverability Support Form

Lots of folks seem to have an outdated bookmark (or have found an outdated link) for the Outlook.com (aka Microsoft Hotmail) deliverability assistance request form.

Here's the correct link (as of April 2015):
https://support.live.com/eform.aspx?productKey=edfsmsbl3&ct=eformts

For information on how to troubleshoot deliverability issues when sending to Outlook.com, visit the Outlook.com Postmaster website. Their Troubleshooting page may be of particular interest.

More Jobs @ the Litmus Job Board

Looking for other, non-deliverability related email jobs? Check out the Litmus Job Board.

Troubleshooting AOL Deliverability Issues

A client asked me the other day, how do I go about troubleshooting AOL deliverability issues? Since AOL is an ISP where (for the most part) it's easy to solve deliverability issues, I thought I would share some general guidance here, to make it easy for people to get started.

If you're having trouble delivering mail to AOL, it tends to be one of these three things.
  1. Is your IP address whitelisted with AOL? Most ESPs manage this process for you, and most of them have probably submitted all, or big groups of their IP addresses, to AOL for whitelisting already. But, stuff happens. AOL doesn't tell you if your IP address falls off of their whitelist. Ask your ESP to check this for you. Ask them to resubmit your IP address to the AOL whitelist. If it is already whitelisted, the attempt will fail with a simple "this address is already whitelisted" error, and then you'll know. If you send on your own, not using an ESP, here's where you can find more information about the AOL whitelist.

  2. Are you set up with AOL's Feedback Loop? A feedback loop (FBL) is what allows you to receive a complaint back from a subscriber, when they click the "this is spam" or "junk" button inside of a webmail's user interface. AOL and many other ISPs over FBLs. They indirectly (but importantly) help with your deliverability by allowing you to cease mailing people who complain; preventing repeat complaints. More importantly, if you have an excess of spam complaints, they help you tie complaint numbers back to specific segments or processes that you may need to refine or retire if you want to stay in AOL's good graces (and in the inbox). Like with whitelisting, ESPs tend to manage this process for you. Ask your ESP to help you confirm that your AOL FBL is set up properly and working. Check your ESP's user interface to scan for unsubscribes or complaints that would have been delivered back to you via that FBL. And if you send on your own, not using an ESP, learn more about and sign up for the AOL FBL here.

    (An important note for ESP users: Do not sign up for the AOL FBL yourself unless your ESP has given you permission to do so. Your FBL signup attempt can interfere with the ESP's own attempt to manage this process for you. Bad things can happen, like you could accidentally redirect spam complaints to somebody at your company, who won't know what to do with them. Complaining subscribers will not get unsubscribed, and your deliverability will suffer.)

  3. Is your spam complaint rate just too darn high? I don't exactly know what constitutes "too high a complaint rate" in 2015. AOL used to publish a threshold of .1% as an allowed complaint rate. Later it was .3%. A quick Google search isn't finding me any updated numbers. Regardless, the AOL bounce error message would probably give you some insight to whether or not excessive complaints are at issue. A common block is "554 RLY:B1" which does indeed indicate that your mail is generating too high a complaint rate as measure by AOL. How do you fix that? Try to tie complaints back to specific segments or processes. If one generates more complaints than others, that may be the culprit. The devil can be in the details, so it might be wise to engage a deliverability consultant for assistance. (AOL does publish some fairly good-but-high-level sender best practice guidelines as well.)
How do I know if I have a good sending reputation at AOL? Here's a link to AOL's IP reputation lookup form. Plug in your sending IP address and their system will tell you its opinion of the mail being sent from that IP address.

Do other ISPs have reputation lookup tools, feedback loops, and postmaster websites? My friend Laura Atkins over at Word to the Wise has put together an excellent matrix listing all of the different ISP resource details and links that she is aware of. This is well worth bookmarking.

Do you have additional insight to share with regard to troubleshooting AOL deliverability issues? Please share in comments.

Now Hiring: Email Operations Engineer/Groupon

Hey, thanks to Ryan Boyd of Groupon who reached out in response to my last post. He says that they are currently looking to hire an Email Operations Engineer, "responsible for actively monitoring, maintaining, and supporting all aspects of global email delivery infrastructure." Interested? Click here for more information.

Are you hiring for deliverability?

I know a few folks who are looking for deliverability-related positions due to layoffs and downsizing at various companies recently. Are you hiring? Feel free to drop me a line and I'll be happy to post your job opening here on Spam Resource for free.

Great work, MAAWG!

On March 10th, the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) published a new version of the Senders BCP (Best Common Practices) document -- a solid overview and set of recommendations on how to not be a spammer.

They're not particularly rough or tough recommendations to follow. If you're not a spammer, you're probably following most or all of them already. They outlay good/better/best recommendations for opt-in permission. They explain that email append is unacceptable. They say that subscribers should never unknowingly end up on a mailing list. It should always be easy and simple to unsubscribe. Be transparent in what you do as a sender. Again, this is not earth shattering stuff, but it is good to see it published in a good industry forum, in an easy to digest format.

Do these recommendations matter? Yeah, because just about every mailbox a sender is going to want to send mail to is hosted by an ISP or company represented in M3AAWG. It's a pretty clear guide to what the rules are.

(H/T: Josh over at Word to the Wise)

DMARC & Mailing Lists: A Roundup

In 2014, Yahoo and AOL both implemented strict "p=reject" DMARC policies on their primary domains. This presented challenges to both AOL/Yahoo users and various service providers. Yahoo implemented this new DMARC policy in February. AOL implemented the sample policy in April.

In particular, this makes delivering mail more challenging for discussion mailing list providers. A number of them have had to implement header changes to "play nice" with DMARC restrictions.


Running your own mailing list manager? Here are my suggestions on message checks and header changes that you should consider implementing into your discussion list software. They approximately mirror what Google and Yahoo have implemented. (And some savvy commercial groupware/list management software publishers were quick to implement similar changes.)

Some mailing list managers have decided to reject signups from users at AOL and Yahoo. I recommend against taking this stance; your list of rejection domains is only going to grow as additional ISPs and domain owners implement DMARC policies similar to what AOL and Yahoo have done.

Yahoo is not likely to roll this back any time soon. They find their new DMARC policy choice to have been a success. AOL likely feels the same way.

Additional Frequently Asked Questions:
Ask Al: Is my personal domain affected by DMARC?
Ask Al: Should I add a DMARC record to fix the Yahoo issue?

If you run the mailing list manager software Mailman, here you'll find information on how to configure Mailman to work within the confines of DMARC restrictions.

Keep in mind, if you implement any DMARC-related DNS changes for your domain, be sure to test! If you do DMARC wrong, you're setting yourself up to have your mail rejected.

Spamhaus Sued for Libel in UK

Ken Magill has the story on initial filings regarding the lawsuit brought by Craig Ames and Robert McGee against Spamhaus in the United Kingdom.

Engagement Affects Deliverability

Ever dealt with a scenario where you were struggling to get a client's mail out of the spam folder at Gmail and back into the inbox? Maybe not for you, maybe not always, but in my experience, improving engagement, restricting sends to only engaged subscribers, has been a big part of what fixes that type of issue.

Others might have a different opinion. Good for them!

But that's what has worked for me, numerous times, helping numerous senders. So I, and others, will continue to trumpet it. Intelligently, of course.

House Introduces Email Privacy Bill

Read all about it over at The Hill. My question is, does this thing have a chance of going anywhere, based on the current gridlock in Congress? I'm doubtful, but we will see.

Amazon Starting Email Service

According to multiple sources, Amazon is starting up a cloud-hosted email service. Called WorkMail, it looks as though it'll be price competitive to similar offerings from Microsoft and Google. Looking into my crystal ball, I assume they'll get some adoption in 2015. What does this mean to you, dear sender? Get ready, because eventually you'll have a new platform to send to, with a potentially new set of spam and reputation filters to contend with. Let's stay tuned and see if this takes off, shall we?

Microsoft Updates Use of List Unsubscribe Header

What is a list-unsusbcribe header, you might ask? It's an email header, typically hidden from the end user, that includes information that allows the MUA (mail user agent; meaning your email client, email reader, or webmail platform) to submit an unsubscribe request on your behalf. This is typically linked up to an "unsubscribe" button in a webmail provider's user interface. If you see an "unsubscribe" button or link in the Gmail or Outlook.com user interface for a given email message, that message likely contains a list-unsubscribe header.

The header itself is defined in RFC 2369 from 1998. It's very common for email service providers and list management tools to provide support for this header; and if you're building any sort of new tool or list mail sending service, I would recommend including it. Doing so makes it just as easy for a subscriber to click "unsubscribe" as it does for them to click "report spam." Making it easier to unsubscribe means you're likely to garner fewer spam complaints, and thus your deliverability and sending reputation will be at least slightly higher than they would have been without this functionality.

There are two methods of specifying how to unsubscribe a subscriber using the list-unsubscribe header. There's the HTTP method, and the MAILTO method. The HTTP method implies that when it is time to request unsubscribing of that particular user, a particular web page will be visited. The URL would typically include all of the parameters necessary to denote which subscriber, for which sender, is requesting to be unsubscribed. The MAILTO method implies that when it is time to request unsubscribing of that particular user, an email message will be generated to the email address specified in the list-unsubscribe header. (The destination email address typically would include all of the parameters necessary to denote which subscriber, for which sender, is requesting to be unsubscribed.)

A few days ago, Melinda Plemel of Return Path clarified that Microsoft is now only utilizing the MAILTO method and that they are not supporting the HTTP method at this time. (It is implied that Microsoft properties previously supported both the MAILTO method and the HTTP method, but I don't have a lot of experience with the HTTP method myself and I was not able to confirm this.)

TL;DR? Implement a list-unsubscribe header, or make sure your email platform provides one. If you're building it yourself, only implement the MAILTO-based functionality, as it is the most broadly supported. (I'm aware of multiple ISPs supporting the MAILTO method, but I am not aware of any others that are or were supporting the HTTP method, other than Microsoft.)