Is Google applying SPF checks to EHLO values for stricter email authentication?
Published 19 Apr 2025
Updated 11 Aug 2026
11 min read
Summarize with
Updated on 11 Aug 2026: We added bounce-message guidance and refreshed Gmail's current sender requirements.
The direct answer is no: Google does not publish EHLO SPF checking as a separate Gmail sender requirement, so an EHLO SPF failure should not be the first diagnosis for a Gmail rejection. Google requires email authentication, valid forward and reverse DNS for sending IPs, and TLS. 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, poor reputation, or a blocklist (blacklist) issue is a more likely cause.
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. That check is cleaner when the hostname maps to one sending machine, but it is not the same thing as DMARC passing. DMARC cares whether the visible From domain matches the SPF-authenticated MAIL FROM domain or the DKIM signing domain.
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: Too many includes, missing senders, or a domain mismatch can break 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 the EHLO hostname, its A or AAAA record, and the sending IP's PTR record consistent so SPF and reverse DNS describe the same host.
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.
What Google publishes
Google's published requirements are broader than SPF alone. The Google sender guidelines require all senders to use SPF or DKIM, and bulk senders to use SPF, DKIM, and DMARC. 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.
Google Postmaster Tools screen showing authentication, reputation, spam rate, and delivery error panels.
|
|
|
|---|---|---|
SPF | Sender authorization | Include every sender |
DKIM | Signed domain | Prefer 2048-bit keys |
DMARC | From-domain match | Monitor reports |
PTR | Forward and reverse DNS | Fix FCrDNS |
Spam rate | User complaints | Stay below 0.3% |
The published Gmail requirements point to combined authentication and infrastructure checks, not EHLO SPF alone.
That is why PTR and 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 4.7.23 for temporary rate limiting and 5.7.25 for blocking when PTR or forward DNS is invalid. SPF failures for bulk senders have separate 4.7.27 and 5.7.27 codes, which makes the SMTP response more useful than guessing at an EHLO-specific rule.
A left-to-right flowchart showing Gmail checks for FCrDNS, SPF or DKIM, DMARC, and reputation.
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. Then compare those values with DMARC aggregate data where the SPF result has a scope of mfrom or helo.
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. This is not a replacement for MAIL FROM SPF. It is a small hardening step that makes the host identity easier for receivers to evaluate.
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.
DMARC aggregate scope examplexml
<policy_evaluated> <spf>pass</spf> <dkim>pass</dkim> </policy_evaluated> <auth_results> <spf> <domain>bounce.example.com</domain> <scope>mfrom</scope> <result>pass</result> </spf> </auth_results>
Where Suped fits
Suped's product turns this investigation into a repeatable workflow. Suped groups DMARC reports by sending source, surfaces SPF and DKIM failures, tracks blocklist and blacklist changes, and sends alerts with issue details. Hosted SPF is available when frequent sender changes or lookup pressure make a static DNS record difficult to maintain.
- Issue detection: Suped groups failing senders, DNS gaps, and authentication failures into fixable issues.
- Hosted SPF: Suped can host your SPF record so sender changes do not require constant DNS edits.
- Alerts: Real-time alerts help catch Gmail-facing failures before they become a long outage.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
SPF records also need to stay under lookup limits. If a Gmail failure appears after adding senders, check for too many DNS lookups and flattening issues. Suped's SPF flattening workflow addresses that specific problem.
Fix order when Gmail rejects mail
When Gmail starts deferring or rejecting a sender, do not wait for proof that one obscure signal caused the whole problem. Gmail evaluates several signals. Fix the documented infrastructure problems first, then use controlled tests, SMTP response codes, and DMARC reports to confirm what changed.
Fix priority for Gmail-facing senders
Prioritize issues that Google publishes as requirements before treating EHLO SPF as the main cause.
Critical
Fix now
Broken PTR, missing forward DNS, or NXDOMAIN hostnames.
High
Same day
Missing SPF, DKIM, DMARC, or sender-domain mismatch.
Medium
This week
SPF lookup pressure, weak DKIM key size, or poor segmentation.
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, a strong key, and a signing domain that matches the visible sender domain.
- DMARC reports: Review aggregate reports to find failing sources and the SPF scope receivers are recording.
- 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, a single bad DNS detail can make the rest of the message look suspicious. A small netblock at a hosting provider, cold IPs, incomplete rDNS, and inconsistent hostnames create a delivery profile Gmail can distrust even when a narrow SPF test passes.
Common false leads
EHLO SPF is easy to blame because it is technical and less visible than normal SPF. A more common pattern has one or two infrastructure faults, Gmail tightens acceptance because the total risk score is higher, and the team searches for a new hidden rule.
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.
Usually the real cause
- Cause: One IP has broken PTR or forward DNS.
- Cause: The MAIL FROM domain is not the domain being tested.
- Cause: Reputation or blocklist (blacklist) status changed at the IP level.
The best diagnostic habit is to test the identity Gmail actually evaluates at each layer. Test the envelope domain for SPF, the selector domain for DKIM, the visible From domain for DMARC matching, the sending IP for PTR and FCrDNS, and the IP/domain pair for reputation.
Suped's Hosted SPF is useful when SPF management is spread across teams or vendors. It keeps the published SPF path stable while senders change underneath, which reduces the chance of Gmail-facing SPF failures caused by rushed DNS edits.
Views from the trenches
Best practices
Check MAIL FROM SPF, DKIM, DMARC, PTR, forward DNS, TLS, and reputation together.
Publish SPF on the EHLO hostname when you control it, but do not rely on that alone.
Use aggregate reports to see whether SPF scope is mfrom or helo for each receiver over time.
Common pitfalls
Treating an NXDOMAIN PTR hostname as harmless creates failures at Gmail and other receivers.
Fixing only EHLO SPF misses broken MAIL FROM SPF, weak DKIM, and domain reputation.
Assuming one Gmail error maps to one cause hides the combined scoring behind delivery.
Expert tips
Send controlled tests after each DNS fix so the SMTP result shows what actually changed.
Keep HELO names stable, host-like, and forward-confirmed before you add SPF for them.
Use Suped to watch issue alerts, DMARC trends, and blocklist or blacklist changes.
Marketer from Email Geeks says SPF can be checked against HELO, but the recommendation does not make it the same as a Gmail-only requirement.
2022-03-08 - Email Geeks
Marketer from Email Geeks says most real-world sender troubleshooting still starts with the MAIL FROM identity because that is where most platforms give control.
2022-03-08 - Email Geeks
The practical answer
Treat EHLO SPF as a legitimate SPF capability, not as the first explanation for Gmail tightening authentication. Gmail's published rules point to SPF or DKIM for all senders, SPF, DKIM, and DMARC for bulk senders, valid forward and reverse DNS, TLS, and reputation. A broken PTR record with a hostname that returns NXDOMAIN is a direct problem, not a side issue.
For direct mail servers, publish clean EHLO hostnames, add SPF for those hostnames when you control them, and keep MAIL FROM SPF correct. Pay particular attention to EHLO SPF for bounce messages with an empty reverse-path. For platform-based sending, focus on the envelope sender domain, DKIM signing domain, DMARC reports, and sender reputation because that is where the deliverability work usually pays off.
Suped helps turn that into an operating process: monitor DMARC, watch SPF and DKIM results, see which sources fail, catch blocklist or blacklist changes, and use hosted records where DNS complexity is slowing fixes. That gives the team evidence when Gmail delivery changes.
