Schnelle Antwort
Wie richte ich DMARC für meine Domain ein?
Veröffentlichen Sie einen TXT-Eintrag bei _dmarc.ihredomain mit dem Inhalt v=DMARC1; p=none; rua=mailto:sie@ihredomain, lesen Sie etwa einen Monat lang die Aggregatberichte, heben Sie dann die Richtlinie auf quarantine an und schließlich auf reject. DMARC ist seit Mai 2026 durch RFC 9989 definiert. Postelva hostet den Eintrag in seinem kostenlosen DNS-Editor.
Die drei DMARC-Richtlinien und was jede bewirkt
| Richtlinie | Eintrag | Wirkung auf eine Nachricht, die DMARC nicht besteht | Wann zu verwenden |
|---|---|---|---|
| Überwachen | v=DMARC1; p=none; rua=mailto:[email protected] | Wird wie gewohnt zugestellt; Berichte werden an Sie gesendet | Erste Wochen, um jeden Absender zu sehen |
| Quarantäne | v=DMARC1; p=quarantine; rua=mailto:[email protected] | Wird als verdächtig behandelt, meist in den Spam-Ordner gelegt | Nachdem SPF und DKIM bei all Ihren legitimen E-Mails bestehen |
| Ablehnen | v=DMARC1; p=reject; rua=mailto:[email protected] | Wird vom empfangenden Server abgelehnt | Wenn die Berichte keinen legitimen Fehlschlag mehr zeigen |
DMARC in sechs Schritten einrichten
Zuerst SPF und DKIM bestätigen
DMARC braucht mindestens eines von beiden, das besteht und zu Ihrer From-Domain passt. Veröffentlichen Sie beide vor DMARC, anhand der Leitfäden zu SPF und DKIM.
Ein Postfach für die Berichte wählen
Legen Sie eine Adresse wie dmarc@ihredomain an. RFC 9989 besagt, dass der Inhaber ein Postfach einrichten muss, um Aggregatberichte zu empfangen und zu analysieren.
Den Überwachungseintrag veröffentlichen
Fügen Sie einen TXT-Eintrag mit dem Host _dmarc und dem Wert v=DMARC1; p=none; rua=mailto:dmarc@ihredomain hinzu.
Die Berichte etwa einen Monat lang lesen
Berichte kommen etwa einmal täglich von Empfängern, die sie senden. Suchen Sie nach legitimen E-Mails, die beim SPF- und DKIM-Alignment durchfallen, und beheben Sie diese Absender.
Zu quarantine wechseln
Ändern Sie p=none in p=quarantine. Behalten Sie es für einen ähnlichen Zeitraum bei und vergleichen Sie in den Berichten, wie die Nachrichten behandelt wurden.
Zu reject wechseln oder bei quarantine bleiben
Wechseln Sie zu p=reject, wenn die Berichte sauber sind. Wenn Sie von dieser Domain aus an Mailinglisten schreiben, bleiben Sie bei quarantine.
; stage 1: monitor
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
; stage 2: quarantine
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
; stage 3: reject
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"Was enthält ein DMARC-Eintrag?
Ein DMARC-Eintrag ist ein TXT-Eintrag bei _dmarc.ihredomain, der mit v=DMARC1 beginnt und durch Semikolons getrennte Tags auflistet. Das Versions-Tag steht zuerst und unterscheidet Groß- und Kleinschreibung. RFC 9989 definiert diese Tags: p (Richtlinie für die Domain), sp (Richtlinie für bestehende Subdomains), np (Richtlinie für nicht existierende Subdomains), adkim und aspf (Alignment, r für relaxed oder s für strict, standardmäßig relaxed), rua (Adressen für Aggregatberichte), ruf (Adressen für Fehlerberichte), fo (Optionen für Fehler), t (Testmodus, y oder n) und psd.
Fehlt p, behandelt der Empfänger die Richtlinie als none. Fehlt sp, gilt die Richtlinie p auch für Subdomains. Fehlt rua, entstehen keine Aggregatberichte. Ein minimal nützlicher Eintrag hat daher drei Teile: die Version, eine Richtlinie und eine Berichtsadresse.
Das Tag pct, das viele ältere Leitfäden noch zeigen, wurde durch RFC 9989 entfernt, weil es außer bei 0 und 100 selten genau angewendet wurde. Das Tag t ersetzt es: t=y verhält sich wie pct=0 und t=n wie pct=100, und n ist der Standard. Streichen Sie pct aus alten Einträgen. Den weiteren Hintergrund bietet SPF, DKIM und DMARC im Vergleich.
Was bedeutet Alignment bei DMARC?
Alignment bedeutet, dass die per SPF oder DKIM authentifizierte Domain zur Domain in der sichtbaren From-Adresse passt. Im Modus relaxed, dem Standard, brauchen beide nur dieselbe Organisationsdomain, sodass mail.example.com zu example.com passt. Im Modus strict müssen sie identisch sein. RFC 9989 stellt fest, dass nahezu alle Domaininhaber relaxed für ausreichend halten.
Eine Nachricht besteht DMARC, wenn SPF oder DKIM besteht und im Alignment liegt. Eines genügt. Ein Postfachanbieter wie Proton Mail oder Fastmail signiert über die DKIM-CNAME-Einträge mit Ihrer eigenen Domain, sodass das Alignment ohne zusätzliche Arbeit stimmt. Die Falle ist ein Drittdienst, der mit seiner eigenen Domain signiert: Sein DKIM besteht, liegt aber nicht im Alignment, bis Sie dafür eine eigene Signierdomain einrichten.
RFC 9989 findet die Organisationsdomain über einen DNS-Baumdurchlauf mit höchstens acht Abfragen statt über eine Public-Suffix-Liste. Für eine gewöhnliche Domain auf .com oder .me ändert das nichts, was Sie tun müssen.
Wie lange sollte ich bei p=none bleiben?
Bleiben Sie mindestens einen Monat bei p=none, dann einen ähnlichen Zeitraum bei p=quarantine, bevor Sie zu p=reject wechseln. Das ist die Reihenfolge, die RFC 9989 in seinen Hinweisen zur Einführung empfiehlt, und sie entspricht den Hilfeseiten der Anbieter. Mailbox.org beginnt seinen Beispieleintrag bei p=none und warnt, dass eine zu früh gesetzte strenge Richtlinie legitime E-Mails zurückweisen kann. Proton empfiehlt p=quarantine und den Wechsel zu p=reject, sobald legitime E-Mails bestehen.
Nach der Auswertung von Postelva vom 12. November 2026 zu den DMARC-Hinweisen der 3 Anbieter, die sie veröffentlichen (Proton Mail, Mailbox.org und Mailfence), beginnen 2 bei p=none und 1 empfiehlt p=quarantine.
Für p=reject gelten zwei Vorbehalte. RFC 9989 besagt, dass sich eine Domain, die es nutzt, nicht allein auf SPF verlassen darf und mit DKIM signieren muss, weil SPF bei Weiterleitung bricht. Außerdem besagt er, dass Domains, deren Nutzer an Mailinglisten schreiben, p=reject gar nicht veröffentlichen sollten. Listen verändern Nachrichten oft, was die Signatur bricht.
Wohin gehen DMARC-Berichte, und was zeigen sie?
Aggregatberichte gehen an die mailto:-Adresse in rua, meist einmal täglich von jedem Empfänger, und listen die Quellen auf, die E-Mails mit Ihrer Domain in der From-Zeile gesendet haben. RFC 9989 verlangt, dass Empfänger mailto:-Adressen unterstützen, und empfiehlt, Aggregatberichte mindestens alle 24 Stunden zu senden. Die Aggregatberichterstattung ist in RFC 9990 definiert.
Fehlerberichte, die mit ruf angefordert werden, sind Kopien einzelner Nachrichten. Viele Empfänger halten sie aus Datenschutzgründen zurück oder schwärzen sie, verlassen Sie sich also nicht darauf. Liegt die rua-Adresse außerhalb Ihrer Domain, muss der Inhaber dieser anderen Domain sie mit einem TXT-Eintrag bei ihredomain._report._dmarc.anderedomain autorisieren, der v=DMARC1; enthält, eine Regel, die den Missbrauch fremder Postfächer verhindert. Für eine kleine private Domain ist die Liste der Quellen kurz: Ihr Anbieter und wenig sonst.
Um zu lesen, was Ihr DNS vor und nach jeder Stufe veröffentlicht, nutzen Sie die Befehle zur Prüfung von MX-, SPF-, DKIM- und DMARC-Einträgen.
Braucht meine private Domain DMARC?
Ja, für jede Domain, die E-Mails sendet: Es kostet einen TXT-Eintrag und blockiert gefälschte Nachrichten, die Ihren Namen nutzen. Google verlangt DMARC, wobei die Richtlinie none genügt, von Absendern mit mehr als 5,000 Nachrichten am Tag an Gmail-Konten, und Microsoft wendet dieselbe Schwelle auf Outlook.com an. Ein privates Postfach liegt weit unter diesen Grenzen. Der Eintrag sagt Empfängern dennoch, was Sie bei einer Fälschung wünschen.
Für eine Domain, die nichts sendet, setzen Sie sofort p=reject mit SPF -all und einem Null-MX. Postelva bietet dafür eine Vorlage „Keine E-Mail“. Für eine Domain mit Postfach beginnen Sie bei none. Die Transportseite desselben Schutzes, die Verschlüsselung zwischen Servern, behandelt die Einrichtung von MTA-STS und TLS-RPT.
Eine zitierfähige Definition: DMARC ist die DNS-Richtlinie, die Empfängern sagt, was sie mit E-Mails tun sollen, deren SPF- und DKIM-Ergebnisse nicht zur From-Domain passen, und wohin sie Berichte darüber senden sollen.
Fragen zur DMARC-Einrichtung
Verlangt RFC 9989 p=reject?
Nein. Der Standard definiert drei Richtlinien und überlässt die Wahl dem Domaininhaber. Er rät zu einem schrittweisen Vorgehen und warnt vor p=reject bei Domains, deren Nutzer an Mailinglisten schreiben.
Ändert RFC 9989 meinen bestehenden DMARC-Eintrag?
Einträge beginnen weiterhin mit v=DMARC1, ein funktionierender Eintrag funktioniert also weiter. Das Tag ri wurde gestrichen, pct entfernt, und t, np und psd wurden hinzugefügt.
Was passiert, wenn ich p=reject zu früh veröffentliche?
Legitime E-Mails, die das Alignment nicht bestehen, etwa von einem vergessenen Newsletter-Werkzeug, werden von Empfängern abgewiesen. Die Berichte bei p=none dienen dazu, diese Absender zuerst zu finden.
Kann ich ein kostenloses Postfach für die Berichte nutzen?
Ja, jedes Postfach, das Sie lesen. Eine eigene Adresse oder ein Alias hält die täglichen Berichtsdateien aus Ihrem Haupt-Posteingang heraus.
Wie viele DMARC-Einträge kann eine Domain haben?
Einen pro Name, bei _dmarc.ihredomain. Subdomains können einen eigenen Eintrag haben oder die Richtlinie der übergeordneten Domain über sp erben.
Zusammenfassung
- DMARC ist ein TXT-Eintrag bei _dmarc.ihredomain, der mit v=DMARC1 beginnt.
- RFC 9989 (Mai 2026) ist die aktuelle Spezifikation; er löst RFC 7489 ab und entfernt pct.
- Beginnen Sie bei p=none mit einer rua-Adresse und lesen Sie etwa einen Monat lang die Berichte.
- Dann p=quarantine für einen ähnlichen Zeitraum, dann p=reject.
- Eine Nachricht besteht, wenn SPF oder DKIM besteht und zur From-Domain passt; relaxed Alignment ist der Standard.
- Eine Domain mit p=reject darf sich nicht allein auf SPF verlassen und sollte nicht mit Mailinglisten genutzt werden.
- Postelva hostet den Eintrag im kostenlosen DNS; eine .com kostet jedes Jahr 12,49 $/Jahr.
Quellen (6)
- RFC 9989, Domain-based Message Authentication, Reporting, and Conformance (DMARC) — RFC Editor (abgelesen am 2026-11-12)
- RFC 7489, DMARC (abgelöst) — RFC Editor (abgelesen am 2026-11-12)
- SPF, DKIM und DMARC für eine eigene Domain — Mailbox.org (abgelesen am 2026-11-12)
- Eigene Domain und Schutz vor Spoofing — Proton (abgelesen am 2026-11-12)
- Richtlinien für Absender von E-Mails — Google Workspace Admin Help (abgelesen am 2026-11-12)
- E-Mail-Sicherheit stärken: neue Anforderungen an Absender mit hohem Volumen — Microsoft Tech Community (abgelesen am 2026-11-12)