554 5.7.5 Permanent Error Evaluating DMARC Policy [SOLVED]

Właściciele domen mogą natknąć się na błąd "554 5.7.5 permanent error evaluating DMARC policy" z następujących powodów:

1. Nieprawidłowa składnia rekordów SPF, DKIM lub DMARC 
2. Zbędne lub brakujące znaki w rekordach DNS 
3. Brak wsparcia dla wiadomości e-mail z przypisanym SPF 
4. Niezgodności domen podpisów DKIM

"554 5.7.5 trwały błąd oceniający DMARC policy" jest częstym błędem, który zatrzymuje SMTP przed przyjmowaniem wiadomości e-mail z Twojej domeny. Problem zazwyczaj występuje z powodu kombinacji ustawień w rekordzie SPF, rekordzie DMARClub usługi e-mail.

W tej instrukcji opiszemy, jak szybko i łatwo rozwiązać ten problem.

Kluczowe wnioski

• Problemy takie jak niepoprawna składnia w rekordach SPF, DKIM lub DMARC, nadmiarowe znaki lub brak obsługi wiadomości e-mail z wyrównaniem SPF mogą powodować "554 5.7.5 stały błąd oceny polityki DMARC".
• Błąd ten blokuje porty SMTP przed przyjmowaniem wiadomości e-mail, zakłócając ich dostarczanie.
• Upewnij się, że rekord SPF kończy się na -all lub ~all, unika neutralnych polityk i przestrzega limitów wyszukiwania DNS.
• Niezgodności między tagiem d= w sygnaturach DKIM a domenami wysyłającymi mogą spowodować niepowodzenie walidacji DMARC.
• Popraw składnię rekordów, dostosuj tymczasowo DMARC do p=none i monitoruj przepływ poczty przed ponownym egzekwowaniem polityki. Sprawdź obsługę wyrównania SPF swojego dostawcy poczty e-mail i włącz uwierzytelnianie DKIM.
• Użyj darmowego narzędzia DMARC Lookup Tool firmy PowerDMARC, aby skutecznie zidentyfikować błędy w swoich rekordach.

Dlaczego pojawia się błąd "554 5.7.5 Permanent Error Evaluating DMARC Policy"?

Jeśli masz do czynienia z komunikatem "554 5.7.5 permanent error evaluating DMARC policy", oto kilka najczęstszych przyczyn tego błędu:

1. Niekompletne lub nieprawidłowe ustawienia rekordu DMARC

Niekompletne rekordy DMARC mogą prowadzić do błędów w ocenie polityki DMARC. Na przykład brakujący tag p=. Jeśli Twój rekord DMARC wygląda mniej więcej tak: 

v=DMARC1; pct=100;

To jest przykład niekompletnych Ustawienia DMARC brak znacznika polityki. Jest to błędny rekord. Podczas konfigurowania DMARCmożna wybrać opcję p=none lub p=quarantine/reject.

Podobnie, błędy składni w rekordzie, takie jak dodatkowe znaki lub spacje, mogą również wywołać stały błąd 554 5.7.5 oceniający błąd polityki DMARC. 

v=DMARC1; p:none; pct=100; rua=mailto:[email protected]; 

W tym przykładzie ":" jest nieprawidłowym znakiem, ponieważ po wszystkich mechanizmach następuje znak równości (=), a następnie wartość. 

Prawidłowa kolejność rekordów DMARC

• Twój rekord DMARC powinien zaczynać się od nazwy wersji v=DMARC1 
• Znacznik polityki jest również obowiązkowy i powinien mieć wartość none/reject/quarantine. 
• Wszystkie znaczniki DMARC muszą być poprzedzone znakiem "=[value]" i zakończone średnikiem (;). 
• Pomiędzy poszczególnymi mechanizmami lub tagami powinna znajdować się pojedyncza spacja 
• Nie powinno być spacji pomiędzy każdym zdefiniowanym mechanizmem, na przykład: p=none; 

2. Nieprawidłowe wyrównanie DKIM

DKIM to skrót od DomainKeys Identified Mail. Jest to metoda weryfikacji autentyczności nadawcy wiadomości e-mail, która zapobiega podszywaniu się złośliwych podmiotów pod nazwę domeny nadawcy wiadomości.

Czasami mogą wystąpić problemy z uwierzytelnianiem DKIM. Niezgodność między znacznikiem "d=" w podpisie DKIM a domeną wysyłającą spowoduje, że ocena DMARC nie powiedzie się.

Na przykład, jeśli nazwa domeny została zmieniona i nie została zaktualizowana w rekordach DKIM, to również nie przejdzie oceny zasad DMARC.

3. Nieprawidłowy rekord SPF

