Customers who have signed up for premium services receive what we like to call, “Technical and Deliverability Account Management”. But what does that really mean for you, aside from getting support on a first name basis?

As a SparkPost Technical Account Manager (TAM), I work with many premium service customers on a daily basis. Although some might think we only offer just technical support, TAMs provide much more than that. To get a better understanding of what I do as a TAM for our customers, here’s a typical new premium support customer sign-up journey and the role I play.

Step One: Getting Started

As a TAM, I’m notified when I’ve been assigned a brand new customer who’s decided to join the SparkPost family. I’ll quickly send an introductory welcome email, along with next steps and a request to schedule a kickoff meeting to get started right away. We’re aware of the desire to hit the ground running, and we do our best to meet any critical timelines or cut-off dates to migrate mail traffic to our platform.

During the official kickoff meeting, I introduce myself as the dedicated TAM, and introduce a team member from our awesome Deliverability team, who will work in tandem with me to define message segmentation strategy and IP warmup. We listen to our customer’s concerns and/or risks, review business needs, discuss current sending methodologies, and highlight best practices.

Communication is critical to success, and we have a variety of protocols we use to connect with our customers, from weekly phone calls, to email or even Slack!

The final critical milestone in step one is firming up a go-live date that the customer is aiming for, and ensuring the warm-up plan will not only fulfill the customer’s needs, but also build in enough buffer time to establish credible reputation with the ISPs.

Step Two: Integration

At this point, the customer now has full access to their SparkPost environment, and is fully testing to ensure all systems are good to go for go-live. Our weekly touch point meetings comprise of questions the customer might have with testing, setting up new subaccounts, determining a bounce domain strategy, asking about relay webhooks, and how message events differ from webhook events. I like providing training sessions to my customers through screen sharing to ensure they’re set up for success. I’ll also review the account to check if DNS is correct, if suppression lists are functioning and ready to go, double checking ip pool mapping, and making sure subaccounts are properly set up. The deliverability team and I also refine and make any necessary changes to the warm-up plan and make any final preparations for the start of go-live.

Did I also mention that premium support customers get access to our Inbox Assist Tool (250ok)? This is a powerful third party partner that empowers our customers with data-driven real-time insights into email performance, brand reputation, and DMARC compliance.

Step Three: Go-Live

The day is finally here!

First thing in the morning, I remind my Deliverability counterpart that our customer is going live, and to keep an extra careful watch on their traffic. I’ll log into their environment, review any traffic that might have been sent so far, alert Deliverability if there are any abnormalities, and monitor throughout the day.

Things TAMs look out for in particular detail are ensuring your traffic is properly being routed onto the right dedicated IP pools and that traffic is flowing smoothly without significant delays. Any issues seen here, and we’ll reach out to the customer proactively to remediate as quickly as possible. How’s that for premium service?

Step Four: On-Going Support

The customer is now post Go-Live, and all traffic has successfully been migrated over onto SparkPost. What now?

Our Deliverability team will continue to provide a weekly report with analysis on how traffic is flowing and any remediation that might be required with ISPs. I provide monthly as well as quarterly updates, and share any upcoming features we’re rolling out with the customer, as well as how to leverage the benefits in their specific use case.

I work with customers to bring any additional messaging streams onto SparkPost, discuss any new requirements or feature requests, and always lend a hand for any coding issues or problems that might arise.

We’re Here For You

Sending emails isn’t always smooth sailing, but having a TAM in your corner to help you navigate through rough waters is always a plus. If you have any questions for me about my role as a TAM, find me on Twitter or LinkedIn.

-Isaac Kim

For more insight into our TAM services, check out this post.

Top 10 Blogs: Our Year in Review

We’re finishing out the year with a roundup of our top 10 blogs from 2016. The Mandrill announcement in April impacted our community, and as a result our blog, in a big way. We’re recapping that along with other top posts on deliverability tips and email marketing best practices down below. As always, our ears are open, so if there’s a certain topic you’d like to see on the blog, leave us a comment, tweet us, or ping us in slack.

Without further ado, we give you the top 10 blogs of 2016:

#1 Mandrill Alternatives

It’s no surprise that our Mandrill alternative blogs dominated our top 10 list (5 out of our top 10). We responded in real-time to the Mandrill crisis and told you why we could offer 100K emails/month for free. Our CEO even weighed in and made you a promise he intends to stick by for the long haul. The Mandrill incident also inspired us to create SendGrid and Mailgun migration guides, check them out when you have a chance.

