Gmail und Yahoo Authentifizierung: Was DACH-Unternehmen jetzt tun müssen

Google und Yahoo verlangen seit Februar 2024 von allen E-Mail-Versendern SPF, DKIM und DMARC. Wer diese drei DNS-Einträge nicht korrekt gesetzt hat, riskiert, dass E-Mails ungezustellt bleiben oder direkt im Spam landen – unabhängig von der Listenqualität oder dem Absenderruf. Dieser Leitfaden zeigt dir, was genau gefordert wird und wie du es in ActiveCampaign umsetzt.

Das Wichtigste in Kürze

• Google und Yahoo verlangen seit Februar 2024: SPF, DKIM, DMARC (mindestens p=none) sowie One-Click-Unsubscribe für Bulk-Sender ab 5.000 E-Mails täglich an Gmail-Adressen.
• DKIM ist das technisch kritischste Element: Fehlt die Übereinstimmung zwischen Signing-Domain und From-Domain, schlägt das DMARC-Alignment fehl – auch wenn DKIM technisch vorhanden ist.
• ActiveCampaign bietet native Domain-Authentifizierung für alle Tarife; die Einrichtung erfordert drei DNS-Einträge und dauert 24–48 Stunden bis zur vollständigen Propagation.
• DMARC-Policy immer mit p=none starten, mindestens vier Wochen Reports auswerten, dann schrittweise auf quarantine und reject erhöhen.
• T-Online, GMX und Web.de filtern unabhängig von Google und Yahoo; saubere Authentifizierung verbessert die Zustellbarkeit in alle DACH-Postfächer gleichzeitig.

Was Google und Yahoo seit Februar 2024 von allen Versendern verlangen

Google und Yahoo haben ihre verschärften Anforderungen zeitgleich angekündigt und umgesetzt. Die Regeln unterscheiden zwischen zwei Versender-Kategorien: alle Versender ohne Mengenschwelle und Bulk-Sender, die täglich mehr als 5.000 E-Mails an Gmail-Adressen schicken.

Für alle Versender gilt: E-Mails müssen entweder SPF- oder DKIM-authentifiziert sein, und die Absender-Domain in der From-Adresse darf keine @gmail.com- oder @yahoo.com-Adresse sein. Letzteres klingt selbstverständlich, ist aber in der DACH-Praxis noch häufig zu sehen – Unternehmen nutzen eine Gmail-Adresse als offiziellen Absender und wundern sich über Zustellprobleme.

Für Bulk-Sender kommen vier zusätzliche Anforderungen hinzu. SPF und DKIM müssen beide konfiguriert sein, nicht nur eines von beiden. DMARC muss mit mindestens p=none für die Absender-Domain eingerichtet sein. Die From-Domain muss mit der DKIM-Signing-Domain übereinstimmen – das nennt sich DMARC-Alignment. Und ausgehende E-Mails müssen einen One-Click-Unsubscribe-Header nach RFC 8058 enthalten, der Empfängern das Abmelden direkt aus der E-Mail-Oberfläche ermöglicht.

Wichtig zur Mengenschwelle: Die 5.000 E-Mails täglich an Gmail werden pro Kalendertag gemessen, nicht als Monats- oder Wochenschnitt. Wer einmal im Monat einen großen Newsletter an zehntausende Adressen schickt, davon viele mit @gmail.com-Endung, fällt an diesem Versandtag in die Bulk-Sender-Kategorie und muss alle vier Zusatzanforderungen erfüllen.

Warum Absenderadressen mit Free-Mail-Domains nicht funktionieren

Wenn du eine @gmail.com-Adresse als Absender verwendest, erwartet der empfangende Gmail-Server, dass Google die E-Mail selbst signiert hat. Kommt die E-Mail aber von ActiveCampaign oder einem anderen Versanddienstleister, stimmt das DMARC-Alignment nicht: Die DKIM-Signatur trägt die Domain des ESPs, nicht die des From-Headers. Google und Yahoo lehnen solche E-Mails bei verschärfter DMARC-Policy direkt ab.

