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:

17-Things-To-Improve-DeliverabilityYou’ve probably read about it: U.S. email reaches subscribers’ inboxes only 76% of the time, according to research from Return Path. It’s nearly the worst deliverability rate in the world. Only Brazil (74%) has a lower rate of inbox placement. U.S. senders are on a constant search for ways to improve email deliverability

(Of course, we should point out that in stark contrast to this flagging industry performance, SparkPost boasts nearly 98% inbox placement—dramatically higher than the industry average, and 8% better than the next-best cloud infrastructure vendor. That sort of performance is a big part of why we’re the industry’s leading email delivery service, bar none.)

So there’s no time like the present to take action to improve email deliverability. Here are 17 things you can do to increase the likelihood that your email message will get into your recipients’ inboxes, where hopefully they will open, click, and engage with you and your brand.

  1. Use double opt-in. Double opt-in is compliant with laws like CASL and CAN SPAM. It generally requires that the recipient click on an activation email that you send. It can also set up a pattern of engagement.
  2. Make your from and subject line explicitly you and true to the message. If the message is not “from” your brand, it should be from a person at your brand. The subject line should also clearly reflect the content of the message.
  3. Segment your list. All your recipients are not alike. Segmenting your list by interest and modifying frequency accordingly can drive more engagement.
  4. Implement Sender Policy Framework. By using SPF, you provide ISPs with the assurance you are who you say you are, making them more likely to deliver your message to the inbox.
  5. Prune your list. When it comes to your email list, more is not always better. If the recipient hasn’t engaged with you in 6 months, target them with a special message and if that doesn’t drive engagement, remove them from your list.
  6. Let someone help you avoid bouncing. Hard bounces should be removed from your list. At SparkPost, we add those to your suppression list right away so you don’t see more bounces, but it’s still up to you to remove those addresses from your list.
  7. Watch out for spam traps. Spam traps are emails created by ISPs to find spammers.
  8. Check your reputation. One tool you can use is Sender Score to find out where you stand with respect to your sending reputation.
  9. Don’t add emails from contests and giveaways. You’ll probably get multiple signups from the same email address. If you do these types of promotions, make sure you vet the resulting emails carefully before adding them to your list.
  10. Check blacklists. Make sure your organization isn’t on a list that automatically sends your emails into a black hole instead of the inbox.
  11. Consider the source. Where did you get that email address? Some sources are much more reliable than others. As a general rule, buying lists is a bad idea.
  12. Make unsubscribing very easy. If unsubscribing is difficult, in frustration, recipients may mark your email as spam as a way to stop receiving your email. If recipients cry spam, ISPs listen and you can quickly land on a blacklist.
  13. Register for feedback loops (where you can). How can you find out if a recipient is marking your email as spam? By subscribing to relevant feedback loop reports from ISPs. One notable exception is Gmail, which only sends feedback loop reports to email service providers.
  14. What’s the frequency? Pay attention to how frequently you are sending email and what kind of responses you get. Send email too often and you risk being ignored (or deleted without opening, which harms deliverability). Send too infrequently and recipients may forget about you. It’s a balancing act.
  15. Keep frequency consistent. Once you settle on a frequency, stick with it. Erratic sending patterns are considered a marker of spam.
  16. Study your metrics. Real-time analytics are the best way to drive your email marketing strategy. SparkPost offers numerous real-time reports and webhooks that you can leverage to drive engagement and improve deliverability. Pay attention to clicks and opens. If you’re having trouble with blacklisting, SparkPost can often work with you to help you get removed from those lists.
  17. Work to improve your open rate. Deliverability is clearly important, but it’s not the end game. You want to drive engagement, to have recipients open and click on your email. That happens with engaging content, a subject line that tantalizes followed by summary text that draws them in further.

Have further questions about ways to improve email deliverability? Read this post: Email Marketing Metrics: Beyond the Click

Yield Big Rewards with Small Email Improvements

