About SPF, DKIM, and DMARC for email authentication

On this page:

Overview

Email addresses are easily spoofed. Spammers often take advantage of this to send email messages that impersonate trusted users, companies, organizations, and universities to mask their true identities. In recent years, attempts have been made to address this problem using email authentication protocols such as SPF, DKIM, and DMARC.

Sender Policy Framework (SPF)

Sender Policy Framework (SPF) allows a domain to define which mail systems are permitted to send emails on its behalf. SPF records may contain the mail system addresses of its domain as well as those of its partner domains that are trusted to send emails as the domain (such as a vended email system or a constituent relationship management (CRM) service like Salesforce). The SPF record is published in the domain's DNS records. An email server will query the SPF record from the domain's DNS records when it receives an email message with a sending address from that domain. A match authenticates the message as having originated from a trusted source on behalf of the sending domain.

DomainKeys Identified Mail (DKIM)

Using DomainKeys Identified Mail (DKIM), a domain provides a cryptographic signature in email messages it sends, and that signature can then be verified via a DNS record containing the public key. The DKIM signature contains both a domain identifier for the hosted public key record to query from DNS, and the selector to uniquely identify the email messages signed. This DKIM signature is added to the email headers of signed email messages.

A domain may publish multiple DKIM keys, and a domain may have multiple selectors. This permits the domain to configure multiple keys to distinguish and manage sending from different accounts and email servers. An email server receiving a signed email message will query the public DNS record according to the DKIM signature to verify that the domain from which it is purported to have been sent matches the signature.

Domain-based Message Authentication, Reporting & Conformance (DMARC)

Domain-based Message Authentication, Reporting & Conformance (DMARC) uses SPF and/or DKIM to verify that received email messages "align", and it also tells receiving email systems what action to take with received email messages based on what the domain publishes in the DMARC record. The DMARC record is published to the domain's DNS records. Without a DMARC record, email systems will act independently. Having a DMARC record puts the domain in control of how email messages are handled by other email systems.

DMARC permits a domain to tell email systems what to do with messages that do not "align" with their SPF and/or DKIM records. The three permitted options are:

  • Take no action: This option is often implemented during the information-gathering phase to collect reporting data from other domains about email messages being received.
  • Quarantine: This option recommends marking messages that do not align with SPF and/or DKIM as spam.
  • Reject: This option advises email servers not to accept email messages that do not align with SPF and/or DKIM.

Effect of DMARC on forwarded messages

While DMARC affects delivery of email messages, the impact to forwarded messages is particularly problematic. Email forwarding where the receiving address is forwarded to another email address without rewriting the sender address appears to be a spoofed email. If the DMARC policy is set to "quarantine", the email may be marked as spam; if the DMARC policy is set to "reject", the email may not be delivered at all.

For example, assume that an email message sent by PayPal to an IU user is forwarded to an AOL email address. AOL email systems will receive the message from IU systems, but the message originated from a PayPal email system with a PayPal sender address to an IU user, not to an AOL user. The email message will not align with SPF or DKIM; therefore, it will not pass DMARC.

This is document azlu in the Knowledge Base.
Last modified on 2024-04-10 15:23:55.