• Uwierzytelnianie adresów e-mail w największych na świecie firmach zajmujących się sztuczną inteligencją

Uwierzytelnianie adresów e-mail w największych na świecie firmach zajmujących się sztuczną inteligencją

Ostatnia aktualizacja:
9 czas czytania: 9 minut
Uwierzytelnianie adresów e-mail w największych na świecie firmach zajmujących się sztuczną inteligencją

Kluczowe wnioski

  • Wszystkie 30 ocenianych firm zajmujących się sztuczną inteligencją publikuje podstawowe dane dotyczące uwierzytelniania wiadomości e-mail: rekordy SPF (Sender Policy Framework) i DMARC (Domain-based Message Authentication, Reporting, and Conformance), a co najmniej 28 z nich potwierdza konfigurację DKIM (DomainKeys Identified Mail).
  • Tylko 2 spośród 30 firm (Google i Microsoft) stosują protokoły MTA-STS i TLS-RPT do szyfrowania na warstwie transportowej. Żadna z firm start-upowych zajmujących się sztuczną inteligencją nie stosuje tych zabezpieczeń.
  • Tylko 6 spośród 30 firm stosuje podpisywanie domeny głównej za pomocą protokołu DNSSEC. Co ciekawe, żadna z czołowych firm z branży technologicznej (Google, Microsoft, Meta, NVIDIA, Amazon, Apple, IBM) nie stosuje podpisywania swoich korporacyjnych domen najwyższego poziomu.
  • 19 spośród 30 firm kończy swój wpis SPF kwalifikatorem „~all” (softfail), w tym 10 firm, które stosują rygorystyczną politykę DMARC p=reject.
  • Żadna z firm nie przekracza ścisłego limitu 10 zapytań określonego w sekcji 4.6.4 dokumentu RFC (Request for Comments) 7208, ale kilka z nich zbliża się do tego limitu (Writer – 9, Perplexity – 8, OpenAI/Microsoft/Cohere – 7).
  • Trzy duże firmy (Hugging Face, Stability AI i Cerebras) nadal mają ustawioną wartość p=none, przez co ich główne domeny są narażone na ataki typu spoofing, o ile nie stosują aktywnego blokowania.

Branża sztucznej inteligencji poświęciła dwa lata na to, by przekonujące podszywanie się pod inne osoby w sieci stało się dla każdego dziecinnie proste. Postanowiliśmy sprawdzić, jak skutecznie wiodące światowe firmy z branży AI chronią swoje własne domeny korporacyjne przed dokładnie tymi samymi zagrożeniami związanymi z podszywaniem się. 6 sierpnia 2026 r. przeprowadziliśmy na żywo testy rekurencyjnego wyszukiwania DNS w ramach ośmiu podstawowych protokołów bezpieczeństwa poczty elektronicznej dla 30 największych firm z branży AI.

Główny wniosek jest prosty. Każda z tych firm wdrożyła podstawowy poziom uwierzytelniania poczty elektronicznej. Wszystkie 30 publikują rekordy SPF i DMARC, a co najmniej 28 potwierdza stosowanie DKIM. Gdy jednak wyjdzie się poza te podstawowe elementy, poziom bezpieczeństwa gwałtownie spada. Tylko dwie z trzydziestu firm publikują rekordy MTA-STS. Tylko sześć podpisuje swoje rekordy DNS za pomocą DNSSEC, a 19 nadal pozostawia swoje rekordy SPF ustawione na tryb „softfail”.

Żadna z firm z branży sztucznej inteligencji objętych naszym badaniem porównawczym nie publikuje certyfikatu MTA-STS. Jedynymi dwoma podmiotami uwzględnionymi w analizie, które to robią, są Google i Microsoft.

W związku z tym każda firma z branży sztucznej inteligencji należąca do tej grupy jest narażona na ataki polegające na obniżaniu wiarygodności oraz przechwytywanie ruchu podczas przesyłania, nawet jeśli jej rekordy DMARC przejdą weryfikację.

Sprawdź bezpieczeństwo swojej domeny