Mandrill Template Migration top 10 blogs

#2 PHP

But beyond Mandrill, we also had some other top posts. Coming in second was using SparkPost in PHP. Believe it or not, many of you use PHP through our WordPress plugin.

PHP in SparkPost

#3 Advanced Email Templates

For developers who want to get the most out of SparkPost templating capabilities, this post was meant for you! In this straight-forward post, Chris Wilson makes sending email easy and gives you some pro tips along the way.

 

advanced email templates

 

#4 What Recruiters Look for in a Dev Candidate

Everyone wants to know how to interview well. In this post we told you about what four tech recruiters look for when hiring developer and engineering candidates.

Recruiter for Dev Candidate

#5 Webhooks!

One of the most useful elements of SparkPost are our webhooks and in this post, Ewan Dennis walks you through the basics and beyond. Knowing what to expect functionally beyond the raw API spec is half the battle when consuming new data sources like SparkPost webhooks.

webhooks: beyond the basics

#6 Outlook and Hotmail Email Deliverability

The Outlook inbox is one of the major destinations for most email senders, especially those with large numbers of consumer subscribers. It also has a reputation for being somewhat tricky to get into. In this post, one of our deliverability experts, Tonya Gordon, shares what senders need to know in order to get the best Hotmail/Outlook deliverability and ensure their messages reach the inbox.

#7 Announcing Subaccounts!

Thanks to your feedback, the Mandrill event helped us expedite our release of subaccounts ahead of schedule. Our VP of Product told you about how we process your feedback and what’s available with subaccounts.

SparkPost #WeLoveDevelopers

#8 Are You an Email Rookie?

Sometimes you need to go beyond a top 10 list and in this case we did — 17 tips on how not to be labeled an email rookie. In this post we put together a list of common mistakes, with a heavy dose of snark, on how to avoid being labeled an email marketing rookie.

Email Marketing Rookie Kid Missing Steering Wheel

#9 Retail Marketing Stats You Need to Know

Do you know what the lowest e-commerce order generators are? In this post, we give you five tips and stats for mastering retail marketing. From social media, to mobile and beacon triggered emails.

Retail Marketing statistics mobile 2016

#10 Setting Up SparkPost as your SMTP Relay

You know you need to send email, but you don’t want to spend a lot of time or effort on it — you just want something that works out of the box. It’s not too much to ask! Many frameworks, languages, and tools come with SMTP support, but the last step is the most important – an SMTP server. In this post, we walk you through how to set up SparkPost as your SMTP Relay.

And that rounds out our Top 10 Blogs for 2016! Any industry trends or topics you think were under-represented? Leave us a comment below, or tweet us!

-Tracy

When we speak of “Email Authentication”, we’re referring to a technique that is meant to provide to the recipient of a message some level of certainty that the message actually originated with the claimed source of the message. The idea is to achieve some level of defense against fraudulent email, such as phishing and spoofing, that could erode a recipient’s trust in receiving email. That said, the act of sending authenticated email does not, in and of itself, assert that the email is good or wanted email; it only means that the mail is such that a reputation for the authenticated party can be reliably established and used in email acceptance and placement decisions.

There are two primary forms of email authentication in use today—Sender Policy Framework (SPF) and DomainKeys Identifed Mail (DKIM). In this blog post, I’ll explain what SPF is, and how it works.

SPF Overview

Sender Policy Framework (SPF), to paraphrase RFC 7208, is a protocol that not only allows an organization to authorize hosts and networks to use its domain names when sending email, but also provides a way that a receiving host can check that authorization.

When you’re done reading this post, I hope you’ll have learned the following:

  • SPF is a “path-based” authentication system.
  • SPF policies are declared in DNS TXT records.
  • Validation is keyed to the Return-Path domain (what we here at SparkPost call the “bounce domain”) or the HELO domain.
  • Validation can be done early in the SMTP transaction, so it’s a good check to use to quickly reject unauthenticated mail.
  • It is prone to a relatively high percentage of false negatives.

“Path-Based” Authentication

SPF is deemed to be a path-based authentication system because it’s tied solely to the path the message took to get from its origin to its destination. When a sending server initiates an SMTP transaction with a receiving server, the receiving server will determine whether or not the sending server is authorized to send that message based on the domain’s SPF policy. It’s solely a decision based on where the message is coming from, with nothing whatsoever to do with the content of the message.

Declaring an SPF Policy

