Eigener Mailserver: was wirklich dranhängt

Ein Mailserver ist technisch kein besonders schwieriger Dienst. Postfix, Dovecot, ein Zertifikat, fertig. Die Schwierigkeit liegt woanders: Deine Mails müssen bei Empfängern ankommen, die dich nicht kennen und deren Filter im Zweifel gegen dich entscheiden.

Dieser Beitrag ist deshalb zu zwei Dritteln ein DNS- und Reputationsbeitrag.

Was der Empfänger prüft#

SPF beantwortet: Darf diese IP-Adresse für diese Domain senden? Ein TXT-Eintrag listet die erlaubten Absender.

DKIM beantwortet: Ist die Nachricht unterwegs unverändert geblieben? Der sendende Server signiert, der öffentliche Schlüssel liegt im DNS.

DMARC beantwortet: Passt die Domain im sichtbaren Absender zu dem, was SPF und DKIM bestätigt haben? Und was soll passieren, wenn nicht?

Bevor irgendetwas installiert wird: drei Prüfungen#

1. Ist ausgehender Port 25 überhaupt offen?

Viele Anbieter sperren Port 25 für neue Konten. Ohne ihn kannst du nicht direkt zustellen.

# Muss eine 220-Begrüßung liefern
timeout 8 bash -c 'exec 3<>/dev/tcp/gmail-smtp-in.l.google.com/25; head -1 <&3'

2. Ist die IP-Adresse sauber?

Eine wiederverwendete Adresse kann Vorgeschichte haben. Prüfen, bevor man Zeit investiert, mehrere öffentliche Blocklisten-Prüfdienste erledigen das in einem Aufruf.

3. Lässt sich Reverse-DNS setzen?

Wenn der Anbieter keinen PTR-Eintrag erlaubt, hört es hier auf. Details dazu in IPv6 auf dem VPS, für IPv4 gilt dasselbe.

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

Die DNS-Einträge#

Für die Domain example.com mit Mailserver mail.example.com auf 203.0.113.10:

; Wo Mail für die Domain hin soll
example.com.            MX    10 mail.example.com.

; Der Server selbst
mail.example.com.       A     203.0.113.10
mail.example.com.       AAAA  2001:db8::10

; SPF: nur diese eine Maschine darf senden
example.com.            TXT   "v=spf1 mx -all"

; DKIM: öffentlicher Schlüssel, Selektor "mail"
mail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..."

; DMARC: erst beobachten, später verschärfen
_dmarc.example.com.     TXT   "v=DMARC1; p=none; rua=mailto:[email protected]; pct=100"

; Sagt Empfängern, dass du TLS erwartest
_mta-sts.example.com.   TXT   "v=STSv1; id=2026050601"

Zu den einzelnen Zeilen:

-all statt ~all. Das Minus heißt „alles andere ist gefälscht“, die Tilde heißt „verdächtig, aber annehmen“. Wenn du sicher weißt, welche Systeme senden, ist -all richtig. Wer noch ein Newsletter-Werkzeug oder ein Shop-System hat, muss deren Einträge mit aufnehmen (include:), sonst landen genau diese Mails im Nichts.

p=none am Anfang. DMARC mit p=reject von Tag eins ist der klassische Selbstschuss: Jede vergessene Absenderquelle wird sofort abgelehnt. Mit p=none bekommst du wochenlang Berichte, siehst, wer in deinem Namen sendet, und verschärfst dann in Ruhe auf p=quarantine und später p=reject.

mailcow: der praktische Weg#

Postfix und Dovecot von Hand zu konfigurieren ist lehrreich und dauert. mailcow: dockerized bündelt Postfix, Dovecot, Rspamd, SOGo und eine Verwaltungsoberfläche.

sudo apt install -y git
cd /opt
sudo git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized
sudo ./generate_config.sh          # fragt nach dem Hostnamen: mail.example.com

Vor dem Start mailcow.conf durchgehen. Zwei Werte lohnen einen zweiten Blick:

# Wenn schon ein Reverse-Proxy auf 80/443 läuft, weicht mailcow aus
HTTP_PORT=8080
HTTP_BIND=127.0.0.1
HTTPS_PORT=8443
HTTPS_BIND=127.0.0.1

sudo docker compose pull
sudo docker compose up -d
sudo docker compose logs -f postfix-mailcow

Der DKIM-Schlüssel wird in der Oberfläche unter Konfiguration → ARC/DKIM erzeugt; der öffentliche Teil gehört dann in den DNS-Eintrag oben.

Ausgehende Zustellung testen, bevor echte Mail läuft#

# Sendet eine Mail an einen Prüfdienst, der SPF/DKIM/DMARC auswertet
swaks --to [email protected] \
      --from [email protected] \
      --server mail.example.com --tls

Die Antwortmail sagt zeilenweise, was bestanden ist. Alles außer pass bei allen drei Prüfungen bedeutet: nachbessern, bevor der erste echte Empfänger schlechte Erfahrungen sammelt.

Zusätzlich einmal an ein Konto bei einem der großen Anbieter senden und dort die Kopfzeilen ansehen:

Authentication-Results: mx.google.com;
       dkim=pass [email protected];
       spf=pass (google.com: domain of ... designates 203.0.113.10 as permitted sender);
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

Drei pass, das ist das Ziel.

Reputation aufbauen#

Eine frische IP-Adresse hat keine Vorgeschichte, und das ist nicht dasselbe wie eine gute. Große Empfänger drosseln neue Absender.

• Langsam anfangen. Die ersten Wochen wenig Volumen. Von null auf tausend Mails am Tag ist ein Muster, das Filter kennen.
• Keine Massenmails vom selben Server. Newsletter über einen spezialisierten Dienst, Transaktionsmail über den eigenen, sonst zieht eine Beschwerdewelle beides mit.
• DMARC-Berichte lesen. Sie zeigen, wer in deinem Namen sendet. Das ist der einzige Weg, p=reject verantwortungsvoll zu erreichen.
• Abuse- und Postmaster-Adresse einrichten, und zwar so, dass jemand hinsieht.

Die ehrliche Alternative: ein Relay#

Für die meisten Fälle, eine Anwendung, die Passwort-zurücksetzen-Mails verschickt, ist ein eigener Mailserver der falsche Aufwand. Ein SMTP-Relay eines Anbieters übernimmt die Zustellung, und du kümmerst dich um nichts davon.

# Postfix als reiner Weiterleiter
sudo apt install -y postfix libsasl2-modules

# /etc/postfix/main.cf
relayhost = [smtp.anbieter.example]: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

echo "[smtp.anbieter.example]:587 benutzer:passwort" | sudo tee /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
sudo systemctl restart postfix
echo "Test" | mail -s "Relay-Test" [email protected]

Wann lohnt der eigene Server trotzdem? Wenn Postfächer für Menschen dazugehören, wenn die Datenhoheit ein Ziel ist, oder wenn das Volumen so groß wird, dass ein Relay teuer wird. Für „meine App muss E-Mails verschicken“ ist das Relay die richtige Antwort und die Sperre für ausgehenden Port 25 aus Firewall auf dem VPS kann bestehen bleiben, weil ein Relay auf 587 läuft.

Was danach dauerhaft anfällt#

Das ist der Punkt, an dem man die Entscheidung noch einmal ehrlich abwägt: Ein eigener Mailserver ist kein Projekt, sondern ein Abonnement auf Wartung.