Skip to main content

Successful mass mailing

Happy families are all alike; every unhappy family is unhappy in its own way.
- Leo Tolstoy
Like happy families, successful mass mailings are easily taken for granted as normal, but they are more an exception than a rule.

Most mass mailings fail in one or more ways. And the ways that a mass mailing can fail are probably more diverse and interesting than you think. So when you ask "why am I not receiving my mass mail" or "so-and-so isn't getting my mass mail", it's rarely a simple answer. Even if it used to work fine.

To put some perspective on this - if you're getting only 10% of your mass mail opened, it's not bad. Industry-wide, a 7% click through seems to be about average.

In this post, I'm going to follow a piece of mass mail and show you all the different ways it can fail to be successful. I use CiviMail for my mass mailings, and but I think most of it will be tool agnostic. 

To keep it simple, I won't try and go through all the ways you can fail to even get your mail out of the mailer itself, I'll assume the mailing has gone out the door. 

1. "Deliverability" and the envelope

Once a piece of mail leaves the building, it gets sent to a destination IP as determined by the MX record of the destination email's address. That means there's a piece of software (an MTA) that is tasked with striking up a conversation with another MTA on a different machine and cajoling it to accept that mail.

Being a machine, the receiving MTA doesn't have good instincts, it can only follow rules, which have gotten progressively more complicated as the spam wars have gotten ever more sophisticated. 

But at least at this first step, the rules are limited to a few key factors. The reason for this is that the receiving MTA initially uses only a few pieces of information about the mail: 
a. The IP of the sending MTA 
b. The "sender-from" address on the envelope 
c. The "sender-to" address on the envelope
So this first step can fail in three main ways: 

a. IP reputation

The internet keeps track of mail delivery and punishes IPs that appear to not be following the accepted rules. Specifically, if an IP sends a lot of mail to undeliverable addresses, then it's assumed this IP is not paying attention to remove bad addresses and is probably a spammer. The good news about this factor is that it's fairly measurable - i.e. you can keep track of your IP's reputation, which is reported on a scale from 0 to 100.

A good IP reputation hovers just below 100, but most receiving MTAs will even accept mail from an IP with reputation down to 50. It's a policy set by the receiving mail service. 

IP reputation is probably in general overrated in importance, and it's not enough on its own, but it's easy enough to check that it should always be a first step in your diagnosis. 

b. "sender-from" and SPF 

The "sender-from" address is the equivalent of the return address on a paper envelope. You might assume it's the same as the from address in the email itself, but with mass mail, it's almost never the same. The reason is that if a message is not deliverable, it gets sent back with an explanation to this "sender-from". With mass mail, you want that mail to be processed automatically for you, so a mass mailer will stick on a clever and mostly unreadable sender-from address so that it can process your bounces for you. 

You might think that a receiving MTA could have a useful gate for accepting mail based on this "sender-from", but of course a spammer can put any "sender-from" address they like on an envelope, e.g. 

To try and solve this problem, the "SPF" record was invented. The "SPF record" is a special DNS record published for a domain that tells the world which IPs are allowed to deliver mail on behalf of their domain. So for example, if you were to type this: 
dig -t TXT 
and look at the SPF record, it would provide you with a list of ip's that are allowed to use a sender-from address (yeah, not directly, but that's a more complicated answer you probably don't want to know). 

So, making sure you've got a valid SPF record for your mail is another simple thing to check. But don't forget that regardless of having a valid SPF record, if your sender-from address's domain has been used for spamming, it still might not be accepted. 

c. "sender-to" 

The last gate here is having an address that actually exists and that the receiving machine will accept. That's usually the easiest problem to diagnose, and your mass mailer should be automatically identifying the ones that get rejected. A certain percentage of rejections (due to mailbox full or doesn't exist) is acceptable.

2. Spam filters and content

Although the three 'deliverability' gates filter out some spam, most receiving MTAs also implement some kind of analysis of the "inside" of the mail, i.e. all those headers and the body itself.

There's no way to list exhaustively all the ways to get caught by the spam traps, but here are three of the most common I come across:

a. From address

If you publish an email address on your site, and then use it as a From address in your mail, you'll almost always hit this one. Unfortunately, it's also an extremely common mistake, since that address is typically something like "" that is monitored in a very impersonal way - it feels like an obvious thing to use as the from address in your mass mail as well.

The way to think of it is this: any address that is published on your site is "tainted" because it will be harvested from your site by spammers and then used as the from address in their spam exactly because it's a known valid email address.

So, my recommendation is to always use a dedicated, unpublished address for your mass mails. I don't recommend the 'do-not-reply' pattern - if you're going to send a lot of email, you should be responsible for answering.

And also, try to avoid publishing your email address on your site, there are alternatives.

b. Content

Spam filters look extra askance at two things: attachments and links. The reason for this is because that's how viruses get propagated. In addition, attachments are often large and that's a hassle for storage, etc.

Conclusion: if you really want to send a pdf or image in your mass mail, make sure you're just linking to it, not actually "mail attaching" it. And don't ever link or send something that looks like it might be a virus (e.g. a file ending in .dll or .exe).