Believe it or not, if a spam filtering system deems your email as spam or if your intended recipients mark your email as spam, your reputation score will go down. In this post you’ll learn five email deliverability best practices for achieving a good sender reputation with Yahoo! Mail. Yahoo Mail determines a sender’s overall reputation by considering many factors including, but not limited to:

  • IP address reputation
  • URL reputation
  • Domain reputation
  • Sender reputation
  • Autonomous System Number (ASN) reputation
  • DomainKeys Identified Mail (DKIM) signatures
  • Domain-based Message Authentication Reporting and Conformance (DMARC) authentication

Below are the top 5 best practices that can help maintain delivery with Yahoo.

  1. Remove subscribers that won’t engage. If an email address hard bounces (no longer exists) or returned in the complaint feedback loop (marks your message as spam) remove them immediately from future mailings. SparkPost suppresses both hard bounces and complaint feedback loop subscribers.
  2. Authenticate. Make sure your messages are DKIM signed.
  3. Send consistently. If you send emails at a certain rate and suddenly have a spike of activity, you could get flagged as a compromised sender. Honor the intended frequency of a list. Don’t send daily to a list that was intended to be sent to monthly. When ramping up volume, never send more than double your previous average send.
  4. Content matters. The subject line should not appear to be generic nor should the content. Sending email to subscribers who do not find your content relevant therefore not reading the message or marking it as “spam” will hurt your overall reputation.
  5. Reconfirm the unengaged. Consider sending a reconfirmation email to inactive subscribers periodically.

Curious about best practices for Gmail? Read this blog post.

Email Marketing Metrics Beyond the Click

email deliverability best practicesGmail uses many different references to determine inbox placement as well as delivery of your messages. Below are the top 10 email deliverability best practices you should follow when sending to Gmail as well as five bonus best practices regarding the Promotions vs. the Primary Inbox Tabs.

  • Opt-in. Gmail strongly suggests double opt-in or confirmed opt-in when possible. However, single opt-in is a must. SparkPost policy prohibits sending unsolicited messages.
  • Engagement. The most important thing to remember is to send messages to subscribers that are engaged with your brand. They are opening, reading, clicking and interacting with your brand. Interacting may mean purchasing or even getting involved with the discussion depending on your business model.
  • Overall list hygiene. Do not continue to send to email addresses that no longer exist or hard bounce (SparkPost suppresses hard bounces). Do not continue to send to subscribers that have not opened or clicked in a reasonable time. This length of time really depends on your business model. If you send daily or several times a week you should not continue to send to subscribers that have not opened or clicked in 6 months to a year with the same cadence as subscribers who have.
  • Monitor blacklistings. Gmail does use 3rd party blacklists (which ones are unknown) to determine inbox placement.
  • Avoid URL shorteners. Gmail will block most of them if used in bulk mailings, especially Bit.ly.
  • Use the unsubscribe header. Make it easy for subscribers to unsubscribe from your message! Spam complaints are not shared back to you through feedback loops like other ISPs. Therefore it is crucial that your subscribers unsubscribe rather than reporting as spam. SparkPost deploys the list-unsubscribe header and suppresses unsubscribes.
  • Avoid affiliate marketing. Gmail states you should avoid affiliate marketing as a tactic. It is also against SparkPost policy to send affiliate marketing through our system.
  • Authenticate. Authenticate with both SPF and DKIM.
  • Subdomains. Use different subdomains that well define your different email streams. (Example: newsletter.example.com; deals.example.com; confirmation.example.com) Be consistent. Don’t add too many as you want to be able to develop a reputation for each subdomain.
  • Warm up Domains just like you do IPs. If you add a new domain or subdomain do a traditional warm up to avoid bulking or blocks.
  • Gmail Warm up Volumes. Week 1 send 20,000 and double week over week.
  • Engagement. Send to your most engaged subscribers 1st then add lesser-engaged subscribers as your lists grows week over week.