A domain’s SPF policy record is just a specifically formatted DNS TXT record, commonly containing one or more of the following “mechanisms”:

  • v=spf1 – Required first token to indicate that TXT record is SPF record (a domain can have multiple TXT records)
  • ipv4, ipv6 – Used to specify IP addresses and networks that are permitted to send mail for the domain
  • a – If the sending domain has a DNS “A” record that resolves to the sending IP, the IP is permitted
  • mx – If the sending IP is also one of the MX records for the sending domain, the IP is permitted
  • all – Required last token, always modified:
    • -all – Only what’s listed here can pass; reject failures.
    • ~all – Stuff that’s not here should softfail; accept it but note it.
    • ?all – Not sure if stuff that’s not here should pass.
    • +all – We think SPF is useless; pass everything.

Other less common mechanisms that are still in widespread use are:

  • include – Used when a domain not only has its own servers, but also uses someone else’s servers. Must be used judiciously. Each include is another DNS query, and SPF records can’t require more than ten DNS queries to resolve.
  • redirect – When domain A and domain B are owned by the same entity and use the same infrastructure. The owners typically want to maintain just one copy of the SPF record for both, and configure B to redirect queries to A.
  • exists – If a domain has lots of small, non-contiguous network blocks, it can use this mechanism to specify its SPF record, instead of listing them all. Useful to stay within size limit (512 bytes) for DNS response.

A note about the “ptr” Mechanism

A final mechanism, “ptr” existed in the original specification for SPF, but has been declared “do not use” in the current specification. The ptr mechanism was used to declare that if the sending IP address had a DNS PTR record that resolved to the domain name in question, then that IP address was authorized to send mail for the domain.

The current status of this mechanism is that it should not be used. However, sites doing SPF validation must accept it as valid.

Some Example SPF Records

Here are some example records, and their meanings. This example shows RFC 1918 addresses, but I recognize that such addresses will never show up in real SPF records.

  • MX record, one IP address, one IP network, softfail everything else:
    • “v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
  • A record, two IP networks, reject everything else:
    • “v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
  • We send no mail:
    • “v=spf1 -all”
  • We think SPF is stupid:
    • “v=spf1 +all”
  • The SPF record for the domain sparkpostmail.com (redirect mechanism used)
    • “v=spf1 redirect=_spf.sparkpostmail.com”
  • The SPF record for _spf.sparkpostmail.com (exists and ptr mechanisms used):
    • “v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”

At SparkPost, we’re currently using the ptr mechanism in our SPF record. We have found it necessary due to a lack of universal support for validating the exists mechanism. And to date, we’ve seen no SPF failures result due to our using the ptr mechanism.

How Does SPF Authentication Work?

Here is what a typical SMTP transaction looks like when SPF is involved:

  • The sending server (client) connects to receiving server
  • The receiving server notes the client’s connecting IP address
  • They exchange greetings, including client’s HELO hostname
  • Client issues SMTP MAIL FROM command

The receiving server can now look up SPF record for either MAIL FROM domain or HELO hostname to determine whether or not the connecting IP is authorized to send mail for the domain, and decide whether or not to accept the message.

MAIL FROM or HELO – Which to Check?

The SPF specification stipulates that receiving sites MUST check SPF for the MAIL FROM domain, and RECOMMEND checking it for the HELO hostname. In practice, checking only happens on the MAIL FROM domain, except perhaps for those times when the MAIL FROM address is the NULL sender (i.e., “<>”), in which case the HELO hostname is the only identity available.

SPF Is Not Foolproof

While it seems a relatively straightforward way to authenticate email, SPF is vulnerable to failure in the form of false negatives. These failures can occur more frequently than many are comfortable with.

Here are two common scenarios where perfectly legitimate mail can fail SPF validation and so appear to be fraudulent:

  • Automated forwarding, where a message sent to jsmith@alumni.university.edu, a mailbox set to automatically forward all mail to jsmith@isp.com
  • Mailing lists, where mail sent to talk-about-stuff@listserv.foo.com gets “exploded” and sent to each subscriber

In both of these cases, if the Return-Path is unchanged from its original, the mail may fail SPF checks (depending on the modifier used with the ‘all’ mechanism). This is because it arrives at its final destination from an intermediate server, not the original one, and that intermediate server is not likely to be in the domain’s SPF record. A technique called “Sender Rewriting Scheme” or “SRS” can mitigate this risk, and some larger sites have adopted it, but it’s not universal.

Wrap Up

