SpamAssassin RDNS_DYNAMIC and HELO_DYNAMIC_IPADDR - spamassassin

Question

I'm using SendGrid to deliver emails and the recent test I conducted from my server, using their API, ended up having SpamAssassin flagging my email. Here is the result:
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information.
[URIs: sendgrid.net]
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 T_SPF_HELO_TEMPERROR SPF: test of HELO record failed (temperror)
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
0.0 HTML_MESSAGE BODY: HTML included in message
2.0 HTTPS_HTTP_MISMATCH BODY: No description available.
1.1 KAM_REALLYHUGEIMGSRC RAW: Spam with image tags with ridiculously huge
http urls
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's
domain
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid
2.6 RDNS_DYNAMIC Delivered to internal network by host with
dynamic-looking rDNS
2.0 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr 1)
X-Spam-Flag: YES
The webhosting company I'm using just came back to me saying that they fixed the problem by disabling SpamAssassin from my server. I might need a better solution.
So the main question I have is: who should I contact to get the following lines fixed? My webhost, Sendgrid or someone else?
2.6 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS
2.0 HELO_DYNAMIC_IPADDR Relay HELO'd using suspicious hostname (IP addr 1)

Answer 1

HELO_DYNAMIC_IPADDR indicates that the sending server connected to the receiving server and announced itself with an IP address rather than a Fully Qualified Domain Name (FQDN), and RDNS_DYNAMIC indicates that the Reverse DNS check on that IP address resolves to something that resembles the FQDN of a dynamically issued IP address.
To rectify this you would need to get the rDNS of your sending IP to resolve to a plausible FQDN, and in turn use that FQDN in the HELO / EHLO handshake. Both of these relate to the MX phase of your message exchange, and would be caused by the sending server, but maybe your sender doesn't want to announce themselves overtly to avoid other more direct SPAM rules from being applied to their perceived sender reputation ?
I would have expected SendGrid to send on your behalf using your domain name during the HELO handshake, and consequently require their sending IP ranges to be included in any SPF records for your domain.
Historically it used to be misconfigured Exchange Servers that announced the IP address during the HELO handshake, because unwitting admins entered an IP address in the FQDN field of their Send Connectors.