The HELO hostname can be different from the sender
The HELO hostname should have a matching A & PTR, but they do not have to match the domain used in neither RFC 5321 MAIL FROM nor RFC 5322 originator fields From header – nor even share an organizational domain.
E.g., mail1.example.com & mail2.example.com could well send mail for example.com, example.net & example.org. Otherwise, every domain would need an own IP address with a matching PTR record. Think of the amount off domains large email service providers are handling, and they certainly use a common infrastructure for them all.
MX records are for incoming mail
The MX records do not relate to sending mail but to receiving it. In the scope of your question there is not any kind of relation between them. The inbound mail could be handled by a different set of servers altogether. E.g., newsletters from a domain could be sent using SendGrid or MailChimp while the incoming mail is handled by M365 or Gmail.
Origin of HELO/DNS mismatches
Using HELO / A / PTR mismatches as an indication of spam is common, as described by, e.g., MXToolBox:
This practice probably comes from an interpretation of RFC 5321, 2.3.5:
The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an address RR) or, if
the host has no name, an address literal, as described in
Section 4.1.3 and discussed further in the EHLO discussion of
Section 4.1.4.
However, it is not a hard requirement, as the 4.1.4 further defines, that:
The SMTP client MUST, if possible, ensure that the domain parameter
to the EHLO command is a primary host name as specified for this
command in Section 2.3.5. If this is not possible (e.g., when the
client's address is dynamically assigned and the client does not have
an obvious name), an address literal SHOULD be substituted for the
domain name.
An SMTP server MAY verify that the domain name argument in the EHLO
command actually corresponds to the IP address of the client.
However, if the verification fails, the server MUST NOT refuse to
accept a message on that basis.
Here, the SMTP protocol seems to follow the robustness principle i.e. "be conservative in what you do, be liberal in what you accept from others".
SPF
It is mandatory for the Sender Policy Framework (SPF) implementations to protect the MAIL FROM identity (RFC 7208, 2.4) and it can optionally protect the HELO identity (RFC 7208, 2.3), too:
It is RECOMMENDED that SPF verifiers not only check the MAIL FROM
identity but also separately check the HELO identity by applying
the check_host() function (Section 4) to the HELO identity as the
<sender>. 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.
As this is done independently, SPF does not require them to match, either.
SPF protects the hostname from being used as the envelope sender without permission, and it is not inherited by the subdomains. Therefore, you should protect every A record you have with a corresponding TXT SPF record – not just the ones you are using for sending email.
DMARC
The Domain-based Message Authentication, Reporting, and Conformance (DMARC) requires a match between RFC5322.From and the Identifier Alignment as defined in RFC 7439, 3.1. Those identifiers can either be DKIM-Authenticated (3.1.1) or SPF-Authenticated (3.1.2) and depending on the mode it could require an exact match or a shared organizational domain (3.2). Unlike SPF, DMARC is inherited; a DMARC policy at the domain apex protects all the subdomains from being used in the From header, too.
The SPF alignment requires a matching MAIL FROM, but the DKIM alignment does not; it is sufficient to have a valid and authorized DKIM signature with a matching signing Domain identifier (SDID) (d= field). As a bottom line, neither of these requires a matching HELO/EHLO hostname.