SPF to skrót od Sender Policy Framework. Jest to technika uwierzytelniania wiadomości e-mail używana do sprawdzania, czy wiadomość e-mail pochodzi z serwera ważnego nadawcy, czy nie.

DMARC działa poprzez sprawdzanie rekordów SPF w celu zweryfikowania, czy są one ważne, czy nie. Aby uniknąć tego błędu, należy upewnić się, że rekordy SPF są poprawnie skonfigurowane i działają z nazwą domeny. Kilka rzeczy, których należy unikać w przypadku SPF jest następujących: 

• Rekord SPF musi kończyć się mechanizmem niepowodzenia (-all lub ~all) 
• Unikaj stosowania neutralnej polityki do oceny SPF 
• Unikanie przekraczania limitów SPF DNS i void lookup 

4. Brak wsparcia dla wiadomości e-mail z przypisanym SPF przez ESP

Czasami, jeśli otrzymujesz błąd "554 5.7.5 Permanent Error Evaluating DMARC Policy", może to być problem po stronie dostawcy usług poczty elektronicznej. Nie wszyscy dostawcy usług poczty elektronicznej obsługują wiadomości e-mail z przypisanym SPF. Niektórzy nawet obsługują politykę SPF wewnętrznie, co może prowadzić do błędów, jeśli masz włączony SPF dla swojej domeny. 

Naprawa "554 5.7.5 Permanent Error Evaluating DMARC Policy" w 5 krokach

Możesz wykonać poniższe kroki, aby potencjalnie rozwiązać błąd "554 5.7.5 Permanent Error Evaluating DMARC Policy". Ale rozwiązanie nie jest gwarantowane. Jeśli wykonanie tych kroków nie naprawi błędu skontaktuj się z nami aby uzyskać bezpłatną ocenę bezpieczeństwa domeny.

1. Usuń dodatkowe znaki z rekordu

Stały błąd 5.7.5 oceniający politykę DMARC może wynikać z różnych czynników, ale dominujące przyczyny zazwyczaj obejmują:

• Niewłaściwie użyty cudzysłów
• Nadmiar znaków lub symboli w rekordzie
• Brakuje średnika, aby zakończyć zapis.

Oto przykład rekordu, w którym wystąpił ten błąd:

Ten rekord może na początku wyglądać dobrze, ale podczas testowania go otrzymaliśmy komunikat "5.7.5 permanent error evaluating DMARC policy".

Po ponownym sprawdzeniu okazało się, że na końcu rekordu znajduje się dodatkowa kropka - jeśli przyjrzeć się temu samemu rekordowi powyżej, można zauważyć, że na końcu znajduje się kropka (.). 

Po usunięciu tej kropki i ponownym przeprowadzeniu testu wszystko działało bez zarzutu.

Oto jak wygląda ten sam rekord bez błędów:

2. Zmień swój rekord SPF z neutralnego

Jeśli otrzymujesz komunikat o błędzie "5.7.5 permanent error evaluating DMARC policy" podczas próby wysłania wiadomości e-mail, to prawdopodobnie rekord SPF jest ustawiony na Neutral.

SPF to skrót od Sender Policy Framework, który pomaga upewnić się, że serwer pocztowy, z którego wysyłane są wiadomości e-mail, jest legalny. Nie wystarczy mieć tylko serwer, który wysyła e-maile; musi być jakaś weryfikacja, że ten serwer jest legalny. To właśnie robi SPF: weryfikuje, czy Twój serwer pocztowy ma właściwe referencje.

Dlaczego Twój rekord SPF nie może być neutralny? 

Jeśli wiadomości mogą być wysyłane za pośrednictwem neutralnego serwera, oszuści mogą wysyłać fałszywe wiadomości e-mail przy użyciu nazwy domeny, co oznacza, że ludzie mogą myśleć, że są prawdziwe, podczas gdy tak nie jest - i ostatecznie klikają linki lub pobierają pliki, których nie powinni.

Dlatego też powinieneś przynajmniej zmienić swój rekord SPF na softfail ~all lub hardfail -all po wdrożeniu DMARC - aby ludzie wiedzieli, że wiadomość z Twojej domeny jest prawdopodobnie bezpieczna.

3. Sprawdź, czy twój dostawca usług e-mail obsługuje wiadomości e-mail z przypisaniem SPF

Jednym z najczęstszych powodów otrzymania tego błędu jest fakt, że Twój dostawca usług poczty elektronicznej nie obsługuje wiadomości e-mail z przypisanym SPF.

Dostawcy poczty elektronicznej, tacy jak MailChimp i ProtonMail, mają własne rekordy SPF i kiedy wysyłasz przez nich wiadomości, nie wysyłają one wiadomości z wyrównaniem do SFP. W związku z tym ważne jest, aby sprawdzić typ dyspozycji SPF swojego dostawcy usług email, aby sprawdzić, czy obsługuje on emaile z wyrównaniem SPF.

