DMARC legt fest, wie Mailserver mit E-Mails umgehen sollen, die angeblich von Ihrer Domain stammen, sich aber nicht als echt ausweisen können. Hier beantworten wir die häufigsten Fragen – durchgehend nach dem aktuellen Standard RFC 9989 vom Mai 2026.

Welcher DMARC-Eintrag passt zu Ihrer Domain?

Für Eilige vorab die Kurzantwort. Die Einträge werden als TXT-Record unter _dmarc.example.com erfasst. Die Hintergründe erklären wir in den Antworten weiter unten.

Was ist DMARC und was bringt es mir?

DMARC steht für "Domain-based Message Authentication, Reporting and Conformance". Das Verfahren schützt die Absenderadresse, die Ihre Empfänger im Mailprogramm tatsächlich sehen: die Domain im "From"-Header einer E-Mail. Genau diese Adresse fälschen Betrüger bei Phishing-Mails am liebsten.

DMARC erfüllt drei Aufgaben:

• Prüfen: Der empfangende Mailserver kontrolliert anhand von SPF und DKIM, ob eine E-Mail wirklich im Auftrag Ihrer Domain versendet wurde.
• Anweisen: Sie legen fest, was mit E-Mails geschehen soll, welche die Prüfung nicht bestehen – nichts, Quarantäne (z.B. Spam-Ordner) oder Ablehnung.
• Berichten: Mailserver weltweit schicken Ihnen Berichte, wer in Ihrem Namen E-Mails versendet. So erkennen Sie Missbrauch und eigene Konfigurationsfehler.

Wichtig zu wissen: Ihre Richtlinie ist ein Wunsch, kein Befehl. Die endgültige Entscheidung über eine E-Mail trifft immer der empfangende Mailserver. Die meisten grossen Anbieter berücksichtigen DMARC aber in ihren Filtern.

DMARC ist seit Mai 2026 als offizieller IETF-Standard in RFC 9989 spezifiziert. Die Berichte sind in den begleitenden Standards RFC 9990 (aggregierte Berichte) und RFC 9991 (Fehlerberichte) beschrieben.

Wann besteht eine E-Mail die DMARC-Prüfung?

SPF und DKIM prüfen je eine Domain, die der Empfänger nicht sieht:

• SPF prüft die Domain der Envelope-Adresse (MAIL FROM, auch "Return-Path" genannt), an die Unzustellbarkeitsmeldungen gehen.
• DKIM prüft die Domain, die im d=-Tag der digitalen Signatur steht.

Beide Verfahren können bestehen, obwohl im sichtbaren Absender eine ganz andere Domain steht. Deshalb verlangt DMARC zusätzlich eine Übereinstimmung, das sogenannte Alignment: Eine E-Mail besteht die DMARC-Prüfung, wenn mindestens eines der beiden Verfahren erfolgreich ist und dessen Domain zur Domain im "From"-Header passt.

Wie genau "passt" zu verstehen ist, bestimmen Sie mit den Tags adkim und aspf:

Die letzte Zeile ist der häufigste Grund für DMARC-Fehler in der Praxis: Ein externes Newsletter- oder CRM-Tool signiert mit seiner eigenen Domain. DKIM besteht zwar, DMARC trotzdem nicht. Die Lösung ist eine Signatur mit Ihrer eigenen Domain – am saubersten über eine eigene (Sub-)Domain mit Full Alignment.

RFC 9989 empfiehlt, beide Verfahren einzusetzen. Für eine vollständige DMARC-Teilnahme sollten Ihre E-Mails also sowohl ein passendes SPF- als auch ein passendes DKIM-Ergebnis liefern. Fällt eines davon unterwegs weg (z.B. SPF bei einer Weiterleitung), besteht die E-Mail dank des anderen trotzdem.

Wo und wie wird der DMARC-Eintrag veröffentlicht?

Der DMARC-Eintrag ist ein TXT-Record in der DNS-Zone Ihrer Domain, und zwar unter dem Namen _dmarc. In einer Zonendatei sieht das so aus:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Beim Aufbau gelten ein paar feste Regeln:

• v=DMARC1 muss zwingend das erste Tag sein, exakt in dieser Schreibweise. Sonst wird der ganze Eintrag ignoriert.
• Die weiteren Tags werden mit Semikolon getrennt, ihre Reihenfolge ist beliebig. Unbekannte Tags werden ignoriert.
• Pro Name darf es nur einen DMARC-Eintrag geben. Findet ein Mailserver mehrere, verwirft er alle – Ihre Domain ist dann ungeschützt.
• Lange Einträge dürfen auf mehrere Zeichenketten verteilt werden. Der Mailserver fügt sie vor der Auswertung wieder zusammen.
• Fehlt das Tag p oder ist es ungültig, behandelt der Empfänger den Eintrag wie p=none, sofern eine gültige Berichtsadresse (rua) vorhanden ist. Ohne gültige Berichtsadresse findet gar keine DMARC-Verarbeitung statt.

