DMARC ist ein TXT-Eintrag unter _dmarc.<your domain>. Er teilt Empfangsservern mit, was sie mit E-Mails tun sollen, die deine Domain im From-Header tragen, aber weder SPF noch DKIM mit Alignment bestehen, und wohin sie Reports schicken sollen. p=none fordert nur Reports an, p=quarantine bittet Empfangsserver, durchgefallene E-Mails als verdächtig zu behandeln, und p=reject bittet sie, diese abzulehnen.

Gmail, Yahoo und Microsoft akzeptieren p=none von Bulk-Sendern. Viele Domains veröffentlichen deshalb diese Richtlinie und belassen es dabei: Sie erhalten Reports über Spoofer, blockieren sie aber nicht. Eine Analyse von Red Sift über 73,3 Millionen Domains, zitiert im April 2026, ergab, dass 14,9 % überhaupt eine DMARC-Richtlinie hatten und 2,5 % p=reject durchsetzten. EasyDMARC, ein weiterer DMARC-Anbieter, berichtete 2025, dass 62,7 % der Fortune-500-Unternehmen mit DMARC p=reject nutzten, gegenüber 15,2 % der Unternehmen aus der Inc. 5000.

Hier ist ein 30-Tage-Plan bis p=reject, Eintrag für Eintrag, für eine Domain, die über Workspace-Mail, ein oder zwei ESPs, einen Helpdesk und ein Abrechnungstool versendet. Dreißig Tage passen für eine Versand-Subdomain. Eine Domain, über die deine Mitarbeitenden ihre alltäglichen E-Mails schreiben, braucht länger.

Das Wichtigste in Kürze

• Veröffentliche an Tag 1 v=DMARC1; p=none; rua=mailto:.... Ohne rua dürfen Empfangsserver keine aggregierten Reports senden.
• Jeder legitime Absender muss SPF oder DKIM mit Alignment zu deiner From-Domain bestehen. Bei den meisten Tools heißt das: DKIM-Signatur mit deiner Domain.
• Beschränke SPF auf höchstens 10 Terme mit DNS-Abfrage, verschachtelte Includes mitgezählt, sonst bekommen alle deine E-Mails permerror.
• Wechsle an Tag 15 zu p=quarantine und an Tag 22 zu p=reject, jeweils nach einer Woche mit sauberen Reports. Für eine Domain, die deine Mitarbeitenden für alltägliche E-Mails nutzen, verlangt RFC 9989 für jede der ersten beiden Stufen einen Monat.
• RFC 9989 (Mai 2026) stuft pct als historisch ein. Verzichte auf die Rampe mit pct=10 und pct=50.
• BIMI braucht p=quarantine oder p=reject auf der Organisationsdomain, kein sp=none, ein Logo im Format SVG Tiny PS und für Gmail ein VMC oder CMC.

Was sich 2026 bei DMARC geändert hat

Im Mai 2026 hat die IETF RFC 7489, ein Informational-Dokument von 2015, durch DMARCbis ersetzt: RFC 9989, einen Proposed Standard, der auch RFC 9091 ablöst, dazu RFC 9990 für das aggregierte Reporting. Drei Änderungen sind hier wichtig:

• pct ist historisch. Laut Anhang A.6 wurde es „meist nicht korrekt angewendet, es sei denn, der angegebene Wert war entweder 0 oder 100“.
• t=y ersetzt pct=0. Empfangsserver wenden eine Stufe unterhalb deiner Richtlinie an, p=reject; t=y wirkt also wie quarantine. Es ist ein Testschalter.
• np ist neu. Es gilt für Subdomains, die im DNS nicht existieren, und ältere Empfangsserver müssen es ignorieren.

Außerdem ersetzt ein Durchlauf durch den DNS-Baum (DNS Tree Walk) die Public Suffix List, wenn es darum geht, die Organisationsdomain zu bestimmen.

Die drei Einträge, auf denen DMARC aufbaut

DMARC ist bestanden, wenn SPF oder DKIM besteht und die dabei geprüfte Domain zur From-Domain passt (Alignment). Ein bestandener Check mit Alignment reicht.

SPF und das Limit von 10 Lookups

