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.

 

 

Feedback loops can affect your sender reputation and impact your entire email program

Email Feedback Loops

Maintaining a clean list and good sender reputation are critical if you depend on email to help drive revenue (and who doesn’t these days?). Doing so, however, isn’t easy. It requires constant vigilance. Thankfully, email marketers have a variety of data at their disposal to help them maintain a clean list and ensure a good sender reputation. One source of that data is email feedback loops.

What is an email feedback loop? An email feedback loop is a report that ISPs send to large-volume senders for every email recipient who marked the sender’s message as spam, also known as a complaint. Future messages can be suppressed, preventing unwanted messages in a recipient’s inbox. When recipients receive your email message, they have several options: they can delete it, read it, or mark it as spam. Because the ISP keeps track of how many recipients mark your messages as spam and uses the received-to-complaint ratio to gauge a sender’s reputation, it’s important to subscribe to feedback loops and use this data to consistently clean your list from recipients that don’t want your messages, keeping that ratio positive rather than negative (more on that in our next post).

Managing feedback loops can be a challenge. First of all, not all ISPs provide them. Of those that do provide feedback loops, there can be hundreds or thousands of domains that fall under that ISP; you don’t just subscribe to a feedback loop for Hotmail, for example, but all the domains that fall under hotmail.com as well (such as Hotmail.mx or Outlook.com).

SparkPost makes the process of subscribing to and processing feedback loops easier for senders. Senders subscribe to most feedback loops on an IP basis. Anytime SparkPost puts an IP into production, we automatically subscribe to all the feedback loops on the sender’s behalf – even for a dedicated IP.

If you’d like to get a rough idea of your reputation, you can look up your sending IP, domain, or both at SenderScore.org, and the site will provide your sender score. This includes your FBL rate, among other reputation measures. The site is managed by Return Path, a company that handles feedback loop processing for a number of ISPs. While they have a couple of large and many smaller ISPs as their customers, Return Path doesn’t process feedback loops for every ISP. It’s important to note, therefore, that the sender score they provide is based on the feedback loops they process, so it’s not 100% accurate, but can give you an idea of where you stand.

In all of this, bear in mind that feedback loops are a negative statistic – a recipient doesn’t want your message so much that they clicked the spam button rather than deleting it and moving on. You’re really looking for positive statistics, which indicate engagement. That means following the best practices of good list hygiene, removing anyone who hasn’t opened or clicked on your message in a certain timeframe. If you send to a subscriber multiple times in a week, look at 30 days opened or clicked stats and if anybody hasn’t opened or clicked longer than that, send to them less frequently or try to engage them in a different way. If you send weekly, you might look at 90 days, or if you send monthly, look at six months’ worth. The key is never to send to any subscriber who has not opened or clicked actively in the past 12 months as you run the risk of hitting inactive email addresses that have been turned into spam traps. Even when the address is still good, these recipients are clearly showing you they are not interested in your mail, and are much more likely to click the spam button and harm your inbox placement as a result.

Work toward strong engagement with your subscribers, making sure that the people you send to really want your messages. If you do that, you will be able to keep your sender reputation—and your email marketing efforts—strong.

If you liked this article then you  may also like:

9 Things ISPs Really Want Email Marketers to Know

 

FeedbackLoop_Blog1Two new feedback loops (FBLs) were released today by Return Path:

  1. Telenor: http://fbl.online.no/
  2. XS4ALL: http://feedbackloop.xs4all.nl/

These new Feedback Loops will follow the same format as their existing hosted FBLs: IP-based, ARF reports. For those not familiar with ARF (Abuse Reporting Format) reports, this format obfuscates the address of the user who complained to protect their Personally Identifiable Information (PII). More detail can be found here.

It’s important to keep in mind that simply applying does not guarantee your subscription will be accepted. The goal of offering a feedback loop for these providers is to help responsible senders to actively manage their subscriber experience by removing users who complain about their mail and using the data to adjust their targeting, in order to reduce user complaints moving forward.

In addition to these two new FBLs, there is a new resource on the horizon for senders, which will be available via the M3AAWG website. The M3AAWG Feedback Loop Best Common Practices group, led by myself and Kate Nowrouzi (also of SparkPost), has developed the M3AAWG Feedback Loop Resource Page which will be available to the public through the M3AAWG website in the next couple weeks. The page will contain:

  • A definition of the term “feedback loop” for those who are not familiar with them
  • A description of the various reporting formats
  • A list of all currently available feedback loops and links to their applications
  • Additional feedback loop related resources