c. Sending mail to yourself

If your "from email address" uses your organizational domain (which it usually should) then you often get tagged as spam for recipients at your organizational domain. So everyone in your organization fails to receive your mass mail!

The reason for this is that the receiving system hasn't sent it, but feels like it should have. Or more to the point, pretending that your mail is from someone in the same organization as the destination is a common way to try and get spam into an organization's email.

This can happen even if you've followed the SPF rules, which is only about the 'sender-from' address. In this case, the recipient MTA needs to be told that your mass mailer is allowed to send mail from your domain to your domain. I mostly run into this with Microsoft services.

3. Getting Read

Okay, let's assume your message has been accepted by the receiving MTA and not ditched by the spam filters (which, incidentally, may or may not actually tell you the sender that they've thrown it out).

If you're a system administrator, you're job is done, but since I called this "successful mass mailing", I'm also going to talk about a human actually reading your message.

Much ink has already been spilled on this topic by more knowledgeable content writers than I, but I'd like to give you a few really easy things to consider.

As a recipient of your mass mail, I'm sitting here looking at a screen with a long list of emails, most of which I might not ever read. Your job is to give me the right information to help me decide that I want to open your mail. Typically, what I use to make that decision is: the from address, the subject line, and the "snippet".

a. "Friendly" From Address

The "from" address is made up of an actual email address as well as (usually) a "friendly" name. Most of the time, the recipient will only see your friendly name. Make sure that the "friendly name" of your from address, as configured in your mass mailer is not too long that it gets truncated. You probably don't want to keep changing it, though I see that the latest strategy seems to be to use individual names instead of organization names.

b. Subject

Also don't make this too long. It's not the title of your academic paper, it's gotta be short or it'll get cut off, but enough to tell them what your email is about so they can decide whether they want to read it. People who do this for a living will try out a few different headlines on a subset of their recipients to test which ones work best (it's called A/B testing).

c. Snippet

If your mass mailer is good (e.g. if you're using Mosaico in CiviCRM), you can specify the 'snippet' that is shown in most mail interfaces. Originally, and by default, this is just the beginning of your email body, so if you don't specify it, it'll often be a wasted repetition of something like "click here to unsubscribe". Doesn't make a good first impression ...

So there you have nine different ways to not be successful with your mass mail.

Of course, you're the expert when it comes to knowing what to actually put in your message, and what actions you might want your recipient to take. That's probably where you've put most of your energy and thought!

Popular posts from this blog

The Tyee: Bricolage and Drupal Integration

The Tyee is a site I've been involved with since 2006 when I wrote the first, 4.7 version of a Drupal module to integrate Drupal content into a static site that was being generated from bricolage. About a year ago, I met with Dawn Buie and Phillip Smith and we mapped out a number of ways to improve the Drupal integration on the site, including upgrading the Drupal to version 5 from 4.7. Various parts of that grand plan have been slowly incorporated into the site, but as of next week, there'll be a big leap forward that coincides with a new design [implemented in Bricolage by David Wheeler who wrote and maintains Bricolage] as well as a new Drupal release of the Bricolage integration module . Plans Application integration is tricky, and my first time round had quite a few issues. Here's a list of the improvements in the latest version: File space separation. Before, Drupal was installed in the apache document root, which is where bricolage was publishing it's co

drupal, engagement, mailing lists, email

I lived, worked and studied in Costa Rica from 1984 to 1989. Ostensibly, I was there to study Mathematics at the University, and indeed I graduated with an MSc. in Mathematics supervised by Ricardo Estrada (check that page, he even advertises me as one of his past students). And yes, I do have a nine page thesis that I wrote and defended in Spanish somewhere in my files, on a proof and extension of one of Ramanujan's theories. But mathematics is a pretty lonely endeavour, and what drew me back to Central America (after the first visit, which was more of an accident), was the life and politics. The time I lived there was extremely interesting (for me as an outsider, though also painful and tragic for it's inhabitants) because of the various wars that were largely fuelled by US regional hegemonic interests (of the usual corporate suspects and individuals) and neglect (of the politicians and public) - the Contra war in Nicaragua, the full-scale guerrilla wars in El Salvador and

Orchestrating Drupal + CiviCRM containers into a working site: describing the challenge

In my previous posts, I've provided my rationale for making use of Docker and the microservices model for a boutique-sized Drupal + CiviCRM hosting service. I've also described how to build and maintain images that could be used for the web server (micro) service part of such a service. The other essential microservice for a Drupal + CiviCRM website is a database, and fortunately, that's reasonably standard. Here's a project that minimally tweaks the canonical Mariadb container by adding some small configuration bits: That leaves us now with the problem of "orchestration", i.e. how would you launch a collection of such containers that would serve a bunch of Drupal + CiviCRM sites. More interestingly, can we serve them in the real world, over time, in a way that is sustainable? i.e. handle code updates, OS updates, backups, monitoring, etc? Not to mention the various crons that need to run, and how about things