DMARC-Record-Builder

Der DMARC Record Builder erstellt Domain-based Message Authentication, Reporting, and Conformance (DMARC) DNS-Records über eine interaktive Oberfläche, die Sie durch alle verfügbaren Richtlinien-Tags führt. Wählen Sie eine Richtlinie wie p=reject, konfigurieren Sie Berichtsadressen und erhalten Sie einen vollständigen Record wie v=DMARC1; p=reject; rua=mailto:[email protected], der unter _dmarc.ihredomain.com veröffentlicht werden kann.

DMARC verstehen

DMARC ist die Richtlinienebene, die SPF und DKIM zu einem kohärenten E-Mail-Authentifizierungssystem verbindet. Für sich allein prüft SPF, ob der sendende Server autorisiert ist. Für sich allein verifiziert DKIM, dass die Nachricht nicht manipuliert wurde. Aber keiner von beiden teilt empfangenden Servern mit, was bei fehlgeschlagenen Prüfungen zu tun ist, und keiner verlangt, dass die authentifizierte Domain mit der Domain im From-Header übereinstimmt, den Benutzer tatsächlich sehen. DMARC schließt beide Lücken: Es definiert eine Richtlinie für den Umgang mit Fehlern und erfordert Domain-Alignment, wodurch es Angreifern deutlich schwerer gemacht wird, Ihre Domain in Phishing-Kampagnen zu fälschen.

Wenn Sie einen DMARC-Record veröffentlichen, teilen Sie jedem empfangenden Mailserver im Internet drei Dinge mit: wie Nachrichten behandelt werden sollen, die sowohl SPF- als auch DKIM-Prüfungen nicht bestehen (ignorieren, in Quarantäne stellen oder ablehnen), wohin Berichte über Authentifizierungsergebnisse gesendet werden sollen, damit Sie überwachen können, was passiert, und wie streng die authentifizierten Domains mit Ihrer From-Header-Domain übereinstimmen müssen. Ohne DMARC kann ein Phisher eine E-Mail senden, die SPF und DKIM für Ihre Domain nicht besteht, aber der empfangende Server hat keine Richtlinie, die ihn anweist, die Nachricht abzulehnen -- er könnte sie trotzdem annehmen und im Posteingang des Empfängers landen lassen.

Der andere große Vorteil von DMARC ist das Reporting. Wenn Sie eine rua-Adresse festlegen, senden Ihnen empfangende Server tägliche XML-Berichte, die jeden Nachrichten zusammenfassen, der als von Ihrer Domain stammend empfangen wurde, zusammen mit den SPF- und DKIM-Ergebnissen für jeden einzelnen. Diese Berichte enthüllen nicht autorisierte Absender, von denen Sie nichts wussten -- ob es Phisher sind, die Ihre Domain missbrauchen, legitime Dienste, die Sie vergessen haben in Ihren SPF-Record aufzunehmen, oder Weiterleitungsserver, die die Authentifizierung brechen. Diese Transparenz ist unerlässlich, bevor Sie Ihre Richtlinie verschärfen, denn der Wechsel zu p=reject ohne Verständnis Ihres E-Mail-Ökosystems wird mit ziemlicher Sicherheit einige legitime E-Mails blockieren.

So erstellen Sie einen DMARC-Record

1. Wählen Sie Ihre Richtlinie (p=): none zur Überwachung, quarantine für den Spam-Ordner oder reject zum Blockieren von Fehlern
2. Setzen Sie optional eine Subdomain-Richtlinie (sp=), wenn Subdomains anders behandelt werden sollen
3. Legen Sie den Prozentsatz (pct=) fest, um die Richtlinie schrittweise durchzusetzen (z. B. mit 10 % beginnen)
4. Geben Sie die Aggregatbericht-E-Mail-Adresse (rua=) ein, um tägliche XML-Berichte zu erhalten
5. Geben Sie optional die forensische Bericht-E-Mail-Adresse (ruf=) für einzelne Fehlerberichte ein
6. Konfigurieren Sie Alignment-Modi (aspf=, adkim=) für striktes oder lockeres Matching
7. Kopieren Sie den generierten Record und veröffentlichen Sie ihn als TXT-Record unter _dmarc.ihredomain.com

DMARC-Record-Beispiele

DMARC-Tag-Referenz

Wann Sie den DMARC Record Builder verwenden sollten