Promotions vs Primary Inbox Tabs

  • Per-user filtering. Remember that just because some subscriber messages may be in the promotions tab does not mean that all subscriber messages are in the promotions tab. Filtering is done on the individual subscriber level not bulk sender level.
  • HTML to Text Balance. Keep the balance of HTML to Text similar.
  • Encourage Interaction. Subscriber awareness is important. Train your subscribers to expect the message and move the message into the Primary inbox. The messages should start going to the Primary inbox after a few moves.
  • Don’t send a promotion. When the above fails and you need a message to get into the inbox design your message to NOT look like a promotion.
    • Personalize your messages. Include the reader’s first name in your message to Gmail subscribers.
    • Lose the images. Gmail sees images as a sign of a promotion or spam message. You will in crease your readership by not having pictures.
    • Letter format. Design the Gmail template to look more personal and natural like an email.
    • Limit call-to-actions. The best way to keep from looking like a promotion is to have 1 link and not multiple upsells or RSS Feeds. Keep it short and simple!
  • Appreciate the promotions tab. When it comes down to it, if a subscriber wants your message in the primary tab they can move it there and will receive it there going forward. However, Gmail’s tabs are not new and subscribers know how they work and often go to the tab for promotions they are interested in.

Gmail rules look to be a little more relaxed once the introduction of the different folders. It is not like the scary wasteland of lost messages called the SPAM folder. If you have an interesting subject line and a brand that your subscribers want to engage with, the promotions tab will still get you opens and clicks.

Looking for best practices on Yahoo! mail? Then you might like this post.

Email Marketing Metrics Beyond the Click

 

DomainSendingStrategyBlogAfter the making the decision to send bulk email on behalf of your business or organization, one of the first things to think about is what address you’ll use in the ‘From:’ field of your messages. Many of the technical settings you’ll use to make your email seem legitimate will be connected to the domain you use in the From: address, so this is an important decision.

A key concept to understand when making this decision is domain reputation. Emails accrue reputation to both the sending IP address and to the domain they’re sent from. Email reputation is a little like a credit score; receiving systems will put together a reputation based on how good or bad the messages connected to a given domain have been in the past. While the From: address alone is easily faked, most good senders will use this domain in DKIM authentication and potentially other places in the technical headers so that receiving systems are reassured that the domain in question the legitimate sender of that message (as opposed to phishing or fraud, which antispam systems work hard to detect).

Because domain reputation looks at past history and new domains are often exploited by spammers and other malicious senders, it’s a good idea to send with a domain that is already sending mail whenever possible. If you do need to send with a brand new domain, be aware that you’ll need to build up your sending history before you can expect great results.

Do subdomains count as “new domains” or do they have the same reputation as their parent domain? Unfortunately, there is no standard for this – some systems that measure reputation see subdomains as essentially separate from the parent domain, while others bundle reputation together. Subdomains can be a good choice when you want to slightly separate out your email streams while still maintaining a connection; you might set up newsletters.company.com for newsletter traffic, and receipts.company.com for receipts.

For larger organizations considering using their main corporate domain for email, there are a couple of considerations. The first relates to security – make sure your company’s IT security group is willing to let you use the domain with a third party sender! Provided IT is ok with it, you’ll also want to verify that you understand all the mail traffic using this domain. Larger companies may have diverse groups all sending with the same domain, which can make it difficult to resolve deliverability problems if the cause of the issue stems from mailings outside your control. That said, using a unified domain for all corporate communications can help smooth over ripples in reputation resulting from one less-than-stellar mailing, and can help your recipients – both the technical systems and the actual humans receiving your email – trust you and your mailings, resulting in better overall deliverability.

SuppressionListAPIToday’s production release of SparkPost provides Suppression and unsubscribe functionality via a shiny new Email Suppression List API.

Why Do I Need This and How Does it Work?

Protecting your sender reputation is essential to maximizing your email deliverability. Many inbox providers, e.g. Yahoo, Gmail, Hotmail/Outlook.com, or AOL, opt to limit or refuse message traffic based on it. Continuing to send messages to invalid email addresses or to recipients who no longer want to receive your emails can negatively impact your sender reputation. By maintaining an up-to-date suppression list, you can avoid sending unwanted messages. A suppression list — or exclusion list, as it is sometimes called — is a list of recipient email addresses to which you do NOT want to send email.