Jeśli tak, to podpis DKIM zostanie zmodyfikowany podczas procesu wysyłania, tak aby adres From był zgodny z własną domeną (zamiast z domeną MailChimp) i zapewni przejście oceny polityki DMARC.

Jeśli tak nie jest, trzeba będzie skorzystać z usług innego dostawcy poczty elektronicznej (lub zmienić ustawienia dotychczasowego dostawcy), aby można było wysyłać wiadomości z oznaczeniem SPF.

4. Przejście do polityki p=none dla DMARC

Jeśli otrzymujesz błąd "554 5.7.5 permanent error evaluating DMARC policy", oznacza to, że polityka DMARC w Twojej domenie uniemożliwia wysyłanie wiadomości e-mail. Aby to naprawić, musisz po prostu zmienić rekord DMARC u dostawcy DNS, tak aby miał on politykę p=none.

Polityka DMARC mówi dostawcom poczty elektronicznej, co mają zrobić z wiadomościami e-mail, które nie przejdą kontroli SPF i DKIM: odrzucić je lub poddać kwarantannie. Jeśli chcesz wysyłać wiadomości e-mail, nawet jeśli te kontrole nie przejdą pomyślnie, możesz tymczasowo złagodzić swoją politykę, ustawiając ją na p=none w ustawieniach DNS.

DMARC none jest nazywany "zrelaksowaną, bezczynnościową lub tylko monitorującą polityką", więc nie jest zalecany do zapobiegania spoofingowi wiadomości e-mail. Jednak zmiana polityki DMARC na p=none pozwoli na dostarczanie wiadomości e-mail do skrzynek odbiorczych bez wpływu błędów DMARC.

Można na przykład zmienić ten zapis:

do tego:

Co to oznacza dla użytkownika? Możesz wysyłać wiadomości e-mail, nawet jeśli nie przejdą one DMARC. Jednakże, będziesz chciał ostatecznie powrócić do polityki p=reject lub p=quarantine, aby zapobiec spoofingowi wiadomości e-mail w Twojej domenie.

5. Skonfiguruj uwierzytelnianie poczty identyfikowanej za pomocą kluczy domenowych (DKIM)

Jeśli napotkasz kod błędu "554 5.7.5 permanent error evaluating DMARC policy", oznacza to, że uwierzytelnianie poczty DKIM (DomainKeys Identified Mail) nie zostało aktywowane dla Twojej domeny - dlatego, aby przejść DMARC, musisz mieć skonfigurowany rekord uwierzytelniania poczty DKIM (jeśli nie masz jeszcze SPF).

Oto kroki, które należy wykonać, aby to zrobić:

• Zarejestruj się w PowerDMARC i wybierz generator rekordów DKIM z naszego Power Toolbox. 
• Wprowadź nazwę domeny, zdefiniuj selektor (np. selektor1) dla rekordu i naciśnij przycisk Generuj. 
• Nasze narzędzie automatycznie wygeneruje pary kluczy publicznych i prywatnych DKIM. 
• Skopiuj wygenerowaną nazwę rekordu TXT i wartość rekordu TXT (wartość klucza publicznego) i opublikuj je w DNS, uzyskując dostęp do konsoli zarządzania DNS. 

Wymagania dotyczące formatowania zasad DMARC

DMARC to protokół uwierzytelniania wiadomości e-mail, który umożliwia odbiorcom sprawdzenie, czy wiadomości e-mail rzekomo pochodzące z Twojej domeny rzeczywiście zostały wysłane z Twojej domeny. W tym przewodniku przedstawiono niektóre z ważnych wymagań dotyczących formatowania podczas konfigurowania DMARC po raz pierwszy.

•  Po pierwsze, Twój rekord DMARC musi zaczynać się od "v=DMARC1". Dzięki temu dostawcy poczty elektronicznej wiedzą, że rekord jest sformatowany zgodnie z aktualnie używaną wersją protokołu DMARC (czyli 1). 
•  Następnie określ zasady. Polityka musi mieć wartość p=none, p=quarantine lub p=reject. Mówi to dostawcom poczty e-mail, co zrobić, gdy wiadomość e-mail nie przejdzie pomyślnie kontroli uwierzytelniania. 
• Pole polityki w rekordzie DMARC jest polem obowiązkowym po polu v= version. Polityka może być jedną z trzech rzeczy: p=none, p=quarantine lub p=reject. "Brak" oznacza, że chcesz, aby dostawca poczty elektronicznej nie robił nic, gdy zobaczy podejrzaną wiadomość e-mail z Twojej domeny - po prostu pozostawi ją w spokoju, a nawet może ją dostarczyć. "Kwarantanna" oznacza, że podejrzane wiadomości e-mail z Twojej domeny mają być dostarczane jako spam lub wiadomości-śmieci, a nie jako normalna poczta. Wreszcie, "odrzuć" oznacza, że podejrzane wiadomości e-mail z Twojej domeny mają być odrzucane i nigdy nie dostarczane.
•  Używaj dwukropków jako separatorów między wartościami - dobrym pomysłem jest używanie dwukropków, a nie średników. Średniki mogą powodować problemy, zwłaszcza gdy w jednym wierszu podano wiele wartości.
•  Nie należy używać dodatkowych znaków ani złych cudzysłowów. Nadmiar białych znaków na końcu wierszy będzie traktowany jako część rekordu, co może powodować problemy.

