Why Self-Hosted Email Goes to Spam (and How to Earn Reputation)

Why does self-hosted email go to spam even when the configuration looks perfect? Because authentication and reputation are different things. SPF, DKIM and DMARC prove you are who you say you are. They do not prove mail from you is wanted.

A new mail server has no history at Gmail, Outlook.com or Yahoo. Those systems have to guess, and their default guess about an unknown IP is caution. That is the structural disadvantage of self-hosting, and no amount of DNS work removes it — it only shortens the wait.

Here are the mechanics, the order to do them in, what each major receiver requires as of September 2026, and how to read the failure when mail still does not arrive.

The short answer#

Self-hosted mail lands in spam for three reasons, and they stack. First, the prerequisites are missing or wrong — no reverse DNS, broken SPF, unsigned mail, no TLS. Second, the IP is disqualified by policy: most consumer and many VPS ranges are listed as space that should not send mail directly.

Third, and hardest, the IP and domain are unknown. You clear the first two with configuration. You clear the third only with time and consistent, wanted mail.

Before you start: four things to verify#

Do not warm up an IP that cannot pass the basics. Every message sent while a check is failing teaches the receiver something you did not want it to learn.

• Outbound port 25 is open. Many VPS and cloud providers block it by default and will not unblock it for new accounts.
• You control reverse DNS on the sending IP. If the PTR record sits under your provider's domain and they will not change it, you cannot fully satisfy Gmail's or Yahoo's rDNS requirement.
• The IP is not already on a policy blocklist. Residential and dynamic space is the usual culprit, and some VPS ranges inherit a listing from a previous tenant.
• You can publish and edit DNS for the sending domain — TXT records for SPF and DMARC, and a selector record for DKIM.

How to earn reputation on a new mail server#

1. 1

   Set matching forward and reverse DNS

   Point the IP's PTR record at a hostname you own — mail.example.com, not a provider-generated string — and give that hostname an A or AAAA record resolving back to the same IP. Google states it as a round trip: the sending IP must match the IP of the hostname in the PTR record. Use that hostname in HELO/EHLO too.

2. 2

   Publish SPF, and keep it tight

   List only the hosts that actually send for the domain and end the record with -all or ~all. SPF is evaluated against the envelope MAIL FROM address, not the From header a recipient sees — which is why SPF alone does not satisfy DMARC.

3. 3

   Sign every message with DKIM

   Use a key of at least 1024 bits; Google requires that minimum for personal Gmail delivery and recommends 2048. Publish the public key at selector._domainkey.example.com, and confirm the signature validates on a real received message, not just in a test tool.

4. 4

   Publish DMARC and make an identifier align

   Start at v=DMARC1; p=none with an rua address so you actually receive aggregate reports. DMARC passes when SPF or DKIM passes and the passing domain aligns with the From header domain — relaxed alignment means the same organisational domain, strict means identical. Read the reports for a few weeks before tightening to quarantine or reject.

5. 5

   Enforce TLS on both directions

   Offer STARTTLS on delivery and require it outbound where the receiver supports it. Gmail rejects untransported-over-TLS mail with a 5.7.29 error and defers it with 4.7.29, so this is a hard gate rather than a nicety.

6. 6

   Send low volume to people who want it

   Google's guidance is to start with a low volume to engaged users and increase it slowly, at a consistent rate rather than in bursts. No major receiver publishes a messages-per-day warm-up table — the pacing is behavioural, not numeric. Doubling yesterday's volume is the classic way to trigger rate limiting.

7. 7

   Register for the receivers' own telemetry

   Google Postmaster Tools shows domain and IP reputation, spam rate and authentication results for your domain. Microsoft's SNDS shows per-IP filter results and complaint rates, and its JMRP feedback loop forwards messages your recipients mark as junk. Both are free, and both tell you things your own logs cannot.

Platform differences: what each receiver actually requires#

The three big consumer receivers overlap but are not identical, and the differences are where self-hosters get caught. Verified against each vendor's own documentation in September 2026 — check the vendor page before relying on any row.

The 5,000-a-day line is permanent, and it counts subdomains#

Most self-hosters assume bulk-sender rules do not apply to them. Two details make that dangerous. Google counts messages from the same primary domain toward the threshold, so 2,500 a day from example.com plus 2,500 from mail.example.com makes you a bulk sender.

And the status does not lapse. Google states that senders who meet the criteria at least once are permanently considered bulk senders, with no expiration date. Cross the line in one busy week and the stricter requirements apply from then on.

Microsoft runs a separate regime with the same threshold. Since 5 May 2025, domains sending over 5,000 messages a day to Outlook.com must pass SPF, DKIM and DMARC; non-compliant mail is junk-foldered, and Microsoft documents 550 5.7.515 for rejection on authentication grounds. That requirement is missing from most "Gmail and Yahoo requirements" write-ups.

How to check whether your IP is blocklisted#

Blocklists are the fastest thing to rule out, and the easiest to misread. The one that catches self-hosters most often is Spamhaus's Policy Blocklist, which lists IP space that, by policy, should not send mail directly to third-party mail servers. It is not an accusation of spamming — it describes what that address range is for.

Check the IP at Spamhaus's reputation checker. If the PBL is the only listing, removal is possible when the address is static, is genuinely an outbound mail server, has correct DNS, and is assigned to you or your company. If your provider holds the assignment, removal has to come from them.

A listing on a spam-based list is a different problem: mail from the IP was reported or hit a trap. Find the cause — a compromised account, an open relay, a forwarded mailbox — before requesting anything.

What to do when it still does not work#

Read the SMTP response, not the symptom. Receivers name the failed check, and the codes are specific enough to act on.

Be honest about the ceiling#

Self-hosting gives you control over your data and your rules. It does not give you a shortcut to reputation, and the gap is structural rather than a conspiracy against small operators. An established provider sends millions of wanted messages a day from the same IPs; your server sends a handful from an address nobody has seen. Both facts are visible to the receiver.

For a personal or small-team domain with modest, genuine correspondence, the steps above usually reach reliable inbox placement — Microsoft says a new IP can be fully ramped within a couple of weeks or sooner, given accurate lists and low complaints. For marketing volume, or transactional mail with a deadline attached, a self-hosted IP starting from zero is the wrong tool.

A faster way to handle what arrives#

Everything above is about mail leaving your server. The other half is what lands in it — and that part does not need to be manual.

AI Emaily is a mail client, not a mail server and not a deliverability service. It will not warm an IP, fix a PTR record or change how Gmail scores you. What it does is connect to the server you already run over IMAP and SMTP, then triage, summarise and draft on top of it, with approve-before-send, undo and a full audit trail. Voice matching comes from a Personal Context brain and per-client profiles that you set, not from reading your archive.

If you self-host precisely so nobody else holds your mail, that constraint is the point. We build AI Emaily, so treat this as the interested party's view — but the connection is a standard IMAP one, documented at /docs/connect-imap, and it changes nothing about who runs your server.