Begriff · DMARC-Check

Wie führen Sie einen DMARC-Check für Anwendungs-E-Mails durch?

Ein DMARC-Check sollte vier getrennte Dinge prüfen: ob sich im DNS eine gültige Richtlinie finden lässt, ob ihre Pflicht-Tags korrekt geparst werden, ob bei einer echten Nachricht mindestens eine per SPF oder DKIM authentifizierte Kennung mit der sichtbaren From-Domain ausgerichtet ist und ob vor der Durchsetzung jeder legitime Absender der Anwendung erfasst ist. Fragen Sie den _dmarc-Namen ab, prüfen Sie den Eintrag und untersuchen Sie dann die Authentifizierungsergebnisse kontrollierter Sendungen. Ein bestandener DMARC-Check bestätigt die autorisierte Nutzung der Domain; er belegt weder die Zustellung noch die Platzierung im Posteingang.

Einen DMARC-Check als vier Tests behandeln, nicht als einen Lookup

Ein aussagekräftiger Check hat vier Ebenen. Erstens: Ermitteln Sie die Richtlinie, die für die Autorendomain der Nachricht gilt. Zweitens: Validieren Sie den TXT-Eintrag als DMARC-Richtlinie, statt jeden Text zu akzeptieren, den das DNS zurückgibt. Drittens: Testen Sie das Alignment der Kennungen an einer tatsächlichen Nachricht – die per SPF authentifizierte MAIL-FROM-Domain oder eine verifizierte DKIM-Signaturdomain muss mit der Domain im sichtbaren From-Header ausgerichtet sein. Viertens: Bestätigen Sie die betriebliche Abdeckung, indem Sie über jede legitime Anwendung, jeden Provider, jede Region und jede Nachrichtenklasse senden, die die Domain nutzt. Ein grüner DNS-Lookup deckt nur einen Teil der ersten beiden Ebenen ab. Er kann nicht zeigen, ob ein Provider mit der vorgesehenen Domain signiert, ob ein eigener Return-Path aktiv ist, ob Weiterleitungen das SPF-Verhalten verändert haben oder ob ein übersehenes System eine Durchsetzungsrichtlinie übersteht.

Den richtigen DNS-Namen abfragen und der Richtlinienermittlung folgen

Beginnen Sie mit der exakten Domain im From-Header nach RFC5322, oft Autorendomain genannt. Fragen Sie TXT unter _dmarc, gefolgt von dieser Domain, ab. Bei einer Nachricht von alerts@notify.example.test beginnen Sie bei _dmarc.notify.example.test und nicht beim Website-Host, MX-Host oder der Return-Path-Domain. RFC 9989 definiert die Richtlinienermittlung über einen einzelnen Lookup hinaus: Hat die Autorendomain keinen gültigen Eintrag, kann ein Empfänger den DNS-Baum durchlaufen, um die zutreffende Richtlinie der Organisationsdomain oder des Public Suffix zu finden. Die Behandlung von Subdomains kann sich aus dem sp-, np- oder p-Tag ergeben – je nachdem, was vorhanden ist und wo die Richtlinie gefunden wird. Ein Checker sollte deshalb sowohl den abgefragten Namen als auch die tatsächlich gewählte Richtliniendomain melden. Ein Ergebnis, das lediglich „Eintrag gefunden“ meldet, kann Vererbungsfehler oder eine explizite Subdomain-Richtlinie verbergen, die die erwartete Behandlung ändert.

Die Struktur des Eintrags prüfen, bevor Sie die Richtlinie interpretieren

