Was ist DMARC? Alignment, Richtlinien und die RFCs von 2026

Was ist DMARC? Es ist ein DNS-Datensatz, der Mailempfängerservern mitteilt, was sie tun sollen, wenn eine Nachricht deine Domain im From-Header beansprucht, aber die Authentifizierung fehlschlägt, und wohin die Berichte darüber gesendet werden. DMARC authentifiziert selbst nichts. Es überprüft, dass SPF oder DKIM bestanden haben und dass die Domain, die sie validiert haben, mit der Domain übereinstimmt, die der Leser sieht.

Diese Übereinstimmung wird Alignment genannt, und dort schlagen die meisten Teams fehl. Eine Nachricht kann SPF bestehen, DKIM bestehen und trotzdem DMARC nicht bestehen.

DMARC ist eine Richtlinienebene über SPF und DKIM

SPF listet auf, welche IPs eine Domain versenden darf. DKIM signiert die Nachricht, damit ein Empfänger überprüfen kann, dass sie nicht verändert wurde und dass die signierende Domain sie genehmigt hat. Keiner von beiden schaut auf die From-Adresse, die ein Mensch liest.

DMARC schließt diese Lücke. Es stellt eine Frage: Stimmt die Domain im sichtbaren From-Header mit der Domain überein, die SPF oder DKIM bestanden haben? Wenn ja, passiert die Nachricht. Wenn nein, wendet der Empfänger deine Richtlinie an.

Der Datensatz befindet sich bei _dmarc.yourdomain.com als TXT-Datensatz. Ein minimaler, gültiger Datensatz sieht so aus:

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

Drei Tags machen die echte Arbeit. p ist die Richtlinie, rua ist, wohin Aggregatberichte gehen, und adkim / aspf legen fest, wie streng das Alignment ist. Alles andere ist optional.

Alignment ist, wo gute Setups fehlschlagen

SPF authentifiziert den Envelope-Absender, die Return-Path-Domain. DKIM authentifiziert die Domain im d=-Tag der Signatur. DMARC benötigt mindestens eine davon, um die From-Domain zu entsprechen, entweder exakt (streng) oder auf Organisationsdomäne-Ebene (gelockert, Standard).

Hier ist der Fehler, den wir am häufigsten in Traces sehen. Ein Team sendet über einen Drittanbieter, der Anbieter signiert mit seiner eigenen Domain (d=provider-mail.net) und verwendet seine eigene Bounce-Domain. SPF passiert, DKIM passiert, und DMARC schlägt fehl, weil keine Domain example.com entspricht.

Die Lösung ist eine benutzerdefinierte Versanddomain: ein DKIM-Schlüssel, der unter deiner Domain veröffentlicht ist, und idealerweise ein benutzerdefinierter Return-Path auf einer Subdomain. Jeder seriöse Provider unterstützt das. Wenige aktivieren es standardmäßig.

Die drei Richtlinien: none, quarantine, reject

Das p-Tag hat drei Werte, und sie sind nicht eine Leiter, die du nach Zeitplan erklimmst.

• p=none: Der Empfänger liefert normal aus und sendet dir Berichte. Nutze das für die ersten 2 bis 4 Wochen, während du Absender erfasst.

• p=quarantine: Der Empfänger leitet Fehler zu Spam oder Junk. Nutze das, sobald Berichte zeigen, dass alle legitimen Quellen übereinstimmen.

• p=reject: Der Empfänger lehnt Fehler auf der SMTP-Stufe ab. Nutze das, sobald Quarantine einen vollen Versandzyklus ohne Fehler durchlaufen hat.

p=none ist Monitoring, nicht Schutz. Eine Domain, die zwei Jahre bei none sitzt, hat ein Compliance-Häkchen und keine Spoofing-Abwehr. Überspringe die Versuchung, sie dort zu lassen, weil „nichts kaputt ging".

p=reject ist das Ziel für jede Domain, die nur E-Mails versendet, die du kontrollierst. Domains mit starkem Mailing-List-Verkehr oder Legacy-Weiterleitungen brauchen mehr Sorgfalt, da Weiterleitungen oft SPF unterbrechen und DKIM unterbrechen können, wenn der Vermittler den Body ändert.

Warum die Gmail- und Yahoo-Regeln das dringend gemacht haben

Seit Februar 2024 verlangen Googles Absender-Richtlinien, dass jeder, der mehr als 5.000 Nachrichten pro Tag an Gmail-Konten versendet, einen DMARC-Datensatz mit SPF und DKIM veröffentlicht. Die Richtlinie kann none sein. Google bittet Massenabsender auch, die von Benutzern gemeldete Spam-Quote im Postmaster-Tool unter 0,30% zu halten und empfiehlt, unter 0,10% zu bleiben.

