Self-Hosted Email Going to Spam: Fixes

The Problem

Emails sent from your self-hosted mail server arrive in recipients’ spam/junk folders — or don’t arrive at all. Gmail, Outlook, and Yahoo are the most common offenders. This is the #1 problem with self-hosted email.

Diagnostic Checklist

Run through these checks in order. Most spam issues come from the first three.

Check	Command	Expected Result
PTR record	dig -x YOUR_IP +short	Returns your mail hostname
SPF	dig TXT yourdomain.com +short	Contains v=spf1 with your IP
DKIM	dig TXT selector._domainkey.yourdomain.com +short	Returns DKIM public key
DMARC	dig TXT _dmarc.yourdomain.com +short	Contains v=DMARC1
Blacklist	MXToolbox Blacklist Check	IP not listed
TLS	openssl s_client -starttls smtp -connect mail.yourdomain.com:25	Valid certificate

Fix 1: Missing or Incorrect PTR Record

The most common cause. A PTR (reverse DNS) record maps your server IP back to your hostname. Without it, Gmail and Outlook reject your mail immediately.

Check:

dig -x YOUR_SERVER_IP +short

If this returns nothing or the wrong hostname, fix it.

Fix: Configure the PTR record in your VPS provider’s dashboard (not your domain’s DNS panel):

• Hetzner: Cloud Console → Server → Networking → Reverse DNS
• DigitalOcean: Droplet → Networking → PTR Records
• Vultr: Server → Settings → Reverse DNS
• Linode: Linode → Network → Reverse DNS

Set it to your mail server’s hostname (e.g., mail.yourdomain.com).

Critical rule: The PTR hostname must resolve forward to the same IP:

# These must match:
dig -x 203.0.113.10 +short    # → mail.yourdomain.com.
dig A mail.yourdomain.com +short  # → 203.0.113.10

Fix 2: SPF Record Issues

Check:

dig TXT yourdomain.com +short | grep spf

Common problems:

No SPF Record

Add a TXT record to your domain:

yourdomain.com.  TXT  "v=spf1 ip4:YOUR_SERVER_IP -all"

Multiple SPF Records

Having two v=spf1 TXT records on the same domain causes SPF to fail entirely. Merge them into one:

# Wrong — two SPF records:
"v=spf1 ip4:203.0.113.10 -all"
"v=spf1 include:spf.resend.com -all"

# Correct — merged into one:
"v=spf1 ip4:203.0.113.10 include:spf.resend.com -all"

Using ~all Instead of -all

~all (soft fail) is weaker than -all (hard fail). Some providers treat soft fail as suspicious. Use -all.

Too Many DNS Lookups

SPF allows a maximum of 10 DNS lookups. Each include:, a:, mx:, and redirect= counts. Use ip4:/ip6: (zero lookups) where possible.

Fix 3: DKIM Not Signing or DNS Mismatch

Check if emails are being signed:

Send an email to a Gmail address, open it, click the three dots → “Show original.” Look for dkim=pass in the Authentication-Results header.

If you see dkim=fail or no DKIM header:

Verify the DNS record:

# Find your selector from your mail server's DKIM settings
dig TXT default._domainkey.yourdomain.com +short

Common problems:

Wrong Selector

Your mail server signs with one selector (e.g., dkim) but the DNS record uses a different name (e.g., default). Check your server:

Server	Where to Find Selector
mailcow	Admin → Configuration → ARC/DKIM Keys
Mailu	Admin → Mail Domains → DKIM
Docker Mailserver	setup.sh config dkim
Stalwart	Admin → Settings → DKIM

Key Too Short

Gmail and Outlook require 1024-bit RSA minimum. Use 2048-bit for best compatibility. Regenerate your DKIM key if it’s 512-bit.

DNS Record Truncated

Some DNS providers truncate long TXT records. DKIM keys (especially 2048-bit) are long. Verify the full key is in DNS:

dig TXT default._domainkey.yourdomain.com +short
# The output should contain a complete base64 string

Fix 4: DMARC Not Configured

Check:

dig TXT _dmarc.yourdomain.com +short

If this returns nothing, add a DMARC record. Start with monitoring mode:

_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

After verifying SPF and DKIM pass consistently (check DMARC reports for 1-2 weeks), upgrade to:

_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s"

See the Email Deliverability guide for the full DMARC rollout strategy.

Fix 5: IP Address Blacklisted

Your server’s IP might be on a spam blacklist, especially if you’re using a VPS IP that was previously abused.

Check:

# Quick check against major blacklists
dig +short YOUR_IP.zen.spamhaus.org
dig +short YOUR_IP.bl.spamcop.net
dig +short YOUR_IP.b.barracudacentral.org

A response of 127.0.0.2 or similar means you’re listed. No response means you’re clean.

Comprehensive check: Use MXToolbox Blacklist Check.

Fix:

1. Visit each blacklist’s website and request delisting (most have automated forms)
2. Spamhaus: https://check.spamhaus.org/
3. SpamCop: https://www.spamcop.net/bl.shtml
4. Barracuda: https://www.barracudacentral.org/lookups

If your entire IP range is blacklisted: Some cheap VPS providers have entire subnets flagged. Request a new IP from your provider, or switch to a provider known for clean IPs (Hetzner, DigitalOcean, Vultr generally maintain clean ranges).

Fix 6: Missing or Invalid TLS Certificate

Gmail requires STARTTLS. If your mail server’s TLS certificate is expired, self-signed, or misconfigured, Gmail marks you as suspicious.

Check:

openssl s_client -starttls smtp -connect mail.yourdomain.com:25 2>/dev/null | head -20

Look for Verify return code: 0 (ok). If you see certificate errors:

1. Ensure your certificate covers the mail hostname (not just the domain)
2. Use Let’s Encrypt for free, auto-renewing certificates
3. Most Docker mail servers handle TLS automatically — check their documentation

Fix 7: Content Triggering Spam Filters

If authentication passes but emails still land in spam, the content itself may be triggering filters.

Avoid:

• ALL CAPS subjects
• Excessive exclamation marks
• Spam trigger words (“free”, “urgent”, “act now”, “limited time”)
• Large attachments (especially .exe, .zip)
• HTML-only emails with no plain text alternative
• Emails with more images than text
• URL shorteners in the body

Improve:

• Always include a plain text version alongside HTML
• Keep HTML clean and simple
• Avoid tracking pixels if possible
• Include an unsubscribe link for any bulk/newsletter email

Fix 8: Sending Too Much Too Fast

New IPs have no reputation. Sending hundreds of emails immediately triggers rate limits and spam flags.

Build reputation gradually:

1. Start by sending to your own Gmail/Outlook accounts
2. Have recipients reply (engagement signals build trust)
3. Send 10-20 emails per day for the first week
4. Gradually increase volume

Gmail specifically monitors sender reputation at the IP level. A new IP sending bulk email is suspicious by default.

Full Verification

After applying fixes, verify everything with mail-tester.com:

1. Go to mail-tester.com — you’ll get a temporary address
2. Send an email from your server to that address
3. Check your score — aim for 10/10

A score below 7/10 means you have issues that will cause spam filtering.

Prevention

• Monitor DMARC reports weekly — they show authentication failures before they become spam problems
• Check your IP against blacklists monthly
• Keep your mail server software updated
• Don’t use your mail server for bulk sending — use a transactional email service (Resend, Postmark) for newsletters and automated emails
• Set up monitoring with Uptime Kuma to track your mail server’s availability and certificate expiry

Related

• Email Deliverability: SPF, DKIM, DMARC Setup
• How to Self-Host mailcow
• How to Self-Host Mailu
• Best Self-Hosted Email Servers
• Replace Gmail with Self-Hosted Email