SPF autorisiert Server für die Envelope-Domain (MAIL FROM oder Return-Path). Das ist die einzige Identität, die DMARC heranzieht, nicht HELO. RFC 7208, Abschnitt 4.6.4 begrenzt Terme mit DNS-Abfrage auf 10: include, a, mx, ptr, exists und redirect, gezählt über alle verschachtelten Includes hinweg. ip4, ip6 und all kosten nichts. Wird das Limit überschritten, lautet das Ergebnis permerror. Derselbe Abschnitt erlaubt außerdem höchstens zwei „Void Lookups“, meist ein Include für einen Hostnamen, den es nicht mehr gibt.

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:_spf.helpdesk.example include:mail.billing.example ~all"

Das verbraucht schon 4 Lookups, bevor du mitzählst, was jeder Anbieter verschachtelt. Löse deshalb jeden Eintrag mit dig +short TXT <name> die ganze Kette hinunter auf. Um das Limit von 10 einzuhalten, entferne nicht mehr genutzte Tools oder gib jedem ESP eine eigene Return-Path-Subdomain wie bounce.example.com, mit einem eigenen Budget von 10. Microsofts Anleitung zur SPF-Einrichtung empfiehlt, auf Domains, die auch DKIM und DMARC nutzen, mit -all abzuschließen.

Viele ESPs verwenden standardmäßig ihre eigene Return-Path-Domain, die nicht zu deiner passt. Richte einen eigenen Return-Path ein oder verlass dich auf DKIM.

DKIM: 2048-Bit-Schlüssel, Selektoren und Rotation

DKIM signiert jede Nachricht mit einer Domain d= und einem Selektor s=. Der Empfangsserver holt den Schlüssel von <selector>._domainkey.<d domain>. Ein Tool, das mit d=vendor-mail.example signiert, besteht DKIM, fällt aber bei DMARC durch.

Laut RFC 8301 müssen Signierende RSA-Schlüssel mit mindestens 1024 Bit verwenden und sollten 2048 Bit nutzen. Googles Richtlinien für Absender sagen dasselbe für E-Mails an private Gmail-Konten. Ein 2048-Bit-Schlüssel überschreitet das Limit von 255 Zeichen pro TXT-String. Er wird deshalb als mehrere Strings in Anführungszeichen in einem einzigen Eintrag hinterlegt, und die meisten DNS-Hoster teilen ihn für dich auf.

s202610._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1x..."
    "...remainder-of-the-2048-bit-key...IDAQAB" )

Gib jedem versendenden System einen eigenen Selektor und verwende einen Namen nie zweimal. Ein Datum wie s202610 hält die Historie lesbar. Laut den Best Practices der M3AAWG zur Schlüsselrotation solltest du mindestens alle sechs Monate rotieren:

1. Veröffentliche den neuen Selektor und warte, bis er sich verbreitet hat.
2. Stell die Signatur auf den neuen Schlüssel um.
3. Lass den alten öffentlichen Schlüssel 7 bis 30 Tage im DNS, damit E-Mails, die noch unterwegs sind, verifiziert werden können.
4. Leg den alten Selektor mit einem leeren p= still. Lösch ihn nicht.

Alignment: relaxed oder strict

RFC 9989 definiert zwei Modi:

RFC 9989 hält fest, dass „fast alle Domain-Inhaber Relaxed Alignment für ausreichend befunden haben“. Lass aspf und adkim weg. Striktes SPF-Alignment verträgt sich nicht mit dem üblichen Return-Path auf einer Subdomain.

Der 30-Tage-Plan

Der Eintrag für jede Stufe. Geh erst nach einer Woche mit sauberen Reports zur nächsten über.

Wenn in Woche 2 eine Quelle auftaucht, die niemand reparieren kann, bleib bei p=none. Deine eigenen Rechnungen abzulehnen ist schlimmer, als spät durchzusetzen.

Tag 1 bis 7: p=none mit Reporting veröffentlichen

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

Reports kommen als gzip-komprimiertes XML, mindestens einmal täglich von jedem Empfangsserver. Richte rua deshalb auf einen Auswertungsdienst, nicht auf eine Person. Liegt die Adresse auf einer anderen Organisationsdomain, ignorieren Empfangsserver sie laut RFC 9990, es sei denn, example.com._report._dmarc.<report domain> autorisiert sie. Auswertungsdienste veröffentlichen diesen Eintrag, für deine eigenen Domains legst du ihn selbst an.

