Defaults.Exposed › Naprawy › Guides

DKIM przechodzi, ale DMARC nie: pułapka domyślnego podpisu gappssmtp.com / onmicrosoft.com (2026)

Opublikowano 2026-07-08

Dane z 2026-06-29 · metodologia v7. Zagregowane dane ze spisu 261 milionów ocenionych domen. Zobacz jak oceniamy.

Twoja poczta przechodzi DKIM z domyślnym podpisem dostawcy — d= kończące się na gappssmtp.com (Google Workspace) lub onmicrosoft.com (Microsoft 365) — ale ta domena nie pasuje do Twojej domeny From, więc DMARC nie uzyskuje wyrównanego zaliczenia. Włącz podpisywanie z własną domeną, żeby to naprawić. Spośród 12 145 313 domen autoryzujących serwery pocztowe Google, tylko 18,5% wymusza DMARC, zgodnie ze spisem Defaults.Exposed obejmującym 261 086 232 ocenionych domen.

Naprawa to jedna z najczystszych w uwierzytelnianiu poczty: włącz podpisywanie DKIM z własną domeną. W Google Workspace to ekran „Uwierzytelniaj pocztę” w konsoli administracyjnej — wygeneruj klucz, opublikuj jeden rekord TXT, włącz. W Microsoft 365 to strona DKIM w portalu Defender — opublikuj dwa CNAME selektora, włącz. Dwadzieścia minut pracy i DMARC wreszcie uzyskuje wyrównane zaliczenie, na które czekał.

Dlaczego DKIM przechodzi, ale DMARC nadal nie?

Ponieważ DMARC nie pyta „czy jest ważny podpis DKIM?” — pyta „czy jest ważny podpis DKIM dla domeny w nagłówku From?” Ten drugi warunek to wyrównanie, i to jest cały cel DMARC: udowodnienie, że domena, którą widzi Twój odbiorca, jest domeną, która podpisała.

Po wyjęciu z pudełka Google Workspace podpisuje Twoją pocztę domeną jak yourdomain-com.20230601.gappssmtp.com (datownik różni się dla każdej domeny), a Microsoft 365 podpisuje przez yourtenant.onmicrosoft.com. Oba podpisy są kryptograficznie ważne — narzędzia do sprawdzania DKIM mówią pass — ale domena d= należy do Google lub Microsoftu, nie do Ciebie. Nawet przy luźnym wyrównaniu DMARC, które wymaga tylko zgodności organizacyjnych domen, gappssmtp.com to nie yourdomain.com. Brak dopasowania, brak wyrównanego zaliczenia, a jeśli SPF też nie wyrównuje (często nie może — odbiorcy oceniają SPF względem domeny Return-Path, a nie nagłówka From, i przekazywanie całkowicie go niszczy), DMARC nie przechodzi.

To jest definiująca pułapka domyślnych ustawień dostawców: domyślne daje Ci dostarczalność, nie ochronę — wyrównanie to brakujący obrót klucza. Spis pokazuje, ile nadawców zatrzymuje się na wartościach domyślnych: spośród 12 145 313 domen autoryzujących serwery pocztowe Google przez _spf.google.com (z 138 927 207 wydawców SPF na świecie), tylko 18,5% wymusza DMARC. Obraz Microsoftu ma ten sam kształt: 10 205 070 domen autoryzuje spf.protection.outlook.com, 85,0% posiada ścisły rekord SPF, który konfiguracja M365 im daje — i tylko 21,7% wymusza DMARC. Pełne porównanie w naszej tabeli wyników dostawców poczty pod względem SPF.

Pułapka jest niewidoczna w codziennym użytkowaniu: poczta dociera, testy skrzynki wyglądają dobrze, nic nie wywołuje błędu — dopóki nie opublikujesz polityki DMARC i Twoja własna poczta nie zacznie jej nie zaliczać. Nasze bezpłatne skanowanie ujawnia dokładnie tę lukę.

Jak rozpoznać pułapkę domyślnego podpisu w Authentication-Results?

Otwórz wysłaną wiadomość (do skrzynki Gmail lub Outlook), wyświetl oryginał/źródło i znajdź nagłówek Authentication-Results. Sygnałem jest DKIM pass z błędnym d= — przykład odebrany przez Gmail wygląda tak:

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

