E-mailverificatie bij ’s werelds grootste AI-bedrijven

De sector van de kunstmatige intelligentie heeft twee jaar lang gewerkt om overtuigende digitale identiteitsfraude voor iedereen moeiteloos te maken. We hebben besloten te onderzoeken hoe goed ’s werelds toonaangevende AI-bedrijven hun eigen bedrijfsdomeinen beschermen tegen precies dezelfde risico’s op identiteitsfraude. Op 6 augustus 2026 hebben we live recursieve DNS-lookup-tests uitgevoerd voor acht belangrijke e-mailbeveiligingsprotocollen bij 30 grote AI-bedrijven.

De belangrijkste bevinding is eenvoudig. Elk bedrijf heeft de basislaag van e-mailverificatie geïmplementeerd. Alle 30 publiceren SPF- en DMARC-records, en ten minste 28 ondersteunen DKIM. Zodra je verder kijkt dan deze basismaatregelen, daalt het beveiligingsniveau drastisch. Slechts twee van de dertig bedrijven publiceren MTA-STS. Slechts zes ondertekenen hun DNS-records met DNSSEC, en 19 laten hun SPF-records nog steeds ingesteld staan op ‘softfail’.

Geen enkel bedrijf in onze benchmark dat zich volledig op AI richt, publiceert MTA-STS. De enige twee spelers in de analyse die dat wel doen, zijn Google en Microsoft.

Hierdoor is elke AI-startup in deze groep kwetsbaar voor downgrade-aanvallen en het onderscheppen van verkeer tijdens de overdracht, zelfs als hun DMARC-records de verificatie doorstaan.

Controleer de beveiliging van uw domein

Wil je weten hoe het met je eigen domein staat? Controleer de instellingen van je domein in realtime met behulp van de PowerDMARC Domain Analyzer terwijl je de volledige benchmarkdataset doorneemt.

Wat we hebben gemeten en hoe

Onze onderzoekssteekproef omvat 30 toonaangevende AI-organisaties: OpenAI, Anthropic, Google, DeepMind, Microsoft, Meta AI, NVIDIA, Amazon, Apple, IBM, xAI, Mistral, Cohere, Perplexity, Hugging Face, Stability AI, Midjourney en Character.AI, ElevenLabs, Runway, Databricks, Scale AI, DeepSeek, Cursor, Replit, Groq, Together AI, Cerebras, Writer en Glean. We hebben op 6 augustus 2026 het hoofddomein van elke entiteit geëvalueerd – Google en DeepMind worden in dit rapport als afzonderlijke hoofddomeinen behandeld.

We hebben acht specifieke protocollen en parameters gemeten: de configuratie van SPF-records, de aanwezigheid van een DKIM-selector, de implementatie van DMARC-beleid, DNSSEC-validatie, MTA-STS, TLS-RPT, BIMI (Brand Indicators for Message Identification) en MX-serviceproviders. We hebben openbare recursieve resolvers (1.1.1.1, 8.8.8.8, 9.9.9.9, 8.8.4.4) met ingeschakelde EDNS0 geraadpleegd en per record drie tot vier herhalingspogingen uitgevoerd. SPF-apex-TXT-records werden opgehaald via DNS-over-HTTPS om TCP/53-fallback-problemen bij te grote TXT-sets te voorkomen. Het aantal recursieve SPF-opzoekingen werd strikt berekend volgens RFC 7208, paragraaf 4.6.4.

Om dit onderzoek volledig transparant te houden, wijzen we op zes duidelijke analytische beperkingen:

• Beperkingen van DKIM-tests: DKIM-selectors kunnen niet via standaard DNS-query’s worden opgesomd. Ons aantal van 28 op 30 vormt een ondergrens. Zo leverde meta.com bijvoorbeeld geen resultaten op bij meer dan 100 geteste selectors, wat erop wijst dat er sprake is van een aangepaste selector en niet van ontbrekende DKIM.
• Wildcards: databricks.com gebruikt een DNS-wildcard onder _domainkey. Elke selector-query wordt omgezet, waardoor het tellen van exacte selectors geen zin heeft. We hebben deze opzet geregistreerd als een wildcard-vondst.
• Toepassingsgebied: We hebben uitsluitend de primaire topdomeinen van bedrijven getest. Specifieke subdomeinen voor marketing of transacties zijn niet beoordeeld.
• DNS-storingen bij sub-includes: amazon.com maakt gebruik van spf3.amazon.com, dat vanwege de omvang niet kon worden omgezet. Het door Amazon geregistreerde totaal van vier lookups geldt als minimum.
• Reikwijdte op een bepaald moment: DNS-configuraties veranderen. Deze gegevens geven een actuele momentopname weer van 6 augustus 2026.
• Houding versus inbreuk: Een soepeler authenticatiebeleid duidt op een zwakkere aanpak van spoofing. Dit betekent niet dat er sprake is van een beveiligingsinbreuk of operationele nalatigheid.

Elk gegevenspunt in dit rapport kan onafhankelijk worden geverifieerd met behulp van standaard dig-commando’s via openbare resolvers.

Iedereen voldoet aan de basisvereisten voor e-mailverificatie

De standaardprotocollen worden in de hele AI-sector volledig toegepast. Alle 30 bedrijven publiceren een SPF-record, alle 30 publiceren een DMARC-record en 29 publiceren een geldig geaggregeerd rapportageadres (rua). Negentig procent van de steekproef past DMARC toe met de instelling p=quarantine (12 bedrijven) of p=reject (15 bedrijven).

De context speelt echter wel een rol. Precies 50,0% van deze toonaangevende AI-bedrijven hanteert een strikt p=reject-beleid. Ter vergelijking: uit ons recente rapport over de toepassing van DMARC en MTA-STS in de Verenigde Staten blijkt dat het percentage bedrijven dat p=reject hanteert landelijk 49,0% bedraagt. De meest waardevolle AI-bedrijven ter wereld presteren precies op het nationale gemiddelde wat betreft de basisnaleving van DMARC.

Als je wilt begrijpen wat p=reject precies doet: het fungeert als de laatste poort om ongeautoriseerde berichten te blokkeren voordat ze in de inbox terechtkomen. Drie bedrijven in de benchmark – Hugging Face, Stability AI en Cerebras – blijven op p=none staan, waarmee het verkeer wordt gemonitord zonder vervalste e-mails te blokkeren.

Matrix voor de invoering van protocollen (steekproef van 30 grote AI-bedrijven)

Bron: PowerDMARC Live DNS-onderzoek (6 augustus 2026)

Slechts twee van de dertig publiceren MTA-STS

Hoewel basisdomeinverificatie alomtegenwoordig is, ziet het er op het gebied van beveiliging op transportlaag heel anders uit. Van de 30 marktleiders publiceren alleen Google en Microsoft RFC 8461 MTA-STS-records (Mail Transfer Agent Strict Transport Security) en TLS-RPT (SMTP TLS Reporting). Geen enkele AI-gerichte start-up of gespecialiseerde hardwareleverancier publiceert deze records. In onze uitleg over MTA-STS wordt precies beschreven hoe het protocol werkt.

DMARC en MTA-STS lossen totaal verschillende problemen op binnen de beveiligingsstack. DMARC verifieert de identiteit van de afzender om het vervalsen van headers te voorkomen. MTA-STS dwingt versleutelde TLS-verbindingen tussen e-mailservers af om man-in-the-middle-aanvallen en downgrade-aanvallen te voorkomen. Het ene protocol is geen vervanging voor het andere.

Eerlijk gezegd presteert een acceptatiegraad van 6,7% binnen deze steekproef nog steeds beter dan het nationale referentiecijfer van 1,7% dat in ons Amerikaanse onderzoek naar voren kwam. De echte conclusie is van structurele aard: de enige bedrijven in het AI-ecosysteem die transportbeveiliging afdwingen, zijn de twee techgiganten die wereldwijde cloud-e-mailplatforms beheren. Je kunt de status van je transportversleuteling controleren met de PowerDMARC MTA-STS Checker.

De DNSSEC-kloof – met alle grote AI-spelers uit de tech-sector

DNSSEC (Domain Name System Security Extensions) biedt cryptografisch bewijs dat DNS-antwoorden niet zijn vervalst. Slechts zes van de dertig bedrijven in ons onderzoek ondertekenen hun bedrijfsdomein met DNSSEC: Hugging Face, ElevenLabs, Databricks, Scale AI, Writer en Glean. Dat komt neer op een acceptatiegraad van 20,0%, wat iets hoger ligt dan het nationale gemiddelde van 18,0% in de VS.

Het meest opvallende is juist wie er ontbreekt. Geen enkele grote techspeler in onze steekproef beveiligt zijn primaire bedrijfsdomein met DNSSEC. Google, Microsoft, Meta, NVIDIA, Amazon, Apple en IBM laten hun topdomein allemaal onbeveiligd.

Protocolacceptatiegraad: Top 30 AI-bedrijven versus referentiewaarden (2026)

Bron: Origineel onderzoek van PowerDMARC (augustus 2026) | Valimail-sectorrapport 2026

De onvolledige implementatie van Stability AI

Uit onze scans is gebleken dat er bij Stability AI sprake is van een klassieke implementatiekloof. Het domein publiceert weliswaar een geldig DNSKEY-record binnen zijn zone, maar er ontbreekt een bijbehorend DS-record (Delegation Signer) bij de bovenliggende registrar. Omdat de vertrouwensketen op het hoogste niveau wordt onderbroken, beschouwen validerende resolvers de zone als volledig onondertekend. Op papier lijkt het een beveiligingsmaatregel, maar het biedt eindgebruikers geen enkele bescherming.

DNSSEC is van direct belang voor de e-mailbeveiliging, omdat SPF-, DKIM- en DMARC-records allemaal via onversleuteld DNS worden verzonden. Zonder cryptografische zoneondertekening kunnen aanvallers DNS-antwoorden tijdens de overdracht manipuleren om e-mailcontroles volledig te omzeilen.

Negentien van de dertig hebben nog steeds een ‘softfail’ bij SPF

Uit ons onderzoek blijkt dat 19 van de 30 bedrijven hun SPF-record afsluiten met een ~all (softfail) in plaats van een -all (hardfail). Slechts negen bedrijven gebruiken hardfail, terwijl twee bedrijven (Meta en Writer) gebruikmaken van een redirect=-mechanisme.

Het is opmerkelijk dat 10 van de 15 bedrijven die p=reject hanteren, nog steeds ~all in hun SPF-records gebruiken. Op deze lijst staan onder meer Anthropic, Google, DeepMind, NVIDIA, Perplexity, Character.AI, Databricks, Replit, Groq en Glean. Je kunt de SPF-syntaxis van je domein controleren met de PowerDMARC SPF Lookup Tool.

In deze context is het van cruciaal belang om het verschil tussen de syntaxis van ‘softfail’ en ‘hardfail’ in SPF te begrijpen. Wanneer een domein DMARC met p=reject toepast, bepaalt het algemene DMARC-beleid of berichten worden afgeleverd. Een ‘softfail’ in SPF leidt niet tot een beveiligingslek wanneer DMARC actief is. Het gebruik van -all geeft echter een expliciet, ondubbelzinnig signaal aan ontvangers die SPF onafhankelijk beoordelen. De overstap van ‘softfail’ naar ‘hardfail’ blijft een eenvoudige manier om je beveiligingsniveau te versterken.

Uitsplitsing van SPF-kwalificatie bij p=afgewezen (15 bedrijven)

Niemand heeft de limiet voor SPF-opzoekingen overschreden – voorlopig nog niet

RFC 7208 stelt een strikte limiet van 10 DNS-lookups vast voor de SPF-evaluatie. Overschrijding van deze limiet leidt tot een PermError, waardoor de SPF-controle volledig ongeldig wordt. Geen van de 30 bedrijven overschrijdt de limiet van 10 lookups. Writer zit met 9 lookups het dichtst bij de limiet, gevolgd door Perplexity met 8. OpenAI, Microsoft en Cohere zitten op 7 lookups.

Het SPF-record van OpenAI is een goed voorbeeld van moderne e-mailoplossingen voor bedrijven. Hun ‘include chain’ omvat Google Workspace, Microsoft 365, HubSpot, Marketo en Oracle Cloud. Deze configuratie maakt gebruik van zeven lookups, waardoor er nog drie lookups overblijven als reserve. Als er nog maar één externe marketingtool wordt toegevoegd, zou hun record een operationele storing kunnen veroorzaken.

SPF DNS-opzoekcapaciteit (geselecteerde bedrijven die de limiet van 10 opzoekingen bijna hebben bereikt)

Vijf bedrijven besteden het SPF-beheer al uit

Het handmatig beheren van lookups wordt lastig naarmate de schaal toeneemt. Vijf bedrijven in onze benchmark maken gebruik van gespecialiseerde externe diensten voor het beheer van hun SPF-infrastructuur:

Vier van deze vijf organisaties maken gebruik van SPF-macro’s in plaats van statische IP-lijsten. SPF-macro’s beoordelen inkomende verbindingen dynamisch op het moment van de query, waardoor ze een beproefde standaard zijn voor complexe bedrijfsnetwerken.

Organisaties die de opzoeklimieten willen omzeilen zonder handmatig bij te houden, kunnen de PowerDMARC PowerSPF Hosted SPF-oplossingen overwegen.

De configuratie van de schrijver laat zien waarom een correcte implementatie zo belangrijk is. Hun omleidingsmechanisme van een derde partij verbruikt in één enkele stap negen van de tien toegestane lookups. Het gebruik van een beheerde, gehoste SPF-dienst zou je record moeten vereenvoudigen, en niet bijna je hele lookup-budget opgebruiken.

Drie studierichtingen zijn nog steeds uitsluitend voor observatie

Hugging Face, Stability AI en Cerebras hanteren een DMARC-beleid met de instelling p=none. Bij deze instelling worden afleveringsrapporten verzameld, maar wordt het domein niet beschermd tegen misbruik. Aanvallers kunnen met behulp van deze domeinnamen ongeautoriseerde berichten versturen, en de ontvangende mailservers zullen deze berichten gewoon afleveren.

Deze beleidskeuze is met name opmerkelijk voor Hugging Face, dat fungeert als het centrale knooppunt voor het downloaden van open AI-modelgewichten. Een overtuigende valse e-mail van Hugging Face zou ontwikkelaars gemakkelijk kunnen misleiden om gecompromitteerde code of modelbestanden te downloaden. Aan de andere kant verdient Hugging Face lof omdat het een van de slechts zes bedrijven in onze steekproef is die zijn domein met DNSSEC heeft ondertekend.

Wat dit betekent – en wat eraan gedaan moet worden

Deze praktische beveiligingsaanbevelingen bieden de geanalyseerde AI-bedrijven een gericht stappenplan om kwetsbaarheden voor spoofing weg te werken en de reputatie van hun domein te beschermen. Door deze maatregelen voor e-mailverificatie en DNS-beheer te implementeren, wordt strikte verificatie van afzenders afgedwongen, wordt de versleuteling tijdens het transport gewaarborgd en wordt er continu operationeel toezicht ingesteld.

1. DMARC-handhaving realiseren: wijzig uw beleid van p=none naar p=quarantine en stel vervolgens een duidelijke streefdatum vast om p=reject te bereiken.
2. Harden SPF-kwalificaties: Wijzig het einde van je SPF-record van ~all in -all zodra uit je DMARC-geaggregeerde rapporten blijkt dat alle legitieme afzenders aan de vereisten voldoen.
3. Implementeer MTA-STS en TLS-RPT: beveilig uw e-mail tijdens het transport. DMARC controleert de identiteit van de afzender, maar MTA-STS zorgt voor versleuteling tijdens het transport tussen servers.
4. Schakel DNSSEC op de juiste manier in: onderteken uw DNS-zone en zorg ervoor dat uw registrar het bijbehorende DS-record publiceert om de vertrouwensketen te voltooien.
5. SPF-opzoeklimieten beheren: Houd uw totale aantal DNS-opzoekingen nauwlettend in de gaten. Gebruik op macro’s gebaseerde, gehoste SPF-tools om te voorkomen dat u de limiet van 10 opzoekingen bereikt.
6. Subdomeinen expliciet definiëren: Stel in uw DMARC-record een expliciet sp=-beleid in om te voorkomen dat aanvallers onbeveiligde subdomeinen vervalsen.
7. Wijs operationele verantwoordelijkheid toe: Technische maatregelen moeten regelmatig worden gecontroleerd. Wijs een specifiek teamlid aan om de DMARC-rapporten wekelijks door te nemen.

De kloof op het gebied van e-mailverificatie dichten

Uit ons onderzoek van augustus 2026 blijkt dat alle 30 toonaangevende AI-bedrijven de kernelementen van e-mailverificatie hebben geïmplementeerd: SPF, DKIM en DMARC zijn zonder uitzondering aanwezig. De implementatie stopt echter zodra je verder kijkt dan deze eerste stappen. Slechts twee bedrijven publiceren MTA-STS, slechts zes gebruiken DNSSEC-ondertekening en negentien vertrouwen nog steeds op softfail SPF-records.

De AI-sector heeft de eerste implementatiefase met succes afgerond. De volgende stap is het invoeren van geavanceerde beveiligingsmaatregelen, zoals transportversleuteling en zone-ondertekening, om de resterende hiaten te dichten. Voor deze verbeteringen is het niet nodig om van leverancier te wisselen; er is alleen operationele aandacht voor nodig.

Wilt u weten hoe uw domein ervoor staat? U kunt uw eigen domein controleren met de gratis domeinrecordchecker van PowerDMARC of de gratis beveiligingstools van PowerDMARC verkennen om de beveiliging van uw e-mail te verbeteren. Het aantal gevallen van e-mailphishing neemt elk jaar toe, en de bedrijven die hier worden genoemd, zijn precies het soort merken dat aanvallers graag nabootsen. Als u liever persoonlijk wilt bespreken wat deze tekortkomingen voor uw eigen domein betekenen, kunt u rechtstreeks contact opnemen met ons team.

Veelgestelde Vragen

Maken grote AI-bedrijven gebruik van DMARC?

Ja, 100% van de 30 grote AI-bedrijven die in ons onderzoek zijn geëvalueerd, publiceert een geldig DMARC-record. Slechts 90% past echter een actief beleid toe (in quarantaine plaatsen of afwijzen), terwijl 10% in de modus ‘alleen monitoren’ blijft (p = geen).

Hoeveel AI-bedrijven passen DMARC toe met p=reject?

Precies 15 van de 30 bedrijven (50,0%) passen DMARC toe met de instelling p=reject. Dit komt overeen met het huidige nationale gemiddelde in de VS van 49,0%, zoals vastgesteld in bredere sectorbrede benchmarks.

Wat is MTA-STS en waarom wordt het niet vervangen door DMARC?

MTA-STS zorgt ervoor dat e-mails tijdens het transport tussen servers via versleutelde TLS-verbindingen worden verzonden. DMARC verifieert de identiteit van de afzender om adresvervalsing te voorkomen. Ze beschermen verschillende onderdelen van het e-mailproces, wat betekent dat geen van beide protocollen het andere kan vervangen.

Is DNSSEC van belang voor e-mailverificatie?

Ja, DNSSEC beschermt uw domein tegen DNS-spoofing en cache poisoning. Aangezien SPF-, DKIM- en DMARC-records afhankelijk zijn van DNS-verzoeken, zorgt DNSSEC ervoor dat deze beleidsrecords tijdens de overdracht niet kunnen worden gemanipuleerd.

Is SPF ~all (softfail) een beveiligingsprobleem?

Niet als je domein DMARC handhaaft met p=quarantine of p=reject. Wanneer DMARC-handhaving actief is, heeft dit voorrang op de softfail. Overschakelen naar -all (hardfail) biedt echter een sterker beveiligingssignaal voor ontvangers die SPF afzonderlijk controleren.

Wat is de bovengrens voor het opzoeken van SPF 10 en wie zit daar dichtbij?

RFC 7208 beperkt SPF-evaluaties tot 10 recursieve DNS-opzoekingen om misbruik van servers te voorkomen. Bij meer dan 10 opzoekingen wordt een PermError gegenereerd. In ons onderzoek staat Writer bovenaan met 9 opzoekingen, gevolgd door Perplexity met 8.

Hoe is dit onderzoek uitgevoerd?

De gegevens zijn op 6 augustus 2026 verzameld door middel van live DNS-query’s via openbare recursieve resolvers. We hebben de topniveaudomeinen van 30 grote AI-bedrijven beoordeeld aan de hand van acht belangrijke e-mailbeveiligingsprotocollen volgens de RFC-normen.

• Over
• Laatste berichten

Milena Baghdasaryan

Content-specialist bij PowerDMARC

Milena is een ervaren schrijfster en content creator met meer dan 7 jaar ervaring in het creëren van boeiende content over IT, cyberbeveiliging, virtuele evenementen en meer. Ze heeft bewezen werk van hoge kwaliteit af te leveren voor internationale tijdschriften en is afgestudeerd aan prestigieuze instellingen zoals New York University Abu Dhabi, UWC China en het Europacollege.

Laatste berichten van Milena Baghdasaryan (Bekijk alle berichten)

• E-mailverificatie bij ’s werelds grootste AI-bedrijven - 10 augustus 2026
• Top 5 tools voor Business Email Compromise (BEC) in 2026 - 31 juli 2026
• Gratis DMARC-tools: controleprogramma’s, generators en monitoring (2026) - 30 juli 2026