# Was ist DMARC? Alignment, Richtlinien und die RFCs von 2026 URL: https://notificationharbor.com/de/journal/was-ist-dmarc Type: blog Locale: de Published: 2026-09-29 Updated: 2026-09-29 --- > DMARC teilt Mailservern mit, was sie mit E-Mails tun sollen, die deine Domain beanspruchen aber fehlschlagen. Hier erfährst du wie. 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. ![Engineer reviewing DNS records in a terminal on a laptop at a desk](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/f76a50-inline1.webp) 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. ![Lowered customs barrier at a harbor container yard at dusk](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/4a2947-inline3.webp) ## 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: - Veröffentliche `p=none` mit einer `rua`-Adresse. - Sammle zwei bis vier Wochen lange Berichte. Erstelle das Absender-Inventar. - Behebe jede legitime nicht übereinstimmende Quelle mit einer benutzerdefinierten DKIM-Domain oder Return-Path. - Wechsle zu `p=quarantine`. Beobachte Support-Tickets über fehlende E-Mails. - 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. ![Cream envelope being sealed with a red wax stamp](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/f3aca9-inline2.webp) ## 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. ## FAQ ### Ist DMARC erforderlich? Für Massenversand effektiv ja. Google verlangt einen DMARC-Datensatz für Absender von mehr als 5.000 Nachrichten pro Tag an Gmail, und Yahoo verlangt eine gültige Richtlinie von mindestens p=none. Erzwingung ist nicht erforderlich, aber der Datensatz und das Alignment sind erforderlich. ### Was bedeutet p=none in DMARC? Das bedeutet Monitoring. Empfänger liefern fehlgeschlagene E-Mails normal aus und senden dir Berichte. Es erfüllt das Gmail- und Yahoo-Minimum, bietet aber keinen Schutz vor Spoofing. ### Kann eine E-Mail SPF und DKIM bestehen und trotzdem DMARC nicht bestehen? Ja. DMARC erfordert, dass die Domain, die von SPF oder DKIM validiert wurde, mit der From-Header-Domain übereinstimmt. E-Mails, die über einen Provider versendet werden, der mit seiner eigenen Domain signiert, bestehen beide Checks und scheitern trotzdem beim Alignment. ### Wie lange sollte ich bei p=none bleiben? Typischerweise zwei bis vier Wochen Aggregatberichte, lange genug, um jeden legitimen Absender zu sehen, einschließlich solcher mit niedrigem Volumen. Wechseln Sie, sobald jede legitime Quelle als übereinstimmend angezeigt wird. ### Beeinflusst DMARC die Zustellbarkeit? Indirekt. Ein veröffentlichter, übereinstimmender Datensatz ist eine Grundanforderung bei Gmail und Yahoo, und fehlgeschlagenes Alignment kann E-Mails in Spam verschieben oder eine Ablehnung unter einer erzwingenden Richtlinie auslösen. Sie behebt nicht schlechten Sender-Ruf oder hohe Beschwerdequoten. ### Was hat sich mit DMARCbis und RFC 9989 geändert? RFC 9989 ersetzt RFC 7489. Es entfernt pct, rf und ri, fügt t, np und psd hinzu und ersetzt Public Suffix List-Lookups durch einen DNS-Tree-Walk. Vorhandene v=DMARC1-Datensätze bleiben gültig.