E-Mail-Authentifizierung bei den weltweit größten KI-Unternehmen

Die KI-Branche hat zwei Jahre lang daran gearbeitet, überzeugende digitale Identitätsfälschungen für jedermann mühelos möglich zu machen. Wir haben uns vorgenommen zu prüfen, wie gut die weltweit führenden KI-Unternehmen ihre eigenen Unternehmensdomains gegen genau dieselben Risiken der Identitätsfälschung schützen. Am 6. August 2026 führten wir Live-Tests mit rekursiven DNS-Abfragen für acht zentrale E-Mail-Sicherheitsprotokolle bei 30 großen KI-Unternehmen durch.

Das wichtigste Ergebnis ist einfach: Jedes einzelne Unternehmen hat die grundlegenden Maßnahmen zur E-Mail-Authentifizierung umgesetzt. Alle 30 veröffentlichen SPF- und DMARC-Einträge, und mindestens 28 bestätigen DKIM. Sobald man jedoch über diese Grundlagen hinausblickt, verschlechtert sich die Sicherheitslage drastisch. Nur zwei von dreißig Unternehmen veröffentlichen MTA-STS. Nur sechs signieren ihre DNS-Einträge mit DNSSEC, und 19 lassen ihre SPF-Einträge weiterhin auf „Softfail“ eingestellt.

Kein einziges Unternehmen aus dem KI-Bereich in unserem Benchmark veröffentlicht MTA-STS. Die einzigen beiden Akteure in der Analyse, die dies tun, sind Google und Microsoft.

Dadurch ist jedes KI-Startup in dieser Gruppe anfällig für Downgrade-Angriffe und das Abfangen von Datenverkehr während der Übertragung, selbst wenn seine DMARC-Einträge die Überprüfung bestehen.

Überprüfen Sie die Sicherheit Ihrer Domain

Möchten Sie wissen, wie es um Ihre eigene Domain steht? Überprüfen Sie Ihre Domain-Einstellungen in Echtzeit mit dem PowerDMARC Domain Analyzer in Echtzeit und erkunden Sie gleichzeitig den vollständigen Benchmark-Datensatz.

Was wir gemessen haben und wie

Unsere Stichprobe umfasst 30 führende KI-Unternehmen: OpenAI, Anthropic, Google, DeepMind, Microsoft, Meta AI, NVIDIA, Amazon, Apple, IBM, xAI, Mistral, Cohere, Perplexity, Hugging Face, Stability AI, Midjourney und Character.AI, ElevenLabs, Runway, Databricks, Scale AI, DeepSeek, Cursor, Replit, Groq, Together AI, Cerebras, Writer und Glean. Wir haben am 6. August 2026 die oberste Unternehmensdomain jeder Organisation ausgewertet – Google und DeepMind werden in diesem Bericht als separate oberste Domains erfasst.

Wir haben acht spezifische Protokolle und Parameter gemessen: SPF-Einträge, Vorhandensein eines DKIM-Selektors, Implementierung von DMARC-Richtlinien, DNSSEC-Validierung, MTA-STS, TLS-RPT, BIMI (Brand Indicators for Message Identification) sowie MX-Dienstanbieter. Wir haben öffentliche rekursive Resolver (1.1.1.1, 8.8.8.8, 9.9.9.9, 8.8.4.4) mit aktiviertem EDNS0 abgefragt und pro Eintrag drei bis vier Wiederholungsversuche durchgeführt. SPF-Apex-TXT-Einträge wurden über DNS-over-HTTPS abgerufen, um Probleme beim Fallback auf TCP/53 bei übergroßen TXT-Sätzen zu vermeiden. Die Anzahl der rekursiven SPF-Abfragen wurde streng gemäß RFC 7208, Abschnitt 4.6.4, berechnet.

Um die vollständige Transparenz dieser Untersuchung zu gewährleisten, weisen wir auf sechs eindeutige analytische Einschränkungen hin:

• DKIM-Prüfgrenzen: DKIM-Selektoren können nicht über Standard-DNS-Abfragen ermittelt werden. Unsere Zählung von 28 von 30 stellt eine Untergrenze dar. So lieferte meta.com beispielsweise bei über 100 geprüften Selektoren keine Treffer, was auf einen benutzerdefinierten Selektor hindeutet und nicht auf fehlendes DKIM.
• Platzhalter: databricks.com betreibt einen DNS-Platzhalter unter _domainkey. Jede Selektorabfrage wird aufgelöst, wodurch eine genaue Zählung der Selektoren bedeutungslos wird. Wir haben diese Konfiguration als Platzhalter-Fund vermerkt.
• Apex-Umfang: Wir haben ausschließlich primäre Apex-Domains von Unternehmen getestet. Spezielle Marketing- oder Transaktions-Subdomains wurden nicht berücksichtigt.
• DNS-Fehler bei Untereinbindungen: amazon.com greift auf spf3.amazon.com zurück, dessen Auflösung aufgrund der Größe fehlgeschlagen ist. Die von Amazon erfassten insgesamt vier Abfragen dienen als Untergrenze.
• Zeitpunktbezogener Umfang: DNS-Konfigurationen ändern sich. Diese Daten spiegeln eine aktuelle Momentaufnahme vom 6. August 2026 wider.
• Haltung vs. Sicherheitslücke: Eine lockere Authentifizierungsrichtlinie spiegelt eine schwächere Haltung gegenüber Spoofing wider. Sie bedeutet jedoch weder eine Sicherheitslücke noch eine operative Nachlässigkeit.

Jeder Datenpunkt in diesem Bericht lässt sich mithilfe von Standard-dig-Befehlen gegenüber öffentlichen Resolvern unabhängig überprüfen.

Jeder meistert die Grundlagen der E-Mail-Authentifizierung

Die Basisprotokolle werden im gesamten KI-Sektor flächendeckend angewendet. Alle 30 Unternehmen veröffentlichen einen SPF-Eintrag, alle 30 veröffentlichen einen DMARC-Eintrag und 29 veröffentlichen eine gültige Adresse für die Sammelberichterstattung (rua). Neunzig Prozent der Stichprobe setzen DMARC entweder mit p=quarantine (12 Unternehmen) oder p=reject (15 Unternehmen) durch.

Allerdings spielt der Kontext eine Rolle. Genau 50,0 % dieser führenden KI-Unternehmen wenden eine strenge „p=reject“-Richtlinie an. Zum Vergleich: Unser aktueller Bericht zur DMARC- und MTA-STS-Einführung in den Vereinigten Staaten zeigt eine landesweite Durchsetzungsrate von 49,0 % für „p=reject“. Die wertvollsten KI-Unternehmen der Welt liegen bei der grundlegenden DMARC-Durchsetzung genau im nationalen Durchschnitt.

Wenn Sie verstehen möchten, was „p=reject“ eigentlich bewirkt: Es dient als letzte Sperre, um unberechtigte Nachrichten zu blockieren, bevor sie im Posteingang landen. Drei Unternehmen im Benchmark – Hugging Face, Stability AI und Cerebras – bleiben bei „p=none“, wodurch der Datenverkehr überwacht wird, ohne gefälschte E-Mails zu blockieren.

Matrix zur Protokollübernahme (Stichprobe von 30 führenden KI-Unternehmen)

Quelle: PowerDMARC Live-DNS-Studie (6. August 2026)

Nur zwei von dreißig veröffentlichen MTA-STS

Während die grundlegende Domain-Verifizierung mittlerweile überall üblich ist, sieht es bei der Sicherheit auf der Transportebene ganz anders aus. Von 30 Marktführern veröffentlichen nur Google und Microsoft RFC 8461 MTA-STS-Einträge (Mail Transfer Agent Strict Transport Security) und TLS-RPT (SMTP TLS Reporting). Keines der KI-nativen Start-ups oder spezialisierten Hardware-Anbieter veröffentlicht diese Einträge. In unserem MTA-STS-Leitfaden wird genau erklärt, wie das Protokoll funktioniert.

DMARC und MTA-STS lösen völlig unterschiedliche Probleme im Sicherheitsstapel. DMARC authentifiziert die Identität des Absenders, um das Fälschen von Kopfzeilen zu verhindern. MTA-STS erzwingt verschlüsselte TLS-Verbindungen zwischen Mailservern, um Man-in-the-Middle-Angriffe und Downgrade-Angriffe zu verhindern. Das eine Protokoll ersetzt das andere nicht.

