An introduction to SPF, Sender ID and DKIM

Email delivery can be a complicated business. If you have an account with, we take care of a lot of the trickier aspects, but there are a few things you can do to help to improve the likelihood of your emails reaching the inbox. Here's a quick guide to SPF, Sender ID and DKIM – three mechanisms which help to boost delivery rates.

What is SPF / Sender ID?

SPF (Sender Policy Framework) and Sender ID are two slightly different ways that servers receiving email can verify that the person sending the message is allowed to send emails from that domain name. 

What is the difference between SPF and Sender ID?

SPF validates the originating email address of a message. This is not always the same as the 'from' address as it relates to the actual server sending the message. SPF has been widely adopted by the major ESPs such as Gmail, Hotmail, AOL and Yahoo.

Sender ID validates the actual 'from' address of the email. Update of Sender ID among ESPs have been low, with AOL being the only larger ESP adopting it.

Why is SPF important?

SPF adds an extra layer of security to email. It makes it much more difficult to send email from forged addresses, a favourite trick of spammers and scammers. By adopting SPF, legitimate email can be more easily separated from junk.

How does SPF affect me?

SPF affects everyone who sends marketing emails.

Major ESPs like Hotmail and Gmail use SPF to screen emails. If an email is received which does not have an SPF record set then it is highly likely to end up in the junk/spam folder, and may even not be delivered at all.

If an email is received from an address with an SPF record but from a system that is not listed in the record, it is sent to the junk/spam folder or not delivered at all.

If you are sending email from an email marketing system like you need to ensure that the system is listed in the SPF record for your domain name, as this will help to maximise the delivery rate of your campaign.

How does SPF work?

An SPF record is a small piece of text that is stored in the DNS record of your domain name. This text explains which servers are allowed to send email on your behalf. When a system receives email from you, it looks up this record and checks it against the details of the server that sent your message. As only the owner of a domain name can alter its DNS record, this is a fairly secure way to manage this information.

How do I create an SPF record?

1. Access the DNS record of your domain name. This will usually be through the company you registered your domain name with, or your web hosting/design company. You need to check that this company supports creating a TXT record in your DNS. If they don't, you will need to move your DNS to another provider like This doesn't mean that you will need to change your web host, just your DNS provider.

2. Create a TXT record. You can use various online wizards to generate a TXT record for you. To allow to send on your behalf, the TXT record would look something like this (please replace with your domain):

Type: TXT
Value: “v=spf1 ~all"
TTL: 86400

3. Add the TXT record to your DNS. When you have your TXT record, you will need to add it into your DNS record. It should detect that you have a record set. Note that in some cases it may take up to 72 hours before your new record propagates.

What about Sender ID?

Due to the lack of uptake of Sender ID amongst the major ESPs, we recommend using SPF. However, if you send a lot of emails to ISPs which use Sender ID instead of SPF (such as Bell Canada or AT&T addresses), we would recommend adding a Sender ID record to your SPF record. This will look the same as the TXT record above, except the value is slightly different:

Value: "v=spf1 ~all  spf2.0/pra ~all"

I don't have my own domain name; can I still use SPF, Sender ID or DKIM?

No – you have to control the domain name to set the SPF, Sender ID or DKIM policy. As such you should avoid sending out emails from free email addresses ( etc.) through systems like

What about DKIM?

DKIM (DomainKeys Identified Mail) is a further way a receiving mail server can authenticate an email when it arrives. In simple terms, it allows the mail server to see if an email has been "signed" and not modified in transit, meaning mail servers are more likely to trust your email and send it to the inbox. The good news is, all emails sent out through are signed with our own DKIM signature.

The downside of our DKIM signature is that it affects how your 'from' details are displayed in your email campaigns - most notably in Outlook or Gmail showing that we are sending "on behalf of" your domain.

Can I remove this "on behalf of"?

Yes. To do this you’ll need to make a change to the DNS records of the domains that you send from. As with SPF, accessing the DNS record of your domain name will usually be through the company you registered your domain name with, or your web hosting/design company.

Once you’ve accessed your DNS settings, the next steps are:

1. Generate your DKIM policy. This is the policy that your domain will operate on. We recommend the following:

Name Type Value TTL TXT "o=~;" 86400

2. Create a CNAME record. This will match with a corresponding record and 'key' at our end, authenticating the DKIM signature:

Name Type Value TTL CNAME 86400

If you have an AU region account, the CNAME record you will need is slightly different:

Name Type Value TTL CNAME 86400

3. Let us know! Once this is done for all the domains that you send from, please get in touch with our support team (AU region accounts please contact the AU support team). We'll check the configuration (DNS changes can take up to 72 hours to propagate) before making the final change to your account at our end to get this all working for you.

Further reading

Powered by Zendesk