This site has told you several times not to start with email. Here is the actual reason.

The short version: receiving mail is a solved problem. Sending mail that arrives is not, and the difficulty has almost nothing to do with your server.

The two halves are not equally hard

Receiving is a matter of running an SMTP server, pointing an MX record at it, and handling the mail. Postfix, or Dovecot for IMAP on top. It works, it has worked for decades, and nobody else gets a vote.

Sending requires that Gmail, Outlook, and a handful of other providers decide your mail is legitimate. Between them they hold the large majority of the world’s mailboxes. Their decision is based on reputation: how your IP address and domain have behaved over time.

A new server has no reputation. In spam filtering, no reputation is close to bad reputation, because that is exactly what a freshly compromised machine looks like.

You cannot configure your way out of this. You can only do everything correctly and then wait.

What you must get right

None of these will give you deliverability. All of them missing will guarantee you have none.

SPF

A DNS TXT record listing which servers may send for your domain.

example.com. IN TXT "v=spf1 mx ip4:203.0.113.10 -all"

-all means hard fail: anything not listed is forged. ~all is soft fail, which is weaker and what you use while testing.

SPF breaks on forwarding. If someone forwards your mail, the forwarding server is now sending it and is not in your SPF record. This is a known limitation and the reason SPF alone is insufficient.

DKIM

A cryptographic signature on each message. The private key signs; a public key in DNS verifies.

mail._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

DKIM survives forwarding, because the signature travels with the message. This is why both exist.

Rotate keys periodically, and use at least 2048-bit RSA.

DMARC

Ties SPF and DKIM to the visible From address and tells receivers what to do on failure.

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"

p=none monitors without acting, p=quarantine sends failures to spam, p=reject refuses them.

Start at p=none and read the reports. The rua address receives aggregate XML reports showing who is sending as your domain, which reveals both forgery and your own systems you forgot about. Moving to reject before you understand your own mail flow is how you discover your invoicing system was sending through a path you never configured.

PTR, the one people forget

A reverse DNS record mapping your IP back to your hostname, and it must match the name your server announces in HELO.

dig -x 203.0.113.10 +short
# mail.example.com.

Only your hosting provider can set this. Many receivers reject mail from an IP with no PTR or a generic one outright, before any content filtering. Check that your provider offers it before you pick them, because not all do.

TLS

Inbound and outbound. MTA-STS and DANE are worth adding once the basics work.

Why it still fails

You have done all of the above correctly and your mail goes to spam. This is the normal outcome, and it is the part that catches people out.

Your IP range may be pre-blocked. Large swathes of cloud provider address space are treated with suspicion because a great deal of spam originates there. Some ranges are permanently poor. You inherit whatever the previous tenant of that address did.

Residential connections are effectively excluded. Home IP ranges are on blocklists by default, and most ISPs block outbound port 25 regardless.

Volume patterns matter. Sending nothing for a month then a hundred messages looks like a compromise.

Complaints are disproportionate. A handful of recipients marking your mail as spam damages your reputation far more than a large number of deliveries helps it.

There is no appeal. You will not get a useful explanation, and the feedback is silent. Your message is simply not read, and you find out weeks later when someone mentions they never got it.

That last point is the real problem. A mail server that fails loudly is fixable. One that silently delivers 80 percent of your mail is a slow leak of missed messages you cannot detect.

The arrangement that actually works

Receive yourself. Send through a smarthost.

A smarthost is a third-party SMTP relay that takes your outgoing mail and delivers it using their reputation. Postmark, Mailgun, SES, Fastmail, and others do this, and the free tiers cover personal volumes.

# Postfix, relaying outbound through a smarthost
relayhost = [smtp.provider.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

What you keep: your domain, your storage, your accounts, your archive, your privacy for stored mail, no vendor holding your mailbox.

What you delegate: the one part that is genuinely outside your control.

Purists will say this is not self-hosting. The response is that hosting the hard-to-control part badly is not a principled position, it is a broken mail setup, and a message nobody received is worth nothing regardless of where it was sent from.

If you insist on full self-hosting

It is possible. People do it successfully. Plan for:

A dedicated IP with clean history and a settable PTR. Ask the provider before committing.

A warming period. Weeks of low-volume sending to recipients who will actually open your mail.

Monitoring. Blocklist checks, DMARC report parsing, and a test account at each major provider that you check.

Ongoing maintenance. The spam ecosystem changes, and a configuration that worked two years ago may not now. Our Dovecot coverage is a reminder that mail server software also needs patching promptly, because an IMAP server is internet-facing and parsing untrusted input.

Never becoming an open relay. Automated scanners find one within hours.

# verify you are not relaying for strangers
swaks --to test@example.org --from test@example.net --server your-server.com
# this must be rejected

The all-in-one option

Mailcow, Mail-in-a-Box, and Mailu bundle Postfix, Dovecot, spam filtering, webmail, and DKIM management into one deployment. They are genuinely good and they handle the configuration correctly.

They do not solve deliverability, because nothing running on your server can. They remove the configuration difficulty and leave the reputation problem entirely intact.

That distinction is worth being clear about before you spend a weekend on it. Our self-hosting introduction covers choosing a first project, and email is a reasonable third or fourth one, after you have learned what running a service actually costs.

Frequently Asked Questions

Why is self-hosted email so difficult?

Receiving mail is straightforward. Sending mail that reaches inboxes depends on your IP address and domain having a reputation with the large providers, and a new address starts with none. Nothing you configure on your server changes how Google or Microsoft scores you, which is the part outside your control.

What is the difference between SPF, DKIM, and DMARC?

SPF is a DNS record listing which servers may send for your domain. DKIM cryptographically signs each message so the recipient can verify it was not altered and came from your domain. DMARC ties the two together, tells receivers what to do when checks fail, and requests reports.

Can I run a mail server on a home connection?

Realistically no, for sending. Residential IP ranges are on blocklists by default at most providers precisely because compromised home machines send spam, and most ISPs block outbound port 25 anyway. Receiving on a home connection is possible if your ISP permits inbound 25.

What is a smarthost and does using one count as self-hosting?

A smarthost is a third-party SMTP relay that your server hands outgoing mail to for final delivery. You keep control of storage, accounts, and receiving, while delegating the deliverability problem. It is the pragmatic middle ground and most self-hosted mail setups that work reliably use one.

How long does it take to build sending reputation?

Weeks to months, assuming you send consistently and generate no spam complaints. The process is called warming and involves starting with low volume to engaged recipients. A new address sending a burst of mail on day one looks exactly like a compromised host.

What happens if my mail server is misconfigured as an open relay?

Spammers find it within hours through automated scanning and use it to send bulk mail. Your IP lands on blocklists quickly, your provider may suspend the server, and the reputation damage outlasts the misconfiguration. Always verify your server is not relaying for unauthenticated senders.