How to create mail validation records: SPF, DKIM, DMARC

Have you ever had:

  • An email message bounce back with a cryptic response like “5.7.1 Command Rejected”, or had someone email you only to get a similar message?
  • An email bounce with a clear answer about an SPF record or DKIM (or DomainKeys) record failure?
  • Your emails arrive in the destination’s spam folder or not arrive at all?

What’s causing that? Why is it rejected or filtered to spam? While there can be additional reasons for a message being filtered to spam, more often than not, any one of the above issues will occur because there’s an issue with the sending domain’s email spoofing protection configuration.

These protections are called SPF, DKIM, and DMARC, and each one takes the form of a DNS record or two that can be configured to help ensure your domain’s email sending reputation remains solid.

While individually these records don’t guarantee prevention of forged addresses, combined they do a lot to help prevent it. Spammers commonly use sender forgery to try and trick their recipients into reading their SPAM emails.

Tip: DKIM also has a matching mail header, and so because of this, if you opt to use a DKIM DNS record, you will need to ensure all email messages route through your SMTP server — there cannot be any additional sources of mail, or alternate mail servers used, while you have a published DKIM DNS record.

Here’s a breakdown of each type of record and how they work.

SPF Record

SPF records are a way for a domain owner/manager to indicate what servers are allowed to send mail on that domain’s behalf. This helps to prevent spammers or other malicious actors from sending mail that appears to be from your domain.

Need help getting your SPF record right? Scroll down to our SPF Record Generator below.

So how does this work? An SPF Record is a DNS record for your domain (a TXT type record) that looks like this:

v=spf1 include:_spf.websavers.ca +a +mx +ip4:2.2.2.2 -all

Let’s break this down. Each part of the record means something different and is separated by white spaces:

  1. v=spf1 –> This indicates that it’s an SPF record, version 1 (default/standard)
  2. include:_spf.websavers.ca –> Include statements mean to include SPF records available at the provided address. This particular one means to include all outgoing mail servers that Websavers has deemed acceptable. They’re published at _spf.websavers.ca (you can’t go there in a web browser to see them though, they’re only visible to DNS requests)
  3. +a +mx –> Allow servers residing at both the A and MX record addresses to send emails. You can do a lookup of your domain to learn what the A and MX records are set to, or simply look in Plesk or at your DNS host if the DNS is not hosted with us.
  4. +ip4:2.2.2.2 –> The server with IP address 2.2.2.2 is allowed to send emails from your domain
  5. -all –> Do not allow any other servers to send messages.

You might see others using ~all (with a tilde rather than dash), which is a weak equivalent of our default “-all”. Using a ~ is kind of like saying “if it doesn’t match these, its up to you whether or not it’s legitimate”. We strongly recommend using “-all” as shown above. This indicates a much firmer statement of “only these servers are valid”.

If you’d like to learn more about SPF, like additional options for what you can include, check out the OpenSPF website.

Any servers that do not appear in your SPF record using one of the methods described above are not allowed to send email using any of that domain’s email addresses, and any messages sent through those servers are likely to be flagged as spam or blocked entirely at the destination.

Using external mail? Even if you switch to using an external email provider, but keep your website hosted with us, it’s still important to keep both +a and include:_spf.websavers.ca in your SPF record. This is because your website often sends out email directly from the server its hosted on (ex: registration or order notification emails) rather than sending it through your email provider, and you want to still allow those emails to be sent successfully.

SPF Record Generator

We’ve created a tool to help you generate the proper SPF record for your domain. Please fill out the form below and it will generate an SPF record for you to use.

SPF Record Generator
While we do our best to keep these accurate; results are not guaranteed. Especially when picking options like "I don't use any of these" or that your website is hosted elsewhere.

Common SPF Config Reference

The following values are not the entire SPF record, just the portion you’ll want to add to your SPF record to allow the matching company’s SMTP servers to send email on behalf of your domain.

When adding, make sure there are spaces between these additions and the other parts of the SPF record. Also make sure your record begins with v=spf1 and ends with either ~all (loose) or -all (more strict). See the example record near the top of this page for a visual representation of where to insert these records.

  • Websavers: include:_spf.websavers.ca
  • Google: include:_spf.google.com (details)
  • Bellnexxia: +ptr:bellnexxia.net
  • Eastlink: include:_spf.eastlink.ca
  • Microsoft Office 365: include:spf.protection.outlook.com (details)
  • GoDaddy: include:spf.secureserver.net
  • Yahoo: Not possible. Uses DMARC instead and forces their SMTP to be used only by Yahoo accounts.
  • Shopify: include:shops.shopify.com (details)

DKIM Record

DKIM records are not a strictly required component, however they will add more trust, so if you can use them, you should.

