Email lists, bulk emailing, the SPF, DKIM, DMARC, SNDS or JMRP who knows



Is it the SPF? Is it DKIM, SNDS or JMRP, its DMARC right, no wait.. damn, just who knows. 

So your trying to send an emails a lot, or an bulk email and whoops, it's not right.

Anyway, here's the 10 point plan that can help

Step 1 SPF

Make sure your SPF only lets who you say can send email on your behalf.

Step 2 DKIM

DKIM (Domain Keys Identified Mail) - bit tricky and hard to handle the responses, but if there google will love you especially at the their postmaster tools area https://postmaster.google.com/.

Step 3 SNDS and JMRP

SNDS (Smart Network Data Services) & JMRP Junk Mail Reporting Program- this is sort of the same thing now.

Step 4 DMARC

Yep, that too - Domain-based Message Authentication, Reporting & Conformance

Step 5 Static IP

If you can, get your own IP, take it slow and warm it up and don't let anyone else use it.

Step 6 Wait, where did I get these emails?

Your going to ensure that as you build your list that it grows properly and with valid data. I'd recommend starting simple, ask for an email, verify (step 6 below) and build on that (step 7, 8, 9)

If you get it from elsewhere like a lead generation or whatever - request confirmation that every email is valid and even send a test to the lead generation list to see how valid the list is.

Step 7 Wait, did I check or verify that was an email?

Golden fail of all those "build your subscriber list fast" plugins you see all over the web. They often don't have a captcha and you never verified the email; Google has the simplest and best one to ensure its a real user, but wait ***@hotmail.con, really- nope not an email. Cardinal sin for your list management. No email is a subscriber until verified. At the very least mark your list with "verified" emails vs "non-verified"

Step 8 Wait, did I ask you how often you'd like to be contacted?

Always a critical one, if you have 5 emails a week to send out because either your are prolific or you have lots of stuff to sell or tell - not everyone has time to read that stuff and will get eventually get rid of you. This is easy, you just need to set up some type of manage your preferences section, most bulk senders can provide this.  

Step 9 I know I send a lot of emails, did I ask you what you wanted to hear about?

You know, like I'm interested in shoes, not men's shirts, or I'm in Kansas - not California. As above, just expand on a preferences section.

Step 10 Do I really know you

Following on from your location - it would be good to know anniversary details, birthdays, siblings etc; you can just build on that to help the subliminal aspect of your message.

Step 10b I know I know you, but it's been a while...

So you have all these subscribers who haven't opened your emails for ages, but wanted to be mailed every 2 weeks. What to do? 
a) Ask them if they are still interested or update their preferences
b) Ease off and maybe contact them less frequently

I think easing off is a bit easier - others will argue if you ask them to unsubscribe, then they will actually engage - test it. 

In Summary (ok it was 11 points, and I squashed 10 into two parts)

You can get some third party tool to help you with the data of your subscribers and some whiz bang solution, but at the end of the day, your domain is bad, if your list is bad, your screwed.

It's a bit of a black hole trying to figure out what's going on but signing up for https://postmaster.google.com/ will help figure out your domain health, the rest is all about your subscribers and how you collect and maintain them.

Comments

Post a Comment

Popular posts from this blog

cf_sql_timestamp vs cf_sql_date vs getdate()

If there's one thing I don't like it is people confusing a date with a timestamp, and how a lazy bit of development can ruin a load of data. Here is a simple query inserting data to a timestamp I found in a system where all the created dates were truncated because of the incorrect syntax. Bad one which was in use: insert into testdate values (<cfqueryparam cfsqltype="cf_sql_date" value="#createodbcdatetime(now())#">); Result :  2015-09-29 00:00:00.000 Best One (easiest to read) insert into testdate values(getdate() ); Result : 2015-09-29 10:10:09.880 Not great (no binding) insert into testdate values(#createodbcdatetime(now())#); Result :  2015-09-29 10:14:44.000 What the bad one should have been insert into testdate values(<cfqueryparam cfsqltype=" cf_sql_timestamp " value="#createodbcdatetime(now())#">)
Read more

Global SQL Procedure, System Objects and sp_ms_marksystemobject

You may come across a need to have a database of utils full of generic procedures which work on indvidual databases (say client databases). You can't pass the database name into the procedure as a parameter and say "use @dbname" in the procedure and dynamic sql sucks. One workaround is to create the procedure in the master database and then mark it as a system object. eg use [master] create procedure sp_doThis // note the sp_ prefix is required begin // etc etc end go exec sp_ms_marksystemobject 'sp_doThis' // second note, this procedure is undocumented, so I wouldn't be relying on this for life or death. use [myotherdb] exec sp_doThis go All done!
Read more

Ghost Records, Card Recon and PCI Compliance

As part of a PCI Compliance audit, I recently ran a scan on a database using software call Card Recon. A little odd thing occurred. At a point in the past, a row of data in a column, which had been dropped from the database schema, contained a single test credit card number. However, the Card Recon software showed that the data was still there in the database file (this was a SQL Database) in the form of a SQL Ghost Record. A Ghost Record can appear when running a delete or insert command and when running delete and insert in different queries but related by the same indexed data, you can read all about it over at Ghost "Rows" Buster in  SQL Server on Technet. It's basically a record somewhere in the database file, but not directly in a database table and is living in a bit of spare fragmented space somewhere and this needs to be cleaned up. Following this procedure managed to remove the Ghost Record: Convert the database to Simple (only so the transactio
Read more