So that’s SPF authentication, how it works, how to declare an SPF policy, and what the pitfalls are in using SPF. SPF was the first email authentication scheme to achieve widespread adoption, but it’s not the only one out there. SPF authentication is most effective when deployed in combination with other anti-fraud techniques.

-Todd Herr

For further reading on email authentication, please see these great resources about topics like SPF, DKIM, and DMARC.

spam complaints

Spam complaints are one of the most important signals you have access to as a marketer. They can tell you a lot about the health of your mail program. They are also one of the main data points that ISPs look at when determining how to treat your mail. In this post, we’ll explore what they are, how you receive them, and what to do with them.

What is a spam complaint?

A complaint is registered when a user clicks the “This Is Spam” button in the mail client. ISPs track the number of people who complained about your mail relative to the amount of mail you sent to them, which is called a “complaint rate”. As you can imagine, the lower the complaint rate the better.

What is an acceptable complaint rate for good delivery?

A complaint rate of 0.2% or lower is considered good.

How do you receive complaints?

Some ISPs (AOL, Microsoft, and Yahoo to name a few) provide complaint reports back to senders via a feedback loop. The M3AAWG website has a resource page that lists the available feedback loops and more information about what they are here. At Sparkpost, we subscribe all of our customer IPs for the available feedback loops, and the complaints and complaint rate for those ISPs can be viewed in our UI.

Why do ISPs share this information?

ISPs provide this valuable information to senders in order to help them improve their mail programs. That brings us to the next question…

How should you handle spam complaints once you receive them?

Once you are signed up for all of the available FBLs, it’s important to do 2 things:

  1. Ensure you are removing subscribers who have complained from your list.
    1. Though it’s not a legal requirement… Remember, it’s one of the most important metrics that ISPs use to decide whether your mail is wanted by their users or whether it deserves to be in the spam folder, or even blocked.
    2. Plus, it’s just bad form to continue mailing to people who clearly don’t want your mail.
  2. Look at complaint trends.
    1. Send out a new campaign that generated a ton of complaints? Maybe it’s time to take a closer look at the content and targeting.

Spam complaints are a direct signal from your subscribers letting you know how they feel about your mail. Properly managing user expectations lowers your risk of complaints and increases your likelihood of good delivery performance and higher ROI.

Hope this quick overview helps give a better understanding of spam complaints and how you can use them to refine your email programs!

Happy Sending

–Clea

ps: Find this topic interesting? Check out these other related posts:

two hands email bcc pitfalls

Thou Shalt Not BCC

What’s that saying? Everything old is new again. Recently, someone asked why BCC wasn’t a valid work around for those just getting started in email marketing. Truthfully, we had to pause and think about it.

It never occurred that someone might contemplate foregoing the many competitively priced email marketing options out there. So why doesn’t BCC work as a viable alternative to other well established forms of email marketing?

BCC Pitfalls: Tracking and personalization break

The power of email marketing stems from the ability to measure success. The most fundamental type of measurement, for those getting started in email marketing, is an open. Did the recipient open the email? If yes, then assume a level of engagement. If you don’t have an open, then work on your content until you get one. The open and tracking pixel isn’t 100% reliable. Email clients that turn off images and links by default allow someone to read the text in the message without triggering the tracking pixel. Hence, this is a major source of frustration for email marketers everywhere.

How does BCC break this?

If you BCC a list of people and include the tracking pixel, you get but 1 unique open. This is the case because tracking pixels are personalized on a per recipient basis through the clicked link. You might see the link triggered over and over again, but you wouldn’t be able to discern it on a per user basis. Modern marketing applications allow you to generate an email per user and personalize all of the links and underlying redirects. The result of hitting these redirects is captured and aggregated by the sending system which results into granular reporting for the marketer. BCC would render all of that beautiful reporting absolutely useless.

Similarly to how your open tracking would break, link tracking would also render useless using BCC vs. standard unique message generation on a per recipient basis. Modern emails have highly personalized links and redirects that allow marketers to measure the efficacy of their calls to action, their primary, secondary and tertiary offers. Tracking activity by links is crucial to understanding if the content is engaging, if the offers are compelling, and if the marketer is achieving his or her goals.

In addition to measuring efficacy, link tracking is a good way to measure the user friendliness of an email template. Consider a template as a repeating construct with containers to plug in content and links. Then from there, understanding which links get the most clicks helps you refine your template. Less is more. Dropping unnecessary links from email templates, refining designs and cutting to the chase with calls to action is a marketer’s recipe for success.

