MAILCRAFT
Start Funkcje Cennik O nas Blog Kontakt Zaloguj się Rozpocznij →
Konfiguracja konta pocztowego

Wyrównanie DMARC: dlaczego SPF i DKIM przechodzą, a DMARC nie

DMARC Alignment: Why SPF and DKIM Pass but DMARC Fails

W skrócie: DMARC może nie przejść, nawet gdy SPF i DKIM przechodzą, bo te testy mogły uwierzytelnić jakąś inną domenę, a nie tę z widocznego adresu From. Jeśli domeny się nie zgadzają, wynik pozytywny nie liczy się do wyrównania DMARC. Widzę to bez przerwy. Platforma wysyłkowa pokazuje zielone znaczki przy SPF i DKIM, a raporty DMARC dalej wykazują błędy. Irytujące? Bardzo. Poniżej omawiam, które domeny są porównywane, czym różni się wyrównanie luźne od ścisłego, co zwykle idzie nie tak przy zewnętrznych nadawcach i jak czytać nagłówki, które pokazują niezgodność.

Co właściwie sprawdza wyrównanie DMARC?

Sprawdza jedną rzecz: czy domena w nagłówku From: zgadza się z domeną, którą uwierzytelnił SPF albo DKIM. Jak wyjaśnia przewodnik Google o konfiguracji DMARC, wiadomość przechodzi lub nie przechodzi DMARC zależnie od tego, jak bardzo domena From: pasuje do domeny nadawcy z SPF lub DKIM. Nie trzeba, żeby oba się zgadzały. Wystarczy jeden mechanizm, który przechodzi i jest wyrównany. Z perspektywy marketera w grę wchodzą zwykle trzy domeny: adres From, który czytają odbiorcy, Return-Path (adres zwrotny dla odbić, który sprawdza SPF) oraz domena podpisu DKIM, widoczna w podpisie jako d=.

Które domeny są porównywane: From, Return-Path i DKIM d=

Przy wyrównaniu SPF domena From jest porównywana z domeną Return-Path. Przy wyrównaniu DKIM porównuje się ją z domeną d= w podpisie DKIM. I tu jest haczyk. SPF uwierzytelnia wyłącznie adres zwrotny Return-Path, a wiele platform domyślnie ustawia go na własną domenę. SPF przechodzi więc dla platformy, a Twoja domena marki nic z tego nie ma. Z DKIM może być tak samo. Jeśli platforma podpisuje wiadomości jako d=platform.com, podpis weryfikuje się bez problemu. Po prostu nie jest wyrównany z yourbrand.com.

Oto trzy pola nagłówka, których szukasz:

  1. From: adres widoczny dla odbiorców i domena, którą chroni DMARC.
  2. Return-Path (widoczny też jako smtp.mailfrom): domena odbić, którą uwierzytelnia SPF.
  3. DKIM d= (widoczne też jako header.d): domena, która podpisała wiadomość.

Wyrównanie luźne i ścisłe: tagi aspf i adkim

Wyrównanie luźne akceptuje subdomeny domeny From. Ścisłe wymaga dokładnego dopasowania i nic mniej. Według dokumentacji Google o rekordzie DMARC tryb wyrównania dla SPF i DKIM ustawiasz w rekordzie DMARC tagami aspf i adkim. „r” oznacza tryb luźny (domyślny), a „s” ścisły. Załóżmy, że wiadomość przychodzi z news.brand.com i jest podpisana jako d=brand.com. Przy luźnym wyrównaniu DKIM przejdzie. Przy ścisłym nie. Jeśli więc błędy pojawiły się zaraz po tym, jak ktoś dodał adkim=s albo aspf=s, pierwsze pytanie jest proste: czy wysyłasz z subdomen?

Dlaczego DMARC nie przechodzi przy zewnętrznej platformie wysyłkowej