The biggest problem with DKIM records is that they’re a two piece validation system: both a DNS record AND a header that’s added to every single email by your outgoing mail (SMTP) server. Because of this, you absolutely must ensure that all emails sent from @yourdomain.com addresses go through the exact same SMTP server. This means messages sent through your website, CRM, and any other web or server-based tool that sends emails on behalf of your domain must also be configured to use your SMTP server to transmit messages.

  • External Email Host: If your email is hosted externally, I’m afraid you need to talk to your mail provider to get the correct DNS record to apply.
  • Websavers Exchange Mail: Our Exchange service is one such service that does not support DKIM, so you can skip this section.
  • Websavers Plesk Hosting: If you’re hosted with us on shared, reseller, or VPS (with Plesk Panel), you can simply enable DKIM in Plesk and it’ll both configure the SMTP server and your DNS accordingly! See this Plesk guide to learn how to enable DKIM. If your DNS is external, you can check the DNS record Plesk created for this purpose and you’ll need to duplicate them over at your DNS host. Note that we can only help you with this process if your DNS is hosted with us, otherwise your DNS host will need to be your avenue for support.

DMARC Record

Where DKIM and SPF are used to verify that emails are coming from the right servers, DMARC builds upon those tools (especially SPF) and is used to verify that the envelope and from email addresses are correct. It also helps senders to know how their mail is doing with the big providers like Google and Microsoft by publishing an email address to which you (as the sender) wish to receive reports about deliver-ability.

While the SPF record uses no subdomain and applies directly to your root (@) domain, DMARC uses the subdomain _dmarc. Here’s what that looks like at its simplest:

  • Subdomain: _dmarc
  • Type: TXT
  • Value: v=DMARC1; p=none

But that record basically says “hey I’ve got an SPF record and possibly a DKIM record, but I don’t wish for you (the receiver) to do anything special with DMARC”. Let’s jazz it up a bit and provide a couple alternative values to use. Note that with each of these the subdomain and type are always the same as above and you should never publish multiple DMARC records.

The following record example says to quarantine (this usually means put in spam, but some providers will literally hide the message from recipients until an email admin allows it through) any messages that don’t match up (SPF, DKIM, Envelope). It also says that for 20% of all messages received from your domain, if there are any failures, send a report about each failure to the specified email address.

v=DMARC1; p=quarantine; pct=20; ruf=mailto:reports@yourdomain.com;

The following record says to: reject any messages that don’t match up; that you wish to receive reports about 100% of failures; that DKIM should be treated as relaxed; that SPF should be treated as strict; that you want to not see *individual* reports about each message failure (ruf), but rather get an aggregate report (rua). I believe the reports are typically sent monthly, but this may be at the discretion of the receiving provider, like Google or Microsoft.

v=DMARC1; p=reject; pct=100; adkim=r; aspf=s rua=mailto:reports@yourdomain.com;

You will need to enter the actual email address that you want to receive these reports at, otherwise just leave out the rua/ruf option and the pct option, as it’s useless if you don’t want to see the reports. You can use pct and ruf/rua with p=none. That will just mean that the receiving server will pass the message on as normal even if it fails DKIM,SPF,DMARC checks.

The adkim and aspf options appear to default to relaxed if you leave them out.

Tip: you should always use DMARC, even if you don’t have DKIM enabled. But be sure that you have SPF configured correctly, otherwise DMARC won’t be helpful to you.

Where do I put these DNS records?

If your DNS is hosted with us, here’s how to edit your DNS records. In that guide, you’ll be looking to edit an existing record of type TXT.

If your DNS is hosted elsewhere, you will need to login to their panel to edit or add your SPF record.

With our Plesk hosting we configure all of these records for you, however if you’re experiencing problems with deliverability, you should double check that they’re correct. You may have an older version of the record that isn’t optimal, or you or someone with access to your account may have modified it without knowing the implications.

Please do not create multiple SPF records. If you see an existing one in your DNS settings, be sure to edit that one rather than add a second one. Duplicate records will frequently cause none of them to work.

Because these are DNS records, the changes you make to your DNS settings will take a few hours (up to 48 hours) to apply worldwide. Please be patient.

Troubleshooting

SPF Too Many Lookups Error: if you see an error with an SPF record checker about too many lookups, the simple interpretation is that there’s too many items in your record. The only way to resolve this is to remove the least important elements from your SPF record and/or consolidate mail services so you’re not using so many. If you’re using a mailing list service, you could switch its configuration to use a subdomain like mailing-list.mydomain.com and move that part of your SPF record to the subdomain’s SPF record instead.

Read more about SPF Too Many Lookups error in this detailed article here.

If you’re using an external mail service like Google Workspace (formerly G Suite), your best bet to reduce the total number of lookups is to remove the Websavers portion of the SPF record (include:_spf.websavers.ca). But if you do this, be absolutely sure that all websites you have hosted with us are configured to send email using your external mail provider’s SMTP service (such as Google Workspace in this example). This will ensure all mail coming from the website flows through an SMTP server that remains authorized in your SPF record, and not our servers which will not remain in your SPF record.

If you must remove the “include” statement, definitely keep this instead as it will allow our main mail relay to continue to serve your mail:

+ip4:149.56.38.109

Messages being delivered to Spam or Junk: if you have successfully configured all of the above DNS records and it has been 48 hours since you have done so (remember DNS changes take time to propagate), yet your emails are still landing in junk folders of your recipients, please check our troubleshooting guide here.

About Jordan Schelew

Jordan has been working with computers, security, and network systems since the 90s and is a managing partner at Websavers Inc. As a founder of the company, he's been in the web tech space for over 15 years.

Leave a Comment