What about deliverability?

In truth, using BCC doesn’t directly affect deliverability – it sounds crazy but it shouldn’t affect it at all. When you consider that someone using BCC is probably using an application not purposefully built for email, you can assume that they probably aren’t familiar with best practices. They may not be using email authentication, signing with SPF or DKIM or coding their messages properly. There are a lot of problems with using applications that aren’t designed to send email according to best practices and ISP terms of service. BCC as a delivery mechanism isn’t bad. However, it’s not the best way to accomplish the kind of engagement you want when sending email.

Let us know your thoughts in the comments below!

Wild West of bounce codes and deliverability

Navigating Bounce Codes in the Wild West of Email

Giddy-up partner! We got varmints out yonder! Just kidding… but in all seriousness, bounce codes are a little like the wild west. They’re uncertain, fraught with danger, and should be approached with healthy amounts of respect and caution.

Before getting into the meat of bounce codes, let’s review the basics. There are two basic bounce that RFC 1893 defines (and in case you didn’t know, RFC’s are the standards that describe internet technologies and are maintained by the IETF, also check out RFC 5248):

  • Transient bounces (also known as soft bounces) are defined as temporary failures or conditions that once they change will allow for the delivery of the message. There’s a numeric code that is attached, or used to define the temporary failure. We refer to this code as a 4.x.x (the x’s are variables).
  • Permanent failures (also known as hard bounces) are just that, permanent failures that will prevent the message from being delivered to the intended recipient. These bounces are classified with a 5.x.x (again the x’s are variables).
  • A sample bounce code might look something like this:

    SMTP error from remote mail server after end of data:
    host example.domain.com [2a00:1450:4013:c01::1b]:
    550-5.7.1 [2a01:5b40:0:252::55 12] Our system has detected that this message is likely unsolicited mail. To reduce the amount of spam sent to DOMAIN, this message has been blocked. Please visit postmaster.example.domain.com

Extended Descriptors

In addition to these numeric designations, extended descriptors shed more light on why messages aren’t being delivered. Email admins review these text strings, and their corresponding bounce codes to determine where problems occur – either on the sender’s side or the receiver’s. With this information in hand, an email admin makes the necessary changes on their end and can “be the town’s sheriff”. Ultimately affecting positive change, and altering the disposition of the message from bouncing to placement in the inbox.

This would be a perfect world.

However, we don’t live in that world. I wish we did, but we don’t.

Like the old west, not everyone uses words the same way. In the real world there’s a little problem with the seemingly innocuous binary construction of bounce codes and their corresponding description strings. While the RFC defines the two flavors of bounce code, there’s no blanket rule or set of strings that must be employed in the bounce to inform a sender on why delivery fails. A postmaster can, in all truth, write whatever he or she wants into the extended description making the job of the recipient infinitely more difficult. A sample bounce could then look something like this…

  • SMTP error from remote mail server after end of data:
    host example.domain.com [2a00:1450:4013:c01::1b]:
    550-5.7.1 Spammer go die! No seriously, take a long walk off a short pier!

Imagine, every domain has their own set of unique bounce codes and extended descriptions that don’t conform to the simple binary construction defined by RFC. Well you don’t have to imagine it, that’s about the state of bounces all over the world… *deep deep sigh* it’ll be ok.

Hard vs. Soft

Unfortunately for you and me, the world isn’t a neat place where everything is black and white. There isn’t really a universal agreement on what a permanent vs. temporary failure code means. Although a 5.x.x should be ‘user doesn’t exist’ or ‘domain name doesn’t exist’ etc. that’s not always the case. Certain domains believe that if someone is blocked for spamming, or for including a URL (knowingly or otherwise) in the body of the email that’s on a URL blocklist, then that constitutes a permanent failure and will bounce it back with a 5.x.x. As a long time proponent and advocate of Best Common Practices around messaging, I can see how you might want to permanently fail a sender’s messages for spamming or looking like spam.

However, in reality, one man’s spam is another man’s ham. Spammy messages or poorly targeted campaigns are rectifiable situations. Maybe you didn’t think about the implications of sending to people who haven’t received your email in years, so they ran up the spam complaints and your message went to junk or was blocked. These are things that happen on occasion, prompting work to resuscitate your reputation. This may require enlisting the help of deliverability experts like the ones that work here at SparkPost, but nonetheless, it’s resolvable. Again, the problem is that every ISP and mailbox provider does it differently. There’s no true consensus, despite the RFC, on what goes into an extended description, what constitutes a hard bounce vs. a soft bounce or how to go about remediating.

