When your emails mysteriously land in recipients' spam folders, IPv6 connectivity might be the hidden culprit. The issue manifests in email headers with messages like:

Authentication-Results: mx.google.com;
       spf=neutral (google.com: 2001:4ba0:cafe:........ is neither permitted nor denied by best guess record for domain of root@myserver.com)

This occurs because Sendmail prioritizes IPv6 connections when available, but many mail servers lack proper IPv6 DNS records (SPF, PTR) for proper authentication.

Edit your sendmail.mc file (typically located in /etc/mail/) and add:

define(confBIND_OPTS', WorkAroundBrokenAAAA')dnl
define(confDAEMON_OPTIONS', Family=inet')dnl

Then regenerate your sendmail.cf configuration:

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
service sendmail restart

For more granular control, modify your access database to prefer IPv4:

# /etc/mail/access
Connect:IPv6          REJECT

Then rebuild the access database:

makemap hash /etc/mail/access.db < /etc/mail/access

After making changes, verify Sendmail's network behavior:

sendmail -d0.1 -bv root@localhost | grep Daemon

You should see output indicating IPv4-only operation:

Daemon Port: smtp, Addr: 0.0.0.0, Server: inet

While fixing Sendmail's behavior, ensure your DNS records are properly configured:

example.com. IN TXT "v=spf1 ip4:192.0.2.1 -all"
1.2.0.192.in-addr.arpa. IN PTR mail.example.com.

This prevents authentication issues even if IPv6 connectivity is accidentally restored.

---

Many sysadmins have encountered this issue where Gmail suddenly starts routing legitimate emails to spam folders. The root cause often appears in the email headers:

Authentication-Results: mx.google.com;
       spf=neutral (google.com: 2001:4ba0:cafe:........ is neither permitted nor denied 
       by best guess record for domain of root@myserver.com) smtp.mail=root@myserver.com

This indicates Sendmail is using IPv6 for outbound connections while your DNS only has proper SPF and PTR records configured for IPv4.

Most mail servers still primarily operate on IPv4, and many organizations:

• Haven't set up reverse DNS (PTR) for IPv6 addresses
• Omit IPv6 addresses from their SPF records
• Lack proper DKIM/DMARC configurations for IPv6

Edit your Sendmail configuration file (typically /etc/mail/sendmail.mc) and add:

define(confBIND_OPTS', WorkAroundBrokenAAAA')dnl
define(confDIRECT_SUBMISSION_MODIFIERS', C')dnl
DAEMON_OPTIONS(Family=inet, Name=MTA-v4, Port=smtp')dnl
DAEMON_OPTIONS(Family=inet6, Name=MTA-v6, Port=smtp, M=O')dnl

Then rebuild your Sendmail configuration:

make -C /etc/mail
service sendmail restart

Check which IP version Sendmail is using with:

telnet localhost 25
EHLO localhost

Look for lines indicating IPv4 connectivity only. You can also test outbound connections with:

sendmail -bv user@example.com

Even after forcing IPv4, ensure your DNS records are properly configured:

; SPF record example
example.com. IN TXT "v=spf1 ip4:192.0.2.1 -all"

; PTR record should match
1.2.0.192.in-addr.arpa. IN PTR mail.example.com.

For systems where IPv6 isn't needed, you can disable it at the kernel level:

echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
echo 1 > /proc/sys/net/ipv6/conf/default/disable_ipv6

Add this to /etc/sysctl.conf for persistence:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1