Veröffentliche genau einen DMARC-Eintrag. Wenn Einrichtungsassistenten zwei v=DMARC1-Einträge unter _dmarc.example.com hinterlassen, verwerfen Empfangsserver beide.

Verzichte auf ruf. Laut RFC 9989 schwärzen datenschutzbewusste Empfangsserver Failure-Reports stark oder senden sie gar nicht, und laut der FAQ in Microsofts Ankündigung für Versender mit hohem Volumen sendet Microsoft rua-Reports und plant nicht, ruf zu senden.

So liest du einen aggregierten Report

RFC 9990 beschreibt XML-Reports, die „täglich (oder häufiger)“ kommen, einen pro Domain mit DMARC-Richtlinie. Hier ein Datensatz, angepasst aus dem Beispiel im RFC:

<record>
  <row>
    <source_ip>192.0.2.123</source_ip>
    <count>123</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounces.vendor.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>vendor.example</domain>
      <selector>abc123</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounces.vendor.example</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

In policy_evaluated sind dkim und spf Alignment-Ergebnisse, und disposition zeigt, was der Empfangsserver getan hat. auth_results enthält die Rohergebnisse und ihre Domains. Hier bestehen beide für vendor.example und scheitern deshalb beide am Alignment: ein Anbieter, der in deinem Namen sendet, ohne in deinem Namen zu signieren. Aktiviere dort benutzerdefiniertes DKIM oder die Domain-Authentifizierung.

Tag 1 bis 7: unbekannte Absender finden

Gruppiere nach source_ip, envelope_from und der DKIM-Kombination aus domain und selector, sortiere nach count und ordne die Ergebnisse so ein:

Um eine IP zuzuordnen, führe dig -x 192.0.2.123 +short aus und sieh dir den Selektor an, der oft den Anbieter verrät. Frag dann Buchhaltung, Support und Vertrieb, was alles im Namen des Unternehmens versendet: Abrechnung, Helpdesk, Kalendereinladungen, Büroscanner.

Weitergeleitete E-Mails und Mails aus Mailinglisten scheitern auf eine Weise, die du nicht beheben kannst, und Googles Absender-FAQ verlangt dafür kein Alignment. Warte also nicht darauf.

Tag 8 bis 14: jede legitime Quelle reparieren

Arbeite dich vom höchsten count abwärts vor:

1. Workspace-Mail (Google Workspace, Microsoft 365). Aktiviere DKIM in der Admin-Konsole, mit 2048 Bit, wo angeboten, und prüfe, ob das Include des Anbieters im SPF-Eintrag steht.
2. ESPs und Marketing-Tools. Richte die Domain-Authentifizierung ein, damit sie mit deinem d= signieren, und, falls angeboten, einen eigenen Return-Path.
3. Helpdesk, Abrechnung, CRM. Wie bei den ESPs. Wenn ein Tool nicht mit deiner Domain signieren kann, nutze eine Subdomain, für die es signieren kann, oder seine eigene Domain.
4. Nicht mehr genutzte Tools. Entferne ihre Includes und Selektoren.

Zähle danach die SPF-Lookups neu.

Tag 15: p=quarantine

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

Quarantäne heißt meist: Spamordner. Achte auf legitime Quellen mit der Disposition quarantine. Zum Proben bittet p=quarantine; t=y Empfangsserver, die RFC 9989 umsetzen, stattdessen none anzuwenden. Der RFC ist allerdings erst wenige Monate alt, und noch nicht jeder Empfangsserver berücksichtigt t.

Tag 22: p=reject

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

Empfangsserver, die p=reject berücksichtigen, lehnen durchgefallene E-Mails schon in der SMTP-Sitzung ab. RFC 9989 weist sie aber an, in Quarantäne zu verschieben, wenn die Richtlinie ihr einziger Anhaltspunkt ist. Ein Teil landet deshalb im Spam.

Derselbe RFC legt fest, dass sich eine Domain mit p=reject nicht ausschließlich auf SPF verlassen darf („MUST NOT rely solely on SPF“) und mit DKIM signieren muss, weil Weiterleitungen SPF brechen, DKIM aber nicht. Stell vorher sicher, dass jede Quelle DKIM mit Alignment besteht.