Najczęściej platforma uwierzytelnia własną domenę, a nie Twoją. Typowi winowajcy:

  • współdzielony, domyślny podpis DKIM platformy, który wstawia w d= jej własną domenę;
  • Return-Path należący do platformy, przez co SPF przechodzi tylko dla domeny platformy;
  • własny klucz DKIM opublikowany w DNS, ale nigdy niewłączony w ustawieniach platformy (zdarza się częściej, niż myślisz);
  • adres From w innej domenie niż ta, którą zweryfikowano;
  • przekazywanie wiadomości, które wysyła je ponownie z nowego serwera i psuje SPF.

A status w stylu „SPF i DKIM skonfigurowane”? Mówi tylko tyle, że uwierzytelnianie działa. Czy któryś z wyników jest wyrównany z Twoją domeną From, to osobna kwestia, a panel na nią nie odpowie.

Jak sprawdzić wyrównanie DMARC w nagłówkach wiadomości

Otwórz surowe źródło wiadomości testowej i porównaj domenę From z smtp.mailfrom i header.d w linii Authentication-Results. Krok po kroku:

  1. Wyślij kampanię testową na skrzynkę, do której masz dostęp.
  2. Otwórz surową wiadomość (w Gmailu to opcja „Pokaż oryginał”).
  3. Znajdź nagłówek Authentication-Results.
  4. Porównaj trzy domeny: tę po spf=pass smtp.mailfrom=, tę po dkim=pass header.d= i tę w header.from=.

Jeśli widzisz pass przy domenie, która nie jest domeną z header.from, to uwierzytelnianie działa, a wyrównanie nie. Zbiorcze raporty DMARC wymieniają te same domeny, więc ta kontrola pozwala też powiązać błędny wiersz raportu z platformą, która wysłała wiadomość.

Jak naprawić wyrównanie dla domeny wysyłkowej

Najpewniejsze rozwiązanie to sprawić, by platforma podpisywała DKIM Twoją własną domeną. Możesz też ustawić własny Return-Path w swojej domenie, żeby wyrównany był również SPF. Rekordy DNS dla obu znajdziesz w naszym poradniku o konfiguracji SPF, DKIM i DMARC. MailCraft ma kreator konfiguracji tych rekordów i obsługuje własną domenę wysyłkową od planu Pro, co wymieniono wśród funkcji dostarczalności MailCraft. Mimo to wynik i tak trzeba potwierdzić w nagłówkach dla każdego nadawcy, z którego korzystasz. Tu nie ma drogi na skróty. Napraw wyrównanie, póki polityka jest jeszcze w trybie monitorowania, a potem ją zaostrz, korzystając z kroków opisanych w tekście o tym, jak wybrać poziom polityki DMARC.

Po każdej zmianie w DNS lub na platformie wyślij nowy test i ponownie przeczytaj nagłówki. Potem obserwuj kolejne raporty zbiorcze, żeby upewnić się, że wyrównanie DMARC przechodzi dla każdego źródła, które wysyła w imieniu Twojej marki.

FAQ

Czy DMARC wymaga wyrównania zarówno SPF, jak i DKIM?

u003cpu003eNie. Wystarczy jeden mechanizm, który przechodzi i jest wyrównany. Gdybym miał wybrać, postawiłbym na DKIM, bo jego podpis zwykle przetrwa przekazanie wiadomości, a SPF często nie.u003c/pu003e

Wybrać wyrównanie ścisłe czy luźne?

u003cpu003eLuźne jest domyślne i sprawdza się u większości nadawców, którzy wysyłają z subdomen swojej głównej domeny. Ścisłe wybierz tylko wtedy, gdy każda usługa wysyła dokładnie z domeny From. Przy trybie ścisłym każda subdomena nie przejdzie.u003c/pu003e

Dlaczego raporty DMARC pokazują błędy ze źródeł, których nie rozpoznaję?

u003cpu003eMogą to być zapomniane narzędzia, które nadal wysyłają w Twoim imieniu (stary CRM, helpdesk i tym podobne). Może to też być ktoś, kto się pod Ciebie podszywa. Zidentyfikuj każde źródło po domenach Return-Path i DKIM, zanim ruszysz politykę, żeby nie zablokować prawidłowej poczty.u003c/pu003e