RFC 7208, "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", April 2014

Note: This RFC has been updated by RFC 7372, RFC 8553, RFC 8616

Errata ID: 5550
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Borislav Petrov
Date Reported: 2018-11-09

Section 2.3. says:

   Note that requirements for the domain presented in the EHLO or HELO
   command are not always clear to the sending party, and SPF verifiers
   have to be prepared for the identity to be an IP address literal (see
   [RFC5321], Section 4.1.3) or simply be malformed.  This SPF check can
   only be performed when the "HELO" string is a valid, multi-label
   domain name.

Notes:

It looks like that those who have HELO <IP Address> or <malformed> will have result "none" (and pass) but those that have HELO <hostname> and have not yet published their hostname (A record) as allowed sender will get fail. This becomes a very common case for all messages which are DSNs. The whole idea that it is better to have your HELO malformed than a valid hostname which identifies the system is wrong. The point is to fight spam but you actually make it easier for spammers to just have the EHLO malformed and send with <> reverse-path rather than having some proper EHLO/HELO which is subject to other verifications like rDNS, etc.

Report New Errata