Run a mail server that reaches the inbox

Postfix is not the problem. It has been delivering mail competently since 1998 and it will do exactly what you configure it to do. The problem is that SMTP grants no standing to anyone by default, so a receiving gateway has to decide whether to believe an unknown server — and it makes that decision in a fixed order, mostly before your message is examined at all:

• The connecting IP, first and hardest. Before your server has said anything beyond EHLO, the gateway has already looked the address up in public blocklists (Spamhaus SBL, XBL, PBL and CSS, Barracuda, SpamCop) and in its own private reputation store, which also tracks the surrounding /24 and the ASN. A listed address is refused at connection time with a rejection you may never see if nobody is reading the logs.
• The name that address claims. A missing PTR gets connections refused outright by several large providers. A generic provider-assigned PTR of the ip-203-0-113-10.example-host.net variety is worse than it looks — it is the exact signature of consumer lines and unattended boxes, which is where botnets live.
• Authentication. SPF, DKIM and then DMARC, evaluated in that order and combined by the alignment rule in the next section. This is where a setup that looks right on paper usually fails.
• Only then, the message. Content heuristics, list hygiene, the complaint rate you generate, and how recipients behave over the following weeks.

Three of those four are decided before a single byte of your content is scored, which reframes the whole exercise: you are not writing better emails, you are building a credential. The two largest receivers have written the minimum down, so there is no guesswork about the floor. Every sender needs SPF or DKIM, valid forward and reverse DNS, TLS on the connection, and a spam-complaint rate under 0.3%; anything sending in bulk needs SPF and DKIM and a DMARC record with alignment, plus one-click unsubscribe. Treat that as the entry fee rather than the goal.

Each record answers a different question, and the useful way to hold them in your head is by what a forger would have to control to fake it.

• PTR — who owns the address agrees with you. The reverse zone for an IP is delegated to whoever holds the allocation, which is why this is the one record you cannot add at your registrar. A PTR pointing at mail.example.com, plus an A record for mail.example.com pointing back at the same IP, is FCrDNS — forward-confirmed reverse DNS. It proves the address holder and the domain holder are the same party, or at least on speaking terms.
• SPF — this server was allowed to send for this envelope. A TXT record listing the hosts permitted to send for a domain. The trap is scope: SPF authenticates the envelope sender (the MAIL FROM, which becomes Return-Path) and the HELO name. It says nothing whatsoever about the From: header your recipient actually reads, which is why SPF alone has never stopped anyone impersonating you.
• DKIM — this message was signed by a domain and has not been altered. Your server signs selected headers and the body with a private key; the public half sits in DNS at <selector>._domainkey.<domain>. Unlike SPF it survives being forwarded, because the proof travels inside the message rather than depending on which IP delivered it.
• DMARC — and this is the one everybody gets wrong. DMARC does not merely require that SPF or DKIM passed. It requires that a passing mechanism be aligned with the domain in the visible From: header. Relaxed alignment accepts a matching organisational domain (so mail.example.com aligns with example.com); strict alignment demands an exact match.

That alignment rule is worth stating on its own, because it produces the single most exasperating support thread in self-hosted mail: a message can pass SPF, pass DKIM, and still fail DMARC — when both passed for a domain that is not the one in From:. It happens the moment mail leaves through a relay that rewrites the envelope, or when a bundle signs with its own hostname instead of your domain. Everything looks green in your logs and the message is still quarantined. Read the alignment, not the pass.

Less hardware than you would guess, and more commitment than you would like.

• A domain you intend to keep. Reputation attaches to the domain as firmly as to the address, and it accrues over months. A domain you might drop next year is not worth warming.
• A modest plan, sized for filtering rather than for mail. Message delivery costs almost nothing; spam filtering and indexing cost RAM. Cub (1 vCPU / 2 GB / 40 GB NVMe, $5.00/mo) runs Postfix, Dovecot and Rspamd for one domain and a handful of mailboxes without complaint. Scout (2 vCPU / 4 GB / 70 GB, $9.00/mo) is the honest floor for a containerised bundle that also wants ClamAV and a search index. Disk is the part that grows, so size it for the archive rather than for today.
• A dedicated IPv4 with no history, and a routed IPv6 /64. Every plan ships both. This is the component you cannot fix later with configuration, and the reason recycled budget-cloud addresses are a false economy for mail.
• Outbound port 25. Open on every plan, with no unblocking ticket to file. The acceptable-use policy forbids unsolicited bulk mail and open relays, which is precisely what keeps the ranges deliverable for everyone sending legitimately.
• Debian 13 from the template library, and a jurisdiction chosen deliberately. Mail is not latency-sensitive, so pick the location for where the mailbox should legally sit rather than for a few milliseconds.

There are three shapes, and picking the wrong one is how weekends disappear.

• Assembled by hand. Postfix as the MTA, Dovecot for IMAP and authentication, Rspamd for filtering and DKIM signing. Perhaps two hundred lines of configuration in total, all of which you can read and none of which is hidden. Most control, most understanding required, and the version this guide assumes.
• A bundle. mailcow is feature-complete and container-based, and genuinely wants 4 GB before it is comfortable. Mail-in-a-Box is opinionated and pleasant if you accept its choices exactly. Stalwart is a single binary that covers SMTP, IMAP, JMAP and filtering in one process, and is by some distance the lightest of the three. All of them install in an hour; none of them will do your DNS for you.
• A relay you do not run. If the requirement is “my application must send password resets” and there will never be a mailbox, an MTA is the wrong shape entirely. Configure a smarthost and spend the afternoon on something else.

