[TOP TIP] SPF, DKIM & DMARC
The following TXT records need to be setup for all hosted domains, subdomains, including the FQDN of the server itself. For our example, lets pretend that we own the domain "example.tld", thus a typical system will have:
* example.tld (domain name)
myserver.example.tld (FQDN of the server)
Typically, your website will be
What you need to understand, is that you need TXT records FOR ALL 3 of the above names, not just example.tld.
This is simple to setup because it is a passive protection. For the most part, a single server tells others that he is the only one allowed to send emails on behalf of its hosted domains, like this:
v=spf1 +a +mx -all
In some cases, we don't want emails for a particular domain and/or subdomain. For example, we don't want
Create TXT records for all domains and subdomains:
Name Value v=spf1 +a +mx -all (blank name implies the domain name) myserver v=spf1 +a +mx -all www v=spf1 -all
Allow myself (A record), my mail server (MX record) and reject emails originating from all others. If you want, you may add more addresses, or even
include additional SPF records openspf.org
This is more complex system and requires an active daemon that generates an encrypted signature and also performs foreign signature checks. CentOS comes with OpenDKIM. If you are using the
By default, OpenDKIM will keep a copy of a TXT record at: /etc/opendkim/keys/default.txt which looks like this:
default._domainkey IN TXT ( "v=DKIM1; k=rsa; " "p=longstringinhere" ) ; ----- DKIM key default for example.tld
Just copy the two quoted strings without the double quotes and create a TXT record that you can use with Linode's DNS Manager, so the above would look like:
v=DKIM1; k=rsa; p=longstringinhere
Now create TXT records for all your domains, subdomains and the FQDN of the server, for example:
Name Value default._domainkey v=DKIM1; k=rsa; p=longstringinhere default._domainkey.myserver v=DKIM1; k=rsa; p=longstringinhere default._domainkey.www v=DKIM1; k=rsa; p=longstringinhere
While this technology is easy to setup, because it is similarly passive as SPF, but the implications are very widespread. DMARC will prevent others from sending emails in your name, while that sounds awesome, it will affect mailing lists which forward your emails without modification. All major mailing lists have been improved and now compensate for DMARC so there is nothing to worry about there. You can read more about this technology at the
DMARC FAQ DMARC Overview
A restrictive DMARC record that blocks foreign emails from using your name looks like this:
v=DMARC1; p=reject; adkim=s; aspf=s; sp=reject
Create a TXT record for your domain, for example:
Name Value _dmarc v=DMARC1; p=reject; adkim=s; aspf=s; sp=reject
If anyone wants to learn more, check out this definitive guide to SPF/DKIM/DMARC: https://dmarcly.com/blog/how-to-implement-dmarc-dkim-spf-to-stop-email-spoofing-phishing-the-definitive-guide.
It provides step-by-step instructions and various tools to help you achieve an effective email authentication implementation.
Also, you will find real-word examples of email authentication and explanation of how SPF, DKIM and DMARC interact to authenticate emails.
If you run into the "SPF PermError: Too Many DNS Lookups" issue, find out how to fix: https://dmarcly.com/blog/spf-permerror-too-many-dns-lookups-when-spf-record-exceeds-10-dns-lookup-limit