Odczytaj to jako trzy pytania:

Na poczcie odebranej przez Microsoft, ta sama historia pojawia się jako dkim=pass (signature was verified) header.d=yourtenant.onmicrosoft.com obok compauth=fail — wzorzec opisany w przewodniku odrzucania poczty przez Outlook.

Jeśli Twój nagłówek pokazuje zamiast tego zarówno dkim=pass jak i spf=pass z błędem DMARC, jesteś w szerszym przypadku wyrównania — przewodnik DMARC nie przechodzi, ale SPF i DKIM tak opisuje szczegółowo luźne vs ścisłe wyrównanie.

Jak włączyć podpisywanie DKIM z własną domeną?

1. Uruchom bezpłatne skanowanie na defaults.exposed przed dotykaniem czegokolwiek. Pokazuje, czy Twoja domena ma wyrównany DKIM, jaka jest faktycznie Twoja polityka DMARC i czy cokolwiek innego (SPF, składnia rekordu DMARC) nadal Cię blokuje po tej naprawie — żebyś wykonał całą pracę naraz.
2. Zidentyfikuj, z jakim domyślnym podpisem nadajesz. Sprawdź header.d= w Authentication-Results jak powyżej: gappssmtp.com oznacza domyślny Google Workspace, onmicrosoft.com oznacza domyślny Microsoft 365.
3. Google Workspace: wygeneruj i opublikuj własny klucz. W konsoli administracyjnej przejdź do Aplikacje → Google Workspace → Gmail → Uwierzytelniaj pocztę, wybierz swoją domenę i kliknij Generuj nowy rekord (2048-bit, chyba że Twój host DNS nie może go przechować). Opublikuj rekord TXT, który Ci daje, pod google._domainkey.yourdomain.com, poczekaj na DNS (do 48 godzin), a następnie — krok, który ludzie pomijają — kliknij Rozpocznij uwierzytelnianie. Wygenerowanie rekordu nic nie robi, dopóki nie włączysz podpisywania. Pełny opis: konfiguracja DKIM w Google Workspace.
4. Microsoft 365: opublikuj dwa CNAME selektora i włącz. W portalu Defender przejdź do Współpraca e-mail → Zasady i reguły → Zasady zagrożeń → Ustawienia uwierzytelniania poczty → DKIM, wybierz niestandardową domenę i utwórz klucze. Opublikuj oba CNAME — selector1._domainkey i selector2._domainkey, wskazujące na cele, które pokazuje Microsoft (skopiuj dokładne cele z portalu — domeny włączone przed majem 2025 kończą się na .onmicrosoft.com Twojego dzierżawcy; nowsze kończą się na .dkim.mail.microsoft) — a następnie włącz podpisywanie. Dwa selektory to nie opcja: Microsoft rotuje klucze między nimi. Pełny opis: konfiguracja DKIM w Microsoft 365.
5. Zweryfikuj nowy podpis. Wyślij nową wiadomość do zewnętrznej skrzynki i sprawdź ponownie Authentication-Results: dkim=pass powinien teraz pokazywać header.d=yourdomain.com. Jeśli Twój panel DNS automatycznie dołączył Twoją strefę do celu CNAME lub zniekształcił długą wartość TXT, podpis się nie przełączy — specyfika panelu, a nie dostawca, powoduje tu większość błędów.
6. Ponów skanowanie i zrób z wyrównanego zaliczenia dobry użytek. Potwierdź, że skanowanie pokazuje wyrównany DKIM, a następnie go użyj: polityka DMARC na p=none niczego nie chroni. We wszystkich 261 086 232 ocenionych domenach, tylko 10,59% wymusza DMARC (dane z 2026-06-29) — wyrównany DKIM to to, co sprawia, że bezpieczne jest podniesienie wymuszania. Zacznij od jak naprawić DMARC.

Czy włączenie niestandardowego DKIM coś zepsuje?