Oto przykład dobrego rekordu DMARC:

Jak znaleźć błędy w polityce rekordów DMARC

Posiadanie rekordu DMARC to dobry krok w kierunku zabezpieczenia komunikacji e-mailowej. Jeśli jednak wystąpią w nim jakieś błędy, cały system będzie nieskuteczny. Dlatego tak ważne jest znalezienie błędów i jak najszybsze ich usunięcie.

Najlepszym sposobem na to jest użycie DMARC lookup przez PowerDMARC. Narzędzie to sprawdza, czy Twój rekord jest ważny i pokazuje ewentualne błędy. Z narzędzia można korzystać bezpłatnie, wykonując poniższe kroki:

1. Zarejestruj się w PowerDMARC i przejdź do narzędzia DMARC Lookup Tool w Power Toolbox.

2. Wprowadź nazwę domeny w pustym polu.

3. Po sprawdzeniu rekordu narzędzie wyświetli przegląd opublikowanej składni, jednocześnie podświetlając błędy w rekordzie.

4. Jeśli wystąpią jakiekolwiek błędy, zostaną one podświetlone na stronie. 

5. Gdy już wiesz, skąd pochodzą błędy, możesz je łatwo rozwiązać, korzystając z instrukcji dołączonych do każdego komunikatu o błędzie.

Czy martwisz się o bezpieczeństwo swoich służbowych wiadomości e-mail?

To prawdziwy powód do niepokoju. W rzeczywistości wiele cyberataków rozpoczyna się od wiadomości e-mail. W raporcie DBIR firmy Verizon z 2019 r. podano, że 94% naruszeń danych rozpoczyna się od ataków wymierzonych w ludzi za pośrednictwem poczty elektronicznej.

Nie oznacza to jednak, że musisz rezygnować z docierania do klientów za pośrednictwem poczty e-mail!

Zamiast tego zabezpiecz wszystkie służbowe wiadomości e-mail za pomocą usług uwierzytelniania poczty elektronicznej firmy PowerDMARC. Pomoże Ci to zdobyć zaufanie klientów i ochroni Twoją markę przed próbami wyłudzenia danych przez hakerów i innych złych aktorów.

Dzięki PowerDMARC możesz mieć pewność, że wszystkie wiadomości e-mail pochodzące od Twojej firmy są nie tylko bezpieczne dla klientów, ale również łatwe do zidentyfikowania jako legalna komunikacja od Twojej marki poprzez umieszczenie na nich pieczęci Twojej firmy.

Wiemy, że ochrona integralności nazwy i wizerunku Twojej firmy jest dla Ciebie ważna i chcemy, abyś mógł to zrobić w sposób, który ma sens dla obu zaangażowanych stron - dlatego oferujemy tę usługę w przystępnej cenie, a jednocześnie zapewniamy naszym klientom dostęp do całej naszej wiedzy na temat technik uwierzytelniania wiadomości e-mail.

Czy Twoja domena jest chroniona przed spoofingiem e-mail? Uzyskaj swój darmowy DMARC już dziś!

• O
• Latest Posts

Yunes Tarada

Ekspert ds. bezpieczeństwa domen i poczty e-mail w PowerDMARC

Yunes jest liderem zespołu operacyjnego w PowerDMARC z wiedzą ekspercką w zakresie uwierzytelniania i bezpieczeństwa poczty elektronicznej. Yunes jest certyfikowanym przez Microsoft Azure Administrator Associate z certyfikatami CompTIA A+ i wieloma innymi.

Najnowsze posty autorstwa Yunes Tarada (zobacz wszystkie)

• Yahoo Japan wymusza przyjęcie DMARC dla użytkowników w 2025 roku - 17 stycznia 2025 r.
• Botnet MikroTik wykorzystuje błędne konfiguracje SPF do rozprzestrzeniania złośliwego oprogramowania - 17 stycznia 2025 r.
• Nieuwierzytelniona poczta DMARC jest zabroniona [ROZWIĄZANE] - 14 stycznia 2025 r.