SparkPost supports two types of email suppression lists: one (available via the Suppression List API) is specifically for your account, and a global suppression list. Message Systems maintains a global suppression list across all customers. NOTE: The Global Suppression List data is not accessible via the Email Suppression List API.

When a message is injected either using SMTP or HTTP, SparkPost will check the email address against the account-specific and global suppression lists. If an email address for a recipient matches an address on the list, that message will be rejected for delivery by SparkPost automatically.

How are Recipients added to Suppression Lists?

  • Spam Complaints / FeedBack Loops (FBLs): When a recipient clicks the “this is spam” button provided by the ISP, the ISP sends a Spam Complaint or FBL message to SparkPost. SparkPost will automatically add the recipient’s email address to your suppression list.
  • Hard Bounces: When messages bounce, the ISP will include a message that lets the sender know whether it was a “Soft Bounce” or a “Hard Bounce”. A “Soft Bounce” is a temporary error or delay indicating that the message was set to a valid recipient address, while a “Hard Bounce” indicates that the message was sent to an invalid email address that should not be retried. SparkPost will automatically add any email address associated with a “Hard Bounce” to your email suppression list.
  • Unsubscribe Requests: Recipients can request to be unsubscribed by clicking the SparkPost-provided unsubscribe link in the message or by using the List-Unsubscribe header. SparkPost will automatically add the recipient’s email address to the email suppression list.
  • Compliance Team: Recipients can contact Message Systems and request that they no longer receive messages from a particular sender. Protecting our customers’ brands and maintaining high deliverability across all Message Systems’ accounts is of the utmost importance. Message Systems’ Compliance Team ensures that we’re acting as a good sender within the email community across all our customers and takes requests of recipients very seriously. If a request is received, the Compliance Team will add the recipient’s email address to that sender’s suppression list.
  • Suppression List API: Using the REST API, you can insert/update a single entry or multiple entries in your suppression list, check the suppression status for a specific recipient, or remove a recipient from your suppression list. For more information, see the SparkPost Suppression List API.

How to Implement Link Unsubscribe Feature

The link unsubscribe features is easy to implement, simply add a link in your email in the following format:

<a data-msys-unsubscribe=”1″ href=”YOUR_APP_UNSUBSCRIBE_HANDLER” title=”USEFUL_NAME”>UNSUBSCRIBE_LINK_DISPLAY_NAME</a>

That’s it. When users click on this link to unsubscribe, your webhook consumer will receive a link_unsubscribe event and that recipient will be added to your Suppression List.

How to Implement List-Unsubscribe Feature

The list unsubscribe features is baked into every message delivered by SparkPost by default. If you would like to know how to use this feature in your applications, read our user guide: Using Unsubscribe Events

Transactional vs. Non-Transactional Messages

SparkPost gives you the option to treat Transactional messages (such as password resets and shipping notifications) and non-Transactional messages (such as Marketing offers and newsletters) differently for the purpose of suppressing recipients. For example, you likely do not want to suppress recipients from your password reset messages, but do want to honor their request to stop receiving Marketing offers. By default, SparkPost treats your messages as non-Transactional. Designate any Template or Transmission as “Transactional” to bi-pass the Suppression List. Keep in mind — if you designate all your email as Transactional and recipients either opt-out or click “this is spam” but messages continue to go those recipients — your deliverability may suffer as a result. So think about what messages truly deserve to go no matter what vs. your recipients’ desire to opt-out of and designate accordingly.

For an example implementation, check out our user guide: Using Unsubscribe Events

This is an excerpt from A Deep Dive into Momentum’s Intelligent Queuing Architecture

#1 Poor Message Queuing Capabilities are the Root Cause of Many Sending Problems

Many senders have no idea that the poor queuing capabilities of their email infrastructure are the root cause of their sending problems. Open source solutions use a very rudimentary approach of utilizing a single monolithic queue to manage traffic which creates many email deliverability issues. Many senders have dealt with these issues for so long that they accept it is just part of the business of sending email.

#2 Shared Message Queues Cause Delays

