E-Mail-Server absichern: SPF, DKIM und DMARC Guide

Auf meinem VPS läuft ein eigener Mailserver für ein paar Domains. Das ist nicht das, was ich uneingeschränkt jedem empfehlen würde — die Anfangshürde ist hoch, der Wartungsaufwand kontinuierlich, und ein einziger Fehler in der Konfiguration kann dich auf Blacklists landen lassen. Aber wer es ernsthaft betreiben will, kommt an SPF, DKIM und DMARC nicht vorbei. Ohne die drei landen die Mails entweder im Spam oder werden gar nicht erst zugestellt.

Die drei Standards lösen unterschiedliche Probleme, sind aber komplementär — und werden oft missverstanden, gerade was DMARC tatsächlich tut.

SPF: wer darf für meine Domain Mails verschicken

SPF ("Sender Policy Framework") ist ein TXT-Record im DNS, der angibt, welche IP-Adressen berechtigt sind, Mails mit deiner Domain als Absender zu verschicken.

matti.services. IN TXT "v=spf1 mx ip4:5.75.x.y -all"

Bedeutung:

• mx — die in den MX-Records gelisteten Server dürfen senden
• ip4:5.75.x.y — diese IP zusätzlich
• -all — alle anderen sind explizit verboten ("Hard Fail")

Der wichtigste Teil ist das letzte Zeichen. ~all (Soft Fail) sagt "verdächtig, aber nicht ablehnen". -all (Hard Fail) sagt "ablehnen". +all sagt "alle dürfen alles" — wer das hat, hat keine SPF.

Häufiger Fehler: mehrere SPF-Records statt einem. Pro Domain ist genau ein TXT-Record mit v=spf1 erlaubt. Wer einen zweiten anlegt (etwa weil ein Newsletter-Service "fügen Sie diesen Record hinzu" sagt), kriegt SPF-Failures.

DKIM: kryptografische Signatur

DKIM ("DomainKeys Identified Mail") signiert ausgehende Mails mit einem privaten Schlüssel. Der öffentliche Schlüssel liegt im DNS. Empfänger-Server kann verifizieren, dass die Mail tatsächlich von deiner Domain kommt und unterwegs nicht modifiziert wurde.

Auf Postfix mit OpenDKIM:

apt install opendkim opendkim-tools

Schlüssel generieren:

opendkim-genkey -s mail -d matti.services

Erzeugt zwei Dateien: mail.private (kommt in die Konfiguration) und mail.txt (das DNS-Eintrag). Den DNS-Inhalt unter mail._domainkey.matti.services als TXT-Record setzen.

In /etc/opendkim.conf die Standardparameter, dazu Mappings:

KeyTable            /etc/opendkim/key.table
SigningTable        /etc/opendkim/signing.table
ExternalIgnoreList  /etc/opendkim/trusted.hosts
InternalHosts       /etc/opendkim/trusted.hosts

Postfix in main.cf mit OpenDKIM verbinden:

smtpd_milters = inet:localhost:8891
non_smtpd_milters = $smtpd_milters
milter_default_action = accept

postfix reload, systemctl restart opendkim. Eine Test-Mail an [email protected] schicken — kommt eine Antwort mit detailliertem Auth-Bericht zurück.

DMARC: was Empfänger mit failed SPF/DKIM tun sollen

DMARC ist die Policy-Schicht. SPF und DKIM sagen "ist die Mail authentisch", DMARC sagt "wenn nicht — was tun".

_dmarc.matti.services. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"

p= ist die Policy:

• none — nur monitoren, nichts blockieren
• quarantine — verdächtige Mails in den Spam-Ordner
• reject — komplett ablehnen

rua= ist die Adresse für Aggregate Reports — Empfänger-Server schicken dir täglich Berichte über alle Mails, die sie unter deiner Domain gesehen haben. Das ist Gold wert, weil du sehen kannst, ob jemand versucht, deine Domain zu spoofen.

Empfohlener Rollout

Direkt mit p=reject starten ist riskant — wenn du eine SPF- oder DKIM-Fehlkonfiguration hast, blockierst du legitime Mails. Mein Vorgehen:

1. SPF und DKIM einrichten und testen
2. DMARC mit p=none setzen, mind. 2 Wochen Reports sammeln
3. Reports auswerten — wer schickt unter deiner Domain? Sind alle erfasst?
4. Auf p=quarantine; pct=10 hochstufen (10 % der Mails bei Failures quarantinen)
5. Schrittweise auf pct=100, dann auf p=reject

Reports auswerten ist mühsam — die XML-Dateien sind unhandlich. Es gibt Online-Tools (postmark.com bietet einen kostenlosen Parser), die das menschenlesbar machen.

Warum das alles?

Mail-Infrastruktur basiert auf Vertrauen, und das Vertrauen wird permanent ausgenutzt. Phishing nutzt seit Jahrzehnten gefälschte Absender-Adressen. SPF, DKIM und DMARC sind die Antwort darauf — nicht perfekt, aber der einzige skalierbare Mechanismus, den wir haben.

Wer ohne die drei einen Mailserver betreibt, landet entweder im Spam oder ermöglicht Spoofing. Beides will man nicht. Die Einrichtung ist einmalig, der laufende Aufwand minimal — solange man die DMARC-Reports nicht ignoriert.