Ein DMARC-Richtlinieneintrag verwendet Tag-Wert-Syntax. Nach RFC 9989 ist v=DMARC1 erforderlich, unterscheidet Groß- und Kleinschreibung und muss zuerst stehen; ein gültiges p-Tag liefert die angeforderte Bewertungsrichtlinie. Übliche Richtlinienwerte sind none, quarantine und reject. Optionale Tags beschreiben Berichtsziele, Subdomain-Verhalten sowie striktes oder gelockertes SPF- und DKIM-Alignment. Korrigieren Sie falsch geschriebene Tags, fehlende p-Werte, doppelte oder widersprüchliche Einträge, ungültige Trennzeichen oder Werte mit DNS-Provider-Anführungsartefakten nicht stillschweigend. Behandeln Sie einen permanenten Auswertungsfehler als Ergebnis, das korrigiert werden muss, nicht als DMARC-Pass oder -Fail. Unterscheiden Sie außerdem einen vorübergehenden DNS-Lookup-Fehler von einem fehlerhaften Eintrag. Wiederholen Sie einen vorübergehenden Resolver-Fehler über einen kontrollierten Pfad, behaupten Sie aber nicht, die Domain habe keine Richtlinie, bevor autoritatives DNS zuverlässig abgefragt werden kann.

SPF- und DKIM-Alignment an einer echten Nachricht prüfen

DMARC wird anhand der Authentifizierung der Nachricht ausgewertet, nicht anhand der DNS-Konfiguration für sich allein. Vergleichen Sie bei SPF die authentifizierte MAIL-FROM-Domain mit der sichtbaren From-Domain. Vergleichen Sie bei DKIM die d=-Domain jeder erfolgreich verifizierten Signatur mit der sichtbaren From-Domain. Relaxed Alignment akzeptiert Domains mit derselben Organisationsdomain; strict Alignment verlangt identische Domains. Eine Nachricht besteht DMARC, wenn mindestens eine authentifizierte Kennung ihren zugrunde liegenden Mechanismus besteht und ausgerichtet ist. So kann zum Beispiel ein Return-Path des Providers SPF für die Domain des Providers bestehen lassen, aber nicht mit billing.example.test ausgerichtet sein. Wird DKIM bei relaxed Alignment mit d=example.test verifiziert, kann die Nachricht DMARC trotzdem bestehen. Erfassen Sie den rohen Authentication-Results-Header aus kontrollierten Empfängerkonten, interpretieren Sie ihn aber im Kontext, denn er gibt das Ergebnis des auswertenden Empfängers wieder und kann mehrere Hops oder Signaturen enthalten.

Die Ergebnisse pass, fail, none und error genau lesen

Ein DMARC-Pass bedeutet, dass eine Richtlinie gilt und ein authentifizierter SPF- oder DKIM-Identifier mit der Autor-Domain ausgerichtet ist. Ein Fail bedeutet, dass eine Richtlinie gilt, aber kein ausgerichteter authentifizierter Identifier existiert. None bedeutet, dass keine anwendbare Richtlinie gefunden wurde. Permerror und temperror bezeichnen Fehler bei der DMARC-Auswertung; eine Nachricht mit DNS-Fehler kann nicht als DMARC-Pass oder -Fail gelten. Diese Ergebnisse sagen nichts darüber aus, wo der Postfachanbieter die Nachricht abgelegt hat. RFC 9989 beschränkt einen Pass ausdrücklich auf die Validierung, dass die Nutzung durch den Domaininhaber autorisiert war; er behauptet nicht, dass die Nachricht sicher, erwünscht, reputabel oder für den Posteingang geeignet ist. Führen Sie Provider-Annahme, Empfänger-Server-Annahme, DMARC-Ergebnis, Beschwerdesignale und beobachtete Platzierung als getrennte Felder in Diagnosen und Dashboards.

Vor der Durchsetzung jeden legitimen Absender erfassen

Erfassen Sie alle Systeme, die die Domain in From verwenden: Produktivanwendungen, Authentifizierungs-E-Mails, Zahlungshinweise, Support-Tools, Marketingplattformen, Monitoring-Warnungen, CRM-Workflows, regionale Konten und Notfallsysteme. Halten Sie für jeden Stream die sichtbare From-Domain, die MAIL-FROM-Domain, die DKIM-Domain d= mit Selektor, das Provider-Konto, den Verantwortlichen, die Nachrichtenklasse und das erwartete Volumen fest. Senden Sie kontrollierte Nachrichten über den normalen Produktivweg und prüfen Sie sowohl Authentifizierung als auch Alignment. DMARC-Aggregatberichte können Quellen aufdecken, die die Domain nutzen, müssen aber interpretiert werden und können Weiterleitungen oder nicht autorisierten Traffic enthalten. Beginnen Sie mit Monitoring, solange die Bestandsaufnahme unvollständig ist, und beheben Sie legitime, nicht ausgerichtete Streams, bevor Sie eine strengere Behandlung durch die Empfänger anfordern. Ändern Sie keine gemeinsam genutzte Organisationsrichtlinie, nur damit eine einzelne Anwendung grün wird, und wechseln Sie nicht auf Basis einer einzigen Testnachricht zur Durchsetzung.