Most commercial MTA server products are little better. They force traffic into a limited number of shared queues, creating major stability problems when any one of the traffic streams encounters problems. When receiving domains deem certain content or sending practices suspect, they “tarpit” traffic from the offending sender. Tarpitting slows the acceptance of a message to a crawl by drawing out server responses to the maximum time allowed (as specified in the Simple Mail Transfer Protocol). Tarpitting causes messages queued behind the offending message to back up, delaying everything else in the shared queue. Clearing or sidelining the affected traffic could alleviate the problem. But with queuing architecture of this kind, even just determining which messages in a shared queue are causing the problem can be very time consuming.

When using a shared queue and one sender’s large mailing is submitted, these messages are placed at the front of the queues. When a subsequent mailing or transactional message is submitted, those messages are then placed in the queue behind the first mailing. Typically, this queue contention will cause the sender of the second mailing to experience delays, which will often prompt complaints and calls to the IT support operations.

#3 Message Queuing Issues Affects Sender Reputation

Left unaddressed, tarpitting and blocking issues will degrade the reputation of the associated IP addresses, and senders can find themselves in the unfortunate position of getting placed on ISP blacklists. Juggling senders and adding hardware can address the problem, but the process is manually intensive, costly and introduces operational risk. Without an effective solution, many companies find the profitability of their email operations eroding as costs outpace the growth of their revenue streams.

#4 Momentum’s Intelligent Message Queuing Capabilities Resolves Tarpitting & Blocking Issues

A key differentiator between Momentum and other commercial or open source solutions is this: as traffic is processed, Momentum creates a set of receiving domain queues for each traffic stream.

Message Queue Management

Each queue is then independently processed in parallel with the others. For example, a mailing with 50,000 messages that is throttled by the Yahoo queue for one traffic stream will never cause delays to Yahoo queues of other traffic streams. Transactional or bulk traffic will have no impact on any of the other traffic streams, and any tarpitting or blocking problem is limited to a tiny, easily detected fraction of the overall traffic.

Because Momentum enables management down to the receiving domain of each sending IP address, it can easily provide diagnostic statistics at the same level of granularity. The operator can see which traffic streams have unusually high bounce rates and what types of bounces are occurring most frequently, thereby providing the operator and the deliverability manager the information required to immediately begin remediating the issue. For more information about Message Queue Management, download A Deep Dive into Momentum’s Intelligent Queuing Architecture.

Learn more about why monolithic and shared queues used by commodity MTAs are detrimental to the speed and effectiveness of delivering messages in the Momentum vs Commodity MTAs white paper.

MomovsCommodityMTAs_Blog_Post-Ads_061614

One of the positive benefits of our annual Message Systems user conference is that we get to sit down and talk with customers, partners and friends in the industry. At the last conference in San Diego back in October, John Arnold from Return Path was nice enough to share his thoughts on the state of the email industry, where we are, how we got here, and where we’re headed. We broke his interview down into a couple of short clips focused on specific subjects.

In the first one John talks about the emerging new standards around deliverability, how ISPs have changed the ways they handle incoming messages and what this means for marketers. For context, the big ISPs such as Yahoo, Google and Microsoft have moved away from trying to block spam based on message content and have adopted acceptance practices that center on sender reputation and recipient behavior – does the message get opened? Is the recipient scrolling and clicking through? John’s explains that, for Return Path, which is the leading provider of email deliverability services in solutions, these shifts in the industry are opening up new opportunities for innovation:

“With a new paradigm of inbox tracking and going through the new benchmarks that we have, such as read rate and all the different data points that come together in that customer’s inbox, there’s going to have to be another industry that grows out of that. So the innovators and the leaders in the space that ReturnPath are working with are seeing this as an opportunity to innovate, to think, to look at all of the different metrics and data points and come up with new benchmarks and charge ahead.”

Watch the second part of the interview on Challenges of Getting Into The Inbox here.

Forrester Research and Marketo join forces to bring you a webinar on the Keys to Deliverability Success! Learn about how you can automate some of the ever present challenges, including the ever changing ISP requirements.

Keys To Deliverability Success Webinar