Jak skonfigurować rekordy DKIM, SPF i DMARC dla serwera Zimbra

Protokoły DKIM, SPF i DMARC rozwiązują trzy różne etapy uwierzytelniania poczty wychodzącej, a niezawodne wdrożenie Zimbra wymaga ich współdziałania. SPF informuje odbiorców, które systemy mogą wysyłać wiadomości z domeną kopertową. DKIM dodaje podpis kryptograficzny powiązany z domeną. DMARC sprawdza, czy przekazana tożsamość SPF lub DKIM jest zgodna z domeną widoczną w nagłówku „Od” wiadomości, a następnie publikuje zasady obsługi i raportowania.

W tym przypadku istotny jest jeden szczegół aktualnego standardu: od października 2026 roku obowiązującą specyfikacją protokołu DMARC jest RFC 9989 , opublikowana w maju 2026 roku. Zastępuje ona starszą specyfikację RFC 7489 i zmienia niektóre szczegóły wdrożenia, w tym uczynienie starego pctznacznika historycznym i wprowadzenie tznacznika testowego. Jest to istotne, jeśli kopiujesz starszy przykład DMARC z poprzedniego przewodnika Zimbra lub samouczka DNS.

Czego potrzebujesz przed zmianą DNS

Potrzebujesz dostępu do powłoki administracyjnej serwera MTA Zimbra, dostępu do autorytatywnej publicznej strefy DNS dla swojej domeny nadawczej oraz pełnej listy wszystkich systemów, które legalnie wysyłają pocztę za pomocą tej domeny. Lista ta może obejmować serwer Zimbra, serwer przekaźnikowy lub host inteligentny, platformy marketingowe, systemy zgłoszeń, aplikacje chmurowe i dowolną usługę odzyskiwania poczty po awarii.

Powszechnym nieporozumieniem jest przekonanie, że samo publikowanie rekordów dla hosta Zimbra zawsze wystarczy. Wystarczy tylko, gdy Zimbra jest rzeczywiście jedynym autoryzowanym nadawcą. SPF jest oceniany na podstawie tożsamości SMTP, a DMARC może ujawnić zapomnianych nadawców zewnętrznych po włączeniu egzekwowania. Działanie: zinwentaryzuj wszystkie źródła wychodzące przed opublikowaniem restrykcyjnej polityki SPF lub DMARC.

Krok 1: Wygeneruj klucz DKIM w Zimbra

Zimbra zawiera zmdkimkeyutilnarzędzie do podpisywania DKIM na poziomie domeny. Oficjalna dokumentacja Zimbry zaleca uruchomienie go na serwerze MTA. Aby dodać dane DKIM dla domeny, która ich jeszcze nie ma, przełącz się na konto Zimbra i uruchom:

su - zimbra
/opt/zimbra/libexec/zmdkimkeyutil -a -d example.com

Polecenie zapisuje dane DKIM w wpisie domeny LDAP Zimbra i drukuje selektor oraz publiczny rekord TXT, który należy opublikować. Dokumentacja podpisywania DKIM Zimbra zawiera również instrukcje -qdotyczące wyszukiwania istniejących danych DKIM, -uich aktualizacji i -rusuwania.

W przypadku nowoczesnych instalacji Zimbra, dokładna wartość selektora może różnić się od przykładów dostępnych online. Selektor nie powinien być stałym słowem, takim jak default„lub” zimbra; należy używać dokładnie takiego selektora, jaki drukuje serwer. Działanie: skopiuj cały rekord klucza publicznego z wyniku polecenia, zamiast odtwarzać go ręcznie.

Krok 2: Opublikuj rekord TXT DKIM

Weryfikatory DKIM wyszukują klucz publiczny w DNS pod nazwą utworzoną z selektora i ._domainkey. Mechanizm ten jest zdefiniowany w dokumencie RFC 6376. W praktyce, w terminologii dostawcy DNS, rekord zazwyczaj wygląda następująco:

To, czy wpiszesz tylko YOUR_SELECTOR._domainkey, czy pełną nazwę, YOUR_SELECTOR._domainkey.example.comzależy od Twojego panelu sterowania DNS. Niektórzy dostawcy automatycznie dodają nazwę strefy. Działanie: przed zapisaniem wyświetl podgląd ostatecznej, w pełni kwalifikowanej nazwy rekordu u swojego dostawcy, aby uniknąć przypadkowego utworzenia domeny ...example.com.example.com.

Krok 3: Utwórz jeden rekord SPF TXT dla domeny wysyłającej

SPF jest publikowany jako rekord DNS TXT w domenie, której autoryzację wysyłania chcesz opisać. RFC 7208 wymaga rekordów TXT dla SPF i stwierdza, że ​​wiele rekordów SPF dla tej samej nazwy właściciela powoduje trwały błąd. Innymi słowy, nie twórz drugiego v=spf1rekordu TXT tylko dlatego, że dodajesz kolejną usługę pocztową.