Chcesz sprawdzić, jak wygląda sytuacja Twojej domeny? Sprawdź konfigurację swojej domeny w czasie rzeczywistym za pomocą narzędzia narzędzia PowerDMARC Domain Analyzer , przeglądając jednocześnie pełny zbiór danych porównawczych.

Sprawdź bezpieczeństwo swojej domeny-

Co mierzyliśmy i w jaki sposób

Nasza próba badawcza obejmuje 30 czołowych organizacji zajmujących się sztuczną inteligencją: OpenAI, Anthropic, Google, DeepMind, Microsoft, Meta AI, NVIDIA, Amazon, Apple, IBM, xAI, Mistral, Cohere, Perplexity, Hugging Face, Stability AI, Midjourney, Character.AI, ElevenLabs, Runway, Databricks, Scale AI, DeepSeek, Cursor, Replit, Groq, Together AI, Cerebras, Writer oraz Glean. Dokonaliśmy oceny głównej domeny każdej z tych organizacji w dniu 6 sierpnia 2026 r. – w niniejszym raporcie Google i DeepMind są traktowane jako odrębne domeny główne.

Zbadaliśmy osiem konkretnych protokołów i parametrów: konfigurację rekordów SPF, obecność selektora DKIM, wdrożenie polityki DMARC, weryfikację DNSSEC, MTA-STS, TLS-RPT, BIMI (Brand Indicators for Message Identification) oraz dostawców usług MX. Wysłaliśmy zapytania do publicznych rekurencyjnych serwerów nazw (1.1.1.1, 8.8.8.8, 9.9.9.9, 8.8.4.4) z włączoną obsługą EDNS0 i wykonaliśmy od trzech do czterech ponownych prób dla każdego rekordu. Rekordy TXT SPF typu apex zostały pobrane przy użyciu protokołu DNS-over-HTTPS, aby uniknąć problemów związanych z przełączaniem na protokół TCP/53 w przypadku zbyt dużych zestawów rekordów TXT. Liczbę rekurencyjnych wyszukiwań SPF obliczono ściśle zgodnie z sekcją 4.6.4 dokumentu RFC 7208.

Aby zapewnić pełną przejrzystość niniejszych badań, wskazujemy na sześć wyraźnych ograniczeń analitycznych:

  • Ograniczenia testów DKIM: Selektorów DKIM nie da się wyliczyć za pomocą standardowych zapytań DNS. Nasza liczba 28 na 30 stanowi dolną granicę. Na przykład serwis meta.com nie zwrócił żadnych wyników dla ponad 100 sprawdzonych selektorów, co wskazuje raczej na zastosowanie niestandardowego selektora niż na brak DKIM.
  • Symbole wieloznaczne: serwis databricks.com korzysta z symbolu wieloznacznego DNS pod nazwą _domainkey. Każde zapytanie selekcyjne zwraca wynik, przez co podawanie dokładnej liczby selektorów nie ma sensu. Tę konfigurację odnotowaliśmy jako przypadek użycia symbolu wieloznacznego.
  • Zakres badania Apex: Przetestowaliśmy wyłącznie główne domeny korporacyjne typu „apex”. Nie uwzględniono w analizie dedykowanych subdomen marketingowych ani transakcyjnych.
  • Błędy DNS związane z podstronami: serwis amazon.com korzysta z serwera spf3.amazon.com, którego nazwa nie została rozpoznana ze względu na rozmiar. Odnotowana przez Amazon łączna liczba czterech prób wyszukiwania stanowi dolną granicę.
  • Zakres danych z określonego momentu: Konfiguracje DNS ulegają zmianom. Dane te przedstawiają aktualny stan z dnia 6 sierpnia 2026 r.
  • Podejście a naruszenie: Bardziej elastyczna polityka uwierzytelniania oznacza mniej rygorystyczne podejście do przeciwdziałania spoofingowi. Nie oznacza to jednak naruszenia bezpieczeństwa ani zaniedbania operacyjnego.

Każdy punkt danych zawarty w niniejszym raporcie można zweryfikować niezależnie, korzystając ze standardowych poleceń „dig” w publicznych serwerach rozdzielających.

Wszyscy zaliczają podstawy uwierzytelniania poczty elektronicznej