Fairerweise muss man sagen, dass eine Akzeptanzrate von 6,7 % innerhalb dieser Stichprobe immer noch über dem in unserer US-Studie ermittelten nationalen Referenzwert von 1,7 % liegt. Die eigentliche Erkenntnis ist struktureller Natur: Die einzigen Unternehmen im KI-Ökosystem, die die Transportsicherheit durchsetzen, sind die beiden Technologiegiganten, die globale Cloud-E-Mail-Plattformen betreiben. Sie können den Status Ihrer Transportverschlüsselung mit dem PowerDMARC MTA-STS Checker überprüfen.

Die DNSSEC-Lücke – unter Einbeziehung aller großen AI-Akteure der Tech-Branche

DNSSEC (Domain Name System Security Extensions) liefert einen kryptografischen Nachweis dafür, dass DNS-Antworten nicht gefälscht wurden. Nur sechs der dreißig in unserer Untersuchung untersuchten Unternehmen signieren ihre Unternehmenszone mit DNSSEC: Hugging Face, ElevenLabs, Databricks, Scale AI, Writer und Glean. Dies entspricht einer Einführungsrate von 20,0 % und liegt damit leicht über dem US-amerikanischen Landesdurchschnitt von 18,0 %.

Das auffälligste Ergebnis ist, wer fehlt. Kein einziger „Big Tech“-Anbieter in unserer Stichprobe signiert seine primäre Unternehmensdomain mit DNSSEC. Google, Microsoft, Meta, NVIDIA, Amazon, Apple und IBM lassen ihre Apex-Domain allesamt ungesigniert.

Protokoll-Akzeptanzraten: Die 30 führenden KI-Unternehmen im Vergleich zu den Referenzwerten (2026)

Quelle: PowerDMARC-Eigenstudie (August 2026) | Valimail-Branchenbericht 2026

Die unvollständige Einführung von Stability AI

Unsere Überprüfungen haben bei Stability AI eine klassische Sicherheitslücke bei der Bereitstellung aufgedeckt. Die Domain veröffentlicht zwar einen gültigen DNSKEY-Eintrag innerhalb ihrer Zone, es fehlt jedoch ein entsprechender DS-Eintrag (Delegation Signer) beim übergeordneten Registrar. Da die Vertrauenskette auf der obersten Ebene unterbrochen ist, behandeln validierende Resolver die Zone als vollständig unsigniert. Auf dem Papier sieht dies zwar nach Schutz aus, bietet den Endnutzern jedoch keinerlei Sicherheit.

DNSSEC ist für die E-Mail-Sicherheit von unmittelbarer Bedeutung, da SPF-, DKIM- und DMARC-Einträge alle über unverschlüsseltes DNS übertragen werden. Ohne kryptografische Zonensignierung können Angreifer DNS-Antworten während der Übertragung manipulieren, um E-Mail-Kontrollen vollständig zu umgehen.

Neunzehn von dreißig weisen immer noch einen Softfail beim SPF auf

Unsere Untersuchung zeigt, dass 19 von 30 Unternehmen ihren SPF-Eintrag mit dem Qualifizierer „~all“ (Softfail) anstelle von „-all“ (Hardfail) abschließen. Nur neun verwenden Hardfail, während zwei Unternehmen (Meta und Writer) einen „redirect=“-Mechanismus nutzen.

Interessanterweise verwenden 10 der 15 Unternehmen, die „p=reject“ durchsetzen, in ihren SPF-Einträgen weiterhin „~all“. Zu dieser Liste gehören Anthropic, Google, DeepMind, NVIDIA, Perplexity, Character.AI, Databricks, Replit, Groq und Glean. Mit dem PowerDMARC SPF Lookup Tool können Sie die SPF-Syntax Ihrer Domain überprüfen.

In diesem Zusammenhang ist es entscheidend, den Unterschied zwischen der „Softfail“- und der „Hardfail“-Syntax in SPF zu verstehen. Wenn eine Domain DMARC mit der Einstellung „p=reject“ durchsetzt, bestimmt die übergeordnete DMARC-Richtlinie die Zustellung der Nachrichten. Ein „Softfail“ in SPF führt nicht zu einer Sicherheitslücke, solange DMARC aktiv ist. Die Verwendung von „-all“ liefert jedoch ein explizites, eindeutiges Signal für Empfänger, die SPF unabhängig auswerten. Der Wechsel von „Softfail“ zu „Hardfail“ ist nach wie vor eine einfache Möglichkeit, Ihre Sicherheitslage zu stärken.

Aufschlüsselung der SPF-Qualifikanten bei p=reject (15 Unternehmen)

Niemand hat das SPF-Abfrage-Limit überschritten – noch nicht

RFC 7208 legt eine strenge Obergrenze von 10 DNS-Abfragen für die SPF-Auswertung fest. Eine Überschreitung dieser Obergrenze führt zu einem „PermError“, wodurch die SPF-Prüfung vollständig ungültig wird. Keines der 30 Unternehmen überschreitet die Obergrenze von 10 Abfragen. Writer liegt mit 9 Abfragen am nächsten an der Grenze, gefolgt von Perplexity mit 8. OpenAI, Microsoft und Cohere liegen bei 7 Abfragen.

Der SPF-Eintrag von OpenAI ist ein hervorragendes Beispiel für moderne E-Mail-Infrastrukturen in Unternehmen. Die Include-Kette umfasst Google Workspace, Microsoft 365, HubSpot, Marketo und Oracle Cloud. Diese Konfiguration nutzt sieben Lookups, sodass noch drei Lookups als Spielraum verbleiben. Das Hinzufügen von nur einem weiteren externen Marketing-Tool könnte dazu führen, dass der Eintrag nicht mehr ordnungsgemäß funktioniert.

SPF-DNS-Lookup-Spielraum (ausgewählte Unternehmen nahe der Grenze von 10 Lookups)

Fünf Unternehmen lagern die SPF-Verwaltung bereits aus

Die manuelle Verwaltung von Lookups wird bei zunehmendem Umfang schwierig. Fünf Unternehmen in unserem Vergleich nutzen spezielle Dienste von Drittanbietern, um ihre SPF-Infrastruktur zu verwalten:

Vier dieser fünf Organisationen verwenden SPF-Makros anstelle von statischen IP-Listen. SPF-Makros werten eingehende Verbindungen zum Zeitpunkt der Abfrage dynamisch aus und haben sich damit als bewährter Standard für komplexe Unternehmensnetzwerke etabliert.

Unternehmen, die die Abfragebeschränkungen ohne manuelle Nachverfolgung umgehen möchten, können die PowerSPF-Hosted-SPF-Lösungen von PowerDMARC in Betracht ziehen.

Die Konfiguration des Autors verdeutlicht, warum eine korrekte Implementierung so wichtig ist. Der von ihm verwendete Weiterleitungsmechanismus eines Drittanbieters verbraucht in einem einzigen Schritt neun seiner zehn zulässigen Lookups. Die Nutzung eines verwalteten, gehosteten SPF-Dienstes sollte Ihren Eintrag vereinfachen und nicht fast Ihr gesamtes Lookup-Kontingent aufbrauchen.

Drei Hauptfächer werden weiterhin nur beobachtet

Hugging Face, Stability AI und Cerebras verwenden eine DMARC-Richtlinie mit der Einstellung „p=none“. Diese Einstellung erfasst Zustellberichte, ohne die Domain vor Missbrauch zu schützen. Angreifer können unter Verwendung dieser Domainnamen unbefugte Nachrichten versenden, und die empfangenden Mailserver stellen diese weiterhin wie gewohnt zu.

Diese strategische Entscheidung ist besonders bemerkenswert im Fall von Hugging Face, das als zentrale Anlaufstelle für den Download von offenen KI-Modellgewichten dient. Eine überzeugend gefälschte E-Mail von Hugging Face könnte Entwickler leicht dazu verleiten, kompromittierten Code oder Modelldateien herunterzuladen. Andererseits verdient Hugging Face Anerkennung dafür, dass es als eines von nur sechs Unternehmen in unserer Stichprobe seine Domain mit DNSSEC signiert hat.

Was das bedeutet – und was zu tun ist

Diese umsetzbaren Sicherheitsempfehlungen bieten den analysierten KI-Unternehmen einen gezielten Fahrplan zur Beseitigung von Spoofing-Schwachstellen und zum Schutz ihrer Domain-Reputation. Die Umsetzung dieser E-Mail-Authentifizierungs- und DNS-Kontrollen gewährleistet eine strenge Absenderüberprüfung, sichert die Verschlüsselung während der Übertragung und sorgt für eine kontinuierliche operative Überwachung.

1. DMARC-Durchsetzung erreichen: Ändern Sie Ihre Richtlinie von „p=none“ auf „p=quarantine“ und legen Sie dann einen klaren Zieltermin fest, bis zu dem „p=reject“ erreicht werden soll.
2. Harden-SPF-Qualifikatoren: Ändern Sie die Endung Ihres SPF-Eintrags von „~all“ in „-all“, sobald Ihre DMARC-Gesamtberichte bestätigen, dass alle legitimen Absender übereinstimmen.
3. MTA-STS und TLS-RPT implementieren: Sichern Sie Ihre E-Mails während der Übertragung. DMARC überprüft die Identität des Absenders, während MTA-STS die Verschlüsselung während der Übertragung zwischen den Servern gewährleistet.
4. DNSSEC korrekt aktivieren: Signieren Sie Ihre DNS-Zone und stellen Sie sicher, dass Ihr Registrar den entsprechenden DS-Eintrag veröffentlicht, um die Vertrauenskette zu vervollständigen.
5. SPF-Lookup-Limits verwalten: Behalten Sie die Gesamtzahl Ihrer DNS-Lookups genau im Auge. Nutzen Sie makrobasierte, gehostete SPF-Tools, um zu vermeiden, dass Sie die Obergrenze von 10 Lookups erreichen.
6. Subdomains explizit definieren: Legen Sie in Ihrem DMARC-Eintrag eine explizite „sp=“-Richtlinie fest, um Angreifer daran zu hindern, ungeschützte Subdomains zu fälschen.
7. Verantwortlichkeiten festlegen: Technische Kontrollmaßnahmen erfordern eine regelmäßige Überwachung. Bestimmen Sie ein festes Teammitglied, das die DMARC-Berichte wöchentlich überprüft.

Die Lücke bei der E-Mail-Authentifizierung schließen

Unsere Untersuchung vom August 2026 zeigt, dass alle 30 führenden KI-Unternehmen die Kernelemente der E-Mail-Authentifizierung implementiert haben: SPF, DKIM und DMARC sind durchweg vorhanden. Doch sobald man über diese ersten Schritte hinausblickt, kommt die Umsetzung zum Stillstand. Nur zwei Unternehmen veröffentlichen MTA-STS, nur sechs signieren mit DNSSEC, und neunzehn verlassen sich nach wie vor auf Softfail-SPF-Einträge.

Der KI-Sektor hat die anfängliche Einrichtungsphase erfolgreich abgeschlossen. Der nächste Schritt besteht darin, fortschrittliche Sicherheitsmaßnahmen wie Transportverschlüsselung und Zonensignierung einzuführen, um die verbleibenden Sicherheitslücken zu schließen. Diese Verbesserungen erfordern keinen Anbieterwechsel, sondern lediglich eine gezielte operative Ausrichtung.

Möchten Sie wissen, wie es um Ihre Domain steht? Sie können Ihre eigene Domain mit dem kostenlosen Domain-Record-Checker von PowerDMARC überprüfen oder die kostenlose PowerDMARC-Sicherheitstool-Suite nutzen, um die Sicherheit Ihrer E-Mails zu gewährleisten. E-Mail-Phishing nimmt von Jahr zu Jahr zu, und die hier vorgestellten Unternehmen sind genau die Art von Marken, die Angreifer gerne imitieren. Wenn Sie lieber persönlich besprechen möchten, was diese Schwachstellen für Ihre eigene Domain bedeuten, können Sie sich direkt an unser Team wenden.

Häufig gestellte Fragen

Nutzen große KI-Unternehmen DMARC?

Ja, 100 % der 30 großen KI-Unternehmen, die im Rahmen unserer Untersuchung bewertet wurden, veröffentlichen einen gültigen DMARC-Eintrag. Allerdings setzen nur 90 % eine aktive Richtlinie durch (Quarantäne oder Ablehnung), während 10 % im reinen Überwachungsmodus verbleiben (p = keine).

Wie viele KI-Unternehmen setzen DMARC mit dem Wert „p=reject“ durch?

Genau 15 von 30 Unternehmen (50,0 %) wenden DMARC mit der Einstellung „p=reject“ an. Dies entspricht dem aktuellen nationalen Durchschnitt in den USA von 49,0 %, der anhand umfassenderer Branchen-Benchmarks ermittelt wurde.

Was ist MTA-STS und warum wird es nicht durch DMARC ersetzt?

MTA-STS erzwingt verschlüsselte TLS-Verbindungen für E-Mails, die zwischen Servern übertragen werden. DMARC authentifiziert die Identität des Absenders, um Adressfälschungen zu verhindern. Beide Protokolle schützen unterschiedliche Teile der E-Mail-Pipeline, was bedeutet, dass keines der beiden Protokolle das andere ersetzen kann.

Spielt DNSSEC bei der E-Mail-Authentifizierung eine Rolle?

Ja, DNSSEC schützt Ihre Domain vor DNS-Spoofing und Cache-Poisoning. Da SPF-, DKIM- und DMARC-Einträge auf DNS-Abfragen basieren, stellt DNSSEC sicher, dass diese Richtlinien-Einträge während der Übertragung nicht manipuliert werden können.

Stellt SPF ~all (Softfail) ein Sicherheitsproblem dar?

Nicht, wenn Ihre Domain DMARC mit den Einstellungen „p=quarantine“ oder „p=reject“ durchsetzt. Wenn die DMARC-Durchsetzung aktiv ist, hat sie Vorrang vor dem Softfail. Die Umstellung auf „-all“ (Hardfail) bietet jedoch ein stärkeres Sicherheitssignal für Empfänger, die SPF unabhängig davon überprüfen.

Was ist die Obergrenze für SPF-10-Abfragen und wer nähert sich dieser Grenze?

RFC 7208 begrenzt die SPF-Auswertungen auf 10 rekursive DNS-Abfragen, um einen Missbrauch der Server zu verhindern. Werden mehr als 10 Abfragen durchgeführt, wird ein „PermError“ ausgelöst. In unserer Studie liegt Writer mit 9 Abfragen an der Spitze, gefolgt von Perplexity mit 8.

Wie wurde diese Untersuchung durchgeführt?

Die Daten wurden am 6. August 2026 mithilfe von Live-DNS-Abfragen über öffentliche rekursive Resolver erhoben. Wir haben die Apex-Domains von 30 führenden KI-Unternehmen anhand von acht zentralen E-Mail-Sicherheitsprotokollen gemäß den RFC-Standards ausgewertet.

• Über
• Neueste Beiträge

Milena Baghdasaryan

Content-Spezialist bei PowerDMARC

Milena ist eine erfahrene Autorin und Inhaltserstellerin mit mehr als 7 Jahren Erfahrung in der Erstellung ansprechender Inhalte über IT, Cybersicherheit, virtuelle Veranstaltungen und mehr. Sie hat eine nachgewiesene Erfolgsbilanz bei der Erstellung hochwertiger Arbeiten für internationale Magazine und ist Absolventin renommierter Institutionen wie der New York University Abu Dhabi, UWC China und dem College of Europe.

Neueste Beiträge von Milena Baghdasaryan (alle anzeigen)

• E-Mail-Authentifizierung bei den weltweit größten KI-Unternehmen – 10. August 2026
• Die 5 besten Tools gegen Business-E-Mail-Betrug (BEC) im Jahr 2026 – 31. Juli 2026
• Kostenlose DMARC-Tools: Prüfprogramme, Generatoren und Überwachung (2026) – 30. Juli 2026