Dasselbe gilt für @gmx.de, @web.de und @yahoo.de als Absenderadressen: United Internet und Yahoo betreiben diese Postfächer und setzen vergleichbare Regeln durch. Wer Marketing-E-Mails über ActiveCampaign mit diesen Absenderadressen verschickt, hat dauerhaft schlechtere Zustellbarkeit zu erwarten. Die Lösung ist in jedem Fall eine eigene Unternehmens-Domain als Absender.

SPF, DKIM und DMARC – was jedes Protokoll leistet

Die drei Protokolle greifen ineinander und erfüllen unterschiedliche Aufgaben. Wer nur eines davon einrichtet, hat keine vollständige Authentifizierung. Wer DMARC aktiviert, bevor SPF und DKIM stabil laufen, riskiert, eigene legitime E-Mails zu blockieren.

SPF: wer darf in deinem Namen versenden

SPF (Sender Policy Framework) definiert in einem DNS-TXT-Eintrag, welche Server berechtigt sind, E-Mails von deiner Domain zu versenden. Der empfangende Server prüft beim Eingang, ob die sendende IP-Adresse auf der Erlaubnisliste steht. Ist sie es nicht, schlägt die SPF-Prüfung fehl.

Ein SPF-Eintrag für eine Domain, die ausschließlich über ActiveCampaign versendet, enthält den von ActiveCampaign beim Setup vorgegebenen include:-Verweis sowie ~all am Ende. Das Tilde-all (softfail) bedeutet, dass E-Mails von nicht gelisteten Servern trotzdem angenommen, aber als verdächtig markiert werden. -all (hardfail) blockt diese E-Mails komplett – sinnvoll erst dann, wenn du sicher bist, alle legitimen Versender erfasst zu haben.

Jede Domain darf nur einen einzigen SPF-Eintrag haben. Wenn du mehrere Dienste nutzt – Newsletter-Tool, Transaktionsmail-Anbieter, ERP – kombinierst du alle include:-Anweisungen in einer einzigen Zeile. Mehrere separate TXT-Einträge mit v=spf1 werden von den meisten Providern ignoriert oder führen zu einem SPF-Fehler.

Achtung: Jedes include: in einem SPF-Eintrag kostet einen DNS-Lookup. SPF erlaubt maximal zehn Lookups pro Prüfung. Bei vielen Diensten läuft man schnell in den sogenannten SPF-Permerror, bei dem die SPF-Prüfung abbricht und als Fehler gilt. Das Gegenmittel ist SPF-Flattening: alle IP-Adressen hinter den include:-Einträgen direkt als ip4:- oder ip6:-Einträge hinterlegen, die keinen eigenen Lookup benötigen.

DKIM: digitale Signatur für jeden Versand

DKIM (DomainKeys Identified Mail) funktioniert mit einem asymmetrischen Schlüsselpaar. ActiveCampaign signiert jede ausgehende E-Mail mit einem privaten Schlüssel. Den zugehörigen öffentlichen Schlüssel veröffentlichst du als DNS-TXT-Eintrag unter einem Selector-Namen. Der empfangende Server liest den öffentlichen Schlüssel aus dem DNS und verifiziert damit, ob die E-Mail auf dem Weg zum Empfänger verändert wurde und ob sie tatsächlich von deiner Domain stammt.

Eine DKIM-Signatur im E-Mail-Header enthält unter anderem d=deinunternehmen.de (die signierende Domain) und s=selector1 (den Selector-Namen). Der Selector ist wichtig, weil eine Domain mehrere DKIM-Schlüssel für verschiedene Dienste haben kann – jeder mit eigenem Selector-Namen im DNS. ActiveCampaign generiert bei der Domain-Authentifizierung automatisch ein Schlüsselpaar und gibt dir den genauen DNS-Eintrag vor; du musst ihn nur kopieren und eintragen.

