Google Workspace DMARC: Eintrag und Rollout

Was prüft DMARC bei Google Workspace eigentlich?

DMARC, definiert in RFC 7489, sagt empfangenden Servern, was sie mit Mails tun sollen, die im sichtbaren From-Header Ihre Domain angeben, das aber nicht belegen können. Eine Nachricht besteht DMARC, wenn SPF oder DKIM besteht und die geprüfte Domain mit der From-Domain übereinstimmt (Alignment). Einer der beiden Checks reicht. Bei Google Workspace wird DKIM mit dem Schlüssel signiert, den Sie in der Admin-Konsole erzeugen (standardmäßig mit dem Selector google), und SPF deckt die Google-Server über include:_spf.google.com ab. Beides liegt auf Ihrer Domain. DMARC ist die Ebene darüber, die aus diesen zwei Prüfungen eine Policy macht. Was viele überrascht: Google Workspace veröffentlicht nie selbst einen DMARC-Eintrag für Sie. In der Admin-Konsole gibt es eine Seite für DKIM, aber keine für DMARC. Der Eintrag gehört zu Ihrem DNS-Hoster, und er gilt für jeden Dienst, der im Namen Ihrer Domain versendet, nicht nur für Gmail. Seit Februar 2024 verlangen Googles Regeln für Massenversender von allen, die täglich 5.000 oder mehr Nachrichten an Gmail-Adressen schicken, einen DMARC-Eintrag (p=none genügt) sowie ein Alignment der From-Domain mit SPF oder DKIM.

Wie richte ich DMARC für Google Workspace ein?

Google Workspace DMARC einzurichten ist eine DNS-Aufgabe mit fester Reihenfolge. Google empfiehlt selbst, dass SPF und DKIM rund 48 Stunden lang Mails authentifizieren, bevor Sie DMARC veröffentlichen. So spiegeln die ersten Aggregate-Reports eine funktionierende Ausgangslage wider und keine halb konfigurierte Domain. Sind MX, SPF und DKIM noch nicht eingerichtet, beginnen Sie mit den Google Workspace DNS-Einträgen für MX, SPF und DKIM und kommen Sie zurück, sobald diese aktiv sind.

1. 1 SPF als einen einzigen TXT-Eintrag im Root der Domain veröffentlichen, der include:_spf.google.com enthält, und dabei unter dem SPF-Limit von 10 DNS-Lookups bleiben.
2. 2 In der Admin-Konsole zu Apps, Google Workspace, Gmail, E-Mail authentifizieren gehen, einen 2048-Bit-Schlüssel erzeugen, den TXT-Eintrag google._domainkey veröffentlichen und dann auf Authentifizierung starten klicken.
3. 3 Mindestens 48 Stunden warten und prüfen, ob Ihre versendeten Mails im Header Authentication-Results dkim=pass und spf=pass zeigen.
4. 4 Einen TXT-Eintrag mit dem Host _dmarc und dem Wert v=DMARC1; p=none; rua=mailto:ihre-report-adresse anlegen.
5. 5 Mit dig TXT _dmarc.ihredomain.de abfragen und kontrollieren, ob genau ein Eintrag zurückkommt, der mit v=DMARC1 beginnt.

Wie sieht der DMARC-Eintrag für Google Workspace aus?

Der DMARC-Eintrag für Google Workspace ist derselbe wie für jede andere Domain. Google braucht kein spezielles Tag, und es gibt keinen Google-spezifischen Wert zum Einfügen. Eine sinnvolle erste Version lautet v=DMARC1; p=none; rua=mailto:dmarc@ihredomain.de. Damit sammeln Sie Daten, ohne Empfänger anzuweisen, bei Fehlschlägen einzugreifen. Die Tags, die Sie tatsächlich anfassen werden, stehen unten. Pflicht sind nur v und p, und v=DMARC1 muss an erster Stelle stehen.

Tag	Funktion	Startwert
v	Version; muss das erste Tag sein	DMARC1
p	Policy für die Domain: none, quarantine oder reject	none
rua	Adresse für tägliche Aggregate-Reports (XML)	mailto:dmarc@ihredomain.de
sp	Policy für Subdomains; übernimmt p, wenn weggelassen	anfangs weglassen
adkim / aspf	Alignment-Modus: r (relaxed, Standard) oder s (strict)	beim Standard r lassen
pct	Anteil der fehlschlagenden Mails, auf den die Policy angewendet wird, 0-100	weglassen, solange p=none gilt

