KNOWNHOST KNOWLEDGE BASE

Hosting Question? Find the Solution - Browse our Guides, Articles, and How-To's

Setting up SPF, DKIM, and DMARC Records

SPF, DKIM, and DMARC records are intended to fight SPAM and email spoofing. These mechanisms don’t analyse content of the message in search of malicious code, spam-like content, or content that would be used in a phishing attempt. Other dedicated tools should be used to detect viruses & malicious scripts or to flag messages as spam-like or scam-like based on the content of an email message.

SPF

SPF Overview

SPF (Sender Policy Framework) helps to fight email spoofing when a malicious sender forges MAIL FROM field in message. To implement this solution, domain owners should create a special TXT record in a domain’s DNS zone telling all recipients about authorized senders for their domain.

SPF record consists of the following parts divided by spaces, and each part is processed in order:

  • v=spf1 – version of protocol
  • mechanisms – the ways to interpret allowed senders. Commonly used are: amxip4includeall. At least one mechanism should be in the record:
    • a: All the A DNS records for domain are tested.
    • mx: All the A DNS records for all the MX records for domain are tested in order of MX priority.
    • ip4: A CIDR-spec is an IP network range. If no prefix-length is given, /32 is assumed.
    • include: The specified domain for the include is searched for a match. If the lookup does not return a match or an error, processing proceeds to the next directive. Warning: If this other domain does not have a valid SPF record, the result is a “Permanent Error”.
    • all: This mechanism always matches. all should go at the end of your SPF record.
  • Each mechanism has a qualifier – it represents the action which should be taken. The list of qualifiers:
    • + for a PASS result. It’s used by default if no other qualifier is set, and is often omitted from SPF records.
    • ? for a NEUTRAL result. No action should be taken (ignore that mechanism).
    • ~ (tilde) for SOFTFAIL. Mostly interpreted as “accept this message, but mark/tag it”.
    • - (minus) for FAIL, the mail should be rejected.

Sample SPF record for domain domain.com:

  $ dig txt domain.com +short
  "v=spf1 a ip4:10.10.10.10 include:spf.example.com -all"

There are 4 mechanisms in it: aip4include, and all. First 3 mechanisms have + or PASS qualifier (if no qualifier for a mechanism is set, the qualifier defaults to “PASS”). The last all mechanism has - which is the (FAIL) qualifier. This record states that message should be accepted if it comes from IP address to which A record of domain.com resolves, or from example IP 10.10.10.10. Also, the message is accepted if it passes the policy of another domain – spf.example.com. Finally, message should be rejected if it does not pass previous mechanisms.

Managing SPF in cPanel

SPF record for single DNS zone could be set up or modified in WHM DNS zone editor (Home »DNS Functions »Edit DNS Zone).

The below options require root access!
To add SPF records for already existing domains go to (Home »DNS Functions »Enable DKIM/SPF Globally) and click “Proceed”. Also, script /usr/local/cpanel/scripts/enable_spf_dkim_globally could be used for same purposes, see documentation at cPanel

There’s also a script /usr/local/cpanel/bin/spf_installer for managing SPF records. For example, you can add custom mechanism include:spf.example.com for all DNS zones:

  for acct in $(awk '{print $2}' /etc/trueuserdomains); do /usr/local/cpanel/bin/spf_installer $acct include:spf.example.com; done

Verifying SPF records

Some services where you can verify SPF record for domain:

Additional Resources on SPF

DKIM

DKIM Overview

DomainKeys Identified Mail (DKIM) is used to verify that message was sent indeed from domain which is presented in FROM field. Sender creates a pair of keys for mail domain: private and public. Private key is stored at mail server and signs each outgoing email message with it. Private key also could be shared with 3rd-party service which sends out messages on behalf of sender’s domain. Public key could be accessed from anyone in the Internet and it’s used to decrypt signed message.

On the other side, recipient decrypts the message and can use result of DKIM verification in further processing, for example reject messages which don’t pass DKIM verification, or mark these messages as spam.

Therefore, by using DKIM two problems of email exchanging are being solved:

  1. Verification of sender
  2. Assurance that content of the message was not changed during transit from sender’s mail server to recipient’s mail server

DKIM selector is used to determine multiple keys within the same mail domain. For example, if there’re several departments use one mail domain to send out messages, mail administrators could set up separate selectors for each department for better control of outgoing mail. However, in general having a default selector is sufficient, unless there is a specific need for multiple selectors.

Using DNS to Publish DKIM Keys

