SPF, DKIM, DMARC: The 3 Pillars of Email Authentication
Brad Gurley, Senior Director of Deliverability, Real Magnet
If you’re an email marketer, you probably heard acronyms like SPF, DKIM and DMARC tossed about frequently with little explanation. It’s often assumed that senders simply know and understand these terms, when in reality, many marketers’ grasp of these concepts is vague at best. It’s not always easy to take a highly technical specification and understand its use in your day-to-day activities, so we’re going to try to provide a brief and insightful look at each of these protocols and how they can work together for you like a triple rainbow of email authentication.
SPF: Sender Policy Framework
Sender Policy Framework, or SPF, 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 Real Magnet. Here’s a brief synopsis of the process:
- The sender adds a record to the DNS settings for the domain used in their FROM: address (e.g. if I send from firstname.lastname@example.org, add the record to realmagnet.com). 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:220.127.116.11 ip4:18.104.22.168 ip4:22.214.171.124/24 include:magnetmail.net ~all
- 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 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 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 a number of values, but only two are required. The first (v) tells the receiving server to check DMARC, while the second (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.
Where to Start
Real Magnet users can take advantage of our detailed Authentication Guide to set up SPF and ensure that messages are properly authenticated. The guide also includes details about DKIM signing, and our Support and Deliverability teams are always happy to help with any questions. If you’re interested in using DMARC as well, our deliverability team can help with guidance on how to get set up. In an upcoming blog post, we’ll dive a bit deeper into the elements of DMARC and how it works.
There are also lots of great tools available on the web, including a number of SPF wizards and DKIM key generators that guide you through the process of creating a record you can copy and paste into your domain management console.
However you go about it, we strongly recommend you authenticate your messages with SPF, DKIM, and DMARC. 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.