Stand: Juli 2026

Zusammenfassung: Nach dieser Anleitung veröffentlicht deine Domain einen DMARC-Record, der empfangenden Servern sagt, was mit nicht authentifizierten Mails geschehen soll — und dir per Report zeigt, wer in deinem Namen sendet.

Voraussetzungen

  • Ein laufender Mailcow-Server
  • SPF und DKIM müssen zuerst eingerichtet sein — die Mailcow-Doku nennt DMARC ausdrücklich „the last step”, nach SPF und DKIM
  • Zugriff auf die DNS-Verwaltung deiner Domain

Was ist DMARC?

DMARC (Domain-based Message Authentication, Reporting & Conformance) verbindet SPF und DKIM zu einer durchsetzbaren Richtlinie. Es ist ein TXT-Record unter der Subdomain _dmarc. Darin legst du fest, was ein Empfänger mit Mails tun soll, die die Prüfung nicht bestehen (die p-Policy), und wohin er dir Berichte schickt (die rua-Adresse).

Beim Selbsthosten schließt DMARC den Kreis: SPF autorisiert deinen Server, DKIM signiert die Nachricht, und DMARC macht aus beidem eine Regel, die empfangende Server durchsetzen.

Die Ausgangslage bei Mailcow

Mailcow selbst setzt den DMARC-Record nicht — deine DNS-Zone liegt bei deinem DNS-Anbieter. Die Mailcow-Doku dokumentiert aber genau, was hingehört, und verweist für die Erstellung auf einen DMARC Assistant. Ihr Beispiel-Record ist bereits scharf gestellt:

_dmarc  IN TXT  "v=DMARC1; p=reject; rua=mailto:mailauth-reports@example.org"

Für einen sauber konfigurierten Selfhoster ist p=reject das richtige Ziel — aber komm dorthin über die Rampe, nicht sofort.

Der sichere Weg: none → quarantine → reject

  1. p=none — beobachten, nichts blockieren. Hier startest du und sammelst Reports:
v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de
  1. p=quarantine — verdächtige Mails landen im Spam, optional gestaffelt mit pct:
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@beispiel.de
  1. p=reject — die Durchsetzung, optional mit strenger Ausrichtung und Subdomain-Policy:
v=DMARC1; p=reject; rua=mailto:dmarc@beispiel.de; sp=reject; adkim=s; aspf=s

Wechsle erst weiter, wenn die Reports zeigen, dass alle deine legitimen Sendequellen SPF/DKIM bestehen.

Schritt-für-Schritt-Anleitung

1. Report-Adresse festlegen

Die rua-Adresse empfängt die aggregierten Reports. Für die Auswertung lohnt sich ein DMARC-Monitoring wie MARCo, das die täglichen XML-Reports lesbar macht und dir zeigt, welche Quellen noch nicht sauber authentifiziert sind.

2. _dmarc-TXT-Record beim DNS-Anbieter anlegen

Lege einen TXT-Record auf dem Host _dmarc an. Wo genau, hängt vom DNS-Anbieter ab — siehe unsere Anleitungen für IONOS, Strato, Netcup oder Hetzner DNS (bei Hetzner muss der TXT-Wert in Anführungszeichen stehen).

3. Reports lesen und die Policy anziehen

Starte mit p=none, wandere über quarantine zu reject, sobald die Reports sauber sind.

4. Warten, bis die Änderung aktiv ist

DNS-Änderungen brauchen je nach Caching einige Stunden.

Die wichtigsten Tags

TagBedeutung
v=DMARC1Version, muss am Anfang stehen
p=Policy: none (beobachten), quarantine (Spam), reject (ablehnen)
rua=Adresse für aggregierte Statusberichte
ruf=Adresse für forensische Fehlerberichte
sp=eigene Policy für Subdomains
adkim= / aspf=Ausrichtung (r relaxed, s strict) für DKIM bzw. SPF

Ergebnis prüfen

Prüfe deine Konfiguration mit dem kostenlosen MXAudit-Scanner — er zeigt dir DMARC-Policy, SPF und DKIM auf einen Blick.

Häufige Fehler

Mailcows p=reject-Beispiel 1:1 übernommen. Das Doku-Beispiel ist scharf. Übernimmst du es, bevor deine Quellen sauber authentifizieren, blockierst du eigene Mails. Erst p=none, Reports lesen, dann anziehen.

Kein rua gesetzt. Ohne Report-Adresse siehst du nie, welche Quellen scheitern.

DMARC ohne SPF/DKIM. DMARC prüft die Ergebnisse von SPF und DKIM. Erst SPF und DKIM, dann DMARC.

Falscher Hostname. Der Record gehört an _dmarc — nicht an @ oder die nackte Domain.