• Start der E-Mail-Authentifizierung bei einer Domain ohne bestehende DMARC-Richtlinie
• Schrittweise DMARC-Einführung -- Wechsel von p=none zu quarantine zu reject über Wochen hinweg
• Konfiguration des DMARC-Reportings, um Transparenz darüber zu gewinnen, wer E-Mails als Ihre Domain versendet
• Festlegen separater Subdomain-Richtlinien, wenn Subdomains unterschiedliche E-Mail-Anforderungen haben
• Prüfung der Alignment-Einstellungen, um zwischen striktem und lockerem Matching für SPF und DKIM zu entscheiden
• Erfüllung von Compliance-Anforderungen, die DMARC-Durchsetzung vorschreiben (PCI DSS, NIST, behördliche Vorgaben)

Wie die DMARC-Authentifizierung funktioniert

Der Authentifizierungsablauf

Wenn ein empfangender Server eine E-Mail von Ihrer Domain erhält, wertet er DMARC in dieser Reihenfolge aus:

1. SPF prüfen: Stimmt die sendende IP mit dem SPF-Record überein? Stimmt die RFC5321.MailFrom-Domain mit der From-Header-Domain überein?
2. DKIM prüfen: Gibt es eine gültige DKIM-Signatur? Stimmt die signierende Domain (d=) mit der From-Header-Domain überein?
3. DMARC anwenden: Wenn entweder SPF oder DKIM besteht und aligned ist, besteht DMARC. Wenn beide fehlschlagen oder keines aligned ist, wird die DMARC-Richtlinie angewendet.

Lockeres vs. striktes Alignment

• Locker (aspf=r, adkim=r): Die authentifizierte Domain und die From-Domain müssen dieselbe Organisationsdomain teilen. Beispiel: mail.example.com aligned mit example.com.
• Strikt (aspf=s, adkim=s): Die authentifizierte Domain muss exakt mit der From-Domain übereinstimmen. mail.example.com aligned nicht mit example.com.

Lockeres Alignment ist der Standard und für die meisten Organisationen geeignet. Striktes Alignment bietet stärkeren Schutz, kann aber legitime E-Mail-Flüsse von Subdomains unterbrechen.

Empfohlene Einführungsstrategie

Woche 1-2:  v=DMARC1; p=none; rua=mailto:[email protected]
            -> Berichte überwachen, alle legitimen Absender identifizieren

Woche 3-4:  v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]
            -> 10 % der Fehler in Quarantäne, auf False Positives achten

Woche 5-6:  v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected]
            -> Auf 50 % erhöhen

Woche 7-8:  v=DMARC1; p=reject; pct=25; rua=mailto:[email protected]
            -> Beginnen, 25 % der Fehler abzulehnen

Woche 9+:   v=DMARC1; p=reject; rua=mailto:[email protected]
            -> Vollständige Durchsetzung

DMARC-Bereitstellung in der Praxis

Das größte Risiko bei der DMARC-Bereitstellung ist ein zu schneller Wechsel zu p=reject. Viele Organisationen veröffentlichen einen DMARC-Record mit p=none, sammeln ein oder zwei Wochen Berichte und springen dann direkt zu p=reject, weil die Berichte sauber aussehen. Das Problem ist, dass einige legitime E-Mail-Flüsse nur periodisch auftreten -- monatliche Newsletter, vierteljährliche Rechnungsbenachrichtigungen, jährliche Verlängerungserinnerungen -- und möglicherweise in einem kurzen Berichtszeitraum nicht erscheinen. Das pct-Tag existiert genau für dieses Szenario: Es ermöglicht Ihnen, Ihre Richtlinie nur auf einen Prozentsatz der fehlgeschlagenen Nachrichten anzuwenden, sodass Sie Probleme im Maßstab erkennen können, ohne alle Ihre E-Mails zu blockieren, falls etwas schiefgeht.

Eine häufige Überraschung bei der DMARC-Bereitstellung ist die Entdeckung, wie viele Dienste E-Mails in Ihrem Namen versenden. Marketing sendet über Mailchimp, Support-Tickets kommen von Zendesk, Rechnungen laufen über QuickBooks, Passwort-Resets kommen von Auth0 und Systemwarnungen werden über PagerDuty geroutet. Jeder dieser Dienste muss entweder SPF bestehen (durch Aufnahme in Ihren SPF-Record) oder DKIM bestehen (durch Signierung mit einem Schlüssel, der zu Ihrer Domain aligned ist). Die p=none-Überwachungsphase ist Ihre Gelegenheit, all diese Dienste zu identifizieren, bevor die Durchsetzung beginnt. Nutzen Sie die Aggregatberichte, um ein vollständiges Inventar Ihrer E-Mail-Versanddienste aufzubauen.