Zwei Fehler tauchen immer wieder auf. Der erste: zwei TXT-Einträge unter _dmarc. RFC 7489 behandelt das so, als gäbe es überhaupt keinen gültigen Eintrag. Der zweite: rua zeigt auf ein Postfach unter einer anderen Domain, ohne dass diese Domain einen Autorisierungseintrag unter ihredomain.de._report._dmarc.anderedomain.de veröffentlicht. Fehlt dieser Eintrag, kommen die Reports schlicht nicht an.

Warum fallen Brevo-Mails auf einer Google-Workspace-Domain bei DMARC durch?

Ihr _dmarc-Eintrag gilt für die Domain, nicht für den Postfachanbieter. Eine Brevo-Kampagne, die als sie@ihredomain.de verschickt wird, wird also nach derselben Policy bewertet wie eine Nachricht, die Sie in Gmail tippen. Googles DKIM-Schlüssel hilft Brevo-Mails nicht, denn Brevo signiert mit einem eigenen Schlüssel. Dieser muss auf Ihrer Domain veröffentlicht sein, damit die Signatur aligned ist. Die Einrichtung beschreiben wir unter G Suite DKIM mit dem Google-Eintrag und der Brevo-Einrichtung. Typische Gründe, warum Brevo-Traffic in Ihren Aggregate-Reports als fehlgeschlagen auftaucht:

• Die DKIM-Einträge von Brevo wurden nie angelegt, also wird die Nachricht mit einer Brevo-Domain signiert, die nicht zu Ihrem From passt.
• Der Envelope-Absender (Return-Path) liegt auf der Domain von Brevo, daher kann SPF für Brevo zwar bestehen, aber nicht aligned sein. DKIM muss DMARC dann allein tragen.
• Das include von Brevo wurde als zweiter SPF-TXT-Eintrag angelegt. Zwei SPF-Einträge erzeugen einen permerror, und SPF schlägt für jeden Absender der Domain fehl.
• adkim=s (strict) ist gesetzt, während Brevo mit einer Ihrer Subdomains signiert – relaxed Alignment würde bestehen, strict nicht.
• Der DNS-Hoster hat die Domain an das Host-Feld angehängt und den DKIM-Schlüssel unter dem falschen Namen veröffentlicht, sodass Abfragen nichts zurückliefern.

Solange p=none gesetzt ist, sieht man keinen dieser Fehler – außer in den Reports. Genau deshalb fängt man dort an.

Wann sollte ich von p=none auf quarantine oder reject umstellen?

Stellen Sie erst um, wenn die Aggregate-Reports zeigen, dass jede legitime Quelle, die im Namen Ihrer Domain versendet, DMARC besteht: Google Workspace, Brevo, Ihr CRM, Rechnungstools und alles andere. Reports kommen ungefähr täglich (das Standardintervall ri beträgt 86400 Sekunden), lassen Sie also mindestens ein paar Wochen verstreichen, damit auch monatliche Absender wie Abrechnungssysteme erfasst werden. Dann gehen Sie stufenweise vor: zuerst p=quarantine, optional mit pct unter 100, um die Policy nur auf einen Teil der fehlschlagenden Mails anzuwenden, und schließlich p=reject. Direkt auf reject zu springen ist der häufigste Fehler. Ein vergessenes Tool, das Rechnungen von Ihrer Domain verschickt, wird dann von Empfängern abgewiesen, die die Policy respektieren, und niemand merkt es, bis ein Kunde fragt, wo die Rechnung bleibt. Weiterleitungen sind die andere bekannte Schwachstelle. Weitergeleitete Mails brechen oft SPF, und Mailinglisten, die den Inhalt umschreiben, brechen DKIM. Unter jeder strengen Policy werden also auch manche legitimen Mails durchfallen. Für eine Cold-Outreach-Domain erfüllt p=none mit sauberen Reports bereits Googles Mindestanforderung für Massenversender. Die Verschärfung ist eine eigene Entscheidung über das Spoofing-Risiko, kein Schalter für die Zustellbarkeit. Das Gesamtbild finden Sie unter SPF, DKIM und DMARC für Cold-E-Mail-Versender.

