Let's Take This to the Inbox
Sign up for our news, resources and updates. The inbox is our favorite place after all. We’ll make sure it’s worth it. (You can unsubscribe at any time, but you probably already knew that.)
Are you an email marketer struggling to understand the purpose and importance of authentication in email deliverability? You’re not alone.
Many types of transactions require authentication. Whether you’re a patient needing treatment, a driver needing a license, a customer paying with a credit card, or a passenger boarding an airplane – in order to proceed, you must prove that you are who you say you are. You provide a passport, proof of health insurance, a Social Security card, or some other form of identification to prove that the name on the appointment, credit card, or airline ticket, really belongs to you.
The world of deliverability works the same. In order to get through the gates of ISP filters, you need to prove that you are a legitimate sender. You need to show that you are not sending on behalf of someone else, and that your identity has not been compromised. How do you prove this? By utilizing SPF, DKIM, and DMARC.
SPF, DKIM, and DMARC are acronyms for text records that specifically prove and protect a sender’s authentication. Let’s break them down.
SPF, or Sender Policy Framework, is an email validation protocol designed to detect and block email spoofing. It allows mail exchangers to verify that incoming mail from a specific domain comes from an IP Address authorized by that domain’s administrators. An SPF record is a TXT record found in the DNS (Domain Name System) record that specifies which IP addresses and/or servers are allowed to send mail “from” that domain. It is akin to a return address on a postcard—most people are much more likely to open a letter if the letter has a reliable and recognizable return address from which it was sent.
After an email message is sent, ISPs check the message’s Return-Path domain. They then compare the IP address that sent the email to the IP address listed in the Return-Path domain’s SPF record to see if it is aligned. If so, SPF authentication has been confirmed and the message will be delivered.
SPF is a “proposed standard” that helps protect email users from potential spammers. Email spam and phishing often use forged “from” addresses and domains, so publishing and checking SPF records is considered one of the most reliable and simple to use anti-spam techniques. If you have a good sending reputation, a spammer might attempt to send email from your domain in order to piggyback off your good sender reputation with ISPs. But properly set up SPF authentication will show the receiving ISP that even though the domain may be yours, the sending server has not been authorized to send mail for your domain.
An SPF record in a top domain (ie: collegedata.com), will automatically authenticate any subdomains (mail.collegedata.com) under it that may not contain their own SPF record.
For more information on how to create an SPF record, click here.
DKIM, or DomainKeys Identified Mail, lets an organization (or handler of the message) take responsibility for a message that is in transit. DKIM attaches a new domain name identifier to a message and uses cryptographic techniques to validate authorization for its presence. The identifier is independent of any other identifier in the message, such as in the author’s From: field. DKIM is also a TXT record signature that builds trust between the sender and the receiver.
DKIM uses an encryption algorithm that creates a pair of electronic keys—a public key and a private key. Your ESP should create these keys for you.
The private key remains on the computer it was created on. The first key’s encryption can only be decrypted by the other key. A sender will post the “public” key in the DNS record and list its location in the DKIM signature with the “d=” domain and the “s=” selector. The private key is kept secret by the owner of the DNS and stored in the sending email server. If the information in the decrypted signature matches the information it received in the unencrypted header, it knows the header has not been tampered with during transmission and reception.
In other words, DKIM is a way to ‘sign’ an email with a digitally-encrypted signature. This signature is a header that is included in an email message. Here is an example of a DKIM signature:
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1476054397;
s=m1; d=e.rentpath.com; email@example.com;
To understand the inner workings of DKIM would require strong knowledge on modern cryptography. For our purposes, DKIM is a technical practice that builds trust between a sending and a receiving email server.
For more information on DKIM, click here.
DMARC, or Domain-Based Message Authentication Reporting and Conformance, is an added authentication method that uses both SPF and DKIM to verify whether or not an email was actually sent by the owner of the “Friendly-From” domain that the user sees. In order for DMARC to pass, both SPF and DKIM must pass, and at least one of them must be aligned.
For SPF to align, the message’s From-domain and its Return-Path domain must match. For DKIM to align, the message’s From domain and its DKIM d= domain must match.
Any message that does not align is treated as phishing and is not delivered. Phishing is the fraudulent practice of sending malicious emails pretending to be someone else in an attempt to steal a user’s credit card information or other personal information. Therefore, with DMARC, you are protecting yourself. In March 2017, the Federal Trade Commission published a study on DMARC usage by businesses. The study found that about 10% of 569 businesses with a significant online presence publish strict DMARC policies.
When implementing a DMARC record, you have 3 policies to choose from. These policies inform the recipient server how to treat mail sent from you that is not DMARC compliant. Please note that the recipient server is not required to treat mail as requested.
A successful DMARC implementation would slowly ramp up from different percentages of quarantine to ultimately fully reject. A successful practice also requires the sender to regularly monitor DMARC reports. These reports would inform you of any phishing attempts to your domain, if your own mail is being rejected for failing DKIM or SPF.
Is DMARC necessary? Let’s just say that Google recommends the use of DMARC for bulk email senders and we highly suggest it as well. It proves to ISPs that you are a serious sender and are willing to take precautionary measures to protect your identity and reputation. Plus, Gmail and Microsoft are quickly adopting DMARC into their filtering methods.
As with every authentication method mentioned, it’s better to be safe than sorry!