SPF, DKIM, and DMARC - What are they and how do they work

For marketers interested in the technical aspects of email deliverability, it won’t be long before you come across the acronyms SPF (Sender Policy Framework), DKIM (Domain Keys Identity Management), and DMARC (Domain-Based Message Authentication, Reporting and Compliance). Besides being catchy jargon, understanding these concepts and what they do is important to managing the email deliverability of your company, particularly when it comes to setting up your Eloqua instance.

So, before I write about what SPF, DKIM, and DMARC can do, let’s be clear about what they cannot do: They cannot, by themselves, be a panacea for any email deliverability woes. All three can help you develop a great sender reputation amongst ISPs and other email recipient systems; however, if you negate to follow good email practices, SPF, DKIM, and DMARC won’t save you.

What they will do is enable you to prove that your emails are authentic. As technical protocols, they demonstrate that Eloqua is authorized to send emails on behalf of your company and the contents have not been tampered with. Because of the prevalence of fraudulent and SPAM emails, ISPs value being able to verify the authenticity of any email before delivering it to the recipients’ inboxes. Each of the protocols enables specific aspects of this verification, and I’ll outline these next.

Sender Policy Framework

SPF’s main function is to help email systems to check whether another specific email platform is allowed to send emails on behalf of a particular domain. In other words, if you use @marketing.example.com to send marketing emails, SPF enables ISPs to check that your specific instance of Eloqua is allowed to send emails using the example.com domain. In this manner, SPF helps ISPs to avoid one aspect of email spooking: where one server falsely claims to send emails from a specific domain.

To understand how SPF works, you need a little background on how the Internet functions. If you want to use a new domain, such as relationshipone.com, on the Internet, the domain must be registered with a Domain Name Registrar, which is an organization that records who owns what domain and also the IP addresses associated with the domain. An IP address is a numeric string (e.g. 116.113.255.255) that servers use to find and direct requests and replies to each other.

When a request, such as to view a web page, is made to a domain, a complex network of specialized servers called Domain Name Servers (DNS) direct the request to the IP address of your company’s DNS. Your DNS then directs the request to the correct system within your company’s internal network.

When Eloqua sends out an email, SPF enables receiving systems to verify that the IP address associated with your instance is authorized to send on behalf of that domain. So, let’s say your email platform has an IP address of 116.113.255.255 and sends an email on behalf of @marketing.example.com. When an ISP receives an email from your Eloqua instance, the ISP will reach out to your company’s DNS, which is registered for example.com, and look for a record called an A-record that associates 116.113.255.255 with the domain marketing.example.com. If the ISP finds that record, your email is said to have passed SPF. Passing SPF doesn’t mean your email will automatically be delivered into the recipients’ inboxes, but it does mean your email will not be blocked outright.

DKIM

While SPF deals with the authenticity of an email’s source, DKIM ensures its contents haven’t been altered by unauthorized third parties. It does this by attaching a DKIM signature to outgoing messages, which receiving email systems use to discern if the email’s content has been changed.

DKIM works by using hashing and cryptographic key pairs. Hashing is a method for creating a string of alphanumeric text through a mathematical function, while cryptographic key pairs are two non-identical matching strings that encrypt and decrypt data. The genius of these key pairs is they can only be used with each other. One set can only be used to decrypt data received from its matching sibling; it can’t be to decrypt data from a different key.

Thus, when a DKIM signature is applied to an email, parts of the email are first hashed to generate a seemingly random alphanumeric string. So, for example, relationshipone.com might become 12ri5kfk56jkfjkglf. This hash is further encrypted using a private cryptographic key that only your servers can access. This encrypted data makes up part of the DKIM signature, which will also detail the location of the sibling public-key on your DNS.

When you send an email from Eloqua, the receiving mail system will do the following:

Generate its own hash from parts of your email, as stipulated by your DKIM signature.
Use the location given by your DKIM signature to find the public key and use it to decrypt your encrypted string to its original hash.
Compare the self-generated hash to the decrypted hash. Since any tampering would result in the self-generated hash not matching the decrypted one, if a perfect match is made, then the message is deemed to not have been tampered with and thus passes DKIM.

DMARC

DMARC builds on both SPF and DKIM by providing additional security and reporting capabilities. This last part enables owners to take remedial action if unauthorized messages are being sent.

To pass DMARC, a message must do two things:

Pass either SPF or DKIM authentication, and
Pass SFP or DKIM validation. Validation is where the friendly from address in the email, also known as the mail-from address, matches the bounceback address, which is also called the header-from address.
Both authentication and validation must occur within the same protocol. e.g. you must pass SPF authentication and validation OR DKIM authentication and validation.

In tandem with SPF, DMARC provides greater protection against spoofing. While SPF ensures a server at a specific IP address is authorized to send an email on behalf of a particular domain, it doesn’t check the friendly from-address, which is the from address displayed to the user. For example, in Gmail, one can often see emails where the from address looks like “marketing@myDomain.com via marketing@someOtherDomain.com”. In this example, the friendly-from is myDomain.com but a server from the header-domain someOtherDomain.com has actually sent the email. Because some email clients don’t automatically show the header-domain, this can provide opportunities for fraudsters. DMARC closes this gap by checking whether the friendly-form matches the bounceback address, which is directly tied to the sending server. If a mismatch occurs, then the email fails DMARC.

The beauty of DMARC is that email providers can control what happens when a message fails the check. When a message fails, the receiving email server will reach out to your DNS to look for a DMARC record. That record will specify your corporate policy towards failed messages. That policy can range from do nothing to reject only a specified percentage of failures through to quarantine all failures. In addition, your DMARC record also tells details where to send reports and alerts of failed messages, which provides your IT team with the opportunity to fix this problem.

Unlike DKIM or SPF, DMARC is not part of a standard Eloqua set up, so it requires additional configuration. In addition, because it may affect all emails coming out of your company, not just the ones sent out of Eloqua, it requires careful planning.