Why ignoring the email SPF record may be destroying your email marketing campaign?

computer with codeWhat is an email SPF record?

A Sender Policy Framework (SPF) record is an extra entry in your Domain Name System (DNS) zone file for your domain. In specific technical terms, it is a TXT record that is added to your DNS record and details the servers that can send email on behalf of the domain.
Think of it like a whitelist of the servers that can send email using the @yourdomain.com suffix.
An example of a simplistic email SPF record is as follows:-

“v=spf1 ip4: -all”

In this circumstance, only the server at IP address is authorised to send email. This extra TXT record is then tagged on to the main domain record within the DNS server. The important thing to understand about email SPF is that it is relatively new to the Internet having been accepted as a standard in 2006. It is not part of the Mail Exchanger (MX) domain record system that is universally supported by all mail systems and is rarely configured as part of a standard cPanel hosting setup.

Most of the time, you must do it yourself.

Please explain SPF in a non-technical way?

The original internet protocol that controlled who received email was called Mail Exchanger (MX). We still use it today.

It was designed to deal with who received the email and never really bothered about who was doing the sending. Software guys thought like that back in the seventies. They were just trying to make it work.Back then, anyone could send email using a domain providing they had access to an email server that allowed open relaying. Handily enough these were quite common as well. As the internet grew and spam became more of a problem the boffins decided to implement a new standard to control who could send email as a specific domain. This became the Sender Policy Framework.

The problem was that it was not part of the early standards and not supported by any of the ISP’s or email delivery providers who offered services. It was always going to have to be introduced gradually. That was ten years ago. Email SPF is much more common now and many of the major email services will fail if it is not set. Many older webmasters have still not set their SPF record correctly on their domains and now email is going to spam without them knowing.

Why is email SPF relevant to digital marketers?

Normally this is a tech issue. Someone has noticed that when they send email from a work email address to a gmail account that it ends up in spam. The technical support guys looked into it and have now added a new SPF record to the domain with the details of the email server that handles sending the work email.Email that is send out from the corporate email system now no longer goes into spam on email providers with SPF enabled spam defences. This is great.

There is only one problem.

No one told the digital marketing team.

The week after the SPF record was added the digital marketing team sent out its monthly newsletter and most of the email bounced. Oh dear.

But it worked before?

The important thing to understand in the above situation is that there was no SPF record before. No-one was checking the email SPF because the domain did not explicitly have an email SPF record to check. No-one bothered.

Remember, the tech guys have setup a specific SPF record that states that the corporate email server is the ONLY server that is now allowed to send email on behalf of the domain. Anyone that was previously giving it the benefit of the doubt because it never had an SPF record now has absolutely no doubt whatsoever. The problem is that the digital marketing team don’t use the corporate email server to send out their newsletter. They use a third party email provider like Mailchimp, Sendgrid or GetResponse to do it for them. The SPF record that has just been added to the domain makes no mention of this third party server. That server is now about to attempt to send ten thousand people the monthly newsletter.

No-one now believes it is allowed to do this. So it bounces.

What do I have to do to fix email SPF?

The email server details of the third party mail server have to be added to the SPF record.
It may be tempting to just delete the SPF record but it may hang about a bit and it is most unfortunate having to apologise to clients because email is now turning up in spam again. A modern SPF setup uses a CNAME to create a name that links to the third party and then joins the TXT based SPF record to the CNAME. A properly configured SPF record with a third party looks something like this:-

v=spf1 include:spf.mydomain.com include:server.thirdparty.com -all

Both spf.mydomain.com and server.thirdparty.com are CNAMES to separate email servers that are authorised to send.

The email providers have guides for doing this. They can be found here:-
Mailchimp: http://kb.mailchimp.com/accounts/email-authentication/set-up-custom-domain-authentication-dkim-and-spf
Sendgrid: https://sendgrid.com/docs/Glossary/spf.html
GetResponse: https://support.getresponse.com/faq/how-good-is-deliverability

The bad news is that this is quite a technical job. Those who have changed DNS settings in the past should be ok if following a guide. Those users who have never logged into something like cPanel will find it a struggle. Most of the third party email providers offer a tool to check the configuration. The complete setup usually requires a custom domain to be configured with the provider so that they can properly send email with the correct reply domain. The short of it is that this is usually quite a technical operation to get right. Some understanding of DNS is required and CNAME can confuse people. If all this is a bit overwhelming then seek technical advice. Changing DNS settings can take down email or websites.

How do I check that it is working ok?

There is a really great tool at https://mxtoolbox.com

Putting a domain into it will check lots of things about the domain email configuration. This should show the SPF record clearly or warn if it is missing. It is always worth fixing any red issues, including DKIM and DMARC which provide a similar role to SPF.

A screenshot of MX Toolbox

Will this fix the problem?

Having a correctly set SPF record so that only legitimate email servers are allowed to send email on behalf of a domain is a good thing to do. It also stops nasty people trying to spoof the domain. What it will not do is stop all bounces.

There are many factors why email gets marked as spam or bounces and SPF is just one of them. Using a diagnostics tool like mxtoolbox.com to analyse a domain is essential here. There may be lots of other problems at work here. Having a correct SPF will only help.

Do I need to keep changing email SPF?

Generally speaking, once it is all setup that should be it. The standards do occasionally change so occasionally running an email diagnostic tool every few months should suffice. Receiving reports of email bouncing or spam trapping is always a good excuse to run the tool.
If the third party email provider is changed then the digital marketer must ensure that the SPF record is updated (or the tech team notified). The tech team must also be conscious that changes to DNS, MX and email SPF may impact external marketing efforts.



Having control of the SPF record and making sure it is correctly configured for all email providers is a necessity of good email marketing. A digital marketing team must know who owns the domain DNS record within their organisation and ensure that their third-party email provider is properly listed and integrated. If they do not they risk their mailing list email bouncing. It may be the job of tech to do the configuration changes but a good digital marketer needs to understand what is going on.

Technical Appendix

The situation described above is actually quite rare. Most of the major third party email providers send email out with a reply address set to a subdomain of their own domain. This means that the SPF record of the owner’s domain plays no part as the domain is not actually the sender address. Some do not, however.
It is always best to set a custom subdomain with the third party provider so that both the sender address and SPF record match the originating host domain. This is the ideal setup and validates both the email address and the legitimacy of the main corporate domain. It also looks far more legitimate for users who pay attention to sender addresses. It will only ever increase conversion.

Free accounts for a limited time only!

Claim yours today

Signup Now


Richard Norman

Richard Norman

Richard is the Technical Lead and Co-Founder of Yatter. He is an experienced software architect and possesses a deep understanding of the underlying structure and design of a social network. Well we hope he does because he designed Yatter. His articles tend to have a technical slant and he also has a passion for long form content and SEO. Richard is also a qualified accountant.