Behalte rua dauerhaft. Wenn nächstes Quartal ein neues Tool dazukommt, taucht es in deinen Reports auf, bevor es als Ticket beim Support landet.

Wann du den Plan strecken solltest

Laut RFC 9989, Abschnitt 7.4, sollten Domains, deren Nutzer in Mailinglisten posten, p=reject nicht veröffentlichen („SHOULD NOT“). Wer es doch tut, sollte zuvor „mindestens einen Monat“ bei p=none und „einen ebenso langen Zeitraum“ bei p=quarantine verbringen. Das betrifft die meisten Apex-Domains von Unternehmen, gib dort also jeder der ersten beiden Stufen einen Monat. Eine Subdomain, die nur dein ESP nutzt, hat keinen Listen-Traffic und kann beim 30-Tage-Tempo bleiben.

Subdomain-Richtlinie: sp= und np=

p gilt für die Domain und ihre Subdomains. sp überschreibt das für existierende Subdomains, np für nicht existierende. Eine Subdomain mit eigenem Eintrag nutzt diesen, und RFC 9989 ignoriert sp dort.

Eine dedizierte Versand-Subdomain wie mail.example.com, die ein einziger ESP mit verifiziertem SPF und DKIM nutzt, kann p=reject vom ersten Tag an veröffentlichen. p=none; sp=reject auf der Apex-Domain schützt die Subdomains, während du die Hauptdomain fertigstellst, blockiert aber BIMI.

Geparkte Domains sollten laut Microsofts SPF-Anleitung v=spf1 -all veröffentlichen, dazu v=DMARC1; p=reject; unter _dmarc.

Ab Tag 30: BIMI

BIMI zeigt dein Logo neben authentifizierten E-Mails in Postfächern, die BIMI unterstützen:

Der BIMI-Draft liegt in Revision 14 vor (Mai 2026). Er ist noch ein Internet-Draft, der auf RFC 7489 aufbaut, daher pct. Lass pct weg und setze kein t=y.

Die Regel zur Organisationsdomain trifft Absender auf Subdomains: Steht mail.example.com auf p=reject und example.com auf p=none, dürfen Empfangsserver das Logo nicht anzeigen. Auch die Apex-Domain muss den Plan also abschließen.

Die SVG-Empfehlungen der BIMI Group raten zu einem quadratischen, zentrierten Logo auf einfarbigem Hintergrund, kleiner als 32 KB. Google hat im September 2024 die Unterstützung für CMCs ergänzt. Der Eintrag laut Implementierungsleitfaden der BIMI Group:

default._bimi.example.com.  3600  IN  TXT  "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem"

Die Eintragung einer Marke dauert Monate. Wenn du ein VMC willst, fang also jetzt damit an.

Was Gmail, Yahoo und Microsoft verlangen

Keiner der drei verlangt Durchsetzung, nur einen DMARC-Eintrag und Alignment.

Quellen: Googles Richtlinien für Absender und FAQ, Yahoos Best Practices für Absender sowie Microsofts Ankündigung vom April 2025 und Supportseite zu 5.7.515. Microsoft setzt die Anforderungen seit dem 5. Mai 2025 durch, nachdem ein Update vom 29. April die Maßnahme von der Zustellung in den Junk-Ordner auf Ablehnung umgestellt hatte.

Laut Googles FAQ wird Alignment mit SPF und DKIM „irgendwann eine Anforderung an Absender sein“. Sorg deshalb in Woche 2 bei beiden für Alignment. Mehr zu Abmelde- und Spamraten findest du im Beitrag Was weiterhin gilt, wenn ein Agent deine E-Mails versendet und in unserem Leitfaden zur Zustellbarkeit.

DMARC auf einer Versanddomain in Brew

Die Domain-Einrichtung von Brew verlangt:

• DKIM, einen TXT-Eintrag unter einem ._domainkey-Selektor deiner Versanddomain. Erforderlich.
• SPF, einen MX- und einen TXT-Eintrag auf send.<your sending domain>, dem Return-Path von Brew. Erforderlich.
• DMARC, einen TXT-Eintrag unter _dmarc.<your sending domain>. Optional, aber empfohlen.
• Einen CNAME für das Klick-Tracking, nur bei einer eigenen Tracking-Subdomain.

