Articles

The Three Pillars of Email Authentication: SPF, DKIM, and DMARC

by Benjamin B. EmailAuth

If you work in email marketing, you've most likely heard acronyms like "SPF," "DKIM," and "DMARC" tossed about without any explanation. Many people think you immediately understand these phrases, but the fact is that many marketers just have a hazy understanding of them.

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

We'll give you a quick and informative overview of each process, and then you'll be ready to start throwing acronyms about like a pro. First things first…

WHAT IS EMAIL AUTHENTICATION, AND WHY IS IT SO IMPORTANT?

By establishing methods that validate your domain as the sender of your messages, email authentication helps to increase the delivery and credibility of your marketing emails.

Using authentication will not ensure that your email reaches the inbox (you need focus on improving your email deliverability too), but it will protect your brand reputation while ensuring that your communications reach their intended recipients.

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

3 TECHNICAL, BUT ESSENTIAL, EXPLANATIONS OF SPF, DKIM, AND DMARC

SPF: Sender Policy Framework

The Sender Policy Framework, or SPF, allows recipients to verify the sender of an incoming email.

You can define which mail servers are authorized to send mail on your behalf by generating an SPF record. If you use a hosted email solution (Office365, Google Apps, etc.) or an ESP like Higher Logic, this is very useful.

Here's a brief breakdown of the process:

1. A record is added to the DNS settings by the sender.

a. The record should point to the domain used in their FROM: address (for example, if I send from bgurley@ABC.com, the record should point to ABC.com). All IP addresses (mail servers) that are allowed to send mail on behalf of this domain are included in this record. The following is an example of a typical SPF record:

v=spf1 ip4:64.34.187.182 ip4:66.70.82.40 ip4:64.27.72.0/24 include:magnetmail.net ~all

2. The DNS records are checked by the receiving server.

The receiving server verifies the DNS records for the domain in the FROM: field when the email is sent. The message passes SPF if the IP address is listed in that record (as seen above).

3. it’s a hard fail if SPF exists but the IP address isn't in the record.

It's called a "hard-fail" if the SPF record exists but the IP address of the sending mail server isn't in the record. Mail is often rejected or sent to the spam bin as a result of this.

4. it’s a soft fail if no SPF record exists.

A “soft-fail” occurs when there is no SPF record at all. These are the most common reasons for messages being routed to spam, but they can also result in a message being rejected.

DKIM: DomainKeys Identified Mail

DKIM (DomainKeys Identified Mail) allows for the identification of “spoof” emails as well, although it does it in a slightly different way. DKIM uses two encryption keys: one public and one private, rather than a single DNS record that specifies the FROM: address.

The private key is kept in a secure location that only the domain owner gets access too. This private key is used to generate an encrypted signature for every message sent from that domain. The message's receiver may validate the signature against the public DKIM key, which is stored in a public-facing DNS record. If the records "match," the mail could have only been sent by somebody who has access to the private info.

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

While both SPF and DKIM can be used separately, DMARC must rely on one of the two to provide authentication.

DMARC (Domain-based Message Authentication, Reporting, & Conformance) improves these technologies by instructing recipients 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.

DMARC has a reporting component that may be highly valuable for most organizations, in addition to the mandatory tags that indicate how to handle unauthenticated mail. Your business can receive reports indicating all mail sent with your domain in the FROM: address if you enable the reporting features of DMARC. This can assist in the identification of spoofed or faked mail patterns, as well as the detection of other business divisions or partners who may be sending mail on your behalf without authentication.

WHERE SHOULD YOU START WITH EMAIL AUTHENTICATION?

The first step is to speak with your email support team about how to ensure sure your emails are verified. There are also a variety of useful tools on the web, like SPF wizards and DKIM key generators, which will explain the process of creating a record how you can copy and paste into your domain management console.

We strongly advise utilizing SPF, DKIM, and DMARC to verify your messages, regardless of how you go about it. You'll be able to acronym like the best of them while preserving the safety and security of your brand's reputation.


Sponsor Ads


About Benjamin B. Junior   EmailAuth

0 connections, 0 recommendations, 17 honor points.
Joined APSense since, March 10th, 2021, From London, United Kingdom.

Created on Aug 16th 2021 01:21. Viewed 187 times.

Comments

No comment, be the first to comment.
Please sign in before you comment.