Yahoos Sender Hub erklärt die gleiche Kernanforderung: ein gültiger DMARC-Richtlinie von mindestens p=none, mit der From-Domain, die mit der SPF- oder DKIM-Domain übereinstimmt. Gelockerte Ausrichtung ist akzeptabel.

Beachte, was in diesen Regeln ist und was nicht. Die Anforderung ist ein veröffentlichter Datensatz und passendes Alignment, nicht Durchsetzung. Das ist ein Boden. Es ist nicht das Ziel.

Aggregatberichte sind das Produkt, die Richtlinie ist der Schalter

Die rua-Adresse empfängt tägliche XML-Berichte von jedem Empfänger, der DMARC einhält. Jeder Report listet Quell-IPs, Nachrichtenzählen, die SPF- und DKIM-Ergebnisse und ob das Alignment galt. So findest du den vergessenen Absender: den alten CRM-Export, das Abrechnungstool, das ein Unternehmer 2022 verdrahtet hat, die Marketing-Form auf einer Subdomain, die niemand besitzt.

Rohes XML ist bei großem Volumen unlesbar. Leite rua zu einem Postfach weiter, das ein Parser aufnehmen kann, oder zu einem gehosteten DMARC-Reporting-Dienst, und schau dir die nach Quelle gruppierten Daten an. Du möchtest sehen, dass jede legitime Quelle zu 100% übereinstimmt und alles andere eindeutig unbekannt ist.

Ein praktisches Rollout verläuft in dieser Reihenfolge:

1. Veröffentliche p=none mit einer rua-Adresse.

2. Sammle zwei bis vier Wochen lange Berichte. Erstelle das Absender-Inventar.

3. Behebe jede legitime nicht übereinstimmende Quelle mit einer benutzerdefinierten DKIM-Domain oder Return-Path.

4. Wechsle zu p=quarantine. Beobachte Support-Tickets über fehlende E-Mails.

5. Wechsle zu p=reject, wenn Quarantine keine legitimen Fehler zeigt.

Versende jeden Schritt separat. Eine Richtlinienänderung und das Hinzufügen eines neuen Versandanbieters in der gleichen Woche machen jede Regression unmöglich zuzuordnen.

DMARCbis ändert die Tags, nicht deinen Datensatz

2026 veröffentlichte die IETF RFC 9989, RFC 9990 und RFC 9991, die RFC 7489 ersetzen. RFC 9989 ist die Kern-DMARC-Spezifikation. Aggregate Reporting und Failure Reporting zogen in ihre eigenen Dokumente um.

Die praktischen Änderungen für einen Datensatzbesitzer sind klein:

• pct, rf und ri werden entfernt.

• t (Testmodus) ersetzt pct als All-oder-Nichts-Schalter: t=y meldet ohne Durchsetzung.

• np legt eine Richtlinie für nicht vorhandene Subdomains fest, die Spoofing von Adressen wie abc123.example.com blockiert.

• psd markiert Public-Suffix-Domains, und ein DNS-Tree-Walk ersetzt die alte Public Suffix List-Suche.

Vorhandene v=DMARC1-Datensätze bleiben gültig. Nichts bricht, wenn du heute nichts änderst. Die Provider-Unterstützung für die neuen Tags wird ungleichmäßig ausgerollt, also bedeutet ein neuer Tag, der nichts zu tun scheint, normalerweise, dass der Empfänger ihn noch nicht implementiert hat.

Das np-Tag lohnt sich, früh zu übernehmen. Das Setzen von np=reject, während p noch none ist, schließt den Fake-Subdomain-Missbrauchspfad, ohne den Rest deiner E-Mails an Durchsetzung zu verpflichten.

Subdomains und warum der Standard erbt

Ein DMARC-Datensatz auf der Organisationsdomain gilt auch für Subdomains, sofern du ihn nicht mit sp überschreibst. Diese Vererbung ist nützlich und auch eine Falle.

Wenn Marketing von news.example.com durch einen separaten Provider versendet, erbt es die Parent-Richtlinie. Verschieben Sie die Parent zu p=reject, bevor dieser Provider DKIM ausgerichtet hat und der Newsletter fällt auf den Boden. Veröffentliche einen separaten _dmarc.news.example.com-Datensatz, wenn eine Subdomain ihre eigene Absender-Flotte hat und ihr eigenes Rollout-Tempo.

Eine sauberere Architektur trennt Streams von Anfang an nach Subdomain. Transaktionale E-Mails auf eine, Lifecycle auf eine andere, menschliche E-Mails auf die Root. Jede hat ihre eigenen DKIM-Schlüssel, ihren eigenen Ruf und ihren eigenen DMARC-Datensatz.

