I'm try to understand the benefit of the HELO Identity defined in RFC7208 (SPF).

There is a mail server, let's say mail.example.com. This server is used as relay for different domains.

In Section 2.4:

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 by applying the check_host() function to the "MAIL FROM" identity as the <sender>.

I understand that, if the HELO has passed, there is no need to check MAIL FROM.

Similar in section 2.3:

Checking "HELO" promotes consistency of results and can reduce DNS resource usage. If a conclusive determination about the message can be made based on a check of "HELO", then the use of DNS resources to process the typically more complex "MAIL FROM" can be avoided.

Would this not lead to unchecked MAIL FROM identities?

Regards, Alex

New contributor
Alex is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • 1
    Interesting question. Indeed, why is the HELO check considered useful in the first place, and why was it upgraded from an optional extra check in the earlier SPF spec to conditionally replacing the actually relevant check in the current spec? Without knowing the reasoning it just seems like it creates a big hole where there wasn't one before. – Håkan Lindqvist May 4 at 13:14
  • 1
    ‘I understand that, if the HELO has passed, there is no need to check MAIL FROM.’ This is not what the RFC says. It depends on your policy. If your policy is that a HELO pass is sufficient, then indeed you don’t need to check MAIL FROM. But usually that is not a good policy. – glts May 4 at 14:46

Some possible uses:

  • You could reject a failing HELO identity early. Since the HELO SMTP command occurs early in the conversation, you can reject HELO identities that evaluate to fail right away. (I’m using this on my own mail host and see quite a few clients who claim to be this very mail host rejected early.)

  • You could evaluate both the HELO identity and the MAIL FROM identity and use both to contribute towards some ‘score’ of legitimacy. For example, you could assign more trust to a sender whose HELO and MAIL FROM identities evaluate to pass.

  • You could decide to skip evaluation of the MAIL FROM identity if you are satisfied with a HELO identity pass or fail or softfail, as a shortcut, so to speak: you don’t have to check MAIL FROM if you’re not interested in it. Note, however, that the HELO identity can easily be forged, just like the MAIL FROM identity (senders may send whatever they please), so usually you would be interested in the MAIL FROM identity (and possibly feed it into a DMARC component).

It all depends on your requirements. It also depends on what your SPF implementation allows (all of the above is supported by my own implementation, SPF Milter).

In practice, perhaps it helps to think of the HELO identity as something that is primarily useful with negative results (fail, softfail, permerror), not so much with a positive result (pass). When a mail server checks the HELO identity and encounters a negative result, it can either end the conversation right away or record the negative HELO result as the final SPF result in a header. Under such a policy, the MAIL FROM identity indeed does not need to be evaluated in these cases. Such a policy would indeed lead to the mentioned reduction of DNS resources, and so this is where I see immediate practical benefit of providing and checking the SPF HELO identity.

  • Sure. that are all possibilities I can do with that. The RFC should not state that HELO pass is enough to skip MAIL FROM. The SPF record of HELO could be complete different domain. So I see no benefit to check this identity. The check of MAIL FROM would be sufficient. To set the SPF record for the FQDN of the HELO string just give no added value. – Alex 2 days ago

Your Answer

Alex is a new contributor. Be nice, and check out our Code of Conduct.

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.