How to create mail authentication 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, or authentication / validation records are called SPF, DKIM, and DMARC, and each one takes the form of a DNS record that can be configured to help ensure your domain’s email sending reputation remains solid. When all three records are combined, these records do a lot to help prevent email forgery.

Where do I put these DNS records?

If your DNS is hosted with us, here’s how to edit your DNS records. If your DNS is hosted elsewhere, you will need to login to their panel to edit or add your DNS records. For each type of record, first check to see if there is an existing record to edit and, If you don’t see the existing matching record, add a new one instead. Do not create duplicate records.

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.

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.

How to use an SPF Record

An SPF Record is a TXT type DNS record. The host/domain/subdomain field should be empty (or with some DNS hosts, they want you to use the @ symbol) to apply to the domain that is sending email. Only if you’re setting up email on a subdomain should you enter a subdomain.

The value looks like this:

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

The first part is just saying it’s an SPF record, and each part after that defines one or more server addresses/IPs that are allowed or not allowed to send messages from your domain.

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 which are 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 record (probably your website) and MX record (the incoming mail server)
4. +ip4:2.2.2.2 –> The IP address 2.2.2.2 is allowed to send mail
5. -all –> Do not allow any others

Instead of -all, you might see ~all, which is weaker. Using a ~ is like saying “if it doesn’t match these, it’s no big deal” whereas -all says “if it doesn’t match these, don’t accept it”.

Using external mail? If you switch to using an external email provider while keeping your website hosted with us, you should either configure your website to send messages directly through your external mail provider, or keep the include:_spf.websavers.ca part in your SPF record.

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.

How to use a DKIM Record

The biggest confusion with DKIM records is that, unlike SPF, 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 must ensure that all emails sent from @yourdomain.com addresses are always routed through the same SMTP server to ensure that server adds the necessary header. 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 for those messages to be received successfully in the recipient’s inbox.

• External Email Host: If your email is hosted externally, you’ll need to talk to your mail provider to get the correct DNS record to apply.
• Websavers Exchange Mail: Our Exchange service supports DKIM as of November 2023. See our guide to creating all necessary DNS records for Exchange, including DKIM.
• 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 copy them over to your actual 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.

How to use a DMARC Record

DMARC builds upon SPF and DKIM by verifying 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.

Unlike SPF, DMARC uses a subdomain: _dmarc. Here’s what that looks like at its simplest:

• Subdomain: _dmarc
• Type: TXT
• Simple Value: v=DMARC1; p=none
• Strict Value: v=DMARC1; p=reject; adkim=s; aspf=s (use this one if you’re sure you have a working SPF and DKIM record)

The simple record 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”. The Strict value says “I’ve got a solid DKIM and SPF record and I want anything that doesn’t match to be rejected”

Below you’ll find a few more advanced options. 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; adkim=s; aspf=s; 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 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.

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.