Welche Tags kennt der DMARC-Eintrag?

RFC 9989 definiert die folgenden Tags. Ausser v sind alle optional; p wird aber dringend empfohlen.

Die drei Richtlinien im Detail

• none: Sie äussern keinen Wunsch. Empfänger dürfen ihre Zustellung aufgrund dieser Richtlinie nicht verändern. Das ist der reine Beobachtungsmodus ("Monitoring Mode").
• quarantine: Sie stufen nicht bestandene E-Mails als verdächtig ein. Typischerweise landen sie im Spam-Ordner.
• reject: Sie betrachten nicht bestandene E-Mails als klaren Missbrauch. Der Empfänger soll sie bereits bei der Einlieferung ablehnen.

Die Optionen für Fehlerberichte (fo)

• 0: Bericht, wenn keines der Verfahren ein passendes positives Ergebnis liefert.
• 1: Bericht, sobald eines der Verfahren kein passendes positives Ergebnis liefert.
• d: Bericht bei jeder fehlgeschlagenen DKIM-Signatur, unabhängig vom Alignment.
• s: Bericht bei jedem SPF-Fehlschlag, unabhängig vom Alignment.

Welche Richtlinie gilt für Subdomains?

Nicht jede Subdomain braucht einen eigenen DMARC-Eintrag. Der empfangende Mailserver sucht die passende Richtlinie in dieser Reihenfolge:

1. Eigener Eintrag: Gibt es einen Eintrag direkt für die Absenderdomain (z.B. _dmarc.news.example.com), gilt dessen p.
2. Eintrag der Organisationsdomain: Sonst geht der Mailserver die DNS-Hierarchie nach oben (der Standard nennt das "DNS Tree Walk"), bis er den Eintrag der Organisationsdomain findet, z.B. _dmarc.example.com. Für eine existierende Subdomain gilt dann sp, für eine nicht existierende np. Fehlen diese Tags, gilt p.
3. Eintrag der Top-Level-Domain: In seltenen Fällen veröffentlicht auch der Betreiber einer Top-Level-Domain einen Eintrag mit psd=y. Dieser greift nur, wenn Ihre Domain selbst keinen Eintrag hat.

Eine Subdomain gilt als nicht existent, wenn das DNS für sie mit NXDOMAIN antwortet. Sobald für eine Subdomain irgendein DNS-Eintrag existiert – auch nur ein TXT-Record –, gilt sie als existent und sp kommt zum Zug. Mit np=reject verhindern Sie also, dass frei erfundene Subdomains wie zahlung.example.com für Phishing missbraucht werden.

Beachten Sie: sp und np wirken nur im Eintrag der Organisationsdomain. In einem Eintrag, der direkt auf einer Subdomain liegt, werden sie ignoriert.

Für grosse Organisationen mit dezentral verwalteten Zonen gibt es zudem psd=n: Damit erklärt sich eine Subdomain (z.B. eines Tochterunternehmens) selbst zur Organisationsdomain und erhält eigene Richtlinien und Berichtsadressen. Da der DNS Tree Walk aus Sicherheitsgründen auf acht Abfragen begrenzt ist, benötigen Absenderdomains mit sehr vielen Labels in jedem Fall einen eigenen Eintrag.

Wie führe ich DMARC ein, ohne eigene E-Mails zu verlieren?

Das grösste Risiko bei DMARC sind nicht Angreifer, sondern vergessene eigene Versandquellen. Gehen Sie deshalb in Etappen vor:

1. Inventar erstellen: Listen Sie alle Systeme auf, die mit Ihrer Domain als Absender E-Mails verschicken – Mailserver, Newsletter-Tool, CRM, Ticketsystem, Buchhaltung, Kontaktformulare der Website, Onlineshop, Kopierer mit Scan-to-Mail.
2. SPF und DKIM ausrichten: Jede dieser Quellen muss SPF und/oder DKIM mit Ihrer eigenen Domain bestehen.
3. Beobachten: Richten Sie ein Postfach für die Berichte ein und veröffentlichen Sie p=none mit rua. Ihre E-Mail-Zustellung ändert sich dadurch nicht.
4. Auswerten und korrigieren: Die Berichte zeigen Ihnen jede Quelle, die im Namen Ihrer Domain versendet. Legitime Quellen, welche die Prüfung nicht bestehen, müssen gemäss RFC 9989 korrigiert werden, bevor Sie verschärfen. Je nach Versandrhythmus (z.B. Jahresrechnungen) kann das mehrere Monate dauern.
5. Verschärfung testen: Setzen Sie p=quarantine zusammen mit t=y. Der Testmodus bittet die Empfänger, eine Stufe milder zu verfahren – also none statt quarantine bzw. quarantine statt reject. Die Berichte laufen normal weiter.
6. Schützen: Entfernen Sie t=y. Ab jetzt wirkt Ihre Richtlinie vollständig.
7. Optional weiter verschärfen: Ob sich danach p=reject lohnt, erklären wir in der nächsten Antwort.