The stack does not decide your deliverability. It decides how much of your Saturday it costs. Everything that determines whether your mail arrives happens in DNS and in the reputation of one address — which is the whole of the next section.

An address with no reputation does not start neutral. A gateway’s prior for an unfamiliar datacentre IP that has suddenly begun sending is closer to “probably unwanted”, because that is what the overwhelming majority of such addresses turn out to be. Warm-up is the process of replacing that prior with evidence, and it cannot be rushed by any technical means.

• Start small and climb slowly. Tens of messages a day in the first week, roughly doubling every few days, reaching normal volume over two to four weeks. A sender that goes from zero to a thousand overnight is indistinguishable from a compromised host, and gets treated as one.
• Engagement outweighs volume. Messages that are opened, replied to and moved out of spam by real people are worth far more than throughput. Send to the recipients most likely to interact first — yourself, colleagues, correspondents who already know you.
• Be consistent. Two hundred messages one day and nothing for three weeks never builds a stable profile. A steady trickle beats an erratic burst at the same monthly total.
• Keep complaints under control. The published threshold is 0.3%, and above it nothing else you do matters much. Below 0.1% is where you want to live.
• Do not mix streams. Newsletters and password resets on one address means a marketing complaint rate dragging your account recovery into the spam folder. If separating them is worth it, a second dedicated clean IPv4 is $2.00/mo with its own rDNS.

Configuration is reproducible in an hour. Reputation takes months and can be destroyed in one evening by a compromised contact form. Treat the address as the thing you are actually protecting.

• Monitor rather than react. Check the majors on a schedule instead of after a complaint — our walkthrough of checking whether an IP is blacklisted covers which lists carry weight, how to read a listing and how delisting actually works.
• Rate-limit your own outbound. A cap in the MTA is what stands between a compromised script and ten thousand messages leaving before you wake up. This single setting has saved more addresses than any filter.
• Retire hard bounces immediately. Repeatedly delivering to dead addresses is a spam-trap signal, and recycled spam traps are exactly how legitimate senders end up listed.
• Read postmaster@ and abuse@. They are required to exist and they are where you find out about a problem before a blocklist does. Both large receivers also publish free reputation dashboards for domains you have verified; they will tell you things no public list ever will.
• Do not fight a fight you inherited. If the address turns out to be carrying a listing that predates you, or is blocked somewhere that matters commercially, request a swap from the client area rather than spending three weeks in delisting queues for somebody else’s history.

Why the address arrived clean in the first place is the other half of this. High-churn budget clouds recycle IPv4 through enormous numbers of short-lived customers, so a “new” address routinely arrives pre-owned in every sense that matters to a gateway. Every plan here ships a dedicated, screened address rather than a slice of a shared pool — what a clean IP actually means sets out the definition and how to verify it yourself before you rely on it.

The honest accounting, because a guide that only lists the wins is advertising.

• It does not make your mail private. SMTP encrypts hop by hop and opportunistically; the receiving provider decrypts and reads everything you send to their users, exactly as before. If confidentiality of content is the goal, that is end-to-end encryption, not a server you own.
• It does not hide the metadata. Who, to whom, when, how often and the subject line all traverse the network intact — and now your own server logs them too, on a machine you are responsible for.
• It does not free you from the large receivers. You are still asking two companies to accept your mail, and they still set the terms unilaterally. Self-hosting moves the control point; it does not remove it.
• It does not run itself. Certificates renew, keys want rotating, disks fill, and a mail server that quietly stops accepting mail loses messages that senders will not retry forever. This is a service with an on-call dimension, however small.
• It does not make the machine anonymous. A mail server is arguably the most self-identifying thing you can run, because publishing your domain in DNS and standing behind it is the entire mechanism. A no-KYC signup limits what your host knows about you; it does nothing about what a recipient can see. We set out the distinction properly in is a crypto-paid VPS really anonymous, and it is worth ten minutes before you assume otherwise.

Once the records are right and the address is warm, everything left is about where the mailbox lives and who knows it is yours.

Jurisdiction decides who can compel disclosure. A mail server is a searchable archive of correspondence, which makes location a more consequential choice here than for almost any other service. Our footprint is eight locations across the Netherlands, France, Romania, Bulgaria, Sweden, Iceland, Switzerland and Malaysia, and no US-style takedown notice carries force in any of them. That is operational policy stated plainly, not legal immunity — a binding order from a competent local court still applies, and there is a hard abuse floor we do not move. Offshore hosting explains the difference without the marketing.

The account is the part people skip. Signup takes an email address for credential delivery and nothing else — no ID, no card, no postal address, no phone number. There is no verification document to hand over later because none was ever collected; what no-KYC hosting means covers the limits of that honestly.

And the payment. A card ties a server to a bank record and a legal name held in a database neither of us controls. Checkout here settles on chain, with Monero treated as a first-class option rather than an afterthought: paying for a VPS with XMR walks the whole flow, and buying without a credit card covers getting there from no crypto at all. Deploy takes about sixty seconds after confirmation.

Which matters more here than for a disposable box. A mail server is a long commitment to one domain and one address — the reputation you are about to spend a month building is not portable. Decide the jurisdiction, the account and the payment before the warm-up, not after.