Jeśli Twój serwer Zimbra wysyła dane bezpośrednio z jednego, stabilnego publicznego adresu IPv4, minimalnym przykładem jest:

v=spf1 ip4:203.0.113.10 -all

Jeśli wszystkie hosty, do których odwołują się rekordy MX Twojej domeny, są legalnymi nadawcami wychodzącymi, możesz użyć mx; jeśli usługa zewnętrzna publikuje domenę z dołączoną funkcją SPF, może być potrzebny include:mechanizm. Dokładny rekord jest specyficzny dla danego wdrożenia, więc nie ma jednego, uniwersalnego ciągu znaków SPF Zimbra.

Kolejnym częstym błędem jest założenie, że ~allzawsze jest bezpieczniej niż -all. Prawdziwe pytanie brzmi, czy Twój spis autoryzowanych nadawców jest kompletny. Ścisły rekord -alljest rozsądny, gdy jest kompletny. Działanie: autoryzuj każdego legalnego nadawcę w jednym rekordzie SPF, zweryfikuj go w środowisku produkcyjnym, a następnie wybierz ostateczny allkwalifikator na podstawie tych dowodów.

Utrzymaj SPF w miarę prostym. RFC 7208 ogranicza mechanizmy i modyfikatory wyzwalające wyszukiwania DNS do 10 podczas oceny; przekroczenie limitu może skutkować permerror… Działanie: policz dołączenia i inne mechanizmy rozszerzające DNS przed dodaniem kolejnego dostawcy.

Krok 4: Najpierw opublikuj DMARC w trybie monitorowania

Polityka DMARC jest opublikowana pod adresem _dmarc.example.com. Ostrożny pierwszy zapis to:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

p=noneProsi odbiorców, aby nie zmieniali sposobu obsługi zgodnie z polityką DMARC podczas zbierania danych. ruaAdres żąda raportów zbiorczych; obecny format raportów zbiorczych jest określony w dokumencie RFC 9990. Użyj skrzynki pocztowej lub usługi raportowania obsługującej raporty DMARC zamiast nienadzorowanej osobistej skrzynki odbiorczej.

Nie kopiuj bezmyślnie pct=10, pct=25, ani podobnych przykładów wdrożeń ze starszych artykułów. RFC 9989 uznaje się za pctdokument historyczny, ponieważ doświadczenie operacyjne wykazało niespójne zastosowanie. Obecny standard służy t=ydo testowania zachowań w razie potrzeby. Działanie: zacznij od p=noneraportów i przeanalizuj je; nie polegaj na próbkowaniu procentowym jako mechanizmie bezpieczeństwa.

Krok 5: Zweryfikuj wszystkie trzy rekordy w publicznym DNS

Po opublikowaniu rekordów przez dostawcę DNS, należy je przeszukać spoza serwera autorytatywnego lub z serwera rozpoznającego publiczne domeny DNS. Na przykład:

dig +short TXT example.com
dig +short TXT YOUR_SELECTOR._domainkey.example.com
dig +short TXT _dmarc.example.com

W przypadku SPF sprawdź, czy v=spf1pod tą nazwą właściciela istnieje tylko jedna odpowiedź TXT zaczynająca się od . W przypadku DKIM sprawdź, czy selektor dokładnie odpowiada wartości aktualnie przechowywanej przez Zimbra. W przypadku DMARC sprawdź, czy pod oczekiwaną nazwą istnieje jeden użyteczny rekord zasad DMARC.

Propagacja DNS zależy od dostawcy, TTL i pamięci podręcznej resolvera. Zmiana, która pojawia się natychmiast na autorytatywnym serwerze nazw, może nadal być buforowana gdzie indziej. Działanie: przetestuj co najmniej jeden niezależny, publiczny resolver, zanim obwinisz Zimbrę za starą odpowiedź.

Krok 6: Wyślij prawdziwą wiadomość i sprawdź zgodność uwierzytelniania

Wyślij wiadomość z domeny Zimbra do skrzynki pocztowej innego dostawcy i sprawdź pełne nagłówki wiadomości. Pomyślny wynik powinien zazwyczaj oznaczać pozytywny wynik podpisu DKIM i/lub SPF, a także pozytywny wynik DMARC, ponieważ co najmniej jedna uwierzytelniona tożsamość jest zgodna z widoczną domeną nadawcy.

Tu ujawnia się kolejne nieporozumienie: DMARC nie wymaga zarówno SPF, jak i DKIM do zaliczenia. Wymaga on zaliczenia zgodnej tożsamości SPF lub zgodnej tożsamości DKIM. RFC 9989 definiuje zaliczenie swobodne jako domyślne dla obu metod aspfi adkim, chociaż można zażądać ścisłego zaliczenia za pomocą s. Działanie: sprawdź Authentication-Resultsi dokładnie zidentyfikuj, który mechanizm zapewnia zaliczenie zgodnej tożsamości DMARC.