Don’t believe me? Check out this list of postmaster pages and the varying degrees they provide:

 

Confused yet? Don’t worry, we have your back! Although these are just a few of the numerous flavors of error code out there, the domains in the list above represent a lot of mail boxes. If you’re industrious and efficient, you solve for the lowest hanging fruit first. You can do this in a few steps. First, tackle the biggest domains. Incorporate those rules and learn them. Then, adjust sending volume, speed and connection rates. These are all in response to the kinds of errors that are being spit back from the domain’s mailbox provider’s MTAs. This helps to achieve righteously high inbox placement. Rest assured SparkPost does all of this.

Since 25% of the world’s legitimate and non-spam email traverses our software, we see a lot of email. As a matter of fact, we’ve been able to solve the bounce problem for more than the handful of domains I’ve listed above. SparkPost’s automated rule set, the Adaptive Email Network, employs over 3k rules that help us classify a vast majority of the bounces that currently exist in the wild.

 

Synchronous vs. A-Synchronous Bouncing

Here’s where your eyes might glaze over a bit. Bounces return in a couple of different ways. The most common is for the mail server to reject a message from a connecting IP and issue the bounce outright. This is called synchronous as it happens in synch with the conversation. A-synchronous bounces are what you and I see as users. You send an email to your uncle Joe but mis-type his address and receive an email back from Yahoo! saying the message cannot be delivered. The bounce email that you receive is sent back after the bounce, hence it doesn’t happen at the same time you try to deliver the email. The two different conditions change how and where you go looking for the bounces and your reaction to the situation.

But nothing is quite so simple. Have you gotten that feeling? A-synchronous bounces can happen in bulk. They aren’t the most common of bounces as it’s more efficient to send synchronous bounces vs. burning up your back end cycles trying to deliver email and then sending email back in response, but they do happen. Senders of bulk email need to deal with this situation in addition to processing bounces handed to them directly by the connecting mail server. Wild west, remember?!

 

What does this mean for you?

Simply put, when you know what a bounce code means you can take the appropriate actions to ensure your reputation doesn’t suffer and you’re able to reach the inbox. For example: a 421 from Yahoo! is sometimes called a gray listing and the appropriate action is to pause sending for 4 hours and retry. The only way you know this is to capture the bounce, read its contents and then apply automation rules to ALL outbound email. This puts you in compliance with the domain’s stipulated guidelines. Like I said, we got your back!

SparkPost’s vast rule set was built over 16 years of operation. Our deliverability team captures and evaluates the occasional bounce that we can’t classify, and then creates a rule to account for it in the future. Yep, we do that. Now do you believe me when I say we have your back?

Bounces are messy. Knowing what to do with them is complicated and requires the experience and ability to scale appropriate responses in real-time. That’s what we do for our clients, which makes them incredibly successful. More of our clients’ wanted email reaches their customers’ inboxes, that’s the SparkPost advantage. Come check it out, or let us know about your bounce woes. We are happy to help you out.

9 Things ISPs Really Want Email Marketers to Know

Microsoft Hotmail Outlook Deliverability Inbox

 

The Microsoft Outlook inbox is one of the major destinations for most email senders, especially those with large numbers of consumer subscribers. It also has a reputation for being somewhat tricky to get into. Here’s what senders need to know to get the best Hotmail/Outlook deliverability and ensure their messages reach the inbox.

Microsoft’s Outlook service—whether known by the brands Hotmail, Windows Live, MSN, or Outlook.com—uses a combination of factors to determine whether to treat a message as credible or as spam. Like all ISPs, Microsoft’s methods are proprietary. But we know that it analyzes signals that include content, authentication, and domain and IP reputation to create a “trustworthiness” score. Less-than-optimum scores can cause your messages to be “delayed” and/or “spam filtered.

Best Practices for Hotmail/Outlook Deliverability

Here are six best practices to help maximize Microsoft Outlook deliverability:

  1. Warm Up New IPs – Microsoft will only allow 10,000 messages per day for new IP addresses. It will delay the remainder of messages sent from new IPs. Delays are normal when developing an IP reputation.  As your reputation develops over a 2–4 week probationary period, the delays will lessen and eventually discontinue.  The volume of messages that are delivered successfully on the first attempt will rise as Microsoft moves you to a higher reputation level.