Protokoły bazowe są powszechnie stosowane w całym sektorze sztucznej inteligencji. Wszystkie 30 firm publikuje rekord SPF, wszystkie 30 publikuje rekord DMARC, a 29 podaje prawidłowy zbiorczy adres raportowania (rua). Dziewięćdziesiąt procent badanych firm stosuje DMARC z ustawieniem p=quarantine (12 firm) lub p=reject (15 firm).

Należy jednak wziąć pod uwagę kontekst. Dokładnie 50,0% tych czołowych firm z branży sztucznej inteligencji stosuje rygorystyczną politykę „p=reject”. Dla porównania, nasz najnowszy raport dotyczący wdrażania standardów DMARC i MTA-STS w Stanach Zjednoczonych wskazuje, że w skali kraju wskaźnik stosowania polityki „p=reject” wynosi 49,0%. Najbardziej wartościowe na świecie firmy z branży sztucznej inteligencji plasują się dokładnie na poziomie średniej krajowej pod względem podstawowego wdrażania standardu DMARC.

Jeśli chcesz zrozumieć, jak działa opcja p=reject, to jest to ostatnia bariera blokująca nieautoryzowane wiadomości, zanim trafią one do skrzynki odbiorczej. Trzy firmy biorące udział w badaniu porównawczym – Hugging Face, Stability AI i Cerebras – nadal korzystają z opcji p=none, która monitoruje ruch bez blokowania fałszywych wiadomości.

Tabela przyjęcia protokołów (próbka 30 największych firm z branży sztucznej inteligencji)

FirmaSPFDKIMDMARCEgzekwowanieDNSSECMTA-STSTLS-RPTBIMI
GooglePASSPASSODRZUĆTAKNIEPASSPASSPASS
MicrosoftPASSPASSODRZUĆTAKNIEPASSPASSNIE
AntropicznyPASSPASSODRZUĆTAKNIENIENIEPASS
OpenAIPASSPASSODRZUĆTAKNIENIENIEPASS
NVIDIAPASSPASSODRZUĆTAKNIENIENIEPASS
Hugging FacePASSPASSBRAKNIEPASSNIENIENIE

Źródło: Badanie PowerDMARC dotyczące usługi Live DNS (6 sierpnia 2026 r.)

Tylko dwóch z trzydziestu opublikowało artykuł dotyczący MTA-STS

Chociaż podstawowa weryfikacja domeny jest powszechnie stosowana, sytuacja w zakresie bezpieczeństwa warstwy transportowej wygląda zupełnie inaczej. Spośród 30 liderów rynku jedynie Google i Microsoft publikują rekordy zgodne ze standardem RFC 8461 MTA-STS (Mail Transfer Agent Strict Transport Security) oraz TLS-RPT (SMTP TLS Reporting). Żadna z firm start-upowych zajmujących się sztuczną inteligencją ani żadna z firm dostarczających specjalistyczny sprzęt nie publikuje tych rekordów. W naszym przewodniku po protokole MTA-STS dokładnie wyjaśniamy, jak działa ten protokół.

Protokoły DMARC i MTA-STS rozwiązują zupełnie różne problemy w ramach stosu zabezpieczeń. DMARC weryfikuje tożsamość nadawcy, aby zapobiegać fałszowaniu nagłówków. MTA-STS wymusza stosowanie szyfrowanych połączeń TLS między serwerami pocztowymi, aby zapobiegać przechwytywaniu wiadomości przez ataki typu „man-in-the-middle” oraz atakom typu „downgrade”. Żaden z tych protokołów nie zastępuje drugiego.

Trzeba jednak uczciwie przyznać, że wskaźnik wdrożenia na poziomie 6,7% w tej próbie nadal przewyższa krajowy poziom odniesienia wynoszący 1,7%, odnotowany w naszych badaniach przeprowadzonych w Stanach Zjednoczonych. Najważniejszy wniosek ma charakter strukturalny: jedynymi firmami w ekosystemie sztucznej inteligencji, które dbają o bezpieczeństwo transmisji danych, są dwaj giganci technologiczni obsługujący globalne platformy poczty w chmurze. Stan szyfrowania transmisji można sprawdzić za pomocą narzędzia PowerDMARC MTA-STS Checker.