Die Subdomain-Richtlinie (sp=) verdient sorgfältige Überlegung. Standardmäßig erben Subdomains die Richtlinie der übergeordneten Domain. Wenn Sie p=reject auf example.com setzen, gilt es auch für mail.example.com, app.example.com und jede andere Subdomain. Wenn einige Subdomains E-Mails über eine andere Infrastruktur senden oder noch nicht für DKIM konfiguriert sind, setzen Sie sp=none oder sp=quarantine, um sich Spielraum zu geben, die Subdomain-Authentifizierung getrennt von der Hauptdomain zu bearbeiten.

Häufig gestellte Fragen

Wo veröffentliche ich den DMARC-Record im DNS?

DMARC-Records werden immer als TXT-Record unter _dmarc.ihredomain.com veröffentlicht. Wenn Ihre Domain beispielsweise example.com ist, gehört der Record zu _dmarc.example.com. Dies ist ein fester Speicherort, der durch die DMARC-Spezifikation definiert ist -- es gibt keine Flexibilität bei der Benennung.

Was ist der Unterschied zwischen rua- und ruf-Berichten?

Das rua-Tag gibt an, wohin Aggregatberichte gesendet werden -- dies sind tägliche XML-Zusammenfassungen, die Authentifizierungsergebnisse für alle Nachrichten zeigen. Das ruf-Tag gibt forensische Berichte an -- detaillierte Berichte über einzelne Nachrichten, die die Authentifizierung nicht bestanden haben. Viele Anbieter unterstützen aufgrund von Datenschutzbedenken bei forensischen Daten nur Aggregatberichte. Beginnen Sie nur mit rua; fügen Sie ruf hinzu, wenn Sie eine detaillierte Fehleruntersuchung benötigen.

Kann ich DMARC-Berichte an eine E-Mail-Adresse auf einer anderen Domain senden?

Ja, aber die empfangende Domain muss einen DNS-Autorisierungsrecord veröffentlichen. Wenn Ihre Domain example.com ist und Berichte an [email protected] gehen, muss monitor.com einen TXT-Record unter example.com._report._dmarc.monitor.com mit dem Wert v=DMARC1 veröffentlichen. Dies verhindert Missbrauch, bei dem jemand einen DMARC-Record veröffentlicht, der eine Flut von Berichten an eine beliebige E-Mail-Adresse leitet.

Was bedeutet pct=25 in der Praxis?

Es bedeutet, dass nur 25 % der Nachrichten, die DMARC nicht bestehen, der Richtlinie unterworfen werden. Die anderen 75 % werden behandelt, als wäre die Richtlinie none (überwacht, aber nicht behandelt). Empfangende Server verwenden diesen Prozentsatz probabilistisch. Dies ermöglicht es Ihnen, die Durchsetzung schrittweise hochzufahren und die Auswirkungen zu beobachten, bevor Sie zur vollständigen Durchsetzung bei pct=100 übergehen (was der Standard ist, wenn pct weggelassen wird).

Wie lese ich DMARC-Aggregatberichte?

DMARC-Aggregatberichte sind XML-Dateien, die mit gzip oder zip komprimiert sind. Sie enthalten Daten über jede von Ihrer Domain empfangene Nachricht: sendende IP, SPF-Ergebnis, DKIM-Ergebnis und die Disposition (none, quarantine oder reject). Das Lesen von rohem XML ist in großem Umfang unpraktisch. Die meisten Administratoren verwenden einen DMARC-Berichtsdienst, der das XML parst und Dashboards präsentiert, die Authentifizierungs-Bestanden/Fehlgeschlagen-Raten, nicht autorisierte Absender und Alignment-Probleme anzeigen.

Beeinflusst DMARC die E-Mail-Weiterleitung?

Ja. E-Mail-Weiterleitung ist eine der größten Herausforderungen bei der DMARC-Durchsetzung. Wenn eine Nachricht von einem Vermittler weitergeleitet wird (z. B. einer Mailingliste oder einer Universitäts-Alumni-Weiterleitungsadresse), ändert sich die sendende IP, was SPF bricht. Wenn der Weiterleitende die Nachricht auch modifiziert (Fußzeile hinzufügen, Betreff ändern), bricht auch DKIM. Mit p=reject wird die weitergeleitete Nachricht vom Server des endgültigen Empfängers abgelehnt. Lösungen umfassen ARC (Authenticated Received Chain), das einige Empfänger unterstützen, um die Authentifizierung durch Weiterleitung zu erhalten.

Verwandte Tools

• SPF Record Builder - SPF-Records mit korrekter Syntax erstellen
• SPF Record Length Checker - SPF-Record-Länge und Lookup-Limits prüfen
• DKIM TXT Record Formatter - DKIM-Records mit korrekter Quotierung formatieren
• DNS Record Set Deduper - Doppelte DNS-Records finden und entfernen
• Zone File Linter - Zonendateien auf Syntaxfehler und Duplikate prüfen