SPF HELO/EHLO not published for Google Workspace mailservers

I have checked my e-mails for matching SPF check, resulting in SPF_HELO_NONE flag (HELO does not publish an SPF Record). I own a domain, which is connected to Google Workspace and Gmail service for sending mails. Therefore I send e-mails through their mailservers, so I cannot set up a SPF HELO/EHLO record for the mailserver itself (only for my domain, but there is no mailserver on my domain, since I only use Gmail services for the domain).

I have set SPF records on my domain to include _spf.google.com, but as far as I understand how HELO/EHLO works, it seems like Google does not provide HELO/EHLO records on their mailservers.

Does the SPF HELO/EHLO check fail because there is no HELO/EHLO record on Google's mailserver domains?

Short answer: yes, that flag appears because Google's sending hosts announce a HELO name in a domain that has no SPF record, and no, you can't do anything about it, but it also doesn't matter. Let me separate the pieces.

Two SPF identities, not one

SPF can be evaluated against two different identities (RFC 7208 sections 2.3 and 2.4):

• the HELO/EHLO name the sending server announces, and
• the envelope MAIL FROM (Return-Path).

SPF_HELO_NONE is only about the first one. It means the HELO hostname's domain published no SPF record, so there was nothing to check. It is not a failure. SPF_HELO_FAIL would be a failure; NONE just means "no record found."

Why it happens with Google Workspace

When Google sends your mail, their outbound MTA greets the receiver with a HELO like mail-...google.com, a name Google owns. The HELO SPF check then looks for an SPF record on that Google hostname, not on your domain. Whether one exists is entirely Google's call. As your commenter said, HELO is controlled by Google, so there is genuinely no record you can publish to change this. Your own domain's SPF, the one that includes _spf.google.com, applies to the MAIL FROM identity, which is a separate check.

Why it doesn't matter

For DMARC, the SPF result that counts is the MAIL FROM one, not HELO. DMARC only falls back to the HELO identity when the MAIL FROM is null, which is the bounce case (RFC 7489 section 3.1.2). For your normal outbound mail the HELO SPF result is simply not part of the DMARC decision. Your domain passes and aligns on the MAIL FROM SPF, and on DKIM, which Google Workspace signs with your domain once you enable it, and that is what receivers and DMARC actually use.

So SPF_HELO_NONE is an informational note from whatever checker you ran (it is a SpamAssassin rule, and it carries essentially no score), not a problem to fix. Make sure your domain SPF passes and aligns, and that Google Workspace DKIM is enabled with your domain, and you are done.

The only way to make the HELO check itself pass would be to send through infrastructure whose HELO name you control and can publish SPF for, which for Google Workspace means not using Google Workspace. That is not worth doing for a flag that has no effect on delivery.