Luka w zabezpieczeniach DNSSEC – z uwzględnieniem wszystkich dużych graczy z branży sztucznej inteligencji

DNSSEC (Domain Name System Security Extensions) zapewnia kryptograficzne potwierdzenie, że odpowiedzi DNS nie zostały sfałszowane. Tylko sześć spośród trzydziestu firm objętych naszym badaniem podpisuje swoją strefę korporacyjną za pomocą DNSSEC: Hugging Face, ElevenLabs, Databricks, Scale AI, Writer i Glean. Oznacza to wskaźnik wdrożenia na poziomie 20,0%, nieco przewyższający krajowy poziom odniesienia dla Stanów Zjednoczonych wynoszący 18,0%.

Najbardziej rzuca się w oczy to, kogo brakuje. Żaden z przedstawicieli wielkich firm technologicznych z naszej próby nie podpisał swojej głównej domeny korporacyjnej za pomocą protokołu DNSSEC. Google, Microsoft, Meta, NVIDIA, Amazon, Apple i IBM – wszystkie te firmy pozostawiają swoją domenę najwyższego poziomu niepodpisaną.

Wskaźniki wdrażania protokołów: 30 czołowych firm z branży sztucznej inteligencji w porównaniu z wartościami odniesienia (2026)

Protokół / Parametr30 krajów o najwyższym wskaźniku wdrażania sztucznej inteligencjiPorównawcze dane bazowe dla branży
DMARC włączony100.0%95,8% (wartość odniesienia dla Stanów Zjednoczonych)
p = odrzucenie – wymuszone50.0%49,0% (wartość odniesienia dla Stanów Zjednoczonych)
Opublikowano BIMI36.7%4,0% (wartość bazowa globalna)
Podpisane protokołem DNSSEC20.0%18,0% (wartość odniesienia dla USA)
MTA-STS – tryb aktywny6.7%1,7% (wartość bazowa dla USA)

Źródło: Badania własne PowerDMARC (sierpień 2026 r.) | Raport branżowy Valimail 2026

Niekompletne wdrożenie rozwiązania Stability AI

Nasze analizy ujawniły klasyczną lukę wdrożeniową w serwisie Stability AI. Serwis ten publikuje prawidłowy rekord DNSKEY w swojej strefie, ale brakuje mu odpowiadającego mu rekordu DS (Delegation Signer) u nadrzędnego rejestratora. Ponieważ łańcuch zaufania zostaje przerwany na najwyższym poziomie, programy sprawdzające poprawność traktują tę strefę jako całkowicie niepodpisaną. Na papierze wygląda to na zabezpieczenie, ale w rzeczywistości nie zapewnia żadnego bezpieczeństwa użytkownikom końcowym.

DNSSEC ma bezpośredni wpływ na bezpieczeństwo poczty elektronicznej, ponieważ rekordy SPF, DKIM i DMARC są przesyłane za pośrednictwem zwykłego systemu DNS. Bez kryptograficznego podpisywania stref osoby atakujące mogą manipulować odpowiedziami DNS w trakcie przesyłania, aby całkowicie ominąć mechanizmy kontroli poczty elektronicznej.

Dziewiętnaście z trzydziestu nadal nie spełnia w pełni wymagań SPF

Z naszych badań wynika, że 19 spośród 30 firm kończy swój wpis SPF kwalifikatorem ~all (softfail) zamiast -all (hardfail). Tylko dziewięć stosuje hardfail, natomiast dwie firmy (Meta i Writer) wykorzystują mechanizm redirect=.

Co ciekawe, 10 z 15 firm stosujących ustawienie p=reject nadal używa słowa „~all” w swoich rekordach SPF. Na liście tej znajdują się: Anthropic, Google, DeepMind, NVIDIA, Perplexity, Character.AI, Databricks, Replit, Groq oraz Glean. Składnię rekordu SPF swojej domeny można sprawdzić za pomocą narzędzia PowerDMARC SPF Lookup Tool.