Nie — to rzadka naprawa uwierzytelniania poczty, która zasadniczo nie ma pola rażenia: poczta, która wychodziła z domyślnym podpisem, po prostu wychodzi z lepszym, a dostawca nadal zarządza kluczami (Microsoft automatycznie rotuje między dwoma selektorami). Prawdziwy tryb awarii to zrobienie tego do połowy — opublikowanie TXT Google, ale nigdy nie kliknięcie Rozpocznij uwierzytelnianie, lub opublikowanie jednego selektora M365 zamiast obu. I nie usuwaj potem rekordów DNS „dla porządku”; podpisywanie zatrzymuje się w chwili zniknięcia klucza.

Jedna uwaga dotycząca zakresu: to naprawia pocztę wysyłaną przez Google lub Microsoft. Narzędzia do newsletterów i CRM też podpisują własną domeną domyślnie i każde wymaga włączenia niestandardowego DKIM — ten wzorzec i reguły masowych nadawców Gmail teraz tego wymagają, są opisane w przewodniku 550-5.7.26.

Często zadawane pytania

DKIM pokazuje „pass” w każdym narzędziu testowym — dlaczego cokolwiek trzeba naprawiać? Ponieważ narzędzia odpowiadają na węższe pytanie niż DMARC. Podpis jest ważny — ale to gappssmtp.com lub onmicrosoft.com, nie Twój, więc nic nie znaczy przy wyrównaniu DMARC. Dlatego tak wielu nadawców zatrzymuje się na domyślnym: spośród 12 145 313 domen autoryzujących Google, tylko 18,5% wymusza DMARC (dane z 2026-06-29).

Czy luźne wyrównanie DMARC pozwala domyślnemu podpisowi przejść? Nie. Luźne wyrównanie tylko luzuje dopasowanie do organizacyjnych domen — mail.yourdomain.com wyrównuje się z yourdomain.com. Organizacyjną domeną domyślnego podpisu jest gappssmtp.com lub onmicrosoft.com, która nie ma nic wspólnego z Twoją. Żaden tryb wyrównania nie ratuje cudzego d=.

Czy podpis gappssmtp.com / onmicrosoft.com jest zły? Czy powinienem go usunąć? Nie jest zły — zapewnia, że Twoja poczta niesie jakiś ważny podpis, co pomaga filtracji spamu. Po prostu nie jest Twój. Nie usuwasz go; zastępujesz go włączając podpisywanie z własną domeną.

Moja domena jest na Microsoft 365 z ścisłym SPF — czy jestem już chroniony? Prawdopodobnie nie: ten ścisły rekord to domyślne M365 robiące swoje jedyne zadanie. Spośród 10 205 070 domen autoryzujących spf.protection.outlook.com, 85,0% ma ścisły SPF, ale tylko 21,7% wymusza DMARC (dane z 2026-06-29). SPF też psuje się przy przekazywaniu, bo jest oceniany względem Return-Path, a nie nagłówka From — wyrównany DKIM to noga, która przeżywa, i właśnie dlatego ta naprawa ma znaczenie.

Jak długo trwa naprawa? Praca w konsoli to minuty na dostawcę. DNS jest czekaniem: Google mówi, żeby poczekać do 48 godzin przed rozpoczęciem uwierzytelniania; CNAME Microsoftu są zazwyczaj aktywne w ciągu kilku godzin. Zaplanuj jeden dzień roboczy od końca do końca, przez większość oczekując.

Wyślij właścicielowi raport

Jeśli naprawiasz to dla klienta lub pracodawcy, zamknij pętlę z dowodem. Ponów bezpłatne skanowanie gdy nowy podpis jest aktywny i prześlij oceniony raport właścicielowi firmy: z datą, w prostym języku, pokazujący DKIM wyrównany z ich domeną. To artefakt do przedłużenia ubezpieczenia cybernetycznego i kolejnego kwestionariusza bezpieczeństwa dostawcy — dowód, że domena uwierzytelnia się jako ona sama, a nie jako poddomenowiec gappssmtp.com.

Sprawdź wyrównanie DKIM bezpłatnie

Sprawdź, czy Twoja poczta podpisuje się jako Twoja własna domena — i co dokładnie naprawić — prywatnie i tylko dla właściciela.

Sprawdź swoją domenę → · DMARC nie przechodzi, ale SPF i DKIM tak → · Napraw DKIM → · Skonfiguruj DKIM w Google Workspace → · Tylko dane zagregowane. Dane przechowywane i przetwarzane w UE.