Häufige Fehler bei Anwendungs-E-Mails diagnostizieren

Wird keine Richtlinie gefunden, prüfen Sie die DNS-Zone und den Eintragsnamen, bevor Sie den Wert bearbeiten. Hat der Eintrag einen permanenten Fehler, reduzieren Sie ihn auf eine einzige gültige Richtlinie und prüfen Sie Reihenfolge und Syntax der Tags. Schlägt DKIM fehl, prüfen Sie, ob der erwartete Selektor existiert, ob der Provider die getestete Nachricht tatsächlich signiert hat, ob sich der Body oder signierte Header unterwegs verändert haben und ob die verifizierte d=-Domain ausgerichtet ist. Besteht SPF, aber DMARC schlägt fehl, vergleichen Sie die MAIL-FROM-Domain mit der sichtbaren From-Domain, statt jedes SPF-pass als ausreichend anzusehen. Schlagen nur weitergeleitete E-Mails fehl, bedenken Sie, dass Weiterleitungen oft den Envelope-Pfad ändern und SPF brechen können, während eine gültige, ausgerichtete DKIM-Signatur erhalten bleiben kann. Führt ein Rollout zu Ablehnungen, sichern Sie die fehlschlagenden Header und die Antwort des Empfängers, stoppen Sie jede weitere Verschärfung der Richtlinie und beheben Sie den verantwortlichen Stream, statt unbeteiligte Authentifizierungskontrollen abzuschwächen.

Provider-spezifische Alignment-Regeln bewusst anwenden

Drittanbieter-Absender benötigen eine Konfiguration, die ihre authentifizierten Kennungen an eine Domain bindet, die die Organisation kontrolliert. Amazon SES dokumentiert zwei Wege: eine ausgerichtete eigene MAIL-FROM-Domain für SPF und eine ausgerichtete DKIM-Signaturdomain. Der standardmäßige, dem Provider gehörende Return-Path kann per SPF authentifizieren, ohne mit der sichtbaren From-Domain ausgerichtet zu sein. Daher ist DKIM oft der praktikable ausgerichtete Mechanismus, sofern keine eigene MAIL-FROM-Domain konfiguriert ist. Andere Provider verwenden andere Bezeichnungen für Return-Paths, Bounce-Domains, Domain-Authentifizierung und Signaturidentitäten. Prüfen Sie die tatsächlich ausgegebene Nachricht, statt anzunehmen, dass ein „Verifiziert“-Badge im Dashboard DMARC herstellt. Auch die aktuellen Absenderrichtlinien von Gmail verlangen Authentifizierung und Alignment für den betroffenen Traffic und empfehlen DMARC-Berichte. Anforderungen von Empfängern und Funktionen von Providern können sich ändern; prüfen Sie deren offizielle Dokumentation daher beim Launch und bei der Aufarbeitung von Vorfällen erneut.

Provider-Belege verwenden, ohne sie als DMARC-Urteil zu behandeln

SendHQ unterstützt Versand über verifizierte Domains, Zustell-Events, Sperrlisten und ein Web-Dashboard. Verwenden Sie Informationen zur Versanddomain und Zustellung, um einen Nachrichtenstrom zu untersuchen; prüfen Sie DMARC dann anhand des Headers Authentication-Results des Empfängers und trennen Sie SPF-, DKIM- und Alignment-Belege. Provider-Annahme und Zustell-Events beweisen keine Platzierung im Posteingang.

Ein nachprüfbares Ergebnis des DMARC-Checks festhalten