W tym kontekście kluczowe znaczenie ma zrozumienie różnicy między składnią „softfail” a „hardfail” w SPF. Gdy domena stosuje DMARC z ustawieniem p=reject, o dostarczeniu wiadomości decyduje ogólna polityka DMARC. Softfail w SPF nie stwarza luki w zabezpieczeniach, gdy DMARC jest aktywny. Jednak użycie opcji -all stanowi wyraźny i jednoznaczny sygnał dla odbiorców oceniających SPF niezależnie. Przejście z softfail na hardfail pozostaje prostym sposobem na wzmocnienie zabezpieczeń.

Analiza wyników kwalifikacji SPF przy p=odrzucenie (15 firm)

Kwalifikacje do SPFOpisOdsetek firm przy p = odrzucenieProcent
SPF ~ wszystkieSoftfail10 firm66.7%
SPF – wszystkieHardfail4 firmy26.7%
Przekierowanie SPF=Przekierowanie1 firma6.7%

Nikt nie przekroczył limitu wyszukiwań SPF – przynajmniej na razie

Norma RFC 7208 ustanawia ścisły limit 10 zapytań DNS dla oceny SPF. Przekroczenie tego limitu powoduje błąd PermError, który całkowicie unieważnia weryfikację SPF. Żadna z 30 firm nie przekracza limitu 10 zapytań. Najbliżej tego limitu znajduje się firma Writer z wynikiem 9 zapytań, a zaraz za nią Perplexity z wynikiem 8. OpenAI, Microsoft i Cohere mają po 7 zapytań.

Rekord SPF firmy OpenAI stanowi doskonały przykład nowoczesnych rozwiązań poczty elektronicznej w przedsiębiorstwach. Ich łańcuch „includes” obejmuje Google Workspace, Microsoft 365, HubSpot, Marketo oraz Oracle Cloud. Ta konfiguracja wykorzystuje siedem wpisów, pozostawiając trzy wolne miejsca. Dodanie zaledwie jednego dodatkowego zewnętrznego narzędzia marketingowego mogłoby spowodować, że rekord ten przestałby działać prawidłowo.

Rezerwa na wyszukiwanie DNS w usłudze SPF (wybrane firmy zbliżające się do limitu 10 wyszukiwań)

FirmaWykorzystane zapytania DNSRFC 7208 – limit maksymalny
Pisarz910 maks.
Zdezorientowanie810 maks.
OpenAI710 maks.
Microsoft710 maks.
Cohere710 maks.

Pięć firm już zleca zarządzanie SPF na zewnątrz

Ręczne zarządzanie wpisami staje się trudne w przypadku dużych skal. Pięć firm objętych naszym badaniem korzysta z dedykowanych usług zewnętrznych dostawców w celu obsługi swojej infrastruktury SPF:

FirmaPodejście oparte na hostowanym SPFSzczegóły techniczne
NVIDIAOparte na makrachinclude:%{i}._ip.%{h}._ehlo.%{d}._spf.vali.email
ReplitOparte na makrachDynamiczne rozpoznawanie makr w momencie wykonywania zapytania
IBMOparte na makrachinclude:%{ir}.%{v}.%{d}.spf.has.pphosted.com
PisarzPrzekierowaniemechanizm przekierowania wymagający 9 operacji wyszukiwania
Scale AISamodzielne spłaszczaniea:%{i}._.spfflatten.scale.com

Cztery z tych pięciu organizacji stosują makra SPF zamiast statycznych list adresów IP. Makra SPF dynamicznie analizują przychodzące połączenia w momencie wysłania zapytania, co sprawia, że są one sprawdzonym standardem w złożonych sieciach korporacyjnych.

Organizacje, które chcą ominąć ograniczenia dotyczące wyszukiwania bez konieczności ręcznego śledzenia, mogą rozważyć rozwiązanie PowerSPF Hosted SPF firmy PowerDMARC.

Konfiguracja przedstawiona przez autora pokazuje, dlaczego właściwe wdrożenie ma tak duże znaczenie. Stosowany przez nich mechanizm przekierowań zewnętrznych zużywa dziewięć z dziesięciu dozwolonych zapytań w jednym kroku. Korzystanie z zarządzanej, hostowanej usługi SPF powinno uprościć konfigurację rekordów, a nie pochłaniać niemal cały limit zapytań.