Keep an eye on the M3AAWG website, Twitter, and Facebook pages for an announcement of the new resources.

If you are a SparkPost customer, rest assured that you are subscribed to all available feedback loops. We also provide guidance on program improvement to keep your recipients happy and complaints low. Find out more here.

-Clea

@EmailClea

If you liked this post, you may also like:

Gmail introduces a pilot feedback loop offering

Back in February, Gmail announced their Feedback Loop (FBL) pilot offering to ESPs to help them with identifying bad actors and spammers on their network. For anyone who is interested in learning more, the enrollment form can be found here.

For those of you who are unfamiliar with the process, here’s a brief recap. Feedback loops are essentially reports that ISPs provide to large volume senders about the number of recipients who mark their mails as spam. It’s a really important service that allows businesses to monitor their sender reputation with the ISPs and quickly take action for damage control if large numbers of recipients are marking their emails as spam. As you can already tell, this is pretty crucial for businesses that are dependent on email marketing as a main revenue stream. 

Gmail’s feedback loop, however, differs from other ISPs 

Gmail’s FBL is not in ARF format. In order to protect user privacy, their FBL is offered in the form of aggregated spam statistics per customer or per campaign, which cannot be traced back to the email address of the recipient who marked the mail as spam. This daily report provides a percentage of user spam complaint rate per customer and/or campaign of an ESP, and will be sent to the designated email address provided to Gmail by the ESP (eg: GmailFBL@example.com). The service is not designed for list management or delivery evaluation, and if there is a sizable percentage of spam in your traffic, you will receive the aggregated report the next day.

ESPs are highly encouraged to comply with Gmail Bulk Senders guidelines. Gmail requires all senders to use a consistent IP address to send mail, valid RDNS record for all sending IP addresses, and the same address in the ‘From:’ header on every bulk mail. As far as authentication, they highly recommend signing with DKIM, publishing an SPF record and adhering to the DMARC policy.

How does Gmail’s feedback loop work?

ESPs will first need to insert a feedback identifier header “Feedback-ID”. This header will identify the customer and or campaigns, mailings, and mail types. FBL reports will be generated based on these identifiers.

The “Feedback-ID” header will have a maximum of 4 fields, 3 are optional.

“Feedback-ID: a:b:c:ESPid”

  • “Feedback-ID” is the name of the header
  • “a:b:c” are the optional 3 fields which can be anything the ESP chooses (ie: campaign, mailing, traffic type)
  • “ESPid” is the only required field. This ID corresponds to an ESP customer and must be unique and persistent to that customer.

Gmail will aggregate data for the last 4 fields starting from the right side and ignore any extra fields. The data returned in the feedback report will be aggregated by the tag seen in the Feedback-ID header. Every tag will be included in the report and there are no limits on the number of total tags specified. However, Gmail will ignore tags with too few messages to prevent abuse.

Date Identifier Spam_Rate

3/17/13

 a1

1.70%

3/17/13

 a2

0.89%

3/17/13

 b1

2.50%

3/17/13

 c1

3.50%

3/17/13

 c2

2.00%

3/17/13

 ESPid

1.00%

FBL data will be aggregated by way of each identifier independently and not grouped across identifiers. Spam percentages will be reported across all the mails containing a given identifier, irrespective of the position in the identifier header. The FBL report will be sent in the form of a CSV attachment and contains data received by Gmail on the previous day by the ESP. This report is intended for gmail.com users and doesn’t support Google-Apps or Google hosted domains.

What are the DKIM requirements?

To prevent spoofing of the “Feedback-ID” header the ESP must strip any instances of this header first before inserting it and then DKIM sign it with the ESP’s domain key. This is in addition to any existing signature and is a practice commonly known as “double signing”.

There may only be up to 10 unique DKIM “d=” signing domains used to sign these headers but subdomains may be used as an alternative.

As far as DKIM key length is concerned, Gmail requires a minimum 1024-bit long key. According to the Gmail postmaster site, Gmail has been treating all emails signed with less than 1024-bit keys as unsigned since January 2013. They recommend affected senders with short keys to switch to RSA keys that are at least 1024-bits long.

How can we correctly implement Gmail’s FBL requirements in Momentum?

Multiple signatures are supported in the Momentum platform using Lua policy. OpenDKIM is now the preferred signing module in Momentum versions 3.6.0 and newer. More information about the Lua libraries for signing can be found in our documentation.

