# DMARC: von p=none zu p=reject in 30 Tagen Kanonische URL: https://brew.new/de/blog/dmarc-p-none-to-reject-in-30-days Autor: Thomas Park Veröffentlicht: 2026-10-04 Aktualisiert: 2026-10-04 DMARC ist ein TXT-Eintrag unter `_dmarc.`. 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](https://redsift.com/blog/email-authentication-bespinlabs-redsift), ergab, dass 14,9 % überhaupt eine DMARC-Richtlinie hatten und 2,5 % `p=reject` durchsetzten. EasyDMARC, ein weiterer DMARC-Anbieter, [berichtete 2025](https://easydmarc.com/blog/dmarc-adoption-across-fortune-500-and-inc-5000-the-growing-divide/), 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](https://www.rfc-editor.org/rfc/rfc9989.html), einen Proposed Standard, der auch RFC 9091 ablöst, dazu [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) 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](https://www.rfc-editor.org/rfc/rfc7208.html#section-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. ```dns 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 ` 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](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) 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 `._domainkey.`. Ein Tool, das mit `d=vendor-mail.example` signiert, besteht DKIM, fällt aber bei DMARC durch. Laut [RFC 8301](https://www.rfc-editor.org/rfc/rfc8301.html) müssen Signierende RSA-Schlüssel mit mindestens 1024 Bit verwenden und sollten 2048 Bit nutzen. [Googles Richtlinien für Absender](https://support.google.com/mail/answer/81126) 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. ```dns 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](https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf) 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: | Modus | Tags | Bestandene SPF-/DKIM-Domain | From-Domain | Alignment? | |---|---|---|---|---| | Relaxed (Standard) | `aspf=r`, `adkim=r` | `bounce.example.com` | `mail.example.com` | Ja, dieselbe Organisationsdomain | | Strict | `aspf=s`, `adkim=s` | `bounce.example.com` | `mail.example.com` | Nein, die Namen müssen übereinstimmen | | Beide | | `vendor.example.net` | `example.com` | Nein | 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 ![Ein 30-Tage-Zeitplan für DMARC in vier Stufen: Tag 1 bis 7 mit p=none und rua-Reporting, Tag 8 bis 14 Absender reparieren, Tag 15 mit p=quarantine, Tag 22 mit p=reject, dann ab Tag 30 BIMI, jeweils mit dem exakten TXT-Eintrag für die Stufe.](/images/blog/dmarc-p-none-to-reject-in-30-days-timeline.png) *Der Eintrag für jede Stufe. Geh erst nach einer Woche mit sauberen Reports zur nächsten über.* | Tage | Richtlinie | Was du tust | Voraussetzung für den nächsten Schritt | |---|---|---|---| | 1 bis 7 | `p=none` | Mit `rua` veröffentlichen, alle Quellen erfassen | 7 Tage Reports von Google, Yahoo und Microsoft | | 8 bis 14 | `p=none` | DKIM und SPF reparieren, ungenutzte Absender abschalten | Jede legitime Quelle besteht SPF oder DKIM mit Alignment | | 15 bis 21 | `p=quarantine` | Auf legitime E-Mails in Quarantäne achten | 7 Tage, ohne dass eine legitime Quelle durchfällt | | 22 bis 30 | `p=reject` | Weiter Reports lesen, `np=reject` ergänzen | Eine Woche stabil | | Ab 30 | `p=reject` | Mit BIMI beginnen | Zertifikat ausgestellt | 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 ```dns _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.` 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](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) 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: ```xml 192.0.2.123 123 none fail fail bounces.vendor.example example.com vendor.example abc123 pass bounces.vendor.example pass ``` 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: | Muster im Report | Wahrscheinliche Ursache | Maßnahme | |---|---|---| | DKIM oder SPF mit Alignment bestanden | Korrekt konfiguriert | Keine | | DKIM und SPF für Anbieterdomains bestanden | SaaS-Tool mit eigener Identität | Benutzerdefiniertes DKIM aktivieren | | DKIM mit Alignment bestanden, SPF fehlgeschlagen, IP eines Mailbox-Providers oder einer Mailingliste | Weiterleitung oder Mailingliste | Meist keine. DKIM mit Alignment übersteht Weiterleitungen | | Kein DKIM, SPF fehlgeschlagen, nicht zuordenbare IPs | Spoofing | Keine. Genau das stoppt `p=reject` | 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](https://support.google.com/mail/answer/14229414) 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 ```dns _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 ```dns _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: | Anforderung | Detail | Quelle | |---|---|---| | DMARC-Richtlinie | `p=quarantine` oder `p=reject` auf der Organisationsdomain und der From-Domain | BIMI-Draft | | Subdomain-Richtlinie | Falls `sp` veröffentlicht ist, nicht `none` | BIMI-Draft | | Prozentsatz | Bei quarantine darf `pct` nicht unter 100 liegen | BIMI-Draft | | Logo | SVG Tiny PS: `baseProfile="tiny-ps"`, `version="1.2"`, ein ``, keine Skripte oder externen Verweise, kein `x=` oder `y=` am Wurzelelement | BIMI Group | | Zertifikat | Gmail braucht ein VMC (eingetragene Marke, Häkchen) oder ein CMC (keine Marke, kein Häkchen) | Google | Der [BIMI-Draft](https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/) 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](https://bimigroup.org/creating-bimi-svg-logo-files/) 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](https://workspaceupdates.googleblog.com/2024/09/gmail-additional-bimi-protections.html). Der Eintrag laut [Implementierungsleitfaden der BIMI Group](https://bimigroup.org/implementation-guide/): ```dns 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. | | Gmail | Yahoo | Outlook.com | |---|---|---|---| | Schwelle | Annähernd 5.000 pro Tag an private Gmail-Konten, pro primärer Domain, dauerhaft, sobald einmal erreicht | Bulk-Sender, ohne feste Zahl | Über 5.000 pro Tag an outlook.com, hotmail.com und live.com, pro From-Domain | | SPF und DKIM | Beide | Beide | Beide müssen bestehen | | DMARC | Eintrag erforderlich, `p=none` wird akzeptiert | Mindestens `p=none`, `rua` dringend empfohlen | Mindestens `p=none` | | Alignment | SPF oder DKIM | SPF oder DKIM, Relaxed reicht | SPF oder DKIM | | Bei Verstoß | Vorübergehende und dauerhafte Ablehnungen seit November 2025 | Keine Angabe | `550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.` | Quellen: [Googles Richtlinien für Absender](https://support.google.com/mail/answer/81126) und [FAQ](https://support.google.com/mail/answer/14229414), [Yahoos Best Practices für Absender](https://senders.yahooinc.com/best-practices/) sowie Microsofts [Ankündigung vom April 2025](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) und [Supportseite zu 5.7.515](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com). 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](/de/blog/agent-email-deliverability) und in unserem [Leitfaden zur Zustellbarkeit](/de/blog/email-deliverability). ## DMARC auf einer Versanddomain in Brew Die [Domain-Einrichtung](https://docs.brew.new/get-started/verify-your-sending-domain) 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: ```dns ; 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](/de/blog/transactional-emails), 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](https://bimigroup.org/understanding-bimi-certificate-types/) zeigen einige Anbieter, darunter Yahoo und Fastmail, auch selbst deklarierte Logos ohne Zertifikat an.