Ein belastbares Ergebnis sollte Folgendes enthalten: die Autorendomain, den Abfragezeitpunkt, den Resolver, den abgefragten _dmarc-Namen, die gewählte Richtliniendomain, den exakten normalisierten Eintrag, die Richtlinien- und Alignment-Modi, den DNS-Status und ob das Parsen eine gültige Syntax, permerror oder temperror ergeben hat. Ergänzen Sie pro kontrollierter Nachricht eine Zeile mit einer nicht sensiblen Nachrichtenkennung, dem sendenden System, der sichtbaren From-Domain, der authentifizierten SPF-Domain mit Ergebnis, den verifizierten DKIM-Domains mit Selektoren, den Alignment-Entscheidungen, dem finalen DMARC-Ergebnis und dem Empfänger. Bewahren Sie rohe Header in einem zugriffsbeschränkten Speicher auf, da sie Adressen, Routing-Details und interne Kennungen offenlegen können. Verknüpfen Sie jeden Befund mit einem Verantwortlichen und einem Behebungsdatum. Prüfen Sie erneut, wenn DNS-TTLs abgelaufen sind, sich die Provider-Konfiguration ändert, Schlüssel rotiert werden, neue Nachrichten-Streams hinzukommen oder die Richtlinie verschärft wird. Mit diesen Nachweisen ist der Check reproduzierbar, und ein Screenshot oder ein Tool-Badge wird nicht zum dauerhaften Beleg, nachdem sich die zugrunde liegende Konfiguration geändert hat.

Häufig gestellte Fragen

Wo sollte ein DMARC-Eintrag geprüft werden?

Beginnen Sie mit TXT unter _dmarc plus der exakten Domain der sichtbaren From-Adresse. Ermitteln Sie außerdem die Richtliniendomain, die nach den aktuellen DMARC-Ermittlungsregeln gewählt wird, denn eine Richtlinie der Organisationsdomain oder einer Subdomain kann greifen, wenn der zuerst abgefragte Name keinen gültigen Eintrag hat.

Bedeutet ein gefundenes v=DMARC1, dass DMARC besteht?

Nein. Er ist nur ein Bestandteil eines gültigen Richtlinieneintrags. Eine Nachricht besteht DMARC erst, wenn SPF oder DKIM mit einer Domain authentifiziert, die mit der sichtbaren From-Domain ausgerichtet ist. Testen Sie eine echte Nachricht und prüfen Sie die Authentifizierungsergebnisse des Empfängers.

Kann DMARC bestehen, wenn SPF nicht ausgerichtet ist?

Ja. Eine erfolgreich verifizierte DKIM-Signatur kann die ausgerichtete authentifizierte Kennung liefern, die DMARC benötigt. Umgekehrt geht es auch: Ausgerichtetes SPF kann ein pass ermöglichen, wenn DKIM das nicht tut – wer sich nur auf einen Mechanismus verlässt, verringert allerdings die Ausfallsicherheit.

Belegt ein bestandener DMARC-Check die Platzierung im Posteingang?

Nein. Er bestätigt die autorisierte Nutzung der Autorendomain für diese Nachricht. Ein Empfänger kann beim Annehmen, Ablehnen, Quarantänisieren oder Kategorisieren der Nachricht weiterhin Signale zu Reputation, Inhalt, Empfängern, Missbrauch und lokalen Richtlinien anwenden.

Sollte eine Anwendung direkt auf p=reject wechseln?

Üblicherweise nicht ohne Bestands- und Monitoring-Belege. Ordnen Sie jeden legitimen Absender zu, validieren Sie das Alignment an kontrollierten Nachrichten, prüfen Sie Aggregatberichte, beheben Sie Fehler und stimmen Sie Richtlinienänderungen mit dem Domaininhaber ab, bevor Sie eine strengere Behandlung beantragen.

Was sollte nach einem Wechsel des E-Mail-Providers erneut geprüft werden?

Prüfen Sie erneut die für jede From-Domain ermittelte Richtlinie, die MAIL-FROM- und DKIM-Domains des Providers, das DNS der Selektoren, die SPF- und DKIM-Ergebnisse, relaxed oder strict Alignment, die Aggregatberichte und jede kontrollierte Nachrichtenklasse der Anwendung, bevor Sie den produktiven Traffic erhöhen.

Quellen