Wie arbeitet EmailFlow OS mit Ihrem Google Workspace DMARC zusammen?

EmailFlow OS fügt Ihrer Domain keinen eigenen Absender hinzu, es gibt also keine zusätzliche Quelle, die Sie in Ihrem DMARC-Eintrag autorisieren müssten. Sie nehmen ein Video auf und laden es in EmailFlow OS hoch, verbinden Ihr Brevo-Konto und Ihre Versanddomain und importieren Ihre Prospect-Liste in EmailFlow OS. EmailFlow OS personalisiert diese eine Aufnahme dann für jeden einzelnen Empfänger, nicht nur pro Firma, und verschickt jede Version aus Ihrem eigenen Postfach über Ihr Brevo-Konto und Ihre Versanddomain. Eine geteilte Plattformadresse steht nie in der From-Zeile. In der Praxis hängt das DMARC-Ergebnis dieser Nachrichten also an denselben Einträgen, die Sie ohnehin selbst kontrollieren: Brevos DKIM-Schlüssel auf Ihrer Domain und Ihr einziger _dmarc-TXT-Eintrag. Sind Brevo-Mails in Ihren Aggregate-Reports heute schon aligned, laufen die Video-E-Mails über genau diesen Weg. Sind sie es nicht, korrigieren Sie die DKIM-Einträge von Brevo vor dem Versand, denn kein Tool kann eine Signatur alignen, die Ihr DNS nicht veröffentlicht. Ob ein empfangender Server die Nachricht annimmt, entscheidet weiterhin dieser Server. Bei einer neuen Domain fahren Sie das Volumen zuerst hoch, wie im Beitrag zum E-Mail-Warm-up mit Tagesvolumen und DNS-Einrichtung beschrieben.

Häufige Fragen

? Legt Google Workspace automatisch einen DMARC-Eintrag an?

Nein. Die Admin-Konsole erzeugt Ihren DKIM-Schlüssel und zeigt den Eintrag google._domainkey an, aber DMARC wird nie für Sie angelegt. Sie veröffentlichen beim DNS-Hoster einen TXT-Eintrag unter _dmarc.ihredomain.de, der mit v=DMARC1 und einem p-Tag beginnt. Ohne ihn wenden Empfänger keine DMARC-Policy an, und die Gmail-Regeln für Massenversender mit 5.000 oder mehr Nachrichten pro Tag sind nicht erfüllt.

? Kann ich zwei DMARC-Einträge haben, einen für Google und einen für Brevo?

Nein. DMARC erlaubt genau einen Eintrag pro Domain unter _dmarc. Liefert eine Abfrage nach RFC 7489 mehr als einen v=DMARC1-Eintrag, gilt die Domain so, als hätte sie überhaupt keine DMARC-Policy. Google Workspace und Brevo teilen sich den einen Eintrag. Jeder Dienst braucht seinen eigenen, aligned DKIM-Schlüssel, die Policy selbst ist aber ein einziger TXT-Eintrag.

? Wie lange nach DKIM sollte ich DMARC in Google Workspace hinzufügen?

Google empfiehlt in seiner Einrichtungsanleitung, dass SPF und DKIM rund 48 Stunden lang Mails authentifizieren, bevor Sie DMARC veröffentlichen. Das deckt auch die übliche DNS-Propagation ab, die bis zu 48 Stunden dauern kann. Prüfen Sie, ob Ihre ausgehenden Nachrichten im Header Authentication-Results dkim=pass zeigen, bevor Sie den _dmarc-Eintrag anlegen.

? Reicht p=none für die Absenderanforderungen von Gmail?

Ja, was den DMARC-Teil angeht. Googles Regeln für Absender von 5.000 oder mehr Nachrichten pro Tag an Gmail verlangen einen veröffentlichten DMARC-Eintrag mit mindestens p=none sowie eine From-Domain, die mit SPF oder DKIM aligned ist. Auch mit p=none erhalten Sie Aggregate-Reports. Die Empfänger werden nur nicht angewiesen, fehlschlagende Mails in Quarantäne zu verschieben oder abzuweisen.