A few notes on email authentication

These are some very rough notes for getting oriented around the technology for email authentication.

SPF RFC 7208

Sender Policy Framework (SPF).

The Wikipedia entry for SPF.

Sender Policy Framework (SPF) is a simple email-validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain comes from a host authorized by that domain’s administrators.

Here’s RFC 7208 from IETF

Valimail has a patent-pending Targeted SPF.

A few high level notes:

  • SPF-compliant domains publish valid SPF records as described in Section 3 of 7208.

  • SPF results can be used to determine whether source is or is not authorized.

  • Changing SPF policies requires a transition period between emails with old policy and emails with new policy.

  • SPF checks can be done anywhere in the mail processing chain but are typically performed by the receiving MTA.

  • SPF checks are not mandatory, but if performed mush comply with a correctly implemented check_host() function as defined in 7208.

  • SPF record is a DNS record which declares which hosts are and are not authorized to use a domain name for the “HELO” and “MAIL FROM” identities. The SPF record is expressed as a single string of text found in the RDATA of a single DNS TXT resource. Multiple SPF are not permitted for the same owner name.

DKIM RFC 6379

Domain Keys Identified Mail (DKIM).

From DKIM Wikipedia entry.

DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect email spoofing. It allows the receiver to check that an email claimed to come from a specific domain was indeed authorized by the owner of that domain.[1] It is intended to prevent forged sender addresses in emails, a technique often used in phishing and email spam.

In technical terms, DKIM lets a domain associate its name with an email message by affixing a digital signature to it.

What the above implies is the DKIM separates the identity of the message sender from the identity of the message author.

  • DKIM writes message signature into header instead of into message body.

  • Failed verifications do not preclude message rejection.

  • Compatible with existing email infrastructure with little new infrastructure, deployed incrementally, allows third party signing.

  • No certificate authority is required, the public key is requested from the signer instead of a third party.

  • The main notion is that the message must be signed before leaving the administration domain of the Signer.

  • The DKIM-Signature header field includes the signature and key fetching data.

More than one DKIM signature may be provided by a sending agency. In such cases, “selectors” are provided by the sending agency to direct the recipient to the appropriate key. Selectors take the form selector._domainkey.example.com.

Background material on DKIM is recommended reading:

RFC 6376

Setting up DKIM on Bluehost

  • http://russandbecky.org/blog/2016/03/16/bluehost-dkim-getting-email-working/
  • http://dkimcore.org/tools/keys.html
  • http://www.appmaildev.com/en/dkim/

DMARC RFC 7489

Domain-based Message Authentication, Reporting and Conformance (DMARC).

DMARC depends on DKIM and SPF, explained below.

The DMARC Wikipedia entry.

Domain-based Message Authentication, Reporting and Conformance (DMARC) is an email-validation system designed to detect and prevent email spoofing. It is intended to combat certain techniques often used in phishing and email spam, such as emails with forged sender addresses that appear to originate from legitimate organizations. DMARC is specified in RFC 7489.

The main feature of DMARC seems to be allowing Domain Owners and [email] receivers to collaborate. This is accomplished by providing receivers with assertions about the Domain Owners’ policies and by providing feedback to senders for authentication and threat assessment.

  • DMARC policy assertions are published by Domain Owners via DNS.
  • Receivers compare From address to SPF and DKIM, if present.
  • Receiver sends reports to Domain Owners (or designees) about mail claiming to be from their domain.

DMARC with SPF and DKIM allow for a wider variety of use cases than SPF and DKIM alone.

High level goals for DMARC include allowing Domain Owners to assert preferred handling of authentication failures, verifying authentication deployment, minimizing implementation complexity for senders and receivers, reduce the amount of spoofed email, work at internet scale.