Lesen Sie den Authentication-Results-Header, bevor Sie raten

Wenn eine Nachricht fehlschlägt, zeichnet der Empfängerserver auf, warum. Bei Gmail macht „Original anzeigen" den Authentication-Results-Header zugänglich, und er sagt dir mehr als jedes Dashboard.

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=bounce.provider-mail.net;
  dkim=pass header.d=provider-mail.net;
  dmarc=fail (p=NONE) header.from=example.com

Lies von links nach rechts. SPF ist für bounce.provider-mail.net erfolgreich. DKIM ist für provider-mail.net erfolgreich. DMARC schlägt fehl, weil der From-Header example.com sagt und keine dieser Domains stimmt überein.

Der (p=NONE)-Hinweis zeigt die Richtlinie, die der Empfänger sah. Bei none wurde diese Nachricht trotzdem geliefert. Bei reject würde sie mit einem 5.7.x-Fehler abgelehnt, und der Absender würde es von einem Kunden erfahren.

Zwei Checks fangen die meisten dieser Fälle. Bestätigen Sie, dass der Wert header.d im DKIM-Ergebnis deine Domain ist. Bestätigen Sie dann, dass die Domain smtp.mailfrom deine Domain oder eine Subdomain davon ist.

SPF hat ein Lookup-Limit, das DMARC offenbart

SPF erlaubt zehn DNS-Lookups pro Bewertung. Jedes include: für einen Provider verbraucht einige davon, und verschachtelte Includes verbrauchen mehr. Über zehn gehen und SPF gibt einen permanenten Fehler zurück, der als Fehler zählt.

Teams mit fünf oder sechs Versand-Tools treffen das, ohne es zu bemerken, weil SPF-Fehler vor DMARC-Reporting unsichtbar waren. Sobald rua-Berichte eintreffen, ist das Muster offensichtlich: eine Quelle schlägt plötzlich SPF über alle Empfänger an dem Tag fehl, an dem jemand ein anderes include: hinzugefügt hat.

Das ist ein weiterer Grund, sich auf DKIM-Alignment als primären Pfad zu verlassen. DKIM überlebt die meisten Weiterleitungen, hat kein Lookup-Budget und ist an die Nachricht gebunden, nicht an die verbindende IP. Halten Sie SPF gültig, bauen Sie aber nicht Ihren DMARC-Pass nur darauf auf.

Was DMARC nicht tut

DMARC verhindert exakte Domain-Spoofing. Es stoppt keine Look-alike-Domains (examp1e.com), es urteilt nicht über Inhalte und behebt nicht schlechten Sender-Ruf. Eine perfekt übereinstimmende Domain, die an gekaufte Listen sendet, landet trotzdem im Spam.

Es ersetzt auch nicht Monitoring. Alignment kann lautlos brechen: Eine DNS-Änderung entfernt einen DKIM-Selector, ein Provider rotiert Schlüssel, ein neues Tool beginnt zu versenden, ohne dass du es weißt. Berichte zeigen dir, bevor deine Benutzer es herausfinden.

Behandele den DMARC-Datensatz wie jede andere Produktionskonfiguration. Er gehört zur Versionskontrolle, Änderungen gehen durch Überprüfung, und die rua-Mailbox braucht einen Besitzer.

Vor der Veröffentlichung des Datensatzes

Läuft ein Mal durch. Es dauert unter einer Stunde für eine einzelne Domain.

• Listet jedes System auf, das E-Mails als deine Domain versendet: Produkt, Abrechnung, Support-Desk, CRM, Marketing, Kalendereinladungen.

• Bestätigen Sie, dass jedes mit deiner Domain signiert DKIM nutzt, nicht das des Anbieters.

• Legen Sie einen benutzerdefinierten Return-Path fest, wo der Provider es zulässt.

• Wählen Sie ein rua-Ziel aus, das jemand lesen wird.

• Beginnen Sie mit p=none, und tragen Sie das Datum ein, an dem Sie es überprüfen möchten, in den Kalender ein.

• Überprüfen Sie die Spam-Rate wöchentlich im Google Postmaster Tool während des Rollouts.

Wo man von hier aus geht

Wenn Sie sich Ihre Berichte noch nie angesehen haben, veröffentlichen Sie p=none mit einer rua-Adresse heute und lesen Sie, was in zwei Wochen ankommt. Der erste Bericht nennt fast immer mindestens einen Absender, den niemand erinnerte. Der nächste konkrete Schritt besteht darin, zu entscheiden, welche davon du behältst.