A transactional message is one that verifies that a transaction – like money changing hands – has taken place.  Other messages that fit the secondary definition might include a Double Opt-In verification, or a Welcome message.  Quite often transactional messages are sent by an organization’s back-end system through a simple SMTP of Postfix mail account over a company IP address.  These messages are usually sent in plain text format, but can also be sent in HTML – and hopefully with Multi-part MIME.

Most recipients can’t tell the difference between a system-sent email and one sent from an ESP or in-house commercial MTA, but there’s more to email marketing than being pretty….

The first, and perhaps biggest, problem with system-generated email messages is the lack of visibility – across the board. 

There is usually no visability into bounced messages.  Messages that bounce usually come back to an assigned POP3 email box, where they are regularly purged without ever seeing them.  Oh, sure, some may use a bounce handler like ListNanny or Boogie Tools, but are they using that software to it’s fullest to create comprehensive log files, or are they just counting sheep? 

And what about those bounce handlers?  Do they log all information that comes with a bounced message so that the marketer can actually do something with it, or do they just list a 4xx or 5xx code next to an email address?  This is important because there are no RFC police making sure that all ISPs are using standard codes as designated.  I’ve seen many an email bounce back with a 4xx code (soft bounce) with a 5xx (hard bounce) description.

Now, if you don’t know what I’m talking about with all this RFC and 4xx/5xx code stuff, then you’re probably not qualified to be setting this sort of thing up.  And if you’re relying solely on 3rd-party software, you’re missing the boat, too.  I don’t want to get too technical here, and as much as I like following tangents, let’s move on….

Next up, Feedback Loops.

Hopefully system messages are sent from a different IP address than the corporate exchange server.  If not, well, that can present a whole list of other problems – like having your corporate business mail blocked due to being listed on RBLs.  Sometimes that’s price that’s paid for not having visibility into what’s going on with system-generated messages and being stupid enough to send those messages over exchange server IPs.  So many tangents, so little time….

Back to FBLs….

So let’s assume that system-generated messages run on their own IP address.  Has the tech team set up FBLs?  After all, if tech wants to run these system-generated messages then it’s their job to make sure that FBLs are in place.  And just like bounces, we’re not just counting complaints – that’s not good enough. 

You see, when someone makes a complaint and the information is passed back to the sender from the ISP, the ISP has this little expectation that the sender won’t be mailing the complainant any more.  And not all ISPs are going to make removing the complainant easy for the sender since many will redact the complainant’s email address when registering the complaint with the sender.

Now tech is going to have to code a unique identifier into the header that maps to each recipient of the message sent.  But that’s not all….  Let’s see a show of hands; who thinks that it’s a good idea to also identify which message garnered the complaint?  What about recurring messages?  Yep, that’s right, each iteration of each message should have its own unique identifier in the header along with the unique recipient identifier. 

And we’re still not finished….  Now that we have the data, we need to do something with it – like suppress the complainant from receiving future messages.  Who can guess why each iteration of each message needs to be identified?  If you guessed – or knew – that it is because we want to be able to identify any messages that generate more complaints than others, move ahead three steps.

Think that’s all?  Nope….  Since not all transactional messages are created equal it’s a really good idea to run each type of transactional message on its own unique IP address.  Why?  Because you don’t want anything to interfere with your ability to deliver purchase receipts or any sort of paid subscription services.

There I go, off on another tangent….  But getting back to Bounces and FBLs, what kind of log files are available and do marketers have easy access to them?  Are they in real or near-real time?  Are they regularly monitored and analyzed, or does marketing have to put in a request to DBA and wait until DBA gets around to it?

We’re just scratching the surface here, and I’m already over 800 words for this post. 

Wouldn’t it be easier for tech to just write a stored proc and just send the data to an ESP and let Marketing deal with transactional messages?  Sounds like a better plan to me…. 

But what about organizations using an in-house system?  Serious commercial MTAs are going to take care of most of the bounce processing and logging for you, you’ll just have to code it so that it’s easily available in a UI instead of over a CLI, but you’re on your own for FBLs.

Still think that system-generated email messages are the way to go?