Für DMARC-Alignment muss die DKIM-Signing-Domain (d=) mit der From-Domain übereinstimmen. Wenn ActiveCampaign E-Mails mit der eigenen Plattform-Domain signiert und deine From-Adresse auf deinunternehmen.de lautet, ist das Alignment nicht gegeben. Erst wenn du Custom Domain Authentication einrichtest – DKIM mit deiner eigenen Domain konfiguriert – ist DMARC-Alignment erfüllt. Das ist der häufigste Grund, warum DMARC-Reports zunächst Fehler anzeigen, obwohl DKIM technisch vorhanden zu sein scheint.

DMARC: Richtlinie und Reporting

DMARC (Domain-based Message Authentication, Reporting and Conformance) ist das Kontrollprotokoll, das SPF und DKIM zusammenführt. Es legt fest, was mit E-Mails passiert, die beide Prüfungen nicht bestehen, und gibt dir über tägliche Reports Einblick, wer E-Mails in deinem Namen verschickt.

Die drei Policy-Stufen: Bei p=none werden E-Mails normal zugestellt, Vorfälle werden nur in Reports vermerkt. Bei p=quarantine landen fehlgeschlagene E-Mails im Spam-Ordner der Empfänger. Bei p=reject werden fehlgeschlagene E-Mails komplett abgewiesen und nicht zugestellt.

Ein minimaler DMARC-Eintrag für den Start: v=DMARC1; p=none; rua=mailto:dmarc@deinunternehmen.de. Das rua=-Feld ist die Adresse, an die täglich aggregierte Reports gesendet werden. Diese Reports zeigen dir, welche Server E-Mails in deinem Namen versenden und ob SPF und DKIM jeweils bestehen. Ohne rua-Adresse bist du blind: Du merkst nicht, ob legitime E-Mails scheitern oder ob Dritte deine Domain für Phishing missbrauchen.

So richtest du Domain-Authentifizierung in ActiveCampaign ein

Bevor du anfängst, stelle sicher, dass du Zugang zu den DNS-Einstellungen deiner Domain hast – entweder im Control Panel deines Domain-Registrars (IONOS, all-inkl, Hetzner) oder in einem separaten DNS-Dienst wie Cloudflare. Ohne DNS-Zugang kannst du keine Einträge setzen.

1. Öffne in ActiveCampaign die Einstellungen über das Zahnrad-Symbol im linken Navigationsmenü und wechsle in den Bereich E-Mail, dann Domain-Authentifizierung.
2. Klicke auf "Domain hinzufügen" und gib die Absender-Domain ein – also die Domain, die in der From-Adresse deiner E-Mails erscheint (zum Beispiel deinunternehmen.de).
3. ActiveCampaign zeigt dir anschließend die DNS-Einträge für DKIM und SPF. Kopiere jeden Eintrag vollständig: Typ (TXT oder CNAME), Name/Host und Wert.
4. Öffne in einem zweiten Tab das DNS-Control-Panel deines Registrars und füge die Einträge exakt so ein, wie sie ActiveCampaign vorgibt. Bei SPF prüfe zuerst, ob bereits ein v=spf1-Eintrag existiert – wenn ja, ergänze den ActiveCampaign-include: im bestehenden Eintrag, statt einen zweiten hinzuzufügen.
5. Warte mindestens 15–30 Minuten und kehre in ActiveCampaign zurück. Klicke auf "Einträge prüfen". Bei grünem Status ist die Domain authentifiziert.
6. Richte anschließend DMARC manuell über dein DNS-Control-Panel ein. ActiveCampaign setzt DMARC nicht automatisch. Erstelle einen neuen TXT-Eintrag: Name/Host: _dmarc.deinunternehmen.de, Wert: v=DMARC1; p=none; rua=mailto:dmarc@deinunternehmen.de.
7. Überprüfe alle drei Einträge nach 24–48 Stunden über MXToolbox (mxtoolbox.com) – dort kannst du SPF-Lookup, DKIM-Lookup (mit dem Selector-Namen aus ActiveCampaign) und DMARC-Lookup separat prüfen.

