Written by Ben on March 12, 2021

Prevent email spoofing with SPF, DKIM and DMARC

This guide is for you if:

  • you're configuring your own domain name & want to improve deliverability
  • you're configuring a domain name for a simple cloud email service
  • want some links to other, more in depth resources.

This guide is not for you if:

  • you're an expert looking to improve your knowledge
  • you don't know why you need these things at all

The 5 steps I always follow

  1. Use the free Cloudflare account for DNS (register here)
  2. I get domains from Porkbun, Cloudflare or TSO (in the UK).
  3. I add the domain to Cloudflare and configure the domain host to point at Cloudflare's DNS
  4. Then I configure the domain with SPF, DKIM and DMARC settings for the services I use to send emails (usually Google Workspace and SendInBlue, or AmazonSES)
  5. I add the domains to a free Postmark DMARC monitoring account, to get a weekly report.
  6. Then I make sure everything looks and sends ok (I'll link a few tools)

The elements of email deliverability

For good email deliverability you need correctly configured DNS. That means you need to add various records to your domains DNS (this is what I use Cloudflare for...) - Usually you'll need to:

Create MX Records

Your MX record will point at your email service's servers - each server will have a priority, if the server with top priority is broken, or busy the next server along will handle your email.

Here's one of my MX record sets in Cloudflare:

Here you can see 5 MX records, they all point at Google servers, one server is priority 1, the next two servers are priority 5, the final two are priority 10. When I first set up my Google email address, Google provided the server names, and which priorities to use. I just copied the information in to Cloudflare. If you're doing the same thing, make sure you leave it set for "DNS only".

Add SPF records

The next thing your DNS needs is an SPF record. SPF stands for Sender Policy Framework. SPF is a pass/fail test that asks "is the IP address that this email came from allowed to send emails for mydomain.com?". SPF can be considered the "base" line for email security.

In my example, I'm using Google and Amazon SES to send mail so I need an SPF record that says "Approved Google IP addresses are allowed to send email for me, so are approved Amazon IP addresses".

In this case Google and Amazon tell you what the record should look like when you set your account up with them - you just type it in to Cloudflare, like this:

You'll notice it's not called an SPF record, it's called a TXT record. That's just the way things are. TXT records can contain various things. This one contains an SPF record, we can see that because it begins: v=spf1

The above record tests if the sending IP exists in a list of Google IP addresses found at _spf.google.com and a list of Amazon IP addresses found at amazonses.com

If one of the tests pass, the SPF test is a pass, if all fail then it fails.

"~all" means 'soft fail' (i.e. this email didn't pass the test). If we use "-all" instead, the test would result in a hard fail (this email doesn't pass the test, so discard it).

I use ~all because -all can result in legitimate emails being discarded. You can read more about the difference between -all and ~all here.

You can only have a single TXT SPF record in your DNS, so if you have more than one record to add - you need to combine them on to a single line.

If the domain already has an SPF record, you need to be careful. An existing record means that something is already delivering mail for your domain. It could be another email sending service, some software that you use to send emails, a newsletter service, etc. Check before you delete an SPF record, it's probably doing something!

There are lots of different parameters which can be used to form SPF records, you can read all about them at DMARCIAN, SPF: SPF Record Syntax (open-spf.org) or postmark - for a simple set up (like a domain with Google Workspace or O365, you don't need to know them - you just need to copy what your email provider tells you.

Useful SPF testing tools:

SPF Record Checker - Free SPF Lookup (dmarcian.com) - this gives a handy count of how many of the available 10 SPF lookups have been used.


SPF checks IP addresses, DKIM works using a public/private key. When you send an email your private DKIM key is used to encode a signature. When the email arrives at the destination server the public key is used to decrypt the DKIM signature, so the recipent server can be sure the message hasn't been tampered with. Assuming the DKIM details are good, the message moves on towards the end recipient, otherwise, it will be flagged and handled by the server as probable spam/spoofed email.

Once again, your email service will provide the key - you simply need to create a record for it in DNS

At Amazon SES - they ask you to create several CNAMES:

Which are a specific record type in Cloudflare's DNS configuraton - back in my Cloudflare panel - SES looks like this:

Here you can see Amazon have provided 4 DKIM records - all of which are added as CNAMES. Amazon call the data Name and Value. Cloudflare call it Name and Content (and when you're actually editing the record Cloudflare call it Name and Target!) - sometimes the different services use different names for the same things!!

Google, on the other hand provide a DKIM record that needs to be added as a TXT (rather than CNAME) - once again, the reasoning doesn't matter - you're simply adding the records that your email provide needs.

SPF and DKIM are typically configured together (certainly in the case of Google Workspaces and Amazon SES) - but there is one final record type, which will enhance security and deliverability even further.


DMARC works with SPF and DKIM to provide instructions to the recipent servers about what to do with emails that fail SPF/DKIM tests. Additionally DMARC generates a report, which provides details about messages that have failed, or passed the SPF/DKIM/DMARC process. You can read about DMARC on this detailed FAQ from dmarc.org

DMARC is configured in a similar way to the other records, but requires you to create the text for the record, rather than simply copying it from your provider. They're your rules, after all.

DMARC is a policy, which you create - it looks something like this:

When you create a DMARC policy record (in a text editor like notepad) there are some essential elements:

First you need to state that this TXT record is a DMARC one, so v=DMARC1;

Next, you need to state your overall policy: none, quarantine or reject. You should initially use p=none; ... initial set up is not the time to tell recipient servers to reject your mail, DMARC needs testing first!

... and some optional elements:

DMARC checks don't necessarily need to be carried out on all of your emails. Perhaps recipient servers should sample 50% of your emails (could be useful if you're sending millions of emails) - in this case pct=50 would be correct. However, I'm happy for all emails to be included in DMARC, so I use pct=100;

I use Postmark's free service to recieve DMARC reports, I need to add an rua parameter telling DMARC where to send aggregate reports (Postmark in this case). So I have rua=mailto:[email protected] (Postmark provide this information when you add your domain to their monitoring tool)

Postmark suggests sp=none; this parameter sets a policy for subdomains (like we set p=none at the beginning of the record).

Postmark also add aspf=r; to their suggested record. This is an SPF alignment rule. In this case, set to =r (relaxed) - which is the default anyway! The alternate setting would be strict (=s). You can read about the difference between strict and relaxed here.

In summary, this rule says: "I'm a DMARC record. I don't want you to enact a policy because of me. But, I do want you to look at 100% of my emails. I do want an aggregate report sending to Postmark. I don't want a policy on subdomains. Use relaxed rules to check SPF alignment".

There are other parameters that you can use. Misconfiguring DMARC could result in your emails being rejected more frequently. However, a properly configured DMARC record will improve your domain's reputation, and help to prevent people spoofing emails to look like they've come from you.

DMARC will not help to reduce the amount of SPAM or PHISHING you recieve. It helps recipients. Here's a great post about DMARC from Sparkpost.

In practical terms, you will use the reports generated to ensure all of your valid emails are passing SPF/DKIM checks, before changing your p=none rule to either reject, or quarantine. But you should see this as a journed to a fully configured DMARC record, not a one and done process.


DMARC policy generator https://www.kitterman.com/dmarc/assistant.html

In Summary

Setting up SPF, DKIM and DMARC records for your domain isn't difficult and should be considered essential.

Article written by Ben

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts