Server — Mail — Introduction

Email is the oldest and most stubborn piece of internet infrastructure most people interact with daily. It predates the web, it predates DNS as most people understand it, and it has accumulated thirty years of layered standards, anti-spam measures, authentication protocols, and deliverability folklore. Running your own mail server means engaging with all of that.

It is also the component of this series where the honest case for not doing it is strongest. Gmail, Fastmail, and similar providers handle deliverability, spam filtering, redundancy, and storage on your behalf in exchange for a monthly fee or your data. For many people that is the correct trade. Self-hosting mail makes sense when you want control over your own domain, when you are building infrastructure that needs to send and receive mail as part of its operation, or when the self-sufficiency argument that runs through this series extends to communication as well as compute.

February is going to run mail. This article explains what that means architecturally before any configuration is written.

The components

A complete mail setup on February involves four distinct components, each with a specific role. Understanding what each one does and how they relate to each other is what makes the configuration articles navigable rather than opaque.

Postfix: the MTA

Postfix is the Mail Transfer Agent. It is the component that speaks SMTP: it receives inbound mail from the internet on port 25, applies filtering and routing rules, and delivers accepted mail to local mailboxes. It also accepts mail from local services and authenticated users, and hands outbound mail to the relay.

Postfix is the core of the mail system. Everything else connects to it.

Dovecot: the IMAP server

Dovecot does not send or receive mail from the internet. Its job is to provide authenticated access to the mailboxes that Postfix delivers into. Mail clients — phones, laptops, webmail — connect to Dovecot over IMAP to read, move, and delete mail. Dovecot also handles SASL authentication, which Postfix uses to verify the identity of users submitting outbound mail through the server.

Postfix delivers mail. Dovecot provides access to it.

The external SMTP relay: outbound delivery

Sending mail directly from a homelab server to the world is possible but difficult. Residential and small-business IP addresses are almost universally on block lists maintained by major mail providers. A new IP address with no sending history has no reputation, and major providers such as Gmail and Microsoft treat mail from unknown IPs with deep suspicion, delivering it to spam or rejecting it outright.

An external SMTP relay solves this by acting as the outbound sending infrastructure. February hands outbound mail to the relay over an authenticated SMTP connection, and the relay delivers it to the recipient using its own established IP addresses and sender reputation. The recipient sees mail from your domain, sent via the relay’s infrastructure.

Several relay options exist at different price points: Fastmail if you already use them for personal mail, Mailgun or Brevo for low-volume transactional sending, or Postmark for reliable delivery with detailed logging. The install articles will note the configuration differences between providers; the architecture is the same regardless of which one you choose.

DNS: the glue

Mail does not work without the correct DNS records. Several record types are involved, each serving a specific purpose in the mail authentication and routing system:

MX records tell the internet where to deliver mail for your domain. An MX record for home.arpa pointing at mail.home.arpa tells sending servers to connect to mail.home.arpa when they have mail for any address at home.arpa.

SPF records (Sender Policy Framework) publish a list of IP addresses and servers authorised to send mail from your domain. A receiving server checks the SPF record to verify that the sending server is permitted to send on behalf of your domain. February’s SPF record will include the external relay’s sending infrastructure.

DKIM records (DomainKeys Identified Mail) publish a public key used to verify a cryptographic signature that the relay attaches to outbound mail. The signature proves the mail was sent by an authorised sender and has not been modified in transit.

DMARC records (Domain-based Message Authentication, Reporting and Conformance) tell receiving servers what to do when mail fails SPF or DKIM checks, and where to send reports about mail claiming to be from your domain.

All four of these records live in PowerDNS on February. The DANE article earlier in this series is relevant here too: publishing TLSA records for the mail server’s certificate allows SMTP over DANE-authenticated TLS, which is the strongest available protection against certificate misissuance in the mail transport layer.

The flow

Putting the components together, the inbound and outbound mail flows look like this.

Inbound

1. A sender’s mail server looks up the MX record for your domain and connects to February on port 25.
2. Postfix receives the connection, applies filtering, and checks the sender’s reputation and authentication.
3. Accepted mail is delivered to the local mailbox in Maildir format on February’s filesystem.
4. Dovecot serves the mailbox to your mail client over IMAP on port 993.

Outbound

1. February’s services (NUT notifications, borgmatic alerts, application mail) submit mail to Postfix on the local submission port.
2. Postfix authenticates the submission and hands it to the external relay via SMTP with STARTTLS on port 587.
3. The relay applies DKIM signing and delivers to the recipient using its established sending IP.
4. The recipient’s server checks SPF, DKIM, and DMARC against February’s DNS records.

The honest difficulty assessment

Running mail is harder than running DNS, VPN, or a database. Not dramatically harder, but harder in a specific way: the failure modes are invisible. A misconfigured DNS server gives you obvious errors. A misconfigured mail server silently delivers mail to spam, or has it rejected without notification, or accepts mail from the internet that should be filtered. You often only discover problems when someone tells you they have not received something.

The specific hard parts:

Deliverability. Getting outbound mail reliably into recipients’ inboxes depends on DNS records being exactly right, the external relay having a good reputation, and your sending patterns not triggering spam filters. The external relay handles the IP reputation problem, but the DNS configuration is your responsibility and it needs to be correct before the first mail is sent.

Spam filtering. February will receive connection attempts from spam senders within hours of the MX record going live. Postfix’s filtering configuration needs to reject obvious spam at the SMTP level without rejecting legitimate mail. The configuration articles will cover this in detail.

TLS. Mail clients connecting to Dovecot over IMAP need a valid TLS certificate. SMTP connections between mail servers use STARTTLS. Both need certificates that are either properly signed or covered by DANE records. The TLSA article from the DNS sub-series is directly relevant here.

Maintenance. Mail requires more ongoing attention than most services. Log files grow with connection attempts. Certificates expire. Relay credentials sometimes need rotation. Block lists occasionally list legitimate servers by mistake. None of this is hard to handle, but it requires periodic attention rather than the set-and-forget posture of most other services on February.

What the sub-series covers

The following articles cover the implementation:

Postfix — installing and configuring Postfix for inbound delivery and local submission, connecting to the external relay, and applying basic spam filtering.

Dovecot — installing and configuring Dovecot for IMAP access, integrating with Postfix for authentication, and setting up TLS.

DNS records — configuring MX, SPF, DKIM, DMARC, and TLSA records in PowerDNS. This is where most deliverability problems originate and where the most care is needed.

Testing — verifying the complete mail flow end to end, using tools that check DNS records, TLS configuration, DKIM signing, and DMARC alignment before sending a single real message.

The goal at the end of the sub-series is a mail setup that receives reliably, sends reliably, and has the authentication records in place that tell the rest of the internet you are a legitimate sender. February will not have a large sending volume or complex routing. It will have a correct, well-documented mail setup that handles what it is asked to do without surprises.