Wann ist p=reject die richtige Wahl?

p=reject klingt nach maximalem Schutz, hat aber Nebenwirkungen. RFC 9989 knüpft die strengste Stufe deshalb an klare Bedingungen:

• DKIM ist Pflicht: Wer p=reject veröffentlicht, darf sich nicht allein auf SPF verlassen und muss alle E-Mails mit DKIM signieren. Bei Weiterleitungen (z.B. von einer Alumni- oder Vereinsadresse) geht das SPF-Ergebnis verloren, die DKIM-Signatur bleibt in der Regel erhalten.
• Mailinglisten beachten: Domains, deren Nutzer an Mailinglisten teilnehmen, sollen kein p=reject veröffentlichen. Mailinglisten verändern E-Mails häufig so, dass die Prüfung scheitert. Wer es trotzdem tun möchte, soll zuerst mindestens einen Monat p=none und danach gleich lange p=quarantine betreiben und die Berichte vergleichen.
• Keine Garantie: Empfänger dürfen E-Mails nicht allein wegen p=reject ablehnen, sondern sollen weitere Kriterien einbeziehen. Ohne solche Zusatzinformationen behandeln sie die E-Mail wie bei p=quarantine.

Für eine normale Geschäftsdomain mit Mitarbeitenden ist p=quarantine deshalb meist die richtige Endstufe. p=reject eignet sich für Domains mit rein kontrolliertem Versand (z.B. eine Subdomain nur für Rechnungen oder Newsletter) und für Domains, die gar keine E-Mails versenden.

Welche Berichte erhalte ich und was steht darin?

DMARC kennt zwei Arten von Berichten:

• Aggregierte Berichte (rua, RFC 9990): Zusammenfassungen im XML-Format, die Mailserver in der Regel täglich verschicken. Sie enthalten keine Inhalte, sondern pro absendender IP-Adresse die Anzahl E-Mails sowie die Ergebnisse von SPF, DKIM und DMARC. Diese Berichte sind das wichtigste Werkzeug bei der Einführung. Wie man sie auswertet, beschreiben wir im Blog-Artikel DMARC-Reports.
• Fehlerberichte (ruf, RFC 9991): Meldungen zu einzelnen E-Mails, welche die Prüfung nicht bestanden haben. Weil sie Teile der E-Mail und damit Personendaten enthalten können, verschicken die meisten Anbieter aus Datenschutzgründen keine oder nur stark gekürzte Fehlerberichte.

Ohne rua erhalten Sie keine Berichte. Sie dürfen mehrere Adressen angeben; der Standard empfiehlt Mailservern, an jede Adresse zu senden.

Berichte an einen externen Dienst

Liegt die Berichtsadresse auf einer anderen Domain (z.B. bei einem DMARC-Auswertungsdienst), muss diese Domain den Empfang ausdrücklich erlauben. Sonst könnte jeder beliebige Domains mit Berichten fluten. Der Dienst veröffentlicht dazu einen TXT-Record nach folgendem Muster:

example.com._report._dmarc.example.net.  IN  TXT  "v=DMARC1;"

Seriöse Anbieter richten diesen Eintrag automatisch ein. Fehlt er, bleiben die Berichte aus.

Wie prüfe ich, ob DMARC funktioniert?

1. Ist der Eintrag veröffentlicht?

Unter macOS und Linux im Terminal:

dig +short TXT _dmarc.example.com

Unter Windows in der Eingabeaufforderung:

nslookup -type=TXT _dmarc.example.com

Die Antwort muss genau einen Eintrag enthalten, der mit v=DMARC1 beginnt. Alternativ prüfen Sie Ihre Domain online, z.B. mit dmarcchecker.app.

2. Besteht eine echte E-Mail die Prüfung?

Senden Sie eine E-Mail an ein Postfach bei einem anderen Anbieter und öffnen Sie dort die Kopfzeilen (Quelltext) der Nachricht. Der empfangende Server vermerkt das Ergebnis in der Kopfzeile Authentication-Results. Entscheidend ist dmarc=pass. Steht dort dmarc=fail, obwohl dkim=pass oder spf=pass gemeldet wird, fehlt das Alignment: Die geprüfte Domain passt nicht zum Absender.

3. Bestehen alle Quellen?

Einzelne Test-E-Mails zeigen nur einen Versandweg. Ob wirklich alle Quellen korrekt eingerichtet sind, sehen Sie erst in den aggregierten Berichten über mehrere Wochen.

