DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC legt im DNS fest, was Empfänger mit Mails tun sollen, deren sichtbarer Absender weder per SPF noch per DKIM bestätigt ist, und fordert Berichte an.

So funktioniert’s

Der DMARC-Record ist ein TXT-Record unter _dmarc vor der Domain, etwa _dmarc.example.com mit v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com. Beschrieben ist das Verfahren in RFC 7489.

Eine Mail besteht DMARC, wenn SPF oder DKIM besteht und die dabei geprüfte Domain zur sichtbaren From-Adresse passt (Alignment). Im Standardmodus genügt dieselbe Organisationsdomain, mit adkim=s bzw. aspf=s muss die Domain exakt übereinstimmen.

Die Policy p= sagt, was mit Mails passiert, die durchfallen: none heißt nur beobachten, quarantine in den Spam-Ordner, reject ablehnen. Mit sp= gilt für Subdomains eine eigene Policy, mit pct= nur für einen Anteil der Mails; hat eine Subdomain keinen eigenen Record, gilt der der Hauptdomain.

Über rua schicken dir Empfänger wie Google und Microsoft täglich Aggregatberichte im XML-Format: welche IP-Adressen in deinem Namen gesendet haben, wie viele Mails und mit welchem SPF- und DKIM-Ergebnis. Erst mit diesen Daten lässt sich die Policy gefahrlos verschärfen.

Warum gefährlich

Ohne DMARC oder mit p=none entscheidet jeder Empfänger selbst, was er mit einer gefälschten Mail im Namen deiner Domain macht, und nicht selten landet sie im Posteingang. Phishing mit der echten Absenderadresse eines Kunden braucht dann keinen technischen Aufwand. Gmail und Yahoo verlangen von Absendern mit mehr als 5.000 Mails am Tag einen DMARC-Record.

Umgekehrt trifft eine zu früh verschärfte Policy echte Mails: Steht p=reject, bevor Newsletter-Dienst, CRM und Shop mit der eigenen Domain signieren, weisen Empfänger genau diese Mails ab. Mehrere DMARC-Records auf einer Domain führen dazu, dass Empfänger alle ignorieren.

So vermeidest du es

  1. Mit v=DMARC1; p=none und einer rua-Adresse starten und die Berichte einige Wochen auswerten.
  2. Jeden legitimen Absender aus den Berichten mit DKIM auf der eigenen Domain oder einer passenden Rücklaufadresse ausstatten.
  3. Die Policy schrittweise auf p=quarantine und dann p=reject anheben, bei Bedarf mit pct in Stufen.
  4. sp nicht schwächer als p setzen, damit Subdomains kein Schlupfloch werden.
  5. Domains ohne Mailversand direkt mit p=reject und v=spf1 -all absichern.
  6. Pro Domain nur einen DMARC-Record pflegen.

So erkennt DomainWarn es

Der DMARC-Check fragt _dmarc der Domain ab und prüft Syntax, Policy, pct, Berichtsadresse und Subdomain-Policy. Ein fehlender Record eröffnet schon nach einem Lauf den Incident „DMARC fehlt“, mehrere Records sind kritisch. p=none, p=quarantine, pct unter 100, eine fehlende rua-Adresse und eine schwächere Subdomain-Policy sind Hinweise, Syntaxfehler wie eine fehlende oder ungültige Policy Warnungen. Wird die Policy abgeschwächt, meldet die Änderungserkennung das als kritische Änderung.

Für Subdomains ohne eigenen Record zeigt DomainWarn die geerbte Policy der Hauptdomain an. Mit der Berichtsadresse von DomainWarn in rua landen die Aggregatberichte direkt im Dashboard; der DMARC-Assistent leitet daraus ab, wann der nächste Schritt Richtung p=reject sicher ist, und setzt ihn mit verbundenem DNS-Anbieter nach Bestätigung um.

DomainWarn prüft das für alle deine Domains regelmäßig und meldet sich, wenn etwas fehlt oder sich ändert.

Diese Domain dauerhaft überwachen14 Tage kostenlos testen, keine Kreditkarte.

Weiterlesen

Alle Begriffe