DNS-Änderungen propagieren sich weltweit in der Regel innerhalb von 24–48 Stunden. In dieser Zeit können Tests uneinheitliche Ergebnisse zeigen. Prüfe den finalen Status frühestens am nächsten Morgen, nicht unmittelbar nach dem Eintragen.

DMARC schrittweise verschärfen – der Weg von none zu reject

Die meisten Anleitungen empfehlen, mit p=none zu starten und nach einiger Zeit auf p=reject zu wechseln. Was dabei oft fehlt: Der Schritt dazwischen – das Auswerten der Reports und das schrittweise Erhöhen der Policy – ist entscheidend dafür, dass keine legitimen E-Mails verloren gehen.

Was DMARC-Reports zeigen und wie du sie auswertest

DMARC-Aggregate-Reports kommen täglich als XML-Dateien per E-Mail an die rua-Adresse. Im Rohformat sind sie schwer lesbar; Tools wie DMARC Analyzer, dmarcian oder der kostenlose MXToolbox DMARC-Report-Reader machen die Daten zugänglich. Was du in den Reports suchst:

• Zeilen mit "pass" für SPF und DKIM von ActiveCampaigns IP-Adressen – das zeigt, dass deine Kampagnen korrekt authentifiziert ankommen.
• Zeilen mit "fail", die zeigen, von welchen Servern E-Mails in deinem Namen kommen, die du nicht autorisiert hast.
• Unbekannte IP-Adressen in den Sender-Zeilen – das sind entweder vergessene Dienste oder echte Missbrauchsversuche.

Ein häufiger Fund in der Praxis: Ein CRM- oder ERP-System versendet Benachrichtigungs-E-Mails über einen eigenen Mailserver, der nicht im SPF-Eintrag steht. Oder ein Webshop-Plugin verschickt Transaktions-E-Mails über den Hosting-Server der Domain, ohne DKIM-Signatur. Beides fällt erst durch DMARC-Reports auf – und das ist genau der Zweck der monitoring-Phase mit p=none.

Der Weg von none zu quarantine zu reject

Wenn deine Reports vier Wochen lang zeigen, dass alle legitimen E-Mails SPF und DKIM bestehen, kannst du verschärfen. Wechsle zunächst zu p=quarantine; pct=10. Das pct-Feld legt fest, auf welchen Prozentsatz der nicht authentifizierten E-Mails die Policy angewendet wird; zunächst also auf zehn Prozent. So kannst du testen, ob etwas Unerwartetes auftritt, ohne sofort den vollen Effekt zu spüren.

Steigere pct schrittweise auf 25, 50 und dann 100, jeweils mit einer Woche Monitoring dazwischen. Erst wenn p=quarantine; pct=100 stabil läuft und keine legitimen E-Mails betroffen sind, wechsle zu p=reject. Damit werden nicht authentifizierte E-Mails komplett abgelehnt. Domain-Missbrauch für Phishing wird dadurch erheblich erschwert.

Wann du nicht auf reject wechseln solltest: Wenn deine Organisation viele unabhängige Systeme hat, die E-Mails versenden – CRM, ERP, HR-System, separater Transaktionsmail-Dienst – und du nicht sicher bist, ob alle korrekt authentifiziert sind. Eine vorschnelle Verschärfung kann transaktionale E-Mails wie Bestellbestätigungen und Passwort-Reset-Links zum Scheitern bringen.

DACH-Besonderheiten: T-Online, GMX und Web.de

Die Google-und-Yahoo-Anforderungen sind der Mindeststandard. Im deutschsprachigen Raum sind die drei dominanten Postfach-Provider T-Online (Telekom), GMX und Web.de (beide United Internet) schon länger mit eigenen Filtersystemen aktiv und haben teilweise andere Schwerpunkte als Gmail.

Was bei deutschen Providern zusätzlich zählt