DNS is used to make a public key known for all mail servers which could require DKIM verification from sender. For such purpose a TXT record is used. For example, here’s the public key for default DKIM selector of mail domain knownhost.com:

  $ dig txt default._domainkey.knownhost.com +short
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxG+doMvKHVEE9r4YkdhEqBBHUYYZqs+g9L/9M30cSP/s0ZW6XMVHF3KwhJUcukq3kZNe3TMRFRiFxLb6ncLBnn7+491qS66yKMMStE6TdUFCFu5yq/bdpM/l04kPNcHutNkUJy1zLC6pGUuyxFIOIPlshry+oUkfhULw3E925kk1AOhn404702EBt1DObMXd+" "AQ+hWW/xworVfZwCTRVSQ4TvJ7YH3X+wG6HLRqoEkVsOx2rc4XqHy52FFuoSFDhtNq45jCcOOVK2AdONPq4I5VEbTPAqBzItK3shDOnzvUAzwBl74Zl4sJoA8gyi0XxcNlmrOE6fkjeQqcwPxAUZQIDAQAB;"

You may notice a space between two sections in quotation marks. This just indicates the limit for the length of TXT record and public key does not split in two parts: they are being concatenated during resolving the record by modern applications.

DKIM record also could be a CNAME instead of TXT and point to other record which contains public key for mail domain.

DKIM Verification on Receiver

Once mail server when DKIM verification is configured receives the message it looks in the header for the following line (an example):

  DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=default;
  ...

Tag-value field s=default indicates that default selector is in use. Then mail server queries the TXT DNS record for default._domainkey.example.com, retrieves public key from it, and decrypts the message.

Managing DKIM in cPanel

To turn enable DKIM for newly created domains go to (Home »Server Configuration »Tweak Settings) and find “Enable DKIM on domains for newly created accounts” option on Domains tab.

To add DKIM for already existing domains go to (Home »DNS Functions »Enable DKIM/SPF Globally) and click “Proceed”.

You can allow/disallow DKIM verification for incoming messages in Exim configuration (Home »Service Configuration »Exim Configuration Manager) at “ACL options” tab.

Keys for each domain are stored in the following directories:

  /var/cpanel/domain_keys/public/
  /var/cpanel/domain_keys/private/

Verifying DKIM records

There’re many services where you can verify DKIM record for domain, for example:

Additional Resources on DKIM

DMARC

DMARC Overview

While SPF and DKIM techniques allow mail servers to validate senders for incoming email messages, they both don’t provide mechanisms for senders to publish policies on actions which should be taken upon authentication failures. DMARC (Domain-based Message Authentication, Reporting and Conformance) fills up this gap. It allows domain owners to tell which rules should be applied for messages which failed SPF and/or DKIM authentication. Also, DMARC allows to send back to domain owners reports about validation results per sender IP address.

Using DNS for Publishing DMARC Records

Specially formatted TXT record is used to publish DMARC record for domain. It consists of subdomain _dmarc and tag-value fields divided by semicolons. An example of record for domain domain.com:

  _dmarc.domain.com

The following is an example of value which tells to process 100% of messages coming from domain domain.com, reject those which does not align with DKIM/SPF policies, do not nothing (process further) if message came from subdomain of domain.com, and send aggregated statistics daily to info@domain.com:

  "v=DMARC1; p=reject; sp=none; pct=100; ri=86400; rua=mailto:info@domain.com"

In this example:

  • v – version of protocol
  • p – policy, possible values are: rejectquarantine or none
  • sp – policy for subdomains (the same possible values)
  • pct – percentage of messages subjected to filtering
  • ri – aggregate reporting interval
  • rua – reporting URI(s) for aggregate data

Not all tag-value parameters are mandatory. The only required parameters are version (v) and policy (p). You can find more tags at tools.ietf.org/html/rfc7489#section-11.4

Here’s another example of DMARC record, for gmail.com. It states that all messages from gmail.com should be passed to further processing (neither quarantined nor rejected) whilst messages from a subdomain of gmail.com (e.g. subdomain.gmail.com) should be quarantined.

  $ dig txt _dmarc.gmail.com +short
  "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"

Managing DMARC Records in cPanel

DMARC records can be set up or modified in WHM DNS Zone editor (Home »DNS Functions »Edit DNS Zone). This also could be done after enabling the Zone Editor (AAAA, CAA, SRV, TXT) feature for a package (this feature replaces the Advanced Zone Editor in cPanel.)

Verifying DMARC Records

Resources for verifying DMARC records for domains:

Analyzing DMARC Reports

Resources for analyzing DMARC Reports for a domain:

Additional Information about DMARC