Defaults.Exposed › Behebungen › Guides
DKIM besteht, aber DMARC scheitert: die gappssmtp.com/onmicrosoft.com-Standardsignatur-Falle (2026)
Veröffentlicht 2026-07-08
Zahlen mit Stand 2026-06-29 · Methodik v7. Aggregierte Zensusdaten über 261 Millionen bewertete Domains. Siehe wie wir bewerten.
Ihre Mail besteht DKIM mit der Standardsignatur des Providers — d= endend auf gappssmtp.com (Google Workspace) oder onmicrosoft.com (Microsoft 365) —, aber diese Domain stimmt nicht mit Ihrer From-Domain überein, sodass DMARC kein Bestehen mit Alignment erhält. Aktivieren Sie das Custom-Domain-Signing, um das zu beheben. Von 12.145.313 Domains, die Googles Mailserver autorisieren, setzen nur 18,5% DMARC durch, laut dem Defaults.Exposed-Zensus über 261.086.232 bewertete Domains.
Der Fix ist einer der saubersten in der E-Mail-Authentifizierung: Schalten Sie das DKIM-Signing mit eigener Domain ein. Bei Google Workspace ist das der Bildschirm „E-Mail authentifizieren“ in der Admin-Konsole — Schlüssel erzeugen, einen TXT-Eintrag veröffentlichen, einschalten. Bei Microsoft 365 ist es die DKIM-Seite im Defender-Portal — zwei Selektor-CNAMEs veröffentlichen, aktivieren. Zwanzig Minuten Arbeit, und DMARC bekommt endlich das ausgerichtete Bestehen, auf das es gewartet hat.
Warum besteht DKIM, aber DMARC scheitert trotzdem?
Weil DMARC nicht fragt „gibt es eine gültige DKIM-Signatur?“ — es fragt „gibt es eine gültige DKIM-Signatur für die Domain im From-Header?“ Diese zweite Bedingung heißt Alignment, und sie ist der ganze Sinn von DMARC: der Beweis, dass die Domain, die Ihr Empfänger sieht, die Domain ist, die signiert hat.
Ab Werk signiert Google Workspace Ihre Mail mit einer Domain wie yourdomain-com.20230601.gappssmtp.com (der Datumsstempel variiert je Domain), und Microsoft 365 signiert mit yourtenant.onmicrosoft.com. Beide Signaturen sind kryptografisch gültig — DKIM-Checker sagen pass —, aber die d=-Domain gehört Google oder Microsoft, nicht Ihnen. Selbst unter DMARCs relaxed Alignment, das nur die Übereinstimmung der Organisationsdomains verlangt, ist gappssmtp.com nicht yourdomain.com. Keine Übereinstimmung, kein ausgerichtetes Bestehen, und wenn auch SPF nicht ausrichtet (das kann es oft nicht — Empfänger werten SPF gegen die Return-Path-Domain aus, nicht gegen den From-Header, und Weiterleitung bricht es vollständig), scheitert DMARC.
Das ist die prägende Falle der Provider-Standards: Der Standard bringt Ihnen Zustellbarkeit, nicht Schutz — Alignment ist die fehlende Schlüsseldrehung. Der Zensus zeigt, wie viele Absender beim Standard stehen bleiben: Von den 12.145.313 Domains, die Googles Mailserver über _spf.google.com autorisieren (von 138.927.207 SPF-Veröffentlichern weltweit), setzen nur 18,5% DMARC durch. Microsofts Bild hat dieselbe Form: 10.205.070 Domains autorisieren spf.protection.outlook.com, 85,0% tragen den strikten SPF-Eintrag, den das M365-Setup ihnen mitgibt — und nur 21,7% setzen DMARC durch. Vollständiger Vergleich in unserer SPF-Tabelle der E-Mail-Provider.
Die Falle ist im Alltag unsichtbar: Mail wird zugestellt, Inbox-Tests sehen gut aus, nichts wirft Fehler — bis Sie eine DMARC-Richtlinie veröffentlichen und Ihre eigene Mail daran zu scheitern beginnt. Unser kostenloser Scan macht genau diese Lücke sichtbar.
Wie erkenne ich die Standardsignatur-Falle in Authentication-Results?
Öffnen Sie eine von Ihnen gesendete Nachricht (an ein Gmail- oder Outlook-Postfach), lassen Sie sich das Original / den Rohquelltext anzeigen und suchen Sie den Authentication-Results-Header. Das Erkennungszeichen ist ein DKIM-pass mit dem falschen d= — ein bei Gmail empfangenes Beispiel sieht so aus:
Authentication-Results: mx.google.com;
dkim=pass [email protected];
spf=pass smtp.mailfrom=yourdomain.com;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com
Lesen Sie ihn als drei Fragen:
| Header-Fragment | Was es bedeutet | Urteil |
|---|---|---|
dkim=pass header.d=yourdomain.com | Signatur gültig UND passt zu Ihrer From-Domain | Ausgerichtet — das ist das Ziel |
dkim=pass header.d=…gappssmtp.com oder …onmicrosoft.com | Signatur gültig, aber es ist die Standarddomain des Providers — DMARC ignoriert sie fürs Alignment | Die Falle: Bestehen ohne Schutz |
dkim=fail (beliebiges d=) | Signatur ungültig — anderes Problem | Siehe DKIM reparieren |
Bei von Microsoft empfangener Mail erscheint dieselbe Geschichte als dkim=pass (signature was verified) header.d=yourtenant.onmicrosoft.com neben compauth=fail — das Muster, das der Outlook-Abweisungsleitfaden behandelt.
Zeigt Ihr Header stattdessen sowohl dkim=pass als auch spf=pass bei einem DMARC-Fail, sind Sie im breiteren Alignment-Fall — der Leitfaden DMARC scheitert, aber SPF und DKIM bestehen geht relaxed vs. strict Alignment vollständig durch.
Wie aktiviere ich DKIM-Signing mit eigener Domain?
- Führen Sie den kostenlosen Scan bei defaults.exposed durch, bevor Sie irgendetwas anfassen. Er zeigt, ob Ihre Domain ausgerichtetes DKIM hat, wie Ihre DMARC-Richtlinie tatsächlich lautet und ob Sie nach diesem Fix noch etwas anderes blockiert (SPF, DMARC-Eintragssyntax) — damit Sie die ganze Arbeit nur einmal machen.
- Identifizieren Sie, mit welchem Standard Sie signieren. Prüfen Sie
header.d=in Authentication-Results wie oben:gappssmtp.combedeutet Google-Workspace-Standard,onmicrosoft.combedeutet Microsoft-365-Standard. - Google Workspace: eigenen Schlüssel erzeugen und veröffentlichen. Gehen Sie in der Admin-Konsole zu Apps → Google Workspace → Gmail → E-Mail authentifizieren, wählen Sie Ihre Domain und klicken Sie auf „Neuen Eintrag generieren“ (2048 Bit, sofern Ihr DNS-Host ihn speichern kann). Veröffentlichen Sie den erhaltenen TXT-Eintrag unter
google._domainkey.yourdomain.com, warten Sie auf das DNS (bis zu 48 Stunden), und klicken Sie dann — der Schritt, den alle übersehen — auf Authentifizierung starten. Das Erzeugen des Eintrags bewirkt nichts, solange Sie die Signierung nicht einschalten. Vollständige Anleitung: DKIM auf Google Workspace einrichten. - Microsoft 365: die zwei Selektor-CNAMEs veröffentlichen und aktivieren. Gehen Sie im Defender-Portal zu E-Mail & Zusammenarbeit → Richtlinien & Regeln → Bedrohungsrichtlinien → E-Mail-Authentifizierungseinstellungen → DKIM, wählen Sie Ihre eigene Domain und erstellen Sie die Schlüssel. Veröffentlichen Sie beide CNAMEs —
selector1._domainkeyundselector2._domainkey, zeigend auf die Ziele, die Microsoft Ihnen anzeigt (kopieren Sie die exakten Ziele aus dem Portal — vor Mai 2025 aktivierte Domains enden auf das.onmicrosoft.comIhres Tenants; neuere enden auf.dkim.mail.microsoft) —, und schalten Sie die Signierung dann ein. Zwei Selektoren sind nicht optional: Microsoft rotiert die Schlüssel zwischen ihnen. Vollständige Anleitung: DKIM auf Microsoft 365 einrichten. - Verifizieren Sie die neue Signatur. Senden Sie eine frische Nachricht an ein externes Postfach und prüfen Sie Authentication-Results erneut:
dkim=passsollte jetztheader.d=yourdomain.comzeigen. Wenn Ihr DNS-Panel Ihre Zone automatisch an das CNAME-Ziel angehängt oder den langen TXT-Wert verstümmelt hat, schaltet die Signatur nicht um — Panel-Eigenheiten, nicht der Provider, verursachen hier die meisten Fehler. - Erneut scannen und das ausgerichtete Bestehen nutzen. Bestätigen Sie, dass der Scan ausgerichtetes DKIM zeigt, und setzen Sie es dann ein: Eine DMARC-Richtlinie auf
p=noneschützt nichts. Über alle 261.086.232 bewerteten Domains setzen nur 10,59% DMARC durch (Stand der Daten: 2026-06-29) — ausgerichtetes DKIM ist das, was die Durchsetzung gefahrlos anziehbar macht. Beginnen Sie bei DMARC reparieren.
Macht das Aktivieren von Custom-DKIM irgendetwas kaputt?
Nein — das ist der seltene E-Mail-Authentifizierungs-Fix mit praktisch keinem Explosionsradius: Mail, die mit der Standardsignatur hinausging, geht einfach mit einer besseren hinaus, und der Provider verwaltet die Schlüssel weiter (Microsoft rotiert automatisch über die zwei Selektoren). Der echte Fehlermodus ist die halbe Ausführung — Googles TXT veröffentlichen, aber nie auf „Authentifizierung starten“ klicken, oder nur einen M365-Selektor statt beider veröffentlichen. Und löschen Sie die DNS-Einträge später nicht „zum Aufräumen“; die Signierung stoppt in dem Moment, in dem der Schlüssel verschwindet.
Eine Anmerkung zum Geltungsbereich: Das repariert Mail, die über Google oder Microsoft läuft. Newsletter-Tools und CRMs signieren ebenfalls mit ihren eigenen Standards, und jedes braucht sein eigenes eingeschaltetes Custom-Domain-DKIM — dieses Muster, und die Gmail-Bulk-Sender-Regeln, die es inzwischen verlangen, behandelt der 550-5.7.26-Leitfaden.
Häufig gestellte Fragen
DKIM zeigt in jedem Testtool „pass“ — warum muss überhaupt etwas repariert werden?
Weil die Tools eine engere Frage beantworten als DMARC. Die Signatur ist gültig — aber sie gehört gappssmtp.com oder onmicrosoft.com, nicht Ihnen, und zählt daher fürs DMARC-Alignment nichts. Deshalb bleiben so viele Absender beim Standard stehen: Von 12.145.313 Google-autorisierenden Domains setzen nur 18,5% DMARC durch (Stand der Daten: 2026-06-29).
Lässt relaxed DMARC-Alignment die Standardsignatur bestehen?
Nein. Relaxed Alignment lockert nur die Übereinstimmung auf Organisationsdomains — mail.yourdomain.com richtet sich mit yourdomain.com aus. Die Organisationsdomain der Standardsignatur ist gappssmtp.com oder onmicrosoft.com, die mit Ihrer nichts teilt. Kein Alignment-Modus rettet ein fremdes d=.
Ist die gappssmtp.com/onmicrosoft.com-Signatur schlecht? Sollte ich sie entfernen? Sie ist nicht schlecht — sie stellt sicher, dass Ihre Mail irgendeine gültige Signatur trägt, was der Spamfilterung hilft. Sie ist nur nicht Ihre. Sie entfernen sie nicht; Sie ersetzen sie, indem Sie das Custom-Domain-Signing aktivieren.
Meine Domain liegt auf Microsoft 365 mit striktem SPF — bin ich damit schon abgedeckt?
Wahrscheinlich nicht: Dieser strikte Eintrag ist der M365-Standard, der seinen einen Job macht. Von 10.205.070 Domains, die spf.protection.outlook.com autorisieren, haben 85,0% striktes SPF, aber nur 21,7% setzen DMARC durch (Stand der Daten: 2026-06-29). SPF bricht außerdem bei Weiterleitungen, weil es gegen den Return-Path statt den From-Header ausgewertet wird — ausgerichtetes DKIM ist das Standbein, das überlebt, und genau deshalb zählt dieser Fix.
Wie lange dauert der Fix? Die Konsolenarbeit sind Minuten je Provider. Das DNS ist die Wartezeit: Google empfiehlt, bis zu 48 Stunden zu warten, bevor Sie die Authentifizierung starten; Microsofts CNAMEs sind meist binnen Stunden live. Rechnen Sie mit einem Arbeitstag von Anfang bis Ende, das meiste davon Warten.
Senden Sie dem Inhaber den Bericht
Wenn Sie das für einen Kunden oder Ihren Arbeitgeber beheben, schließen Sie den Kreis mit einem Beleg. Führen Sie den kostenlosen Scan erneut durch, sobald die neue Signatur live ist, und leiten Sie den bewerteten Bericht an den Geschäftsinhaber weiter: datiert, in klarer Sprache, mit DKIM ausgerichtet auf seine Domain. Das ist das Dokument für die Cyberversicherungs-Verlängerung und den nächsten Lieferanten-Sicherheitsfragebogen — der Nachweis, dass die Domain als sie selbst authentifiziert, nicht als Untermieter von gappssmtp.com.
Prüfen Sie Ihr DKIM-Alignment kostenlos
Sehen Sie, ob Ihre Mail als Ihre eigene Domain signiert — und was genau zu reparieren ist — privat und nur für den Inhaber.
Prüfen Sie Ihre Domain → · DMARC scheitert, aber SPF und DKIM bestehen → · DKIM reparieren → · DKIM auf Google Workspace einrichten → · Nur aggregierte Daten. Daten werden in der EU gespeichert und verarbeitet.