T-Online prüft DKIM und SPF, beobachtet aber auch das Versandverhalten über Zeit. Schwankende Versandvolumina – lange Pause, dann plötzlich ein großer Newsletter – stoßen bei T-Online auf Misstrauen. Wer nach langer Sendepause einen großen Verteiler anschreibt, riskiert Spam-Einstufung, auch bei korrekter Authentifizierung. Aufwärmstrecken mit schrittweise steigendem Volumen helfen hier.

GMX und Web.de wenden DKIM-Alignment strikt an. Ein häufiges Problem: Wenn die DKIM-Signing-Domain eine Subdomain ist (zum Beispiel mail.deinunternehmen.de), die From-Domain aber die Hauptdomain (deinunternehmen.de), kann das bei GMX zu Spam-Einstufung führen, auch wenn DMARC formal mit p=none läuft. Strict Alignment statt Relaxed Alignment kann das lösen, erfordert aber, dass DKIM-Domain und From-Domain exakt übereinstimmen.

Posteo und Mailbox.org, zwei datenschutzorientierte Anbieter mit wachsender Nutzerbasis im DACH-Raum, wenden keine proprietären Blocklisten an, prüfen aber DKIM und SPF konsequent. Wer Gmail-konform konfiguriert ist, kommt auch dort zuverlässig an.

DSGVO-Hinweis zu DMARC-Reports

DMARC-Aggregate-Reports enthalten IP-Adressen der sendenden Server. Im Normalfall handelt es sich um IP-Adressen von ESPs und Mailservern, nicht von Einzelpersonen; eine direkte Personenbeziehbarkeit ist selten. Wenn du die Reports an ein externes Analyse-Tool wie dmarcian oder DMARC Analyzer weiterleitest, werden diese Daten an einen Drittanbieter übertragen. Eine kurze Erwähnung in der Datenschutzerklärung ist empfehlenswert, wenn du solche Dienste einsetzt.

Typische Fehler bei der Einrichtung

SPF-Record mit zu vielen DNS-Lookups

Jedes include: in einem SPF-Eintrag kostet einen DNS-Lookup. SPF erlaubt maximal zehn Lookups pro Prüfung. Wer viele Dienste nutzt – CRM, Transaktionsmail-Anbieter, Newsletter-Tool, ERP – läuft schnell in das sogenannte SPF-Permerror. In diesem Fall bricht die SPF-Prüfung ab und gilt als Fehler, auch wenn alle Dienste korrekt eingetragen wären. Das Gegenmittel: Alle IP-Adressen hinter den include:-Einträgen auflösen und direkt als ip4:- oder ip6:-Einträge hinterlegen, die keinen Lookup benötigen.

DMARC verschärfen, bevor DKIM stabil läuft

Wenn DKIM noch nicht vollständig propagiert ist und du DMARC mit p=quarantine aktivierst, scheitern zunächst eigene E-Mails an der Policy. Das Ergebnis: Kampagnen landen komplett im Spam oder werden abgewiesen. Die korrekte Reihenfolge: Erst SPF und DKIM einrichten, Propagation 24–48 Stunden abwarten, dann DMARC mit p=none aktivieren, Reports auswerten, erst dann auf quarantine erhöhen.

Subdomain-Versand ohne eigene DNS-Einträge

Wenn du für Marketingversand eine Subdomain nutzt (zum Beispiel newsletter.deinunternehmen.de als Absenderdomain), braucht diese Subdomain eigene SPF- und DKIM-Einträge. Die Einträge der Hauptdomain gelten nicht automatisch für Subdomains. DMARC kann mit dem Parameter sp=reject gesetzt werden, das alle Subdomains die Policy der Hauptdomain erben lässt; das setzt aber voraus, dass alle Subdomains, die legitim versenden, eigene vollständige Einträge haben.

Transaktionale und Marketing-E-Mails über dieselbe Domain, verschiedene Systeme

Ein häufiges Problem: Der Newsletter läuft über ActiveCampaign und ist korrekt authentifiziert. Bestellbestätigungen und Passwort-Reset-Links laufen über den Webshop-Server und haben kein DKIM. Steht DMARC auf p=reject, werden die Transaktions-E-Mails abgelehnt, obwohl das Marketing-System sauber eingerichtet ist. Das Gegenmittel: Alle sendenden Systeme vor der DMARC-Verschärfung in den Reports identifizieren und vollständig authentifizieren.

