Troubleshooting SPF Authentication Failures and Gmail Email Rejection for Exchange Server 2003

After reviewing your Exchange 2003 setup and DNS configuration, we're dealing with a classic SPF authentication failure combined with Gmail's strict filtering policies. The key symptoms:

1. Gmail rejection despite correct DNS records
2. SPF softfail results from openspf.net
3. Manual telnet sessions working while automated emails fail

The current SPF records for your subdomain structure appear correct at first glance, but let's examine the technical nuances:

; Current SPF Records
corp.delo-company.com.    IN TXT "v=spf1 ip4:82.209.198.147 ~all"
s2.corp.delo-company.com. IN TXT "v=spf1 ip4:82.209.198.147 ~all"

The issue likely stems from Gmail's handling of legacy Exchange servers combined with HELO/EHLO verification. Here's what we should modify:

; Recommended SPF Records
corp.delo-company.com.    IN TXT "v=spf1 mx ip4:82.209.198.147 a:s2.corp.delo-company.com -all"
s2.corp.delo-company.com. IN TXT "v=spf1 ip4:82.209.198.147 -all"

For Exchange 2003, we need to ensure proper SMTP banner configuration:

; Exchange 2003 SMTP Virtual Server Configuration
1. Open Exchange System Manager
2. Navigate to: Servers → [YourServer] → Protocols → SMTP
3. Right-click "Default SMTP Virtual Server" → Properties
4. Delivery tab → Advanced
5. Set "Fully-qualified domain name" to: s2.corp.delo-company.com
6. Restart SMTP service

Instead of relying solely on online validators, implement these verification steps:

# PowerShell SPF Test Command
Resolve-DnsName -Name corp.delo-company.com -Type TXT | 
Where-Object {$_.Strings -like "v=spf1*"}

# Telnet SPF Verification
telnet gmail-smtp-in.l.google.com 25
EHLO s2.corp.delo-company.com
MAIL FROM: <supruniuk-p@corp.delo-company.com>

Since you've been blacklisted before, implement these reputation restoration steps:

1. Submit removal requests to remaining blacklists:
   - mxtoolbox.com/blacklists.aspx
   - multirbl.valli.org

2. Gradually warm up your IP:
   - Start with 50 emails/day
   - Increase by 20% daily
   - Monitor rejection rates

3. Implement DKIM (even for Exchange 2003):
   ; Generate DKIM keys
   openssl genrsa -out dkim_private.key 1024
   openssl rsa -in dkim_private.key -pubout -out dkim_public.key

Verify PTR record matches HELO
Update SPF from ~all to -all after testing
Implement slow ramp-up sending
Monitor Google Postmaster Tools
Consider SMTP TLS encryption

After one of our workstations got infected with malware and sent spam from our IP (82.209.198.147), we faced a perfect storm of email delivery issues. While we cleaned the infected machine immediately, the damage was done - we landed on multiple DNSBLs and Gmail started rejecting all emails from our Exchange 2003 server.

Our DNS configuration for corp.delo-company.com subdomain includes:

corp                     A     82.209.198.147
corp                     MX    20 corp.delo-company.com
corp.delo-company.com    TXT   "v=spf1 ip4:82.209.198.147 ~all"

We also set up HELO verification records:

s2.corp                  A     82.209.198.147
s2.corp.delo-company.com TXT   "v=spf1 ip4:82.209.198.147 ~all"

While most test tools (MXToolbox, Port25 verifier) showed passing results, openspf.net consistently returned softfail results:

<s2.corp.delo-company.com #5.7.1 smtp;550 5.7.1 <spf-test@openspf.net>: Recipient address rejected: SPF Tests: Mail-From Result="softfail": Mail From="supruniuk-p@corp.delo-company.com" HELO name="s2.corp.delo-company.com" HELO Result="softfail" Remote IP="82.209.198.147">

When testing via telnet, we discovered Gmail actually accepted our messages with proper SPF validation:

Received-SPF: pass (google.com: domain of supruniuk-p@corp.delo-company.com designates 82.209.198.147 as permitted sender) client-ip=82.209.198.147;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of supruniuk-...

1. Changed our SPF record from ~all back to -all (more strict):

corp.delo-company.com TXT "v=spf1 ip4:82.209.198.147 -all"

2. Verified our PTR records matched exactly:

147.198.209.82.in-addr.arpa. 86400 IN PTR s2.corp.delo-company.com.

3. Submitted delisting requests to all remaining blacklists showing our IP

• Gmail's reputation system maintains shadow bans even after technical issues are resolved
• Always test with multiple tools (openspf.net proved most accurate in our case)
• Manual SMTP testing bypasses some reputation checks, giving false positives
• Exchange 2003's default EHLO behavior requires precise DNS configuration