SPF, DKIM, DMARC: The 3 Pillars of Email Authentication

If you’re an email marketer, you’ve probably heard acronyms like “SPF,” “DKIM,” and “DMARC” being tossed around with little explanation. People might assume you automatically understand these terms, but the truth is that many marketers’ grasp of these concepts is vague, at best.

The good news is that SPF, DKIM, and DMARC can work together for you like a triple rainbow of email authentication, and that’s why we want you to have a thorough understanding of them. The explanations are technical, but these are three fundamental concepts to understand about email authentication.

We’ll provide you with a brief and insightful look at each of these protocols, then you’ll be able to start tossing these acronyms around like the pros. First things first…

What is email authentication, and why is it so important?

Email authentication helps to improve the delivery and credibility of your marketing emails by implementing protocols that verify your domain as the sender of your messages.

Using authentication won’t guarantee that your mail reaches the inbox but it preserves your brand reputation while making sure you have the best possible chance of having your messages reach their intended destination.

Read on to find out how to ensure you’re achieving the gold standard of email authentication.

SPF, DKIM, and DMARC: 3 Technical, but Essential, Explanations

SPF: Sender Policy Framework

SPF, Sender Policy Framework, is a way for recipients to confirm the identity of the sender of an incoming email.

By creating an SPF record, you can designate which mail servers are authorized to send mail on your behalf. This is especially useful if you have a hosted email solution (Office365, Google Apps, etc.) or if you use an ESP like Higher Logic.

Here’s a brief synopsis of the process:

The sender adds a record to the DNS settings.
1. The record is for the domain used in their FROM: address (e.g. if I send from contact@sysa.tech, add the record to sysa.tech). This record includes all IP addresses (mail servers) that are authorized to send mail on behalf of this domain. A typical SPF record will look something like this:
  v=spf1 ip4:64.34.187.182 ip4:66.70.82.40 ip4:64.27.72.0/24 include:magnetmail.net ~all

The receiving server checks the DNS records.
1. When the mail is sent, the receiving server checks the DNS records for the domain in the FROM: field. If the IP address is listed in that record (as seen above), the message passes SPF.

If SPF exists, but the IP address isn't in the record, it's a hard fail.
1. If the SPF record exists, but the IP address of the sending mail server isn’t in the record, it’s considered a “hard-fail.” This can often cause mail to be rejected or routed to the spam folder.

If no SPF record exists, it's a soft fail.
1. If no SPF record exists at all, this is considered a “soft-fail.” These are most likely to cause messages to be routed to spam but can lead to a message being rejected as well.

DKIM: DomainKeys Identified Mail

DKIM, short for DomainKeys Identified Mail, also allows for the identification of “spoofed” emails but using a slightly different process. Instead of a single DNS record that keys off the FROM: address, DKIM employs two encryption keys: one public and one private.

The private key is housed in a secure location that can only be accessed by the owner of the domain. This private key is used to create an encrypted signature that is added to every message sent from that domain. Using the signature, the receiver of the message can check against the public DKIM key, which is stored in a public-facing DNS record. If the records “match,” the mail could only have been sent by the person with access to the private key, aka the domain owner.

DMARC: Domain-based Message Authentication, Reporting, & Conformance

While SPF and DKIM can be used as stand-alone methods, DMARC must rely on either SPF or DKIM to provide the authentication.

DMARC (Domain-based Message Authentication, Reporting, & Conformance) builds on those technologies by providing directions to the receiver on what to do if a message from your domain is not properly authenticated.

Like SPF and DKIM, DMARC also requires a specific DNS record to be entered for the domain you wish to use in your FROM: address. This record can include several values, but only two are required:

(v) tells the receiving server to check DMARC

(p) gives instructions on what to do if authentication fails.

The values for p can include:

p=none, which tells the receiving server to take no specific action if authentication fails.

p=quarantine, which tells the receiving server to treat unauthenticated mail suspiciously. This could mean routing the mail to spam/junk, or adding a flag indicating the mail is not trusted.

p=reject, which tells the receiving server to reject any mail that does not pass SPF and/or DKIM authentication.

In addition to the required tags advising how to handle unauthenticated mail, DMARC also provides a reporting component that can be very useful for most organizations. By enabling the reporting features of DMARC, your organization can receive reports indicating all mail that is being sent with your domain in the FROM: address. This can help identify spoofed or falsified mail patterns as well as tracking down other business divisions or partners that may be legitimately sending mail on your behalf without authentication.

source

Auteur : Harlok

2019-05-07 14:46:08