It looks like Royal Mail are finally joining the 21st Century, earlier today I received a combined SMS and email delivery notification, no time slot, but knowing how regular my postman is it’s likely I can avoid queues at the post office!
Having worked in email marketing for the last 15 years I tend to have quite a critical eye for the finer details of email campaigns but, for such a well established business like the Post Office, I was left shocked by some of the basic mistakes they made this time.
Taking a look at the details of what they got wrong is a good opportunity to revisit a couple of our favourite topics – testing and deliverability!
Testing
Most ESPs provide a full suite of tools to fully test emails before campaigns are run or transactional processes are put into production.
Agencies spend hours tinkering with HTML and CSS then running numerous tests through Litmus ensuring the email renders correctly on mobile and all other email applications.
The email I received would not render correctly on anything! To understand the fundamental issue lets take a look at the message source.
Message-ID: <250416877.539601402985265913.JavaMail.esbprd1@huesbpd1>
Subject: Royal Mail: Item ready for delivery
MIME-Version: 1.0
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear Customer,
Royal Mail has received your item from WIGGLE LTD (No: XXXXXXXXXX) at Shrewsbury DO Delivery Office. Your item is now ready for delivery and we will attempt to deliver it today subject to any alternative instructions that you have previously agreed with us.
Regards,
Royal Mail
For queries please visit www.royalmail.com or call 08457 740 740
Please do not reply to this message. This email was sent from a notification-only address that cannot accept incoming email.
The source view of the email message looks fine and the text is nicely laid out and legible. However the content type has been declared as text/html and not text/plain.
As the content does not contain any HTML line breaks or paragraphs all of the content gets collapsed onto one line.
Receiving a poorly formatted message makes it very hard to read and reflects poorly on the brand. When testing is so simple in many solutions it’s hard to understand why this stage would be skipped by both the developers and project managers.
Ironically I was busy enhancing our testing tools when I got sidetracked by this email. One of the new features we are adding will be the ability to comment on and approve test emails for delivery – watch out for this in a future release 😉
Tracking
All email tracking is done using a small invisible image inserted into email, when the image is requested ESPs record information which can then be used for reporting and analysis.
Transactional email really should be tracked and monitored as the content is often time critical and can contains important information such as booking confirmations. The data gathered through the tracking process allows customer support teams to diagnose delivery issues and deal with customer enquiries.
On a more basic level tracking open rate also allows you to monitor inbox placement at the major ISPs.
The delivery notifications from the Royal Mail did not include any tracking images so they will be able to gather very little insight.
Deliverability Headers
ISPs user a number of methods for validating the authenticity of email and making decisions on inbox placement, Google include an authentication results header on all mail they transfer which is a really handy summary:
Mon, 16 Jun 2014 23:07:46 -0700 (PDT) Received-SPF: pass (google.com: domain of noreply@royalmail.com designates 144.87.143.123 as permitted sender) client-ip=144.87.143.123; Authentication-Results: mx.google.com; spf=pass (google.com: domain of noreply@royalmail.com designates 144.87.143.123 as permitted sender) smtp.mail=noreply@royalmail.com; dmarc=pass (p=NONE dis=NONE) header.from=royalmail.com
It’s pretty much the accepted standard that all reputable email is now signed using DKIM and the Instiller reputation monitor actively checks for these records. We can see from the Google summary these outbound messages are not being signed and a quick check of DNS shows Royal Mail is not using DKIM at all.
SPF and DMARC records have been created so it seems a little odd to have skipped this step.
DMARC
It’s only fair to highlight an area they have got right, DMARC. Operating high volume delivery notifications for large corporates with a household name gives cyber criminal the opportunity to operate a fairly basic phishing scam.
“We tried to deliver your parcel, fill in your details here to re-arrange delivery”
It’s very encouraging to see that they have partnered with industry leaders Agari who provide DMARC services allowing brands to monitor and mitigate these types of attacks.
v=DMARC1; p=none; pct=100; rua=mailto:d@rua.agari.com
Their DMARC implementation is however very permissive, which I’m guessing is due to the fact that this is the main corporate domain and it needs to cope with lots of different mail systems.
Segregate Traffic Streams
We have always advised that it’s best practice to segregate traffic streams in a number of ways to mitigate deliverability issues and manage reputation. Typically this is done using separate IP addresses and sending domains.
This prevents issues from one traffic stream causing issues to other areas of the business, in the past we have seen corporate email being blocked or heavily filtered by an ill advised marketing campaign sent using the same IP address and sending domain.
Segregating by domain also allows much tighter control over the deliverability policy records, in this example the Royal Mail could have used a separate domain name for notifications and applied a stricter DMARC policy to help prevent phishing.