Is Google applying SPF checks to EHLO values for stricter email authentication?
Published 19 Apr 2025
Updated 19 Oct 2026
12 min read
Summarize with
Updated on 19 Oct 2026: We clarified Gmail's EHLO SPF requirements and corrected the DMARC reporting guidance for RFC 9990.
Google has not documented a separate Gmail sender requirement for an EHLO SPF pass. That does not establish whether Gmail performs HELO or EHLO SPF checks internally. Google requires email authentication, valid forward and reverse DNS for sending IPs, and TLS. Check the SMTP rejection details for a bad PTR, a PTR hostname that returns NXDOMAIN, missing MAIL FROM SPF for a bulk sender, failed DKIM, missing DMARC for a bulk sender, or a reputation issue before attributing the failure to EHLO SPF.
The caveat is important. SPF allows receivers to check the HELO or EHLO identity, and RFC 7208 recommends checking HELO before MAIL FROM when both are checked. That recommendation does not mean Gmail has a public rule requiring an EHLO SPF pass for inbox delivery. It means HELO SPF is a valid receiver-side check, especially for bounce messages or direct-to-MX mail where the connecting host identity matters.
Short answer
- Answer: Gmail has not documented EHLO SPF as a standalone stricter authentication requirement.
- Practical fix: Fix PTR and FCrDNS, MAIL FROM SPF, DKIM, DMARC, TLS, and reputation signals first.
- Optional hardening: Publish SPF for the EHLO hostname when you control that hostname and send directly.
What SPF actually checks
SPF is checked against an identity in the SMTP transaction, not against the visible From header that a recipient sees. Most normal SPF troubleshooting focuses on the envelope sender, also called MAIL FROM or return-path. That is the domain that receives bounces and is the SPF identity most senders control through their email platform.
The EHLO value is different. It is the hostname the sending server presents when it opens the SMTP session. A receiver can check SPF for that hostname as the HELO identity when it is a valid fully qualified domain name (FQDN). That check is cleaner when the hostname maps to one sending machine, but it is not the same thing as DMARC passing. DMARC requires an SPF or DKIM pass with a domain that matches the visible From domain. Strict matching requires an exact domain match; relaxed matching permits the same Organizational Domain. A separate HELO SPF pass does not replace MAIL FROM SPF for messages with a nonempty reverse-path.
SMTP identities involved in SPFtext
S: 220 mx.google.com ESMTP C: EHLO mail1.example.com C: MAIL FROM:<bounce@example.com> C: RCPT TO:<user@gmail.com> HELO identity: mail1.example.com MAIL FROM identity: example.com Header From identity: example.com
EHLO or HELO SPF
- Identity: The hostname announced by the connecting SMTP server.
- Best use: Direct senders with stable hostnames and a small server pool.
- Risk: Many platforms do not give customers control over their EHLO hostname.
MAIL FROM SPF
- Identity: The envelope sender domain used for bounces and SPF.
- Best use: Bulk mail, transactional mail, and delegated sending platforms.
- Risk: Exceeding the SPF lookup limit, missing senders, or a domain mismatch can prevent SPF from satisfying DMARC.
If the question is which domain SPF is checked against, the useful starting point is the SPF domain check. For a focused DNS validation, run the SPF checker against the exact MAIL FROM domain and, where relevant, the EHLO hostname.
Why EHLO SPF matters for bounce messages
Delivery status notifications normally use an empty reverse-path, written as MAIL FROM:<>, to avoid bounce loops. In that case, RFC 7208 defines the MAIL FROM identity as postmaster at the HELO or EHLO domain. The connecting hostname therefore supplies the domain used for SPF evaluation, even though no envelope sender address appears in the SMTP command.
SPF identity for a bounce messagetext
C: EHLO mail1.example.com C: MAIL FROM:<> Derived SPF identity: postmaster@mail1.example.com SPF policy domain: mail1.example.com
- Use a valid multi-label hostname for EHLO, such as mail1.example.com, because an IP literal or malformed name cannot be checked as a normal HELO SPF identity.
- Publish a narrow SPF policy for that hostname when the server sends bounces directly, authorizing only its actual sending IP or IP range.
- Keep a stable EHLO hostname with valid DNS. Separately, the sending IP's PTR hostname must resolve back to that IP; Google does not document an exact EHLO-to-PTR hostname match as a separate requirement.
This bounce-specific behavior explains why EHLO SPF can matter without proving a new Gmail-wide rule. If ordinary messages pass but delivery status notifications fail, compare their empty reverse-path, EHLO hostname, DNS records, and SMTP response before changing the main MAIL FROM SPF record. For SPF to satisfy DMARC on a bounce, the derived domain must also match the visible From domain under the applicable matching rules.
Gmail's published sender requirements
Google's published requirements apply to mail sent to personal Gmail accounts (@gmail.com and @googlemail.com). The Google sender guidelines require all senders to use SPF or DKIM, and bulk senders to use SPF, DKIM, and DMARC. A DMARC policy of p=none meets the policy requirement, but messages must still pass the required authentication and domain matching checks. The same guidance requires valid forward and reverse DNS records for sending IPs, TLS, and a spam rate below 0.3%. Marketing and subscribed messages from bulk senders must also support one-click unsubscribe and a visible unsubscribe link in the message body.
Google defines bulk senders as domains sending close to 5,000 messages or more to personal Gmail accounts within 24 hours, counting subdomains under the same primary domain. Once assigned, bulk sender status is permanent. Google began increasing enforcement against noncompliant traffic in November 2025; that enforcement concerns the published requirements and does not document a new EHLO SPF mandate.
Illustrative Google Postmaster Tools screen with Gmail authentication and delivery error metrics.
|
|
|
|---|---|---|
SPF | MAIL FROM sender authorization | Authorize all legitimate sending IPs |
DKIM | Signed domain | Use at least 1024 bits; prefer 2048 |
DMARC | From-domain match | Publish a policy and verify domain matching |
PTR | Forward and reverse DNS | Fix FCrDNS |
Spam rate | User complaints | Target below 0.1%; avoid 0.3% or higher |
The published Gmail requirements point to combined authentication and infrastructure checks, not EHLO SPF alone.
That is why PTR and forward-confirmed reverse DNS (FCrDNS) belong near the top of the investigation. If a PTR points to a hostname and that hostname has no A or AAAA record returning the sending IP, the reverse DNS chain is broken. Gmail documents 451 4.7.23 for temporary rate limiting and 550 5.7.25 for blocking when PTR or forward DNS is invalid. SPF failures for bulk senders have separate 421 4.7.27 and 550 5.7.27 codes. A 550 5.7.26 response has several documented causes, so read its full explanation instead of treating the code as proof of an EHLO SPF failure.
Gmail delivery troubleshooting flowchart covering reverse DNS, SPF, DKIM, DMARC, and reputation.
How to read Gmail's SPF results
For an accepted message, open Gmail on a computer, open the message menu, and select "Show original". Inspect the Authentication-Results header added by mx.google.com. The smtp.mailfrom property identifies a MAIL FROM SPF result; it is separate from the visible From address.
Illustrative MAIL FROM SPF resulttext
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=bounce.example.com
RFC 8601 uses smtp.helo for a HELO or EHLO SPF result. A missing smtp.helo result does not prove Gmail skipped that check. For a nonempty reverse-path, a HELO pass alone does not establish that MAIL FROM SPF passed.
- none means no usable SPF policy was found for the evaluated identity; it is different from fail.
- fail means the policy did not authorize the IP. softfail is a weaker negative result; neither is pass.
- temperror indicates a temporary evaluation problem, such as a DNS lookup failure.
- permerror indicates a policy or evaluation error, including multiple SPF records or exceeding lookup limits.
For rejected messages, use the sending server logs and full Gmail SMTP response because no delivered copy is available to inspect.
How to test whether EHLO is involved
A clean test separates the SMTP identities instead of changing everything at once. Capture the EHLO hostname, MAIL FROM domain, sending IP, PTR result, forward DNS result, DKIM domain, and Gmail SMTP response. Compare those values with DMARC aggregate results, but use SMTP logs for individual rejected sessions. Aggregate reports are periodic summaries and do not expose every SMTP check or rejection.
Run a full domain health check before narrowing the issue. A single SPF pass does not prove the sending path is healthy when reverse DNS or DKIM is broken.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
If you control the sending host, publish an SPF record for the EHLO hostname after the core DNS is correct. Maintain MAIL FROM SPF separately. SPF policies are not inherited by subdomains, so publish one SPF TXT record at each exact hostname used as an SPF identity.
DNS records for a direct senderdns
bounce.example.com. TXT "v=spf1 ip4:192.0.2.10 -all" mail1.example.com. TXT "v=spf1 ip4:192.0.2.10 -all" mail1.example.com. A 192.0.2.10 10.2.0.192.in-addr.arpa. PTR mail1.example.com.
The example uses the documentation address 192.0.2.10. Replace it with the actual public sending IP, and have the IP provider set the PTR record. If the host also sends over IPv6, authorize that address with ip6 and check its AAAA and reverse DNS records. Google's SPF setup guidance explains where to publish the DNS TXT record.
DMARC aggregate SPF result excerptxml
<auth_results> <spf> <domain>bounce.example.com</domain> <scope>mfrom</scope> <result>pass</result> </spf> </auth_results>
RFC 9990 makes the SPF scope element optional and permits only mfrom when it is present. Older reports can contain helo; treat that as legacy data rather than evidence of a new Gmail requirement. In the excerpt, auth_results records the SPF authentication result. The separate policy_evaluated SPF result reflects DMARC domain matching.
Where Suped fits
Suped's DMARC reporting and email authentication platform groups aggregate reports by sending source so teams can investigate SPF and DKIM failures. Compare these results with SMTP logs to distinguish envelope sender problems from host DNS problems.
- Issue detection: Review failing sending sources and their SPF and DKIM results to choose the next fix.
- Hosted SPF: Suped can host your SPF record so sender changes do not require constant DNS edits.
- Alerts: Use authentication alerts to investigate changes as reports arrive; keep SMTP logs for immediate rejection details.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
SPF evaluation permits at most 10 DNS-querying mechanisms and modifiers, including nested include and redirect processing. Exceeding that limit returns permerror; it is not an allowance for 10 top-level include tags. Suped's SPF flattening workflow helps manage this limit when an SPF policy grows.
Fix order when Gmail rejects mail
When Gmail starts deferring or rejecting a sender, use the full SMTP response to choose the first fix. Gmail evaluates several signals. Confirm the documented infrastructure and authentication requirements, then use controlled tests and DMARC reports to verify what changed.
Fix priority for Gmail-facing senders
Use the SMTP response to choose the first fix; these are troubleshooting priorities, not Gmail thresholds or deadlines.
Critical
Fix now
Missing PTR or a PTR hostname that does not resolve back to the sending IP.
High
Before retrying at scale
Authentication required for the sender category is missing or failing.
Medium
After active failures
SPF policies near the lookup limit or DKIM keys needing a strength review.
Hardening
After basics
EHLO SPF for controlled direct-sending hosts.
- PTR first: Make the sending IP resolve to a hostname, and make that hostname resolve back to the same IP.
- MAIL FROM SPF: Confirm the envelope sender domain authorizes the sending IP or platform.
- DKIM next: Use a valid selector and a strong key. For DKIM to satisfy DMARC, the signing domain must meet its strict or relaxed domain matching rules.
- DMARC reports: Review aggregate reports to find failing sources and distinguish raw SPF authentication from DMARC domain matching.
- EHLO SPF: Add it for direct hosts you control, but treat it as hardening after the required signals pass.
- Reputation: Check complaint rate, bounce patterns, sending spikes, and blocklist or blacklist status.
If you send directly, verify the DNS and reputation of each sending IP separately. A new IP or a different network path needs its own PTR and authentication checks, even when a test against the main sending domain passes.
Common false leads
An EHLO hostname difference does not establish the cause of a Gmail rejection. Compare the sending IPs and full SMTP responses, then check each host's reverse DNS and the actual MAIL FROM domain before assuming an undocumented authentication change.
Looks like EHLO SPF
- Symptom: Gmail accepts one server but rejects another.
- Symptom: The EHLO name differs across hosts.
- Symptom: An SPF tester passes the visible domain.
Other causes to check
- Cause: One IP has broken PTR or forward DNS.
- Cause: The MAIL FROM domain is not the domain being tested.
- Cause: IP reputation changed, or a blocklist (blacklist) entry needs investigation; public list status alone does not prove why Gmail rejected the message.
The best diagnostic habit is to test the identity Gmail actually evaluates at each layer. Test the envelope domain for SPF, the DKIM selector under the signing domain for DKIM, the visible From domain for DMARC matching, the sending IP for PTR and FCrDNS, and the IP/domain pair for reputation.
When to publish EHLO SPF
Treat EHLO SPF as a legitimate SPF capability when you operate a direct mail server. Gmail's published rules require SPF or DKIM for all senders, SPF, DKIM, and DMARC for bulk senders, valid forward and reverse DNS, TLS, and low spam complaint rates. A broken PTR record with a hostname that returns NXDOMAIN needs correction regardless of the EHLO SPF result.
For direct mail servers, use a valid EHLO hostname, add SPF for that hostname when you control it, and keep MAIL FROM SPF correct. Pay particular attention to EHLO SPF for bounce messages with an empty reverse-path. For platform-based sending, the provider normally controls the EHLO hostname. Focus on the envelope sender domain and DKIM signing domain that the provider allows you to configure, then verify the results in DMARC reports.
Frequently asked questions
SPF permits HELO or EHLO checks, but Google does not document an EHLO SPF pass as a separate Gmail sender requirement. Its public guidance does not establish every internal check. Use the SMTP response and Gmail-added authentication headers to investigate the actual failure.
Yes, publish it when you control the hostname and send directly. Keep the record narrow, usually authorizing only the specific host IP. Do not use it as a substitute for MAIL FROM SPF.
Bounce messages normally use an empty reverse-path. RFC 7208 then derives the SPF identity from the EHLO domain, so that hostname's SPF policy directly affects the bounce authentication result.
PTR and FCrDNS should come first because Google explicitly requires valid forward and reverse DNS for sending IPs. A broken PTR chain is a clear infrastructure fault.
Legacy reports can contain helo scope. Under RFC 9990, scope is optional and its only permitted value is mfrom. Inspect message headers or SMTP logs for HELO or EHLO evidence; aggregate reports do not reveal every check performed.
SPF pass is only one signal. Gmail also evaluates DKIM, DMARC, reverse DNS, TLS, complaint rate, sending patterns, IP reputation, and domain reputation.