Best Practices: to avoid delays, start with 2,000 traffic to Outlook/Hotmail, double every day until you see  

RP-001 (DYNAMIC CODE) Unfortunately, some messages from a.b.c.d weren’t sent. Please try again. We have limits for how many messages can be sent per hour and per day. You can also refer to http://mail.live.com/mail/troubleshooting.aspx#errors.

 then slow down the traffic until these delays discontinue.” Note: We highly encourage senders to use their own “custom bounce domain”, “tracking domain” and “dkim sign” with their own domain.

  1. Listen and Respond to FBL Complaints – It is important to honor any unsubscribe requests whether a subscriber hits the spam button or the unsubscribe link.  Continuing to send to subscribers that have unsubscribed will harm your reputation with Microsoft. SparkPost applies for and processes Feedback Loop (FBL) complaint feedback for you to minimize this risk.

Best Practices: Add text reminding subscribers where they opted-in to receive your message.  Ensure your messages are relevant and sending at a frequency that the subscriber is expecting.  Remove subscribers that do not engage with your messages.  If as little as 0.5% of your subscribers complain, it will affect your ability to send to your entire subscriber base.

  1. Minimize “Unknown User” Hard Bounces – Do you practice positive list hygiene?  Are you sending to an old list that includes a large number of inactive or dead addresses?  Microsoft sees this as a sign of email harvesting or spamming. 


Best Practices: Practice list hygiene by maintaining your list.  Purge addresses that have been inactive for 12 months, change the frequency to addresses 3 to 6 months old.  Consistently attempt to re-engage subscribers using different tactics.  Normal unknown user rates average less than 2 to 3 percent.

  1. Avoid Spam Trap Addresses – Addresses used by ISPs and law enforcement agencies to identify email harvesting/spammers. 

Best Practices: Maintain list hygiene with hard and soft bounces. Bounce notices can provide invaluable information about how Outlook (or any provider) is treating your messages. It is critically important that you keep spam trap rates below 0.01% to avoid reputation issues.

  1. Properly Configure Your Sending Infrastructure and Content – Microsoft looks for well set up infrastructure and aligned content as an indicator of a good sender. Microsoft also applies a proprietary content filter called SmartScreen. SmartScreen learns from data provided regarding known phishing threats as well as from Microsoft customers to determine what characterizes good mail and unwelcome mail. Filtering is accomplished by probability-based algorithms used to distinguish between legitimate e-mail and spam.

Best Practices: Always use valid, reputable URLs. Avoid using IP addresses in the URL. Publish your Sender Policy Framework (SPF) records. Focus on content, as well as URLs and HTML elements.

  1. Sending Frequency and Consistency – Sending from the same IP address(es) with consistent volumes and frequencies month over month is ideal. Spammers tend to “pop up” on an IP and disappear. Infrequent senders who send large volumes once a month or quarterly can be an indicator of a spammer or a compromised server. 


Best Practices: Be consistent.  Segment your sends. Prioritize sending genuinely wanted content to a smaller number of engaged subscribers over sending generic content to your entire list. Include your call to action early in your content so subscribers will see it quickly as they scan your message.  Avoid link shorteners like bit.ly and align your links with your content.  Personalize your content to your subscribers’ interest.  Don’t send the same content to your entire list, but instead but segment and personalize using dynamic content.

The Golden Rule for Hotmail/Outlook Deliverability

Overall, Microsoft has incorporated content filtering with authentication and reputation for a combined “trustworthy” score with which it determines how to handle messages and determine Hotmail/Outlook deliverability.  So the simple answer is to follow best practices consistently. Send to only subscribers the content that they expect, when they expect it. That’s the golden rule of email deliverability to Outlook or any ISP.

For more information about Hotmail/Outlook deliverability straight from the source, visit the Microsoft postmaster page.

-Tonya

For more information on deliverability best practices, check out these articles:

 

250ok partnership

You’re probably familiar with the saying, “it takes a village to raise a child.” Likewise, it takes key partners to service the multilayered needs of today’s sophisticated marketer. Email-at-scale is complex and it can be expensive when you don’t have the right tools. More importantly, it can be disappointing when that email doesn’t arrive to the inbox. To ensure our customers have maximum visibility into how their emails are performing, we’re announcing a partnership and integration with 250ok to improve access to deliverability tools and rendering technology.