Häufige Fragen

Brauche ich DKIM mit meiner eigenen Domain, wenn ActiveCampaign die E-Mails schon signiert?

Ja. Wenn ActiveCampaign E-Mails mit der eigenen Plattform-Domain signiert, ist das technisch eine valide DKIM-Signatur, aber die DKIM-d=-Domain stimmt nicht mit deiner From-Domain überein. Das DMARC-Alignment schlägt deshalb fehl. Erst wenn du Custom Domain Authentication einrichtest – DKIM mit deiner eigenen Domain konfiguriert – ist Alignment gegeben. ActiveCampaign bietet das für alle Tarife an und führt dich beim Setup durch den Prozess.

Was ist One-Click-Unsubscribe und wie richte ich es in ActiveCampaign ein?

One-Click-Unsubscribe (RFC 8058) bedeutet, dass E-Mails einen standardisierten List-Unsubscribe-Header enthalten, über den Empfänger sich mit einem einzigen Klick abmelden können – ohne zuerst eine Landingpage zu öffnen. Gmail zeigt diesen Link direkt in der E-Mail-Oberfläche an. ActiveCampaign fügt den List-Unsubscribe-Header automatisch hinzu, wenn du die integrierte Abmeldefunktion und ein konfiguriertes Abmeldeformular nutzt. Bei transaktionalen Templates ohne Abmeldelink gilt die Anforderung nicht.

Wie lange dauert die Erholung der Domain-Reputation nach einer Verbesserung?

Domain-Reputation bei Gmail baut sich über Wochen auf. Wenn E-Mails vorher häufig im Spam gelandet oder geblockt wurden, dauert es in der Regel vier bis acht Wochen sauberen Versendens, bis der Reputation-Score steigt. In dieser Zeit hilft es, das Versandvolumen schrittweise zu steigern statt sofort den vollen Verteiler anzuschreiben. Google Postmaster Tools zeigt den Reputation-Status täglich und ist das verlässlichste Monitoring-Instrument.

Gilt das auch für Transaktions-E-Mails, nicht nur für Newsletter?

Ja. Die Anforderungen gelten für alle E-Mails an Gmail- oder Yahoo-Adressen, unabhängig von der Art. Die Bulk-Sender-Schwelle von 5.000 E-Mails täglich an Gmail kann auch durch Transaktions-E-Mails überschritten werden. Ein Online-Shop, der täglich Tausende Bestellbestätigungen an Gmail-Adressen verschickt, fällt unter die Bulk-Sender-Anforderungen und braucht SPF, DKIM, DMARC und One-Click-Unsubscribe.

Muss DMARC auch für Subdomains separat eingerichtet werden?

Nicht zwingend. Der DMARC-Eintrag der Hauptdomain kann mit dem Parameter sp=reject eine Subdomain-Policy setzen; alle Subdomains erben dann dieselbe strenge Policy, auch wenn sie keinen eigenen DMARC-Eintrag haben. Wenn du bestimmte Subdomains mit einer milderen Policy betreiben willst – zum Beispiel eine Subdomain für Testsendungen –, richtest du dort einen separaten DMARC-Eintrag ein, der die übergeordnete Policy überschreibt.

Wer SPF, DKIM und DMARC korrekt eingerichtet hat, hat die technische Grundlage für zuverlässige E-Mail-Zustellbarkeit gelegt – zu Gmail, Yahoo und den DACH-spezifischen Providern gleichermaßen. Der nächste sinnvolle Schritt ist das Monitoring: DMARC-Reports regelmäßig auswerten und die Policy schrittweise verschärfen. Wer dabei fachliche Unterstützung sucht, findet auf der Seite zur ActiveCampaign-Agentur von Advertal einen Überblick, wie dieser Einrichtungsprozess begleitet wird.