In the modern era, bad actors on the internet are more sophisticated than ever. We must do everything possible to make sure that the security of your websites and email systems is at peak performance. Checks of SPF records and DKIM records are a big part of that security. If they have been set up correctly, you can be assured of safe communication through the internet.

However, if checking SPF records and DKIM records reveals email security vulnerabilities, your business and personal life could be impacted negatively. Knowing the configuration options used to check SPF records and DKIM records is important for establishing email authentication. Therefore, this article will discuss how to check SPF records and DKIM records in the context of Liquid Web email authentication requirements.

Overview of Email Authentication Methods

All website and email system administrators should have a strong understanding of DNS records before continuing with this article. The most common ways of authenticating your emails are by checking SPF records and DKIM records in your DNS zone. As an extraordinary precaution, DMARC and PTR records can also be used.

SPF or Sender Policy Framework essentially tells the receiver which servers are entitled to send emails for your domain name.
DKIM or DomainKeys Identified Mail contains the public key, among other information, to ensure that it is actually you sending the messages and not just someone posing as your domain.
DMARC or Domain-based Message Authentication, Reporting, and Conformance govern what is to be done if an email passes or fails the checks of SPF records/DKIM records and can even send you reports if an email fails the authentication.
PTR or DNS Pointer Record is used in reverse DNS lookups and can be set up to ensure that the receiver can check if the IP address of the server sending the email is correct.

What to Know When You Check SPF Records and DKIM Records

Checking Sender Policy Framework (SPF) Records

As mentioned above, SPF or Sender Policy Framework tells the receiver which email servers are entitled to send emails for your domain. The SPF record is a TXT-type record that is set up for the DNS zone for your websites. If you are having trouble editing the DNS zone for your site, you can review the articles provided below for guidance:

When adding the SPF record (and checking SPF records) through your Client Portal or elsewhere, for the hostname part, you should select the Use Root Domain setting. In the value part, you should pick out the proper SPF flags. Below, we will explain how your SPF record should look in terms of SPF flags. In general, the form for the SPF record for Liquid Web should look like the following example:

v=spf1 +a +mx  include:relay.mailchannels.net ~all

There are multiple flags involved. Each of them has a purpose:

v flag — specifies the version of the TXT record, the format in which the information should be read, spf1 is the version for the SPF record.
+a flag — specifies that the domain’s DNS A record is a valid sender.
+mx flag — specifies that the domain’s DNS MX record is also a valid sender.
include flag — informs the receiver that the email server titled relay.mailchannels.net is also a valid sender.
~all flag — is a Soft Fail Flag that indicates that if an email fails the SPF check, it should be marked as spam instead of blocking it completely. This setting can be overridden with the DMARC record, but this is just for this one instance. There are many more flags, and all of them are essential, especially if you have a custom email configuration. The next sections document the list of qualifiers and flags.

Qualifiers

Qualifiers stand in front of the flag and direct who is and who is not a valid sender:

+ qualifier —is a Pass Qualifier, and if there isn’t a qualifier in front of a flag, then the + qualifier is the default choice. A flag that contains the + qualifier is a valid sender.
– qualifier — is a Fail Qualifier, so a flag that contains – qualifier in front of the flag is not a valid sender.
~ qualifier — is a Soft Fail Qualifier and defines unauthorized senders but doesn’t block them immediately.
? qualifier — is a Neutral Qualifier and doesn’t specify if the sender is valid or not, but it indicates that it shouldn’t be blocked.

Flags

Combining the qualifiers and the flags, we can ensure that only our servers or a custom configuration of emails are made valid. This setup greatly improves the chances for your emails arriving successfully and not in spam or being blocked completely:

a flag — targets the domain’s A or (AAAA) DNS record, which is the IP address of the domain itself.
mx flag — targets the MX DNS record of the domain itself.
ip4 flag — specifies the IPv4 address of the sender that must be verified.
ip6 flag — specifies the IPv6 address of the sender that needs to be verified.
redirect flag — specifies if the IP address of the sender uses SPF from another domain.
include flag — specifies the mail servers of the sender that need to be verified.
all flag — is the last flag in the SPF record, and governs what happens if the SPF check fails.

Here is an example:

v=spf1 -a +mx include:relay.mailchannels.net -all

Again, there are multiple flags used, and each of them has a purpose:

-a flag — tells the receiver if the domain’s IP address is the sender, it will not pass the check SPF record part of the process and since it’s paired with -all that email will be blocked. This instance is used when you have a custom PHPMailer and would like to send emails from just one mail server.
+mx flag — tells the receiver that the domain’s MX record is a valid sender and that email will be accepted.
include flag — tells us that the receiver should accept mail from the relay.mailchannels.net mail server.

Checking DomainKeys Identified Mail (DKIM) Records

DomainKeys Identified Mail, or DKIM for short, is an email authentication tool that uses a digital signature (public key) to match with the sender’s server in order to authenticate it to make sure that the sender is the authorized owner of the domain. Whenever you send an email, the header will be part of the DKIM along with the DKIM header, which contains information about who sent the email, the type of encryption used for the public and private keys, when the email was sent, and to whom.

The most important part is the public key. Once the receiver gets the email, that public key will be used to ask the sender’s server if the server’s private key matches with it. If the public and the private key match, then the DKIM record is valid, and the email passes the DKIM check. DKIM is a powerful tool used to ensure that your emails aren’t spoofed, that is, for some other inauthentic party to send emails under your name. Mind you, this can be done without having the credentials to your mailboxes, so the only way to protect you and your customers from scam emails and to protect the name of your business is to set up a valid DKIM record to ensure this doesn’t happen.

An example of a valid DKIM record would be the following:

v=DKIM1; k=rsa; p=<pubkey_string_without_newlines_or_spaces>;

DKIM records have multiple flags involved — each with a purpose:

v flag — specifies the version of the TXT record similar to the SPF.
k flag — specifies the type of encryption for the private and public keys.
p flag — is the space for the public key string, which has to be carefully formatted to have no spaces or newlines, which will affect the public key and make it invalid.

As mentioned before, the public key is something generated by the server, so you would have to contact one of our support technicians to get it.

Was this article helpful?

Thank you for your input.

Thank you for your feedback.