Krok 7: Przejdź od monitorowania do egzekwowania dopiero po usunięciu błędów z raportów

Gdy dane DMARC wykażą, że legalni nadawcy uwierzytelniają się i dostosowują poprawnie, możesz zmienić politykę na p=quarantinelub p=reject. W obecnym standardzie , none, quarantinei rejectwyrażają ocenę właściciela domeny dotyczącą nieuwierzytelnionego użycia, ale odbiorcy nadal zachowują swobodę lokalnego przetwarzania.

Nie traktuj tego p=rejectjako optymalizacji dostarczalności. DMARC to przede wszystkim mechanizm uwierzytelniania i kontroli nadużyć domen; nie sprawia, że ​​poszukiwana poczta jest automatycznie godna zaufania ani nie gwarantuje umieszczenia jej w skrzynce odbiorczej. Działanie: egzekwowanie powinno być decyzją bezpieczeństwa opartą na potwierdzonym zakresie uwierzytelniania, a nie obietnicą wyższego wskaźnika w skrzynce odbiorczej.

Krok 8: Rotacja kluczy DKIM bez natychmiastowego usuwania starego rekordu DNS

Aby zaktualizować dane DKIM dla domeny, Zimbra dokumentuje:

/opt/zimbra/libexec/zmdkimkeyutil -u -d example.com

Polecenie tworzy zaktualizowane dane DKIM i generuje nowy wpis DNS. Zimbra zaleca pozostawienie poprzedniego rekordu TXT w DNS na określony czas, aby wiadomości podpisane poprzednim kluczem mogły zostać zweryfikowane w trakcie przesyłania lub kolejkowania. Działanie: najpierw opublikuj nowy selektor, zweryfikuj go i tymczasowo zachowaj poprzedni selektor przed jego usunięciem.

Krótkie odniesienie: co udowadnia każdy rekord

Warto wykonać kontrole specyficzne dla Zimbry

Wskazówki dotyczące ochrony poczty e-mail firmy Zimbra wskazują, że DKIM musi być generowany dla każdej domeny i publikowany w publicznym systemie DNS każdej domeny. Dokumentują one również problemy z dopasowaniem, które mogą wystąpić w przypadku niektórych person lub działania autoresponderów w starszych konfiguracjach. Szczegóły te są raczej sytuacyjne niż uniwersalne: jeśli wdrożone rozwiązanie korzysta z aliasów, person, przekaźników lub nietypowego przepisywania w ramach koperty, należy przetestować te ścieżki wiadomości osobno.

W przypadku instalacji Zimbra z wieloma domenami, powtórz konfigurację DKIM i publikację DNS dla każdej domeny wysyłającej. SPF i DMARC to analogiczne polityki domenowe; nie zakładaj, że rekord w jednej domenie hostowanej automatycznie obejmuje inną, niezwiązaną z nią domenę. Działanie: przed włączeniem ścisłego egzekwowania protokołu DMARC utwórz małą macierz testową dla każdej domeny i każdej trasy wychodzącej.

Ostateczna lista kontrolna walidacji

• Istnieje dokładnie jeden rekord SPF zaczynający się od v=spf1każdej domeny wysyłającej.
• Rekord SPF obejmuje wszystkie autoryzowane trasy wychodzące i mieści się w granicach przetwarzania DNS SPF.
• Zimbra podpisuje pocztę wychodzącą przy użyciu selektora przechowywanego dla tej domeny.
• Pasujący klucz publiczny DKIM jest widoczny w publicznym DNS pod adresem selector._domainkey.
• Rekord TXT DMARC jest publikowany pod adresem _dmarc.domaini używa bieżącej składni.
• Zewnętrzne wiadomości testowe pokazują, że zatwierdzono protokół SPF lub DKIM, a zatem że zatwierdzono protokół DMARC.
• Raporty zbiorcze są sprawdzane przed przejściem z etapu monitorowania do etapu kwarantanny lub odrzucenia.
• Stare selektory DKIM są tymczasowo zachowywane podczas rotacji i usuwane dopiero po upływie okna przejściowego.

Jeśli te kontrole zakończą się sukcesem, Twój serwer Zimbra nie tylko publikuje trzy rekordy DNS, ale prezentuje spójny łańcuch uwierzytelniania, który zdalni odbiorcy mogą zweryfikować. To rozróżnienie ma większe znaczenie niż kopiowanie dowolnego przykładowego ciągu z przewodnika, ponieważ prawidłowe źródła SPF, selektor DKIM i czas egzekwowania DMARC zależą od tego, w jaki sposób Twoja poczta faktycznie opuszcza organizację.