Deliverability tools are a special class of tool that help companies measure their deliverability to the inbox. These tools ensure that emails landing in the inbox render consistently across devices and they protect a brand’s reputation and measure engagement through the analysis and synthesis of multiple data sources both public and private. We’re excited to work with 250ok; they have built a best-of-breed platform that addresses the concerns of today’s data-driven marketers.

Customers using SparkPost Elite will now have access to 250ok tools, services, and reporting. From forensic and aggregate DMARC reporting to the 250ok spamtrap network, SparkPost Elite customers can now use the world’s most powerful sending technology with the market’s premiere deliverability tools provider to maximize their inbox placement and understand engagement trends. Additionally, we think they’re a pretty cool set of folks to work with, and we share a lot of the same characteristics. We’re all obsessed with good UI/UX, have a mutual respect for awesome-APIs, work at a rapid clip and care deeply for our customers’ success.

250ok partnershipAccording to Tim Moore, 250ok VP of Customer Solutions, “By combining 250ok’s analytics and reputation offering with SparkPost Elite’s platform and services, customers will have a new layer of contextual and actionable visibility allowing them to unleash the full potential of the email channel.”

We’re sure that our customers will be as excited as we are to have this amazing set of tools at their disposal. If you’re using SparkPost Elite and want to know more about 250ok, reach out to your Technical Account Manager. Or, just give me, and my colleagues at 250ok, a shout. We’ll make sure you have what you need to be successful.

For more details, check out the full press release.

How to Use Feedback Loops

For the uninitiated, FBL stands for feedback loop, the mechanism ISPs like Hotmail and Yahoo! use to report spam complaints to senders.

I know this will be totally shocking because, of course, your customers love you, but your messaging programs generate spam complaints if you send commercial email. And while there is a direct correlation between solid deliverability and a healthy response to complaints, I’m not going to drone on about it for another 500 words.

Instead, I’m going to show you how the newly­ released feedback loops module inside 250ok’s Reputation Informant helps you overcome the historical problems preventing senders from getting the most out of FBLs. It enables you to quickly understand complaint trends, pinpoint problem spots, and take immediate corrective action.

feedback loop
See? Problem spots pinpointed.

The key component of thinking about how you respond to complaints is time. Most feedback loops operate in near real-­time, meaning while there can be a delay of days or weeks between the time you send the message and when it is reported as spam, the FBL notification arrives very soon after the recipient files the report.

The only safe way to interpret a spam complaint is to take it as an indication that the recipient wants to opt-
out of that mail stream. Therefore, your responsibility is to do so, immediately.

Why?

Repeatedly sending messages to recipients who have opted-­out of those messages is the fastest way to tank your reputation. You can wind up in the spam folder, or worse, be fired by your email service provider for not playing by the rules.

Reputation Informant’s feedback loops module gives insight into several things. It shows your complaint reports over time, the current and historical rates at which you receive complaints, the largest sources by reporting domain, and top sources of complaints broken down by sending IP, subject line, and the sending and receiving addresses.

This visibility enables you to:

  • Understand the campaigns generating the highest complaint rates.
  • ­Identify the recipients hitting report as spam most often.
  • ­Predict which of your IP addresses are likely to be affected and at which ISPs.

You’re also able to drill down and examine the fine details of each complaint event.

Most importantly, the feedback loop module makes it incredibly easy to process opt-­out for complaints by allowing you to export a list of their email addresses. It’s essentially the magic-­unicorn functionality you’ve been seeking in managing your complaints.

feedback loops
Exporting a suppression list will help you opt-out your biggest complainers.

The module’s IP and date­-based filters, along with hour­-level granularity, allow you to examine complaint activity preceding a drop in deliverability at a specific ISP. You can also explore the correlation of your heaviest complaint times with your sending patterns.

Our goal at 250ok is to make every sender look great by empowering them with data and tools that simplify email. By partnering with SparkPost to bring the FBL module to every SparkPost user, we’ve made it easy to understand and effectively respond to spam complaints.

Okay, true. It was also an excellent excuse to create pretty graphs and play with a lot of data. But we swear the main motivation was building great tools for our joint customers. Ahem.

Enjoy.

paul headshot

Paul Midgen believes that inside every ruthless revenue-driven sender lurks a recipient-centered Jedi master, and he’s dedicated to setting them free one sender at a time. Before joining 250ok as VP of Engineering, Paul was CEO of Message Bus, ran Inbound Delivery & Anti-Spam at Hotmail, and has spent a lifetime working on things that allow machines to talk to each other for the benefit of humans.

 

 

we love developers