Die Domain kann versenden, sobald SPF und DKIM verifiziert sind, und Brew schlägt einen passenden DMARC-Wert vor:

; dedicated sending subdomain, e.g. mail.example.com
_dmarc.mail.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@mail.example.com"
 
; apex domain, or a domain Brew can't prove is dedicated
_dmarc.example.com.       TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Eine dedizierte Subdomain bekommt p=reject, weil von ihr nichts versendet wird, bevor SPF und DKIM für Brew verifiziert sind. Eine Apex-Domain bekommt p=none, weil vermutlich auch deine anderen Tools unter ihr versenden. Arbeite dort also den Plan oben ab. Das Alignment bleibt relaxed, weil der Return-Path send.<domain> nur im Relaxed-Modus passt.

Brew liest den aktuellen Eintrag unter _dmarc.<sending domain> beim Hinzufügen, beim Verifizieren und bei jeder erneuten Prüfung. Das Ergebnis siehst du unter Domains, ebenso über get_domain_health per MCP und GET /v1/domains/{domainId}/health:

• dmarc_missing: eine Warnung mit dem exakten Eintrag, den du hinzufügen musst.
• dmarc_invalid: bei zwei DMARC-Einträgen unter dem Namen oder bei fehlerhafter Version, Richtlinie oder doppelten Tags. Es nennt den Eintrag, den du löschen musst.
• Verifiziert, sobald genau ein gültiger Eintrag gefunden wurde.

Die automatische DNS-Einrichtung schreibt DMARC nur, wenn noch kein Eintrag existiert, und erzeugt so nie ein Duplikat. Die Prüfung läuft auf der Versanddomain, nicht auf der übergeordneten Domain. Gib also jeder Versand-Subdomain einen eigenen Eintrag, auch der für Transaktions-E-Mails, wenn du beides trennst, wie es die Dokumentation empfiehlt. In deinem Auswertungsdienst für rua liest du die Reports und entscheidest, wann du zu reject wechselst.

Häufig gestellte Fragen

Wie lange sollte ich bei p=none bleiben, bevor ich zu quarantine wechsle?

Bis eine volle Woche Reports zeigt, dass jede legitime Quelle SPF oder DKIM mit Alignment besteht. Bei einer Versand-Subdomain sind das meist ein bis zwei Wochen. Für eine Domain, die deine Mitarbeitenden für alltägliche E-Mails nutzen, verlangt RFC 9989 mindestens einen Monat. Zwei Jahre bei p=none, ohne dass jemand die Reports liest, bringen gar nichts.

Ist das DMARC-Tag pct veraltet?

Ja. RFC 9989 führt pct als „historisch“ und ersetzt die einzigen verlässlichen Werte durch t: t=y verhält sich wie pct=0, t=n wie pct=100. Ältere Empfangsserver lesen pct womöglich noch, haben Zwischenwerte aber nie einheitlich angewendet. Geh also in ganzen Schritten vor.

Blockiert p=reject meine weitergeleiteten E-Mails?

Einfaches Weiterleiten bricht meist SPF, aber nicht DKIM. DKIM mit Alignment besteht also weiterhin. Mailinglisten, die den Betreff oder den Footer ändern, brechen DKIM, und manche schreiben zum Ausgleich den From-Header um. DKIM mit Alignment für jede Quelle ist dein bester Schutz.

Verlangen Gmail und Yahoo p=reject?

Nein. Beide verlangen von Bulk-Sendern einen DMARC-Eintrag und akzeptieren p=none, ebenso Microsoft bei mehr als 5.000 Nachrichten pro Tag an Outlook.com. Durchsetzung stoppt Spoofing und ist für BIMI Pflicht, aber keiner der drei verlangt sie.

Brauche ich für BIMI ein VMC?

Für Gmail brauchst du entweder ein VMC, das eine eingetragene Marke voraussetzt und ein Häkchen anzeigt, oder ein CMC, das das Logo ohne Häkchen anzeigt. Laut der BIMI Group zeigen einige Anbieter, darunter Yahoo und Fastmail, auch selbst deklarierte Logos ohne Zertifikat an.