Fighting Spam

Every email marketer would love to know the special sauce that gets their messages directly into the intended recipient’s inbox. However, most marketers, especially those who’ve been doing it for a while, know just how complicated and tricky that task can be.

ISPs give us a few of their secret ingredients here and there, but most scanning and filtering tools that ISPs use are not shared publicly — and for good reason! No one wants spam in their inbox! And if spammers knew all the secrets, they could circumvent them. But for legitimate senders who need to get an email to people who have asked for their messages, sometimes it can be frustrating.

One of the clues Microsoft gives us into how they measure the legitimacy of your email message lies in the headers. In the last few years, they’ve introduced a rating system that determines how spammy or phishy they believe a message to be as well as how likely the sender is to generate spam complaints.

Microsoft’s Anti-Spam Message Headers: SCL, PCL & BCL

As soon as an email message hits Microsoft’s servers, their proprietary Exchange Online Protection (EOP) filtering service scans the message and then inserts an anti-spam report into the message headers. You can read more about all of the different fields and filters they use here, but the three fields that I’m going to focus on today that have helped us understand how messages are being processed are:

SCL = The Spam Confidence Level
PCL = The Phishing Confidence Level
BCL = The Bulk Complaint Level

When opening the message headers you can do a search for X-Forefront-Antispam-Report and find the SCL ratings underneath. BCL and PCL ratings can be found under the X-Microsoft-Antispam section. Here’s a screenshot of the message headers from a message I received in my Outlook account where I’ve highlighted these ratings.


SCL — Spam Confidence Level

After the email is received and goes through the EOP spam filtering it’s given an SCL score. Here’s a breakdown of what each means:

-1 = A special value that means the message is a safe sender and is not spam. This score tells Microsoft to put the message in the inbox.
0-1 = The content of the message was scanned and determined to not be spam. These two scores also tell Microsoft to deliver the message to the inbox.
5-9 = Starting with a score of 5 the message is suspected to be spam and is increasingly suspect to the highest score of 9 which indicates there’s a high confidence it’s spam. Any rating between 5 and 9 means the message should be sent to the Junk folder.

*Note: 2, 3, 4, 7, and 8 are ratings that are not assigned by Microsoft.

For more information, refer to Microsoft’s official documentation on SCL.

BCL — Bulk Complaint Level

BCL ratings range from 0-9 depending on how likely the message is to generate complaints based on historical data. Microsoft says they use both an internal and third-party tool to assign messages a rating — a message that receives a 2 is unlikely to generate many complaints versus a message that receives a score of 8, which is likely to generate a high number of complaints. Here’s the breakdown of BCL ratings:

0 = Indicates the message is not from a bulk sender.
1-3 = This bulk sender generates few complaints.
4-7 = This bulk sender generates a mixed number of complaints.
8-9 = This bulk sender generates a high number of complaints.

For more information, refer to Microsoft’s official documentation on BCL

PCL — Phishing Confidence Level

This rating simply determines how likely the message is a phishing message based on the content. These range from:

0-3 = Not likely to be phishing.
4-8 = Likely to be phishing and marked as suspicious content.

For more information, refer to Microsoft’s official documentation on PCL.

What Do These Ratings Mean?

So what can we take away from these ratings? If you’re having junk foldering issues at any of the Microsoft domains check your SCL, BCL, or PCL ratings. If any of these are high, it could be the cause of the junk foldering. Microsoft doesn’t disclose the specific criteria for how they assign these ratings, but looking at the ratings will let you know what aspect of your email sending you may need to improve to get better inbox placement, be it the message content or your sending practices.

Got questions or comments? Feel free to tweet us or send us a note in our community slack channel. We would love to hear from you!


Introducing the SparkPost Academy for Product Development Teams

The SparkPost team is passionate about helping product development teams build great apps with email. Our email API and delivery service is the most literal expression of that commitment, of course. But it comes in many other forms as well—whether it’s in-depth ebooks and guides, free tools for building and verifying email configs, the HEML responsive email markup language, or this very fine blog.

To that list, I’m really happy to share another resource: the SparkPost Academy. It’s a great way for product managers and development teams to build their skills and knowledge—and successful, growing apps and services. The SparkPost Academy is full of resources that will help you get up to speed and go deep on email technical best practices, user engagement, cloud development, and product growth skills.

Four Paths to Building Skills and Successful Products

Academy articles are focused on four core topic areas:

Email technical best practices: Delivering email to the inbox is surprisingly complex. Understanding technical best practices and standards will help you improve the effectiveness of your app’s email.

Email and user engagement strategies: User engagement is key to SaaS product growth. Learn how features such as email notifications convey essential information, drive app activity, and visits, and nurture user relationships.

Building and scaling cloud infrastructure: Building modern SaaS applications for the cloud is a complex journey that requires not only technical skills but also an understanding of their business impact.

Growth skills for product managers: Product managers have an outsized responsibility for the success of today’s SaaS apps. Developing a growth mindset is an essential part of every product team’s approach.

You’ll learn how to build better apps with email and discover the best practices product teams need to know to nurture user engagement with strong conversion, retention, and growth. It’s valuable information that’ll help you build a great SaaS product and your career.

I think you’ll find the first articles we’ve posted to be an easy way to begin a foundation for your growth. Even better? We’re just getting started with the SparkPost Academy, and we’ll continuously be adding new materials to each course as we go forward. Check it out and let us know what you think!



What do you want to see in 2018?

Hi Everyone!

We hope you’ve all thoroughly enjoyed the holidays with friends, family and loved ones. As we ramp up for an incredible 2018, we want to hear from you!

At SparkPost, the goal with each blog that we publish is to be helpful, informative or just plain entertaining. Sometimes we totally nail it, and other times we might miss the mark a bit. That’s why we’d like to hear what you think! What kind of content do you enjoy reading the most on our blog? How-to’s on more technical skills? Features on community members using cool technologies? Thought leadership showcasing trends in the email and messaging industries?

We’ve put together a very short survey so you can let us know what you think – there’s room at the end for comments, suggestions, etc. We appreciate your feedback and promise to incorporate it into our plan for next year. For fun, I’ve listed below our top 5 posts from 2017 – they might help refresh you on what types of content we regularly publish here on the blog:

GDPR: What Email Senders Need to Know

Europe’s GDPR privacy law is an issue for almost every company with an app, SaaS product, or other service. Learn exactly what email senders need to know before the changes go into effect.

How to Use Microservices to Build an API That Lasts

Learn some successful strategies we use to build our microservices architecture and how they allow us to evolve our API during rapid growth.

Community Spotlight: CodeNewbie

Whether you are new to coding, want to brush up on skills or just network, CodeNewbie is an incredible resource. Check out this Q&A with founder Saron Yitbarek, and get excited for some fun upcoming projects we’ve got in store with them in the new year.

RESTful API Versioning Best Practices: Why v1 is #1

Breaking changes can result in frustration and loss of trust between an API provider and their users. API versioning is one way to avoid that frustration.

How To Read Email Headers

Email headers host a treasure trove of information. Learn how to read them and understand more about the mail you’re sending and receiving.

Any industry trends or topics you think were under-represented? Be sure to list that feedback in the survey or tweet us with your thoughts!

Happy New Year!


It’s 6pm, Do you Know if Your Message is Getting Delivered?

Email delivery is an outcome easy to take for granted, but the objective industry experts at 250ok have measured that 28% of all sent email is rejected by receiving systems or lands in the spam folder. In other words, with most email delivery options, more than one in four emails never arrives in the inbox!

That’s an astonishing failure, when you consider the real-world impact of undelivered messages—missing revenue, decreased customer engagement, and operational inefficiencies. Ignoring message deliverability quite literally means leaving money on the table.

The Hidden Costs of Poor Email Deliverability

It all comes down to deliverability; the rate that your messages are reaching the inbox. Poor deliverability doesn’t just cost you money, it also limits your growth, costing you long term revenue! Thanks to malicious senders including spammers, phishers, and ransomware pushers, the ISPs have had to be more and more vigilant to prevent unwanted mail from reaching their users. This makes it much harder for legitimate senders to navigate the array of rules and systems in place to protect the inbox.

Consider the costs you may face if your message isn’t delivered: what if you’re sending a purchase confirmation to your customers to the tune of 1,000 messages per day? What if you’re seeing 28% of those messages not delivered? How much does poor deliverability cost when those 280 customers call your call center to ask what happened to their order?

What about your revenue and growth? What if your business is trying to grow at 10%, but you’re getting additional churn because 28% of your signups are not getting your email with their signup confirmation? How much revenue would you lose as a result of increased churn because of poor deliverability?

What about immediate sales? If a major retailer is losing 28% of their customer communications due to poor deliverability, what impact does that have on their bottom line? Thousands? Millions? Even billions of dollars in potential sales?

You Need to Know What Poor Email Deliverability is Costing You

We did the math, and we’d like to share it with you. Our updated guide “The Big Rewards of Email Deliverability” is available now to show you how email deliverability is calculated, how it impacts your bottom line, and how to improve it. Check it out today!



10 Steps Great Deliverability Blog Footer

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 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!


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: ipv4: ~all”
  • A record, two IP networks, reject everything else:
    • “v=spf1 a ipv4: ipv4: -all”
  • We send no mail:
    • “v=spf1 -all”
  • We think SPF is stupid:
    • “v=spf1 +all”
  • The SPF record for the domain (redirect mechanism used)
    • “v=spf1”
  • The SPF record for (exists and ptr mechanisms used):
    • “v=spf1 exists:%{i} ~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:

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.

10 Steps Great Deliverability Blog Footer

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


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!