Modul 4 · 4.4
Deutsch
DMARC ausrollen: von none zu reject
Modul 4: Zustellbarkeit: SPF, DKIM und DMARC in der Praxis · Lesezeit: 12 Minuten
Lernziel: Nach dieser Lektion können Sie erklären, wie Alignment funktioniert, einen DMARC-Rollout in Phasen von p=none zu p=reject planen, die richtigen Tags wählen (rua, sp, np, t) und die bekannten Stolperfallen bei Weiterleitungen und Mailinglisten auffangen.
Kernbegriffe: DMARC (RFC 9989), Author Domain (die Domain im Von-Feld), Alignment (Ausrichtung), relaxed und strict (adkim, aspf), Organisationsdomain, DNS Tree Walk, p=none, p=quarantine, p=reject, rua, sp, np, t=y (Testmodus), veraltete Tags pct, rf, ri, Mailinglisten, From umschreiben, ARC
Was DMARC genau prüft
DMARC beantwortet für jede eingehende E-Mail eine Frage: ist SPF oder DKIM für eine Domain erfolgreich, die zur Von-Adresse gehört? Die Domain in der Von-Adresse heisst im Standard das Author Domain. Die Grundlagen des Records stehen in der DNS-Kurs, Lektion 4.5. Im Mai 2026 ist der überarbeitete Standard erschienen: RFC 9989, mit RFC 9990 für die Sammelberichte und RFC 9991 für die Fehlerberichte. Bestehende Records mit v=DMARC1 bleiben weiterhin gültig.
Alignment in der Praxis
"Gehört zu" heisst Alignment (Ausrichtung). Es gibt zwei Modi:
- relaxed (Standard): die Domains haben dieselbe Organisationsdomain.
nieuws.example.comundexample.comsind ausgerichtet;example.comundexample.netnicht. - strict (
adkim=soderaspf=s): die Domains müssen genau übereinstimmen.
Für SPF vergleicht DMARC die Domain des Return-Path mit der Von-Domain. Für DKIM die d=-Domain einer gültigen Signatur. Ein paar Beispiele für eine E-Mail mit Von: info@example.com:
| SPF-Ergebnis (Return-Path) | DKIM-Ergebnis (d=) | DMARC |
|---|---|---|
pass für example.com | keine Signatur | pass (SPF ausgerichtet) |
pass für bounce.mailer.example | pass für mailer.example | fail (beide erfolgreich, aber keines ausgerichtet) |
pass für bounce.mailer.example | pass für example.com | pass (DKIM ausgerichtet) |
| fail (weitergeleitet) | pass für example.com | pass (DKIM übersteht die Weiterleitung) |
pass für bounce.example.com | keine | pass bei relaxed, fail bei aspf=s |
Lassen Sie adkim und aspf also auf relaxed stehen, es sei denn, Sie haben einen guten Grund dagegen.
Woher weiss ein Empfänger, was die Organisationsdomain ist? Früher mit der Public Suffix List, einer Liste mit Domains wie .nl, .co.uk und github.io. RFC 9989 ersetzt das durch einen DNS Tree Walk: der Empfänger sucht _dmarc-Records der Domain und der übergeordneten Domains. Für einen normalen Nutzer ändert sich nichts; Sie merken es nur, wenn Sie mit Records auf Subdomains arbeiten.
Der Rollout in vier Phasen
Das Ziel ist p=reject: dann weisen Empfänger E-Mails zurück, die sich als Sie ausgeben, und das ist der beste Schutz gegen gefälschte Rechnungen und Phishing in Ihrem Namen. Wer jedoch sofort auf reject geht, ohne seine Versender zu kennen, weist bald seine eigenen Rechnungen zurück. Deshalb diese Reihenfolge (die Empfehlung dieses Kurses):
Phase 0: vorbereiten
- Erstellen Sie die Inventur all Ihrer Versender (Lektion 4.2).
- Stellen Sie sicher, dass jeder Versender SPF oder DKIM ausgerichtet hat; am liebsten DKIM, denn das übersteht Weiterleitungen.
- Erstellen Sie eine separate Adresse für Berichte, zum Beispiel
dmarc@example.com, oder nutzen Sie einen Berichtsdienst. Sie erhalten schnell mehrere Berichte pro Tag.
Phase 1: Messen mit p=none
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"p=none ändert nichts an der eigentlichen E-Mail. Empfänger liefern alles wie gewohnt aus, senden Ihnen aber täglich einen Sammelbericht (aggregate report) mit jedem Server, der im Namen Ihrer Domain gemailt hat, und ob SPF, DKIM und DMARC erfolgreich waren. Damit erfüllen Sie auch die Mindestanforderung von Gmail, Yahoo und Microsoft für Massenversender (Lektion 5.3).
Lassen Sie das mindestens zwei bis vier Wochen stehen, und länger, wenn Sie Dienste haben, die nur gelegentlich mailen (eine jährliche Erinnerung, eine Quartalsrechnung). Lesen Sie die Berichte (Lektion 4.5) und beheben Sie jede eigene Quelle, die fehlschlägt.
Phase 2: p=quarantine
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"E-Mails, die DMARC nicht bestehen, landen beim Empfänger im Spam-Ordner. Vergessen Sie dennoch eine Quelle, ist diese E-Mail nicht verloren, aber schwer zu finden. Wenn Sie vorsichtig sein möchten, fügen Sie zunächst t=y hinzu (Testmodus): Empfänger wenden dann eine Stufe mildere Richtlinie an (bei quarantine also none), aber Sie sehen in den Berichten, was passieren würde. Das ist in RFC 9989 der Ersatz für den alten Tag pct=.
Betrachten Sie wieder ein paar Wochen lang die Berichte.
Phase 3: p=reject
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"E-Mails, die DMARC nicht bestehen, werden abgewiesen. Der Absender erhält eine Bounce, bei Microsoft zum Beispiel mit dem Code 5.7.509 und bei Gmail mit einem Verweis auf die DMARC-Richtlinie (Modul 6). Behalten Sie die Berichte im Auge: neue Dienste kommen immer wieder hinzu.
Wann geht es schneller?
Läuft all Ihre E-Mail über einen einzigen Anbieter, der SPF und DKIM für Sie regelt, und versendet sonst niemand etwas in Ihrem Namen? Dann kann eine strenge Richtlinie sofort eingeführt werden. Manche Hostinganbieter setzen deshalb standardmässig p=reject. Wenn Sie anschliessend doch einen Newsletter-Dienst oder ein Buchhaltungsprogramm nutzen möchten, setzen Sie es zunächst vorübergehend zurück auf p=none mit einer Berichtsadresse, bis dieser Dienst korrekt eingerichtet ist.
Die anderen Tags
| Tag | Wofür | Empfehlung |
|---|---|---|
rua=mailto:... | Adresse(n) für Sammelberichte, durch Kommas getrennt | Während des Rollouts immer ausfüllen |
ruf=mailto:... | Adresse für Fehlerberichte per E-Mail (RFC 9991) | Fast kein Empfänger sendet diese, und sie können personenbezogene Daten enthalten. Meist weglassen |
sp= | Richtlinie für bestehende Subdomains | Weglassen (dann gilt p=), es sei denn, Subdomains mailen anders |
np= | Richtlinie für Subdomains, die nicht existieren | np=reject ist eine sinnvolle Ergänzung, sobald Ihre Hauptrichtlinie streng ist: niemand kann dann von factuur.example.com mailen, wenn dieser Name nicht existiert |
adkim=, aspf= | Strict oder relaxed | Relaxed belassen |
t=y | Testmodus: eine Stufe milder | Praktisch beim Übergang zu quarantine oder reject |
fo= | Wann Fehlerberichte erstellt werden | Nur sinnvoll mit ruf |
pct=, rf=, ri= | Veraltet in RFC 9989 | Nicht mehr verwenden; Empfänger, die den neuen Standard befolgen, ignorieren sie |
Eine Berichtsadresse auf einer anderen Domain (zum Beispiel ein Berichtsdienst) funktioniert nur, wenn diese Domain dies mit einem Record wie example.com._report._dmarc.rapportdienst.example erlaubt. Der Dienst regelt das meistens selbst (RFC 9990, Kapitel 4).
Stolperfallen
Mailinglisten
Eine klassische Mailingliste leitet Ihre E-Mail an alle Mitglieder weiter, von ihrem eigenen Server aus, und fügt oft [liste] zum Betreff oder einen Fusstext hinzu. Dann schlägt SPF fehl (anderer Server) und DKIM ebenfalls (E-Mail verändert). Mit p=reject weisen die Empfänger Ihre Nachricht an die Liste zurück. Moderne Listensoftware löst das, indem sie die Von-Adresse zum Listenadresse umschreibt ("Jan via Mitglieder"), oder indem sie die E-Mail unverändert weiterleitet. Verwenden Sie eine Liste, die das nicht tut, sehen Sie das in Ihren Berichten.
Weiterleiten
Siehe Lektion 3.3: SPF bricht, DKIM übersteht es meistens. Ein Empfänger kann mit ARC beschliessen, einem bekannten Weiterleiter zu vertrauen. In den Berichten erkennen Sie das an E-Mails von einem unbekannten Server mit DKIM pass und SPF fail; das ist kein Grund, Ihre Richtlinie zu lockern.
Zwei Records oder ein Tippfehler
Zwei DMARC-Records auf _dmarc machen die Richtlinie ungültig, und ein Tippfehler in p= ebenfalls (p=rejected existiert nicht). Überprüfen Sie das nach jeder Änderung.
In der Praxis: So sieht es in einem Panel aus
Bei einem Hostingpaket von WebOké steht standardmässig v=DMARC1;p=reject, ohne Berichtsadresse. Das ist sicher, wenn all Ihre E-Mail über diese Server läuft. Mailen Sie auch über andere Dienste, setzen Sie es dann auf p=none mit einer rua-Adresse und arbeiten Sie die Phasen ab. In DirectAdmin tun Sie das in DNS-Verwaltung mit dem Stift hinter dem _dmarc-Record (Felder Domain-Richtlinientyp und Gesamt-E-Mail (RUA)); in Mein WebOké mit der DMARC-Hilfe auf dem Tab DNS. Bei anderen Anbietern erstellen Sie einen TXT-Record auf den Namen _dmarc und geben den Text selbst ein; das Ergebnis ist dasselbe.
Zusammenfassung
- DMARC ist erfolgreich, wenn SPF oder DKIM für eine Domain erfolgreich ist, die mit der Von-Domain ausgerichtet ist; relaxed Alignment akzeptiert Subdomains.
- Rollout: Inventur,
p=nonemitruaund Berichte lesen,p=quarantine(eventuell mitt=y), und dannp=reject. - Verwenden Sie
np=rejectfür nicht existierende Subdomains, sobald die Hauptrichtlinie streng ist.pct,rfundrisind veraltet. - Mailinglisten und Weiterleitungen führen zu erwarteten Fehlern; DKIM und ARC fangen einen Teil davon auf.
- Genau ein Record auf
_dmarc, ohne Tippfehler.
Quiz
Aufgabe
Aufgabe Z4.4: DMARC Ihrer Domain überprüfen und den nächsten Schritt wählen. Geben Sie Ihre eigene Domain ein (oder internet.nl). Geben Sie das DMARC-Record ein, wie Sie es gefunden haben, den Wert von p= und ob eine rua-Adresse enthalten ist. Wählen Sie anschliessend, welche Phase des Rollouts Ihrer Meinung nach der nächste Schritt ist, und warum. Das Programm fragt das Record live ab, prüft die Syntax gemäss RFC 9989 (ein Record, gültiges p, bekannte Tags, veraltete Tags als Warnung) und stellt Ihre Antworten daneben.
Weiterführende Informationen
Die Schritte in diesen Artikeln gelten für die Panels von WebOké; bei anderen Anbietern funktioniert es ähnlich.
- Kostenloser DNS-Kurs 4.5: DMARC: was Empfänger mit gefälschter Mail tun sollen
- DirectAdmin Anleitung 5.9: DMARC einrichten
- Was ist DMARC? Erklärung in einfacher Sprache
- DMARC-Eintrag in DirectAdmin erstellen
- RFC 9989 (DMARC), insbesondere 4.7 (Tags) und Anhang C (Änderungen seit RFC 7489)