Qoding: Delving into email records with PTR & SPF

You fire up your favourite marketing tool, bash out a quick email and send it to your twenty thousand contacts. All you need to do now is sit back, have a coffee, and wait for the cash to roll in. But wait…

Your marketing suite just reported that 75% of the emails didn’t get through! What’s going on?!?

If this sounds familiar, it’s likely that you have fallen foul of the complex area that is email DNS settings. I’m not going to delve into this topic in its entirety, but rather look into two specific settings; PTR and SPF.

Firstly, it is worth checking the email SMTP logs to see if a response has been returned from the emails that failed to get through. It’s likely that you will see something along the lines of:

The+email+sent+from+111.222.333.444+by+ bfranklin@quba.co.uk+was+rejected+by+ the+receiving+server+as+the+sending+server +does+not+have+a+valid+HELO+message.+Please +got+to+http://www.emailbouncing.info/ #validhelorequired+for+more+information.

Basically, this is saying that the email arrived at the recipient, and the recipient didn’t trust it. It thought it was a spoof email and rejected it.

It’s a bit like the story of Little Red Riding Hood. Stick with me here...

The wolf is dressed up as Little Red Riding Hood’s Grandma. He looks and sounds like the Grandma, but if you look closer things don’t quite add up. Grandma didn’t have claws, did she? And why is she so hairy? She definitely doesn’t have a valid HELO message.

OK, no more fairytale analogies I promise. In my defence, I have young children.

So why did it get rejected?

PTR

The first thing to check is if reverse DNS is setup correctly for the domain you are sending from. You will no doubt have an A record setup, which maps your domain name to an IP address. What you may not have is the inverse, a record that maps the IP address to the domain (the PTR record).

With the exponential growth of spam, email providers have hardened their rules. Many providers will block an email that is received that doesn’t have a valid reverse DNS setup.

You can check if you have a PTR setup by using the following commands:

Windows

nslookup 111.222.333.444

UNIX/LINUX

dig -x 111.222.333.444

If you don’t have one, you will be able to set one up via your DNS provider (or they can do it for you). You can only have one PTR record per IP address.

SPF

The second possible cause is that the IP address that the email was sent from is not permitted to send emails for the sending domain.

For example, if an email is sent from a marketing suite, this will be sent using an IP address belonging to the marketing suite, not the domain present in the email. This is a valid use case, but it can of course be used by spammers to send phishing email. Hence, email providers block the request.

To counteract this an SPF record is used to record which IP addresses are permitted to send email for the domain. The receiving server checks this record, and compares the IP of the sender to the values that are allowed, thus deciding whether to permit the email.

There are numerous online tools that allow you create these records, which can then be added as a TXT parameter within your DNS provider. An example would be:

www.quba.co.uk. IN TXT "v=spf1 a ptr ip4:111.222.333.444 ~all"

By changing various parameters, it is possible to allow various IPs, domains and also mark how strictly the rules should be enforced. More details can be found at http://www.openspf.org/SPF_Record_Syntax

Hopefully this post will help you improve your delivery rates, and get your emails through to those that need them.