SPF für Mailcow einrichten

Schritt-für-Schritt-Anleitung für Mailcow (dockerized): SPF-Record nach offizieller docs.mailcow.email-Empfehlung mit Hardfail-Policy, PTR-Record am IP-Provider als Mailcow-Pflicht, dig-Verifikation.

Mailcow · Schritt für Schritt

SPF für Mailcow (Self-Hosted Docker)

Mailcow ist ein Open-Source-Mailserver-Stack auf Docker-Basis — Postfix, Dovecot, Rspamd, nginx, ClamAV und SOGo in koordinierten Containern. Die offizielle DNS-Doku unter docs.mailcow.email/getstarted/prerequisite-dns/ empfiehlt v=spf1 mx a -all: MX und A-Record-IP autorisieren, alle anderen mit Hardfail ablehnen. Zusätzlich Pflicht: Der PTR-Record (Reverse-DNS) Ihrer Server-IP muss exakt auf den Mailcow-FQDN zeigen — sonst lehnen viele empfangende Mailserver bereits den HELO-Handshake ab.

Bei Mailcow konfigurieren Sie SPF nicht über die Web-UI, sondern direkt im DNS Ihres Domain-Providers — die Web-UI zeigt den empfohlenen Record nur zur Kopiervorlage an. v=spf1 mx a -all kostet zwei DNS-Lookups (mx + a) des RFC-7208-Budgets von 10. Da Sie als Self-Hoster volle Kontrolle haben, ist -all (Hardfail) ab dem ersten Tag möglich und empfehlenswert. Der Wolf-Agents Email Security Check validiert die SPF-Lookup-Zählung, prüft die PTR-Konsistenz (Reverse-DNS-FQDN matched mit Mailcow-Hostnamen) und erkennt SPF-Drift, wenn Sie zusätzliche Sender (Backup-MX, sekundäre Container) später ergänzen.

Hardening-Pfad: Nach SPF folgt DKIM für Mailcow — generiert in der Admin-UI per Knopfdruck (RSA 2048-Bit Default, Selektor dkim). Gemeinsam bilden SPF + DKIM die Grundlage für DMARC. Bedrohungs-Cluster: Ein korrekt gehärteter SPF + PTR-Record schließt direkt zwei Klassen von Angriffen — Direct-Domain-Spoofing mit Ihrer Mailcow-Domain und Phishing mit Ihrer Marke (FBI IC3 2024: 21.442 BEC-Beschwerden, 2,77 Mrd. USD Schaden).

1 Schritt 1 von 3

Mailcow-Hostnamen und PTR-Record bestimmen

Mailcow nutzt einen einzigen Hostnamen für SMTP, IMAP, das Web-Admin-UI und SOGo — typischerweise mail.ihre-domain.de. Die offizielle Mailcow-Doku ist explizit: „Make sure that the PTR record of your IP address matches the FQDN of your mailcow host.“ Ohne korrekten PTR lehnen Microsoft 365, Google Workspace und andere Empfänger Ihre Mails häufig schon im HELO-Schritt ab.

DNS-Setup (Mailcow Prerequisite) Mailcow
# A-Record für Mailcow-Hostnamen
mail.ihre-domain.de.  IN  A     203.0.113.10
mail.ihre-domain.de.  IN  AAAA  2001:db8::10

# MX-Record für die Domain
ihre-domain.de.       IN  MX    10 mail.ihre-domain.de.

# PTR-Record (am IP-Provider, NICHT im Domain-DNS!)
# Für IPv4: 10.113.0.203.in-addr.arpa.    IN  PTR  mail.ihre-domain.de.
# Für IPv6: ...ip6.arpa.                  IN  PTR  mail.ihre-domain.de.
PTR wird beim IP-Provider gesetzt

