Odbicie 550 5.7.1 z komunikatem "Email rejected per DMARC policy" oznacza, że serwer odbierający pocztę przeprowadził weryfikację DMARC Twojej wiadomości, wiadomość jej nie przeszła, a Twoja własna opublikowana polityka nakazała odbiorcy ją odrzucić. To nie jest przejaw nadmiernej surowości odbiorcy. To Twoja instrukcja p=reject (lub p=quarantine) działa dokładnie tak, jak została zapisana. Rozwiązaniem prawie nigdy nie jest osłabienie polityki. Jest nim znalezienie źródła wysyłki, które nie jest wyrównane (aligned), i poprawne jego autoryzowanie.
Są dwa pytania, które przesądzają o wszystkim: czy odrzucana poczta pochodzi z systemu, który kontrolujesz, czy z narzędzia zewnętrznego (CRM, system fakturowania, help desk, platforma marketingowa), którego zapomniałeś autoryzować? Odpowiedz na to najpierw, a rozwiązanie stanie się oczywiste.
Odczytujemy wyłącznie publiczny DNS. Nic nie zapisujemy, dopóki nie przypiszesz domeny do konta.
Co tak naprawdę oznacza odbicie 550 5.7.1 DMARC
DMARC (RFC 7489) przechodzi weryfikację tylko wtedy, gdy wiadomość spełnia jednocześnie dwa warunki: uwierzytelnia się za pomocą SPF lub DKIM oraz domena, która ten test przeszła, jest wyrównana z domeną widoczną w nagłówku From:. Gdy ani SPF, ani DKIM nie daje wyrównanego wyniku pozytywnego, DMARC nie przechodzi, a odbiorca odczytuje Twoją politykę z DNS.
Jeśli Twój rekord mówi p=reject, zgodny ze standardem odbiorca odmawia przyjęcia wiadomości już na etapie transakcji SMTP i zwraca coś takiego:
550 5.7.1 Unauthenticated email from example.com is not accepted due to domain's DMARC policy
lub, w przypadku Microsoftu i innych:
550 5.7.1 Email rejected per DMARC policy for example.com
Kluczowy jest zwrot "per DMARC policy", a wskazana domena to Twoja domena, ta z nagłówka From:. To mówi Ci, że odbiorca egzekwuje Twoją instrukcję, a nie własną. Porównaj to z odrzuceniem, które wskazuje na wewnętrzne reguły odbiorcy lub listę blokującą - to zupełnie inny problem. Jeśli widzisz blisko spokrewniony wariant z Gmaila, nasz przewodnik o błędzie 550 5.7.26 unauthenticated sender omawia dokładnie to sformułowanie.
Krok 1: odczytaj odbicie i zidentyfikuj IP nadawcy
Otwórz pełną treść wiadomości zwrotnej, nazywanej także raportem o niedostarczeniu (non-delivery report). Szukasz trzech rzeczy:
- Domeny
From:, którą ocenił odbiorca (powinna to być Twoja domena). - Adresu IP lub nazwy hosta nadawcy, który dostarczył wiadomość.
- Ewentualnej linii
Authentication-Results, jeśli odbiorca ją dołączył.
IP nadawcy to najbardziej przydatna pojedyncza wskazówka. Jeśli należy ono do Twojej normalnej platformy pocztowej (Google Workspace, Microsoft 365, Twój własny serwer), masz problem z wyrównaniem lub konfiguracją na znanym źródle. Jeśli IP należy do usługi, którą ledwo pamiętasz, że subskrybowałeś (narzędzie do planowania spotkań, dostawca podpisu elektronicznego, system kadrowo-płacowy), znalazłeś nieautoryzowane źródło wysyłki. To najczęstsza przyczyna nagle pojawiającej się fali odrzuceń DMARC: jakiś dział podłączył narzędzie SaaS, które wysyła "od" Twojej domeny, a nigdy nie zostało dodane do SPF ani nie otrzymało klucza DKIM.
Jeśli odbicie zawiera nagłówek Authentication-Results, odczytaj go uważnie. Nasz przewodnik o tym, jak czytać nagłówek Authentication-Results, wyjaśnia każde pole. Chcesz sprawdzić, czy spf= i dkim= przeszły oraz, co najważniejsze, czy były wyrównane.
Krok 2: odróżnij błąd wyrównania od błędu uwierzytelnienia
To rozróżnienie sprawia kłopot większości osób. Są dwa różne sposoby, na jakie można nie przejść DMARC.
SPF lub DKIM nie przeszły w ogóle
Wiadomość w ogóle nie została uwierzytelniona. SPF zwrócił fail lub softfail, a nie było ważnego podpisu DKIM. Zwykle oznacza to, że źródło wysyłki nie znajduje się w Twoim rekordzie SPF i nie ma klucza DKIM na Twojej domenie. Typowe dla świeżo dodanego narzędzia zewnętrznego.
SPF lub DKIM przeszły, ale nie były wyrównane
To bardziej subtelne i łatwe do przeoczenia. Narzędzie uwierzytelniło się, ale wobec własnej domeny, a nie Twojej. SPF może przejść dla domeny koperty dostawcy (Return-Path), podczas gdy Twoja domena From: jest inna, więc wyrównanie SPF zawodzi. DKIM może być podpisany domeną d= dostawcy zamiast Twoją, więc wyrównanie DKIM zawodzi. DMARC ignoruje uwierzytelnienie, które nie jest wyrównane. Nasz przewodnik o wyrównaniu relaxed a strict wyjaśnia, dlaczego niezgodność subdomeny lub domeny organizacyjnej nadal liczy się jako błąd, a dlaczego DKIM może zawieść, gdy SPF przechodzi omawia bardzo częstą odmianę tej sytuacji.
Potrzebujesz, aby przynajmniej jeden z dwóch, SPF lub DKIM, jednocześnie przeszedł i był wyrównany. Nie potrzebujesz obu naraz.
Krok 3: potwierdź rzeczywisty stan za pomocą narzędzia sprawdzającego
Zgadywanie marnuje godziny. Przepuść swoją domenę przez skaner powyżej i odczytaj, co pokazuje dla danego źródła wysyłki. Wyświetla on Twój aktualny rekord SPF, każdy zawarty w nim include:, Twoje selektory DKIM oraz politykę DMARC dokładnie tak, jak widzą je odbiorcy. Potwierdź trzy rzeczy:
- Czy Twój rekord SPF zawiera mechanizm
include:dostawcy i czy mieści się poniżej limitu 10 zapytań DNS? Jeśli SPF jest po cichu zepsuty przez zbyt wiele zapytań, zobaczysz PermError, który powoduje błąd wyrównania dla wszystkich. Nasze rozwiązanie problemu zbyt wielu zapytań DNS w SPF obejmuje ten przypadek. - Czy pod selektorem używanym przez dostawcę opublikowany jest klucz DKIM, podpisujący Twoją domeną w tagu
d=? - Jaka jest Twoja polityka DMARC i czy jest to
rejectczyquarantine?
Minimalna, wyrównana konfiguracja dla domeny, która wysyła przez jedną platformę, wygląda w DNS tak:
v=spf1 include:_spf.google.com ~all
z rekordem TXT DKIM pod google._domainkey.example.com oraz rekordem DMARC takim jak:
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=r; aspf=r
Krok 4: autoryzuj źródło, nie osłabiaj polityki
Gdy już wiesz, które źródło zawodzi, napraw to źródło. Błędnym ruchem, kuszącym gdy poczta się odbija, jest cofnięcie polityki do p=none. To ponownie otwiera Twoją domenę na podszywanie się i niweczy ochronę, którą zbudowałeś. Zamiast tego napraw wyrównanie.
Jeśli źródłem jest narzędzie zewnętrzne
Zaloguj się do panelu dostawcy i znajdź sekcję uwierzytelniania poczty lub "sending domain". Niemal każda renomowana platforma daje Ci dwie rzeczy: include: do SPF, który należy dodać do rekordu, oraz jeden lub więcej kluczy DKIM (zwykle rekordy CNAME) do opublikowania, aby podpisywała jako Twoja domena. Dodaj include: do istniejącego rekordu SPF, zamiast tworzyć drugi rekord SPF, ponieważ dwa rekordy SPF to sam w sobie PermError. Opublikuj rekordy CNAME dla DKIM, a następnie zweryfikuj w panelu dostawcy, aż zgłosi domenę jako uwierzytelnioną. Mamy przewodniki dostosowane do konkretnych dostawców, którzy często są winowajcami, takich jak HubSpot, Mailchimp, SendGrid i Amazon SES.
Jeśli źródłem jest Twoja własna platforma pocztowa
Wtedy coś jest źle skonfigurowane w systemie, który posiadasz. Sprawdź, czy DKIM w Google Workspace lub Microsoft 365 jest faktycznie włączony i uruchomiony (włączenie w panelu administracyjnym i opublikowanie rekordu DNS to dwa oddzielne kroki, a poczta zawodzi, dopóki oba nie zostaną wykonane). W przypadku dzierżaw Microsoftu nasz przewodnik DMARC dla Microsoft 365 omawia dokładne przełączniki.
Jeśli źródłem jest przekierowanie
Wiadomość przekazana dalej przez listę mailingową lub regułę "przekaż na mój inny adres" psuje SPF, ponieważ IP przekierowującego nie znajduje się w Twoim rekordzie SPF. DKIM zwykle przetrwa przekierowanie, dlatego wyrównanie DKIM ma tak duże znaczenie. Jeśli polegasz wyłącznie na SPF, przekierowana poczta nie przejdzie DMARC i odbije się. Nasz artykuł o tym, dlaczego przekierowanie psuje SPF, pokazuje, dlaczego DKIM jest trwałym rozwiązaniem.
Krok 5: zweryfikuj poprawkę i monitoruj
Zmiany w DNS potrzebują czasu na propagację, od minut do kilku godzin, w zależności od wartości TTL rekordu. Po dodaniu include: lub klucza DKIM wyślij testową wiadomość z dotkniętego źródła na adres, który kontrolujesz, a następnie odczytaj nagłówek Authentication-Results na otrzymanej kopii. Chcesz zobaczyć wyrównany wynik pozytywny, na przykład dkim=pass header.d=example.com, gdzie example.com odpowiada Twojej domenie From:.
Nie uznawaj zadania za zakończone po jednym udanym teście. Raporty zbiorcze DMARC (adres rua= w Twoim rekordzie) wymieniają każde źródło wysyłające jako Twoja domena oraz to, czy każde z nich przechodzi. Ich czytanie to sposób na wychwycenie kolejnego nieautoryzowanego narzędzia, zanim wygeneruje stertę odbić. Nasz przewodnik o czytaniu raportów zbiorczych DMARC prowadzi przez format XML.
Najczęściej zadawane pytania
Czy powinienem zmienić politykę DMARC na none, aby zatrzymać odbicia?
Nie. Ustawienie p=none wstrzymuje egzekwowanie, co oznacza, że sfałszowana i nieuwierzytelniona poczta znów płynie, a Twoja realna ochrona dostarczalności znika. Odbicie mówi Ci, że konkretne źródło nie jest autoryzowane. Napraw to źródło za pomocą wpisu include w SPF lub klucza DKIM. Jeśli naprawdę wdrożyłeś p=reject zbyt szybko i nie możesz od razu naprawić każdego źródła, użyj tagu pct, aby egzekwować politykę na części poczty w trakcie porządkowania, tak jak opisano w naszym przewodniku o tagu pct w DMARC, zamiast całkowicie wyłączać egzekwowanie.
Wiadomość przeszła SPF, więc dlaczego DMARC i tak ją odrzucił?
Ponieważ przejście SPF to nie to samo, co wyrównanie SPF. DMARC wymaga, aby domena, którą SPF uwierzytelnił (domena Return-Path), pasowała do Twojej domeny From:. Wiele platform przechodzi SPF wobec własnej domeny odbicia, która nie jest wyrównana z Twoją, więc DMARC zawodzi. Uzyskaj wyrównany podpis DKIM (d= Twoja domena), a wiadomość przejdzie DMARC niezależnie od wyniku wyrównania SPF.
Jak znaleźć, które narzędzie wysyła nieautoryzowaną pocztę jako moja domena?
Odczytaj IP lub nazwę hosta nadawcy w odbiciu i skonfrontuj je ze źródłami wymienionymi w raportach zbiorczych DMARC. Raport grupuje ruch według IP nadawcy i podaje wynik pozytywny lub negatywny dla SPF i DKIM. IP, które zawodzi w obu i wysyła wolumen, którego się nie spodziewałeś, to niemal zawsze narzędzie SaaS, które ktoś podłączył bez informowania działu IT.
Czy 550 5.7.1 zawsze oznacza problem z DMARC?
Nie. Kod 550 5.7.1 to ogólna odpowiedź "dostarczenie nieautoryzowane" i jest używany przy kilku rodzajach odrzuceń wynikających z polityki, w tym przy odmowie przekazywania (relay) i regułach dotyczących treści. To odrzucenie DMARC tylko wtedy, gdy tekst wymienia DMARC i przywołuje politykę Twojej domeny From:. Jeśli sformułowanie wskazuje konkretnie na SPF, zajrzyj do naszego przewodnika o 550 5.7.23 SPF validation failed.