We’ve also created a simple OpenDKIM signing Lua policy that easily configures a second signing domain. You can find more info about that here.

Which Other ISPs Provide Feedback Loops?

If you’re looking for more information on how feedback loops operate, do refer to the “Complaint Feedback Loop Operational Recommendations” RFC 6449 document. And while we’re talking feedback loops, it would make sense to share links to the other trusted FBL providers out there, in case you didn’t have them already.

Now, to sum up: it’s great news that Google now provides an FBL. It has some quirks and senders will need to do some configuration to get it to work for them. But for Momentum users, that will be a straightforward process. If any readers would like to share their experience with the new Google FBL, we’d love to hear your story. Feel free to leave feedback in the comments.

 

–Kate Nowrouzi
VP, Email Delivery Operations

 As any email industry veteran can tell you, deliverability is equal parts art and science. Yes, there are a number of technical processes or settings that need to be in place in order to achieve high inbox success rates, like getting authentication (DKIM, SPF, DMARC) in place, setting up feedback loops (FBL) with the ISPs that provide them, applying to get on whitelists and so on. There are also a number of operational processes or practices – here’s where the “art” comes in – that have a big impact on deliverability. These include managing traffic shaping rules and parameters based on ISP’s acceptance policies, FBL and bounce management.

Because deliverability is such a complex subject (and many people hold strong convictions on what constitutes best practices) we often encounter confusion or uncertainty when we talk to potential customers about our Adaptive Delivery (AD) capability. Really briefly, A.D. is a module within the Momentum platform that automatically optimizes message delivery settings to reduce bounces and blocks while ensuring fastest speeds and highest throughput. It does this by:

  • Auto-tuning delivery and traffic shaping parameters in real-time to avoid blocks and safeguard reputation.
  • Proactively slowing, suspending and restarting / ramping-up delivery to avoid problems and optimize sends.
  • Warming up new IP address to build and maintain a strong sending reputation.
  • Shaping outbound traffic according to rules issued by ISPs worldwide – and continually updating the system as rules change.

This last point regarding ISP rules and continual updates is something that sets A.D. and Momentum completely apart from other messaging solutions. The way email delivery over the Internet works, each ISP has wide latitude to set their own inbound handling rules, practices and rate limits. For instance, the number of concurrent connections they’ll allow, messages per hour/per domain, and so forth. Many ISPs will have rate limits that vary based on time of day. They’ll also impose different amplitude, frequency and volume limits when you’re sending mail from a new IP address, limits that are completely different from the ones for existing IP addresses.

Some ISPs publish their rules to help guide senders into optimal sending practices. Others don’t publish rule sets at all. Some change their rules frequently, others seldom do. Given there are more than 12,000 ISPs worldwide (about 7,000 in the U.S. alone) and millions of IP domains, it’s impossible for senders to a) keep track of rules worldwide, and b) continually tweak/update their sending infrastructure to reflect constant changes. So that’s where A.D. and the Message Systems Live Rules Update service comes in.

Meet the Message Systems Deliverability Team

A.D. was very much designed to help senders navigate a deliverability landscape that’s in a constant state of flux. A key element within A.D. is its Live Rules Update service. Whenever an ISP issues a rules change, that data is collected and passed along to the Message Systems user base. New system rules are continually refreshed, automatically downloaded and installed to optimize A.D. and the Momentum platform.

When A.D. debuted in 2011, the system included rules for all the world’s major ISPs that account for the vast majority of global email traffic. Yet many senders using the Momentum platform send a significant portion of their messages to receivers in markets such as South America, Australia or remoter parts of Eastern Europe where much traffic is handled by smaller ISPs. For that reason, the Message Systems deliverability team has worked methodically to bring virtually all the world’s major ISPs (and many minor ones as well) into the Live Rule Updates network. That effort has progressed to the point where we’ve reached approximately 90% ISP domain coverage in North America, South America, Europe, APAC and Australia. In the weeks ahead, we’re going to provide a running tally of the ISPs and new geographies we’ve brought online and continue to bring online. Keep an eye on the Message Systems Twitter feed for the latest updates. Or download our brochure on Adaptive Delivery!

In this whitepaper, email expert Len Shneyder introduces Message Systems Adaptive Delivery – The first solution of its kind specifically designed to automate the monitoring of bounces and complaints, and adjust connection rates and throughput accordingly.

Adaptive Delivery Whitepaper