Was gilt für Domains ohne E-Mail-Versand?

Gerade Domains, die nie E-Mails versenden (z.B. reservierte Markendomains oder reine Website-Domains), sind für Betrüger attraktiv, weil dort niemand hinschaut. Schliessen Sie sie deshalb mit drei Einträgen ab:

• MX IN MX 0 . – die Domain empfängt keine E-Mails
• SPF IN TXT "v=spf1 -all" – kein Server darf für die Domain versenden
• DMARC IN TXT "v=DMARC1; p=reject" – nicht bestandene E-Mails sollen abgelehnt werden

Ein separates np ist hier nicht nötig: Fehlt es, gilt p=reject auch für nicht existierende Subdomains. Weitere Empfehlungen finden Sie im Blog-Artikel DNS-Sicherheit.

Mein Eintrag enthält noch pct, rf oder ri – was nun?

Diese drei Tags sind nicht mehr Teil des Standards und sollten aus bestehenden Einträgen entfernt werden:

• pct=100: Einfach löschen, es entspricht dem normalen Verhalten.
• pct=0: Durch t=y ersetzen. Der Testmodus übernimmt genau diese Funktion.
• Andere pct-Werte: Löschen und bewusst eine Stufe wählen. Prozentwerte wurden von den Mailservern sehr unterschiedlich umgesetzt und waren deshalb nie verlässlich.
• rf und ri: Ersatzlos löschen. Aggregierte Berichte kommen in der Regel täglich.

Welche Fehler sollte ich vermeiden?

• Zwei DMARC-Einträge: Mehrere TXT-Records mit v=DMARC1 unter _dmarc heben sich gegenseitig auf. Ergänzen Sie immer den bestehenden Eintrag.
• Direkt mit Schutzstufe starten: Ohne vorherige Auswertung der Berichte landen legitime E-Mails aus vergessenen Quellen im Spam-Ordner oder werden abgelehnt.
• Ewig bei p=none bleiben: Der Beobachtungsmodus liefert wertvolle Berichte, schützt aber vor keiner einzigen gefälschten E-Mail.
• Berichte nie lesen: Ein rua-Postfach, das niemand auswertet, verschenkt den grössten Nutzen von DMARC.
• Zu grosszügige SPF-Einträge: Jeder Server, der in Ihrem SPF-Eintrag steht, kann ein DMARC-"pass" für Ihre Domain erzeugen. Nehmen Sie nur Server auf, die wirklich für Sie versenden. Müssen Sie einen geteilten Dienst mit vielen Kunden aufnehmen, können Sie ihn mit dem Qualifier ? (z.B. ?include:_spf.example.net) von der DMARC-Bewertung ausnehmen.
• Subdomains aus der Hand geben: Wer die SPF- oder DKIM-Einträge einer Subdomain kontrolliert, kann bei relaxed Alignment E-Mails erzeugen, welche die DMARC-Prüfung für Ihre Hauptdomain bestehen. Delegieren Sie Subdomains nur an vertrauenswürdige Stellen oder verwenden Sie strict Alignment.
• SPF mit -all unterschätzen: Manche Mailserver lehnen E-Mails mit SPF-Fehlschlag bereits ab, bevor DMARC überhaupt geprüft wird. Solche E-Mails erscheinen nie in Ihren Berichten, auch wenn sie dank DKIM eigentlich bestanden hätten.

Wovor schützt DMARC nicht?

• Ähnliche Domains: DMARC schützt nur exakt Ihre Domain. Gegen Nachahmungen mit vertauschten Buchstaben, Zusätzen wie "-support" oder einer anderen Domain-Endung hilft es nicht.
• Gefälschte Anzeigenamen: Ein Absender wie "Ihre Firma AG" <info@example.net> besteht DMARC problemlos, weil nur die Domain der Adresse geprüft wird.
• Unerwünschte Inhalte: Ein DMARC-"pass" bestätigt nur, dass die Domain berechtigt verwendet wurde. Ob eine E-Mail erwünscht oder ungefährlich ist, sagt es nicht aus.
• Manipuliertes DNS: DMARC, SPF und DKIM verlassen sich auf korrekte DNS-Antworten. Mit DNSSEC schützen Sie Ihre Einträge vor Fälschungen.

Wie unterstützt Actra Sie bei DMARC?

In den von uns verwalteten DNS-Zonen hinterlegen wir standardmässig einen DMARC-Eintrag mit p=quarantine. Gerne prüfen wir Ihre bestehende Konfiguration, richten SPF und DKIM für all Ihre Versandquellen ein und begleiten Sie bei der schrittweisen Einführung.

Kontaktieren Sie uns für eine unverbindliche Beratung.

Quellen

• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9990: DMARC Aggregate Reporting
• RFC 9991: DMARC Failure Reporting