Der PTR-Record wird nicht in Ihrer Domain-DNS-Zone konfiguriert, sondern beim Hosting-Provider, dem die IP gehört (Hetzner, Netcup-vServer, Contabo, AWS, etc.). Bei Hetzner-Cloud im Console-Reverse-DNS-Tab, bei Netcup-vServer im Server-Control-Panel. Pflicht für IPv4 und IPv6 — beide separat setzen.

2 Schritt 2 von 3

SPF-Record im DNS anlegen

Erstellen Sie einen TXT-Record für Ihre Root-Domain beim DNS-Provider. v=spf1 mx a -all autorisiert alle MX-Server (also mail.ihre-domain.de) und den A-Record-Host — und lehnt mit -all alle anderen ab. Bei Mailcow ist Hardfail ab Tag 1 sinnvoll, weil Sie als Self-Hoster keine vergessenen Drittsender haben.

DNS TXT-Record (Mailcow-Empfehlung) Mailcow
ihre-domain.de.  IN  TXT  "v=spf1 mx a -all"
Zusätzliche Sender? Includes erweitern.

Wenn Sie über Drittanbieter (Newsletter-Tools, Transaktions-Mail-Services wie Mailgun, AWS SES) zusätzlich versenden, ergänzen Sie deren Includes in einem einzigen Record — RFC 7208 erlaubt nur einen SPF-Record pro Domain:

v=spf1 mx a include:_spf.mailgun.org include:amazonses.com -all
Multi-Domain-Hosting in einer Mailcow-Instanz (Information-Gain)

Mailcow erlaubt beliebig viele unabhängige Domains in einer einzigen Instanz unter Configuration → Mail Setup → Domains. Jede Domain bekommt eigene Mailboxen, einen eigenen DKIM-Key (Selektor pro Domain) und braucht im DNS einen eigenen SPF-Record. Der MX-Hostname zeigt aber für alle Domains auf denselben Mailcow-FQDN (z.B. mail.haupt-domain.de) — daher ergänzen Sie bei zweiter Domain SPF entweder mit dem Mailcow-FQDN über a:mail.haupt-domain.de oder über das include:-Pattern, das auf einen separaten SPF-Eintrag verweist. Quelle: docs.mailcow.email/getstarted/prerequisite-dns/ (abgerufen 2026-05-13, Abschnitt „Misc“ — zusätzliche Domains brauchen keinen eigenen mail.extradomain.tld-Hostnamen, der MX zeigt auf den Hauptserver-FQDN; vgl. Issue #714 zur fehlenden dedizierten Multi-Domain-Doku).

3 Schritt 3 von 3

SPF und PTR verifizieren

Prüfen Sie SPF, A/AAAA und PTR. Wenn der PTR fehlt oder nicht zum Mailcow-FQDN passt, schlagen Mails häufig schon beim HELO bei Microsoft 365 oder Google Workspace fehl — die Mailcow-Logs zeigen dann warning: hostname ... does not resolve to address ....

Terminal — Verifikation Verifikation
# SPF-Record abfragen
dig TXT ihre-domain.de +short
# "v=spf1 mx a -all"

# MX-Record auflösen
dig MX ihre-domain.de +short
# 10 mail.ihre-domain.de.

# A-Record des MX prüfen
dig A mail.ihre-domain.de +short

# PTR-Reverse-Lookup (IPv4)
dig -x 203.0.113.10 +short
# mail.ihre-domain.de.    <- MUSS exakt der Mailcow-FQDN sein

# PTR-Reverse-Lookup (IPv6)
dig -x 2001:db8::10 +short

# In Mailcow-Logs nach HELO-/EHLO-Fehlern suchen
docker compose logs postfix-mailcow | grep -i "helo\|ptr\|reverse"

# Windows (PowerShell)
Resolve-DnsName -Name ihre-domain.de -Type TXT
Resolve-DnsName -Name 203.0.113.10 -Type PTR

Validieren Sie zusätzlich mit dem Wolf-Agents Email Security Check — dieser prüft SPF auf 22 Kriterien inklusive Lookup-Zählung, Qualifier-Bewertung und Mailcow-spezifisch die PTR-Konsistenz.

Häufige Fehler bei Mailcow

Diese drei Fehler treten bei Mailcow-Self-Hosting besonders häufig auf — alle drei können Ihre ausgehenden Mails komplett unzustellbar machen oder Empfänger zu Spam-Marking zwingen.

PTR-Record fehlt oder zeigt auf Provider-Default

Problem: Bei einem frisch gebuchten Hetzner- oder Contabo-vServer steht der PTR-Record standardmäßig auf einen generischen Provider-Hostnamen (z.B. static.10.113.0.203.clients.your-server.de). Mailcow versendet aber mit dem HELO-Hostnamen mail.ihre-domain.de — die Reverse-Forward-Konsistenz schlägt fehl. Microsoft 365 (Postscreen) und Google Workspace lehnen die Verbindung mit 550 Service unavailable; Client host blocked using Spamhaus oder ähnlichen Fehlern direkt im HELO-Handshake ab.

Lösung: Beim IP-Provider den PTR-Record auf den Mailcow-FQDN setzen (z.B. mail.ihre-domain.de). Bei Hetzner-Cloud im Console unter Server → Netzwerk → Reverse-DNS, bei Netcup-vServer im SCP unter Reverse-DNS. Sowohl IPv4 als auch IPv6 separat. Nach Setzen mit dig -x <ip> verifizieren.

SPF mit ~all statt -all (zu lax)

Problem: Aus Tutorials für Shared-Hosting wird oft v=spf1 mx a ~all (SoftFail) kopiert. Bei Self-Hosting auf einer dedizierten IP haben Sie volle Kontrolle über alle ausgehenden Mails — ~all öffnet aber explizit ein Fenster für gefälschte Absender, die Empfänger als „neutral“ oder „verdächtig“ einstufen statt direkt abzulehnen. DMARC-Enforcement mit p=reject wird inkonsistent mit SoftFail-SPF.

Lösung: Bei Mailcow ab Tag 1 v=spf1 mx a -all (Hardfail) verwenden — die offizielle docs.mailcow.email-Empfehlung. Bei Bedarf später Includes ergänzen. Hardfail wird von Empfängern strikt durchgesetzt und ergänzt DMARC p=reject konsistent.

Zwei SPF-Records nach Mailcow-Migration

Problem: Bei der Migration von einem alten Mailhosting (z.B. Microsoft 365) zu Mailcow wird der neue SPF-Record angelegt, ohne den alten zu löschen. RFC 7208 § 4.5 erlaubt nur einen v=spf1-Record — bei zwei Records wirft jeder konforme Resolver PermError und SPF gilt komplett als ungültig. Mailcow-Mails landen dann häufig im Spam-Ordner, weil DMARC-Alignment fehlschlägt.

Lösung: Nach der Migration mit dig TXT ihre-domain.de +short | grep "v=spf1" | wc -l die Anzahl prüfen — Wert muss 1 sein. Den überzähligen Record im DNS-Provider-Panel löschen und alle Includes in einen einzigen Record zusammenführen.

NIS2, BSI TR-03182 und DSGVO Art. 32: SPF bei Mailcow-Self-Hosting

Mailcow ist ein Self-Hosted-Mailserver — Sie als Betreiber sind sowohl Verantwortlicher (DSGVO Art. 4 Nr. 7) als auch technischer Verantwortlicher für die Sender-Authentifizierung. NIS2 Art. 21 Abs. 2 lit. h (Konzepte und Verfahren für den Einsatz von Kryptografie und Verschlüsselung) fordert SPF als Mindeststandard für die Sender-Authentizität via DNS-Kryptografie. BSI TR-03182 nennt SPF explizit als Mindestanforderung. DSGVO Art. 32 verlangt technische Maßnahmen zur Sicherheit der Verarbeitung — die Begrenzung gefälschter Absender mit Ihrem Domain-Namen ist eine direkte Schutzmaßnahme. Anders als bei Managed-Providern fällt der Schutz hier vollständig in Ihre Verantwortung — keine AVV-Delegation möglich. Wolf-Agents empfiehlt für Mailcow die Kombination aus v=spf1 mx a -all (Hardfail), DKIM (RSA 2048-Bit via Mailcow-UI), DMARC p=reject und PTR-Konsistenz. Der Wolf-Agents Email Security Check bewertet SPF mit bis zu 22 Punkten der 165-Punkte-Analyse.

Self-Hosted-Alternativen zu Mailcow

Mailcow ist nicht der einzige Open-Source-Mailserver-Stack. Vier ernsthafte Alternativen mit jeweils eigener Stärken-Profilierung:

Wettbewerber-Profile (Stand 2026-05-13)

  1. Mail-in-a-Box (mailinabox.email) — Auf Ubuntu 22.04 x64 zugeschnittene Turn-key-Lösung mit automatischer SPF/DKIM/DMARC/MTA-STS-Konfiguration; DNSSEC und DANE TLSA werden vom Projekt nicht standardmäßig aktiviert, sondern als optional aktivierbare „higher level of protection“-Schicht beschrieben (Quelle: mailinabox.email, abgerufen 2026-05-13). Vorteil gegenüber Mailcow: Geringere Setup-Komplexität durch starres OS-Zielprofil. Nachteil: Keine Container-Unterstützung, keine modifizierten Images, OS-Lock-in auf Ubuntu 22.04, DNSSEC/DANE erfordern bewusste Aktivierung.
  2. Modoboa (modoboa.org) — Python/Django-basiertes Admin-Webinterface mit Installer („deals with 95% of the work in less than 10 minutes“). SPF/DKIM/DMARC, TLS via Let's Encrypt. Vorteil: Schnelle Installation, Multi-Domain-Verwaltung. Nachteil: MTA-STS nicht prominent dokumentiert, kein dediziertes DMARC-Reporting-Modul (anders als Mailcow mit Rspamd-DMARC + parsedmarc).
  3. iRedMail (iredmail.org) — Multi-OS-Stack: Red Hat Enterprise Linux, CentOS Stream, Rocky, Alma, Debian, Ubuntu, FreeBSD, OpenBSD. Backend-Auswahl: OpenLDAP, MySQL, MariaDB, PostgreSQL. Vorteil gegenüber Mailcow: Maximale OS-Flexibilität (auch FreeBSD/OpenBSD). Nachteil: DMARC und MTA-STS nicht explizit als Features dokumentiert — manuelle Konfiguration nötig.
  4. Stalwart Mail Server (stalw.art) — Rust-basiert, „memory-safe implementation“, alle modernen Standards (DKIM, SPF, DMARC, ARC, DANE, MTA-STS, TLS-RPT, S/MIME, OpenPGP). Clustering und Skalierbarkeit für Millionen von Mailboxen. Vorteil gegenüber Mailcow: ARC-Support nativ, Rust-Memory-Safety, integrierte Cluster-Fähigkeit. Nachteil: Jüngeres Projekt, kleinere Community als Mailcow.

Wolf-Agents-Empfehlung: Mailcow bleibt 2026 die ausgewogene Wahl für DACH-DE-Setups dank großer Community, deutschsprachiger Doku-Treue, Docker-Flexibilität und Built-in-MTA-STS seit 2025-09. Mail-in-a-Box ist besser für Single-Server-Setups mit DANE-Anforderung. Stalwart lohnt sich bei Cluster-Setups und neuen Projekten ohne Legacy-Last. Der Wolf-Agents Email Security Check funktioniert provider-unabhängig — die 22 SPF-Kriterien gelten für alle vier Stacks gleichermaßen.

Wie steht Ihre Domain bei SPF?

Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.