Like SPF, DKIM, DMARC Drive email delivery, security
7 mins read

Like SPF, DKIM, DMARC Drive email delivery, security

Three email authentication standards work together to improve email deliverability for the sender and email security for the recipient.

Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) help ensure that the emails your organization sends are genuine and that malicious actors are not forging or otherwise manipulate you.

SPF, DKIM, DMARC

SPF, DKIM, and DMARC show the receiving email server that a specific message was sent from an authorized IP address, that the sender is authentic, and that the sender is transparent about their identity.

Let’s take each one in turn.

Setting up SPF records for your domain involves adding a type of TXT record that contains an authorized list of outgoing mail servers to the Domain Name System (DNS). SPF verifies that emails from your company’s domain come from an authenticated source and not from a scammer.

DKIM keys consist of two parts: a public key stored in DNS and a private key stored on the sending mail server. The DKIM signature attached to every outgoing email is used by recipients’ mail servers to verify its authenticity. DKIM can also indicate whether a specific email message has been modified.

DMARC is a policy mechanism that allows an organization to control how inbound email from its domain should be treated when it fails SPF or DKIM authentication. The options are Reject, Quarantine, or None. This can act as an alarm bell when a bad guy is trying to use your domain.

SPF records

Setting up an SPF record requires access to your domain’s DNS records at the registrar, such as B. GoDaddy or similar. If you’ve ever had to verify your domain or move it to a new server, chances are you’ve updated its DNS record.

Screenshot of an SPF record in a DNS settings interface

An SPF record is simply a TXT record in your domain’s DNS.

The SPF record will be of type “TXT”. And it starts with the version of SPF you’re using.

v=spf1

The version is followed by a list of authorized IP4 or IP6 addresses, as in:

v=spf1 ip4:192.168.0.1

This SPF record would authorize emails from the IP address 192.168.0.1. To allow a range of IP addresses, you can use Classless Inter-Domain Routing (CIDR) notation (sometimes called “slash” notation).

v=spf1 ip4:192.168.0.0/16

The above SPF record would authorize a range of IP addresses from 192.168.0.0 to 192.168.255.255 – that’s what the “/16” indicates.

With the “a” prefix, an SPF record can authorize a domain by name. The following record authorizes a server associated with the domain example.com.

v=spf1 a:example.com

Likewise, the “mx” (“mail exchange”) prefix authorizes specific mail servers.

v=spf1 mx:mail.example.com

To authorize an external sender, use the “include” prefix. The following example allows both an IP range and Google servers.

v=spf1 ip4:192.168.0.0/16 include:_spf.google.com

There are also two SPF qualifiers. The first is ~all with a tilde (~). The second is -all with a hyphen (-).

The tilde version (~all) is a soft fail qualifier. In most cases, the receiving email server will accept messages from senders who are not included in the associated SPF record but consider them suspicious.

The hyphen version (-all) is a hard fail qualifier. The receiving email server is likely to mark as spam and reject messages sent from a server that is not authorized in the SPF record.

Finally, all of these can be used together for relatively complex authorizations.

v=spf1 ip4:192.168.0.0/16 a:example.com include:_spf.google.com

Remember that SPF records help receiving email servers identify authentic email messages from your organization’s domain.

DKIM key

DKIM protects your domain and prevents anyone from impersonating your company. With the two DKiM keys, the recipient’s email server can verify that your company sent the message and that it was not modified after it was sent.

The first step in setting up DKIM is to generate the keys – one public and one private. The private key is safe on the server used to send email from your domain. The public key is added to DNS as a TXT record.

The tricky part is generating the keys as the exact procedure for creating them varies from email service provider to email provider. And it’s completely different when your company hosts its own mail server.

Email service providers offer instructions. Here are some examples in no particular order.

  • Mailchimp: set up email domain authentication,
  • Klaviyo: How to set up a dedicated broadcasting domain
  • Zoho Campaigns: How to authenticate my domain,
  • MailerLite: email domain authentication,
  • Activist: DKIM, SPF and DMARC,
  • ConvertKit: Using a verified domain to send emails,
  • MailUp: maximizing the deliverability of your emails,
  • ActiveCampaign: SPF, DKIM and DMARC authentication,
  • Hold: DKIM.

In any case, the DKIM is complete when you add – copy and paste – the email provider’s CNAME record to your domain’s DNS. These records represent the public key to authenticate your company’s outbound email marketing messages.

DMARC

DMARC provides another layer of protection, instructing email servers on what to do with messages that fail SPF or DKIM authentication.

The basis of DMARC is a TXT record placed in your domain’s DNS. This contains the DMARC policy with at least two elements:

  • An email address to receive aggregate reports on email authentication, and
  • The action for emails that fail authentication (ie, reject or quarantine).

Here is an example of a DMARC TXT record in a DNS:

v=DMARC1; p=quarantine; rua=mailto:armando@example.com; ruf=mailto:armando@example.com.

Recording starts with the DMARC version.

v=DMARC1;

The “p” element assigns the action for emails that fail authentication. In this case, it’s set to “quarantine,” which tells the receiving server to move such messages to a waiting area. Other options are “none” – which doesn’t stop the email but monitors for SPF or DKIM failures – or “deny”.

p=quarantine;

The prefixes “rua” and “ruf” tell the receiving server where to send aggregate reports (rua – Reporting URI for Aggregate data) and forensic reports (ruf – Reporting URI for Failure data). These reports can uncover a criminal trying to impersonate your company.

Additional modifiers are:

  • pct – The percentage of email messages subject to the DMARC policy.
  • sp – the DMARC policy for subdomains.
  • adkim — Assigns DKIM to strict (adkim:s) or relaxed (adkim:r) mode.
  • aspf — assigns SPF to strict (adkim:s) or relaxed (adkim:r) mode.

Third-party services can help create a DMARC record based on the official standard. These services include:

Protect sender and recipient

Setting up SPF, DKIM, and DMARC records for your domain ensures email servers recognize messages from your company as authentic and reject scammers. The result protects your company’s reputation and protects customers from phishing attacks and other types of email fraud.

Leave a Reply

Your email address will not be published. Required fields are marked *