What is SPF ?

This document describes the vSMTP implementation of the Sender Policy Framework (SPF) protocol. SPF specifications are available in the RFC 7208 document.

SPF is an authentication standard used to link a domain name and an email address. it allows email clients to verify that incoming email from a domain comes from a host authorized by the administrator of this domain.

The SPF framework allows the ADministrative Management Domains (ADMDs) to explicitly authorize hosts to send email. The authorization list is published in the DNS records of the sender’s domain.

DNS records

The type of a SPF record is TXT. There should be only one SPF record per domain. In case of multiple SPF records, an error may be raised.

Here is a basic SPF record example: “only servers in the range 123.123.123.0/24 and MTA (MX) are authorized to send emails from my domain example.com. All other senders are considered unauthorized.”

example.com.          TXT "v=spf1 +mx ip4:123.123.123.0/24 -all"

There is also a tilde version: ~all. It warns that other senders are not allowed, but must still be accepted. This “Soft Fail” statement was first introduced for testing purposes, but is now used by various hosting providers.

Use of wildcard records for publishing is discouraged.

Please refer to RFC 7208 for further details.

vSMTP implementation

HELO/EHLO Identity

The RFC 7208 does not enforce a HELO/EHLO verification.

“It is RECOMMENDED that SPF verifiers not only check the “MAIL FROM” identity but also separately check the “HELO” identity […] Additionally, since SPF records published for “HELO” identities refer to a single host, when available, they are a very reliable source of host authorization status. Checking “HELO” before “MAIL FROM” is the RECOMMENDED sequence if both are checked.“

The RFC 5321 tends to normalize the HELO/EHLO arguments to represent the fully qualified domain name of the SMTP client. However the vSMTP SPF verifier is prepared for the identity to be an IP address literal or simply be malformed.

“SPF check can only be performed when the “HELO” string is a valid, multi-label domain name.“

MAIL FROM identity

According to the RFC, “MAIL FROM” check occurs when :

“SPF verifiers MUST check the “MAIL FROM” identity if a “HELO” check either has not been performed or has not reached a definitive policy result.“

Note that RFC5321 allows the reverse-path to be null. In this case, the RFC 7208 defines the “MAIL FROM” identity as the local-part “postmaster” and the “HELO” identity.

Location of checks

As defined by the RFC :

“The authorization check SHOULD be performed during the processing of the SMTP transaction that receives the mail. This reduces the complexity of determining the correct IP address to use as an input to check_host() and allows errors to be returned directly to the sending MTA by way of SMTP replies.”

vSMTP allows the use of the SPF framework only at the “MAIL FROM” stage.

Results of Evaluation

The vSMTP SPF verifier implements results semantically equivalent to the RFC.

Results headers

Results should be recorded in the message header. Two options are available according to the RFC:

1. The “Received-SPF” header

Received-SPF: pass (mybox.example.org: domain of myname@example.com
  designates 192.0.2.1 as permitted sender)
  receiver=mybox.example.org; client-ip=192.0.2.1;
  envelope-from="myname@example.com"; helo=foo.example.com;

1. The “Authentication-Results” header described in RFC 8601 : Message Header Field for Indicating Message Authentication Status.

Authentication-Results: example.com; spf=pass smtp.mailfrom=example.net

SPF failure codes

The RFC 7372 “Email Auth Status Codes” introduces new status codes for reporting the DKIM and SPF mechanisms.

The following error codes can also be sent by the SPF framework.