Trzy kierunki studiów nadal pozostają wyłącznie pod obserwacją

Firmy Hugging Face, Stability AI i Cerebras stosują politykę DMARC o wartości p=none. To ustawienie pozwala na gromadzenie raportów dostarczalności, nie zapewniając jednak ochrony domeny przed nadużyciami. Osoby atakujące mogą wysyłać nieautoryzowane wiadomości przy użyciu tych nazw domen, a serwery pocztowe, które je odbierają, będą je nadal dostarczać w normalny sposób.

Ta decyzja strategiczna jest szczególnie istotna w przypadku serwisu Hugging Face, który pełni rolę centralnego punktu pobierania otwartych wag modeli AI. Przekonujący fałszywy e-mail od Hugging Face mógłby z łatwością skłonić programistów do pobrania zainfekowanego kodu lub plików modeli. Z drugiej strony należy docenić fakt, że Hugging Face jest jedną z zaledwie sześciu firm w naszej próbie, które podpisały swoją domenę za pomocą protokołu DNSSEC.

Co to oznacza – i co należy poprawić

Te praktyczne zalecenia dotyczące bezpieczeństwa stanowią konkretny plan działania dla analizowanych firm z branży sztucznej inteligencji, mający na celu wyeliminowanie luk związanych ze spoofingiem oraz ochronę reputacji ich domen. Wdrożenie tych środków uwierzytelniania poczty elektronicznej i kontroli DNS zapewnia rygorystyczną weryfikację nadawców, gwarantuje szyfrowanie danych podczas przesyłania oraz umożliwia stały nadzór operacyjny.

  1. Wdrożenie wymogów DMARC: Zmień ustawienia z p=none na p=quarantine, a następnie wyznacz konkretny termin przejścia na p=reject.
  2. Kryteria kwalifikacyjne Harden SPF: Zmień końcówkę rekordu SPF z „~all” na „-all”, gdy zbiorcze raporty DMARC potwierdzą, że wszyscy legalni nadawcy są zgodni.
  3. Wprowadź protokoły MTA-STS i TLS-RPT: zapewnij bezpieczeństwo poczty podczas przesyłania. DMARC weryfikuje tożsamość nadawcy, natomiast MTA-STS zapewnia szyfrowanie transmisji między serwerami.
  4. Prawidłowe włączenie protokołu DNSSEC: Podpisz swoją strefę DNS i upewnij się, że Twój rejestrator opublikuje odpowiedni rekord DS, aby uzupełnić łańcuch zaufania.
  5. Zarządzanie limitami wyszukiwań SPF: Uważnie monitoruj łączną liczbę wyszukiwań DNS. Korzystaj z hostowanych narzędzi SPF opartych na makrach, aby uniknąć przekroczenia limitu 10 wyszukiwań.
  6. Wyraźne zdefiniowanie subdomen: Należy ustawić w rekordzie DMARC wyraźną politykę sp=, aby uniemożliwić atakującym sfałszowanie adresów niezabezpieczonych subdomen.
  7. Wyznacz osobę odpowiedzialną za realizację: Środki kontroli technicznej wymagają regularnego nadzoru. Wybierz jednego z członków zespołu, który będzie co tydzień przeglądał raporty DMARC.

Wypełnianie luki w uwierzytelnianiu wiadomości e-mail

Z naszych badań przeprowadzonych w sierpniu 2026 r. wynika, że wszystkie 30 czołowych firm z branży sztucznej inteligencji wdrożyło podstawowe elementy uwierzytelniania poczty elektronicznej: SPF, DKIM i DMARC są stosowane we wszystkich przypadkach. Jednak wdrażanie tych rozwiązań zatrzymuje się, gdy tylko wyjdzie się poza te wstępne etapy. Tylko dwie firmy publikują MTA-STS, tylko sześć stosuje podpisywanie za pomocą DNSSEC, a dziewiętnaście nadal opiera się na rekordach SPF typu „softfail”.

Sektor sztucznej inteligencji pomyślnie zakończył początkową fazę wdrażania. Kolejnym krokiem jest wdrożenie zaawansowanych mechanizmów kontroli, takich jak szyfrowanie transmisji i podpisywanie stref, w celu wyeliminowania pozostałych luk. Ulepszenia te nie wymagają zmiany dostawców; wymagają jedynie skupienia się na aspektach operacyjnych.

Chcesz sprawdzić, jak wygląda sytuacja Twojej domeny? Możesz to zrobić za pomocą bezpłatnego narzędzia PowerDMARC do sprawdzania rekordów domenowych lub zapoznać się z bezpłatnym pakietem narzędzi bezpieczeństwa PowerDMARC, aby zapewnić bezpieczeństwo swojej poczty elektronicznej. Liczba przypadków phishingu w poczcie elektronicznej rośnie z roku na rok, a firmy przedstawione w tym artykule to właśnie te marki, które atakujący najchętniej podszywają się pod. Jeśli wolisz omówić, co te luki oznaczają dla Twojej domeny, możesz skontaktować się bezpośrednio z naszym zespołem.

Najczęściej zadawane pytania

Czy największe firmy zajmujące się sztuczną inteligencją korzystają z DMARC?

Tak, 100% spośród 30 największych firm z branży sztucznej inteligencji, które poddaliśmy analizie w ramach naszego badania, publikuje prawidłowy rekord DMARC. Jednak tylko 90% z nich stosuje aktywną politykę (kwarantanna lub odrzucenie), podczas gdy 10% pozostaje w trybie wyłącznie monitorującym (p = brak).

Ile firm zajmujących się sztuczną inteligencją stosuje DMARC z ustawieniem p=reject?

Dokładnie 15 spośród 30 firm (50,0%) stosuje protokół DMARC z ustawieniem p=reject. Wynik ten odpowiada aktualnej średniej krajowej w Stanach Zjednoczonych wynoszącej 49,0%, odnotowanej w ramach szerszych badań porównawczych w branży.

Czym jest MTA-STS i dlaczego DMARC go nie zastępuje?

Protokół MTA-STS wymusza stosowanie szyfrowanych połączeń TLS w przypadku wiadomości e-mail przesyłanych między serwerami. Protokół DMARC weryfikuje tożsamość nadawcy, aby zapobiegać fałszowaniu adresów. Oba protokoły chronią różne etapy procesu przesyłania wiadomości e-mail, co oznacza, że żaden z nich nie może zastąpić drugiego.

Czy protokół DNSSEC ma znaczenie dla uwierzytelniania wiadomości e-mail?

Tak, protokół DNSSEC chroni Twoją domenę przed fałszowaniem adresów DNS i zatruwaniem pamięci podręcznej. Ponieważ rekordy SPF, DKIM i DMARC opierają się na zapytaniach DNS, protokół DNSSEC gwarantuje, że te rekordy nie mogą zostać sfałszowane podczas przesyłania.

Czy SPF ~all (softfail) stanowi zagrożenie dla bezpieczeństwa?

Nie, jeśli Twoja domena stosuje politykę DMARC z ustawieniem p=quarantine lub p=reject. Gdy egzekwowanie DMARC jest aktywne, ma ono pierwszeństwo przed softfail. Jednak przełączenie na opcję -all (hardfail) zapewnia silniejszy sygnał bezpieczeństwa dla odbiorców sprawdzających SPF niezależnie.

Czym jest limit wyszukiwania SPF 10 i kto zbliża się do niego?

Standard RFC 7208 ogranicza liczbę rekurencyjnych zapytań DNS podczas weryfikacji SPF do 10, aby zapobiec nadużyciom ze strony serwerów. Przekroczenie limitu 10 zapytań powoduje wygenerowanie błędu PermError. W naszym badaniu na czele znalazł się Writer z wynikiem 9 zapytań, a tuż za nim uplasował się Perplexity z wynikiem 8.

W jaki sposób przeprowadzono te badania?

Dane zebrano 6 sierpnia 2026 r. za pomocą zapytań DNS wysyłanych na żywo do publicznych serwerów rekurencyjnych. Przeanalizowaliśmy korporacyjne domeny najwyższego poziomu 30 największych firm z branży sztucznej inteligencji pod kątem ośmiu podstawowych protokołów bezpieczeństwa poczty elektronicznej zgodnych ze standardami RFC.

CTA