Back to the Learning Center

By: Casey Grimes on April 24th, 2018

I Want to Believe, but: Your Email Deliveries Aren’t Real, Either.

New to next-level email understanding? Check out our earlier pieces in this series on combating false email clicks and ensuring you’re getting the most accurate data out of your Marketo instance.

Last year, I was presented with some very odd behavior by a client. This client had a devoted following of readers for an email that went out twice a week—and when readers stopped getting the emails they were expecting, they complained. When the client looked in their Marketo email logs, though, they saw these emails were getting delivered instead of bouncing. What happened?

At first, we worked with a few educated guesses:

Maybe these emails were getting stuck in their bulk/spam folders.
Maybe they were getting collapsed into other emails.
Maybe they weren’t showing up due to user error.

However, none of these were the case when we worked one-on-one with the readers. Talking to IT departments, we learned there were no filters being set up specifically to block anything from the client—and they received other emails from the company just fine.

This sender did everything right for email deliverability: they had their own IP with a very high reputation, set up their email servers correctly, and sent clean and valid emails.

It was a mystery: why did these emails, which people wanted, not show up?

In order to figure out what happened, we needed to work backwards and take a look at what happened from the moment this email left Marketo to when it was supposed to reach the reader’s inbox. Doing a technical check of what happened to the email after hitting “send” in Marketo let us see if there were any delivery problems that were causing the issues the client was seeing.

How do email systems know who sent what email and how do they filter out emails for technical problems?

Let’s say we were sending an email to you, dear reader, from DemandLab. When we set up our email, we filled the From Address: line at the top of the email editor in Marketo to come from “astronauts@demandlab.com.” Now, this isn’t the real email address that’s used to communicate to servers; it’s just a human-friendly identifier. Marketo sets another reply-to email address for delivery and tracking that’s used to send your email which looks like the following:

236-HUV-161.0.1713.0.0.1905.7.7498@potomac1050.mktomail.com

This particular email address is a unique string that changes based on the email you’re sending from your Marketo instance. It communicates specific details about each individual email being sent to a person, and thus allows Marketo to understand and report on details for delivery details for each it email it sends. As we break down this string, we can actually learn a lot about this particular email:

236-HUV-161 (the first set of nine characters) refers to the Munchkin ID of the instance that sent this email; in this case, this resolves back to DemandLab.

1713 (the third set of characters) refers to the Campaign Run ID, which is a unique number assigned every time a Smart Campaign executes. For example, if you have a Smart Campaign that sends emails once a week on batch, each week will have its own Campaign Run ID despite it having only one Campaign ID.

1905 (the sixth set of characters) refers to the Email Asset ID itself. If you click on an email inside Marketo, you’ll see a URL like https://app-aba.marketo.com/#EM1905A1LA1. The numbers between EM and the next letter are your email’s Asset ID.

7498 (the last number before the @ sign) is the Marketo ID of the person who is receiving the email (if that number seems familiar from the Google Analytics-Marketo blog post… there’s a reason.)

From there, Marketo decides what IP it should use to send this email out from its pool of IPs. Because the DemandLab instance is a standard setup, it sent out of potomac1057.mktomail.com (199.15.213.57), a standard Marketo message transfer agent (MTA) IP.

This gives us three key identifiers for who sent the email:

These factors are important to note because these are three of the main ways spam filters identify who you are and file your activity against their database of good and bad email senders. However, when it comes to the last part—the IP sending the email—you don’t control the measurement and reputation; the email’s fate is tied to Marketo’s fate.

Some Marketo customers have different setups that affect this sequence:

  • Marketo instances that have a “trusted IP” mailing range simply have a subset of IPs with better reputation that are used when sending out emails. These, too, are a pool, but it’s a more selective group that you must apply to be a part of. Only the last part of the equation changes.
  • Marketo instances with a dedicated IP address have a dedicated Marketo IP that only they use, so rather than selecting from a pool, there will be one IP tied to one emailer. However, these still send from mktomail.com as the real from address.
  • If you buy the highest-tier deliverability package available from Marketo, you actually get control of branding from end-to-end and your reputation is fully independent of Marketo’s:

Once we understand the unique email address and IP sending the email, we need to check if the email came from who it says it should come from before we bother with determining the quality of the email.

Why? As of September 2017, unsigned spam accounts for 59.56% of all email traffic.

So now that your email has been identified as a certain sender, the receiving email server or firewall is first going to do a basic check:

When an email passes these technical checks, there’s a lot of divergence depending on which email server software the receiver is using. But two main actions occur:

One action is the receiving email server sends a reply code back to Marketo’s reply-to email address detailing how the email message was handled. Although there is a standardized protocol of status codes, most email servers will send some additional information for clarity purposes. For example, if you look at X.7.1, you’ll see that the official standard says only “delivery not authorized, email refused,” but most modern servers will explain if the email was spam, found on a blacklist, or other details.

The second action is the email message itself will be examined against the server’s anti-spam measures and given a determination of quality. What gets checked is highly proprietary and varies from company to company. Here’s some of what we definitely know gets looked at:

  • Review one, two or all three email identifiers (the friendly from address, the reply-to address, and the IP the email was sent from) against a blacklist of bad senders. These lists can and often do change over time, especially with IPs; an IP that may have been good a couple of days ago can hit temporary suspension due to bad behavior from emails that are being sent from that same IP. This happens most commonly with Marketo customers who are using the default IP pool.
  • Examine the overall size of the email: how long is it in terms of characters? How big are the images that are being loaded ? Are there any attachments on the message?
  • Examine the overall content of the email: what’s the text-to-image ratio in HTML designs, and what’s the plaintext to overall HTML ratio? Are there patterns in the HTML design such as hiding links or text that’s the same color as a background? What phrasing and words are used in the email, its subject line, etc.? How similar is this email to other emails sent not only by this sender but in general?
    There’s also often checks on the quality of the HTML email code itself being sent (no broken tags, etc.), so you’ll want to make sure your emails pass validation and aren’t doing anything like embedding JavaScript or using other malicious-looking code.
  • Review overall email compliance measures: if this is a mass email, is there a physical address listed in the email to show responsibility per CAN-SPAM? Is there a clearly-identifiable unsubscribe link?
  • What behavior has the email sender shown in the past: have they emailed spamtrap addresses, which shows a lack of data hygiene? What sort of open, click and spam complaint rates has this sender had in the past?

After assessing the items we listed individually (and a few proprietary ones as well!), the email receives a score from the email server or firewall software to determine if an email is spam or not. This score determines whether the email even gets to the recipient’s inbox, let alone their account’s spam folder.

This idea of scoring is important: there’s often misinformation about what makes an email land in spam or makes it undelivered. The real truth behind things such as “don’t use X in your subject line” or “use this type of email design only” is that there are a number of factors that can affect deliverability, but nothing that will conclusively make something deliver or not deliver. It’s all about your overall score and where things are rated.

To take a look at a basic example, Microsoft uses a scoring mechanism called the Spam Confidence Level to figure out whether an email is a legitimate message or spam. This number scale from -1 (email from a known good sender) to 9 (high certainty of the message being spam) is assigned like so:

The important thing to keep in mind is that each IT administrator that runs a Microsoft Exchange Server has the power to adjust what number threshold they use when an email should be in a spam folder or even sent to the email user. Therefore, while you should always aim for a lower number when creating and sending emails, the actions taken by each email server are going to vary company by company.

It’s fully possible to have a situation where your email passes all technical requirements to get an email delivered, the email itself may never actually be seen. In other words:

So, with all that we’ve discussed in mind, let’s go back to our original mystery: why were our client’s emails with correct technical setups not being received by people who wanted those emails?

The core issue was not in the emails themselves or how they were technically sent, but the email strategy that was used:

  • The email was sent twice a week at the same email every time — the message was meant to notify people that there had been a website update and that they should click through to see the new changes.
  • The email did not change content (aside from the updated link tagging used by Marketo.)

As part of anti-spam measures, some email servers will perform locality-sensitive hashing; that is, it will make a representation of an email’s content and store that to compare against other incoming emails to see how similar it is. If it’s determined to be a duplicate or near-duplicate, it can get flagged as a repeating spam message. Over time, the confidence of the email being spam kept increasing due to being seen over and over twice a week; this lead to the emails getting “delivered” due to a good reputation but never being seen by their recipients—even in their spam folders.

The fix in this case was straightforward: deliver unique content and highlight some of those website changes in the email itself. This not only added value to the people receiving emails but made sure people who were requesting those emails received them as expected.

All of this is to say between clicks, web page visits, and deliveries, the surface-level metrics around your email efforts are most likely skewed and not truly reflective of reality. We recommend moving from looking at these numbers to measuring your prospects and customers through a customer engagement value model to have a true idea of how your messaging is being received and acted upon.

And hey, if you want to get into the weeds of things such as “what do those other numbers in Marketo’s reply-to address mean,” “how do I proactively manage email deliverability for my instance,” and “how do I raise the bar for email communication?”, DemandLab’s here to help—feel free to drop us a line.