Uwierzytelnianie maili rekrutacyjnych: praktyczna lista kontrolna
Sprawdź uwierzytelnianie maili rekrutacyjnych ze skrzynki, ATS i narzędzia do planowania rozmów. Zweryfikuj SPF, DKIM, DMARC i odpowiedzi przed kontaktem z kandydatami.
Ernest Bursa
Żeby sprawdzić uwierzytelnianie maili rekrutacyjnych, wyślij wiadomość do fikcyjnego kandydata przez każdą używaną usługę. W skrzynce odbiorczej sprawdź wyniki SPF, DKIM i DMARC, zgodność domen oraz miejsce, do którego trafiają odpowiedzi. Udana wysyłka nie dowodzi, że wiadomość trafiła do folderu Odebrane, została przeczytana ani że kandydat odpowiedział.
Dyskusja na Hacker News o poradniku uwierzytelniania Mailfully przypomina o znanym problemie konfiguracji. Skrzynka założyciela, ATS i narzędzie do planowania rozmów mogą wyświetlać nazwę firmy, choć wysyłają przez różne infrastruktury. Poprawne działanie jednej usługi mówi niewiele o pozostałych.
Przygotuj zwięzłą kartę weryfikacji dla każdego sposobu wysyłki. Da się to zrobić bez zastępowania działających rekordów DNS i bez przypisywania zielonemu wskaźnikowi konfiguracji gwarancji, których nie zapewnia.
Które usługi wysyłają maile rekrutacyjne z twojej domeny?
Zanim zmienisz DNS, spisz usługi wysyłające wiadomości do kandydatów. Każdy odrębny sposób wysyłki wymaga własnego testu, nawet jeśli wszystkie wiadomości wyglądają na wysłane z [email protected].
Zacznij od zwykłej skrzynki rekrutera lub założyciela. Dodaj ATS wysyłający potwierdzenia otrzymania aplikacji i odpowiedzi do kandydatów, narzędzie wysyłające zaproszenia na rozmowy oraz osobne usługi używane do ofert lub ocen. Zapisz, kto administruje każdą usługą i z której domeny ma ona korzystać.
Ten podział wynika z działania uwierzytelniania poczty. Normy oceniają infrastrukturę wysyłającą i tożsamości domen, które mogą być różne mimo tego samego widocznego adresu From. To uzasadnia testowanie każdego sposobu wysyłki, ale nie dowodzi, że każdy ATS ma problem z dostarczaniem wiadomości.
Spis powinien być na tyle szczegółowy, żeby ujawnić błędne założenie:
| Sposób wysyłki | Wiadomość do przetestowania | Pytanie osoby odpowiedzialnej |
|---|---|---|
| Skrzynka pracownika | Bezpośredni follow-up po rozmowie | Czy wiadomości ze skrzynki pracownika przechodzą uwierzytelnianie? |
| ATS | Odpowiedź do kandydata wysłana z aplikacji | Czy ATS używa zamierzonej tożsamości firmy? |
| Narzędzie do planowania rozmów | Zaproszenie z rzeczywistego procesu planowania | Kto je wysyła i gdzie kandydat może odpowiedzieć? |
Użyj fikcyjnych danych kandydata i skrzynek, do których zespół ma dostęp. Sprawdzisz, czy odpowiedź trafia do właściwej aplikacji, bez kontaktowania się z prawdziwym kandydatem i bez udostępniania jego rozmowy usłudze diagnostycznej.
Oddziel test techniczny od zobowiązania zespołu. Nasz plan odpowiedzi na aplikacje z Hacker News opisuje, kto przegląda aplikacje i kiedy kandydaci otrzymują odpowiedź. Uwierzytelnianie może wspierać ten proces, ale nie przypisze recenzenta ani nie sprawi, że odpowie.
Co właściwie weryfikują SPF, DKIM i DMARC?
SPF autoryzuje infrastrukturę wysyłającą dla tożsamości kopertowej. DKIM weryfikuje podpis powiązany z domeną podpisującą. DMARC sprawdza, czy pozytywny wynik jest zgodny z domeną adresu From widocznego dla odbiorcy.
Łatwo pomylić te tożsamości, ponieważ program pocztowy zwykle pokazuje tylko jeden adres. Sama wiadomość zawiera ich kilka:
| Tożsamość | Gdzie ją znajdziesz | Co oznacza |
|---|---|---|
| Widoczny From | Nagłówek From wiadomości | Adres prezentowany kandydatowi |
| Nadawca kopertowy | SMTP MAIL FROM; po dostarczeniu zwykle odzwierciedlony w Return-Path | Tożsamość zwykle sprawdzana przez SPF |
| Domena podpisująca DKIM |
d= w nagłówku DKIM-Signature |
Domena odpowiadająca za ten podpis |
| Reply-To | Nagłówek Reply-To, jeśli występuje | Miejsce, do którego program pocztowy kieruje odpowiedź |
Specyfikacja SPF odróżnia tożsamość kopertową od widocznego nagłówka From. Specyfikacja DKIM opisuje podpis domeny. Znana nazwa nadawcy ani poprawny adres Reply-To nie potwierdzają zgodności domen wymaganej przez DMARC.
Rozważ fikcyjną wiadomość wysłaną bezpośrednio:
From: Hiring Team <[email protected]>
Envelope sender: [email protected]
DKIM signing domain: example.com
SPF dostawcy może dać pozytywny wynik dla vendor.example.net, a jednocześnie nie zapewnić zgodności z example.com. Poprawny podpis DKIM dla example.com nadal może dać pozytywny wynik ze zgodnością domen wymaganą przez DMARC. DMARC nie wymaga, żeby oba mechanizmy dały pozytywny wynik i zgodność domen: co najmniej jeden pozytywny wynik ze zgodną domeną może spełnić warunek uwierzytelniania. RFC 9989 wyjaśnia tę regułę.
Zgodność domen zależy też od trybu. Tryb łagodny może akceptować domeny ze wspólną domeną organizacyjną; tryb ścisły wymaga identycznych domen. Subdomena wysyłająca nie oznacza więc automatycznie błędu. Zapisz faktyczne domeny i politykę zamiast traktować każdą różnicę jako usterkę.
Test weryfikuje użycie domeny, a nie wiarygodność oferty pracy czy intencje nadawcy. Ten osobny problem opisuje artykuł o podszywaniu się pod rekruterów i zaufaniu kandydatów.
Jak dodać nadawcę bez psucia działającej poczty?
Pobierz aktualne instrukcje konfiguracji domeny od nowej usługi i porównaj je z opublikowanymi rekordami. Przykładowe wartości DNS służą do objaśnienia mechanizmu, nie do konfiguracji twojej domeny.
Najpierw ustal, czy konfigurujesz uwierzytelnianie wysyłki, kierowanie poczty przychodzącej, czy oba elementy. Rekord MX kieruje pocztę przychodzącą. Jego zmiana może przenieść odpowiedzi pracowników lub kandydatów do innej usługi; nie autoryzuje wysyłki. Jeśli główna domena odbiera już pocztę pracowników w innym miejscu, osobna subdomena rekrutacyjna pozwala podjąć tę decyzję niezależnie.
W SPF zachowaj obecnych, uprawnionych nadawców. Dodanie ATS nie powinno bez ostrzeżenia usunąć uprawnienia potrzebnego skrzynce pracowników.
Publikacja drugiej polityki SPF też nie jest bezpiecznym sposobem na uniknięcie edycji pierwszej. Wybór rekordu SPF zwraca trwały błąd, jeśli znajdzie kilka rekordów spełniających warunki wyboru.
SPF ogranicza także liczbę ocenianych mechanizmów i modyfikatorów powodujących zapytania DNS. Limit wynosi dziesięć takich elementów, w tym elementy z zagnieżdżonych instrukcji include.
Nie jest to liczba wszystkich zapytań DNS wykonywanych przez resolver. Jeśli polityka obejmuje wielu dostawców, sprawdź jej wykonanie zamiast liczyć słowa w rekordzie TXT. Szczegóły opisują limity oceny w RFC 7208.
Dla DKIM opublikuj selektor i klucz lub delegację podane przez dostawcę wysyłki. Rekord selektora skrzynki pracowników nie konfiguruje automatycznie ATS. Zapisz, która usługa odpowiada za każdy selektor. Dzięki temu późniejsze usunięcie dostawcy nie skasuje działającego podpisu innej usługi.
Zanim zastąpisz politykę DMARC przykładem z poradnika, sprawdź obecną konfigurację. Ktoś może już zbierać raporty albo stosować bardziej restrykcyjną politykę. Przed zmianą przekaż osobie odpowiedzialnej za domenę pełną propozycję, w tym zachowanych nadawców i planowany adres raportów.
Jak przetestować rzeczywistą wysyłkę maili do kandydatów?
Wyślij wiadomość przez rzeczywisty proces, sprawdź wyniki po stronie odbiorcy i odpowiedz. Test ze skrzynki administratora nie sprawdza konfiguracji wysyłki ATS.
Dla każdej pozycji w spisie przygotuj rozpoznawalny temat testowy i użyj skrzynki, do której masz dostęp, u dostawcy poczty wymagającego sprawdzenia. W ATS użyj fikcyjnej aplikacji i tej samej funkcji odpowiedzi, z której korzysta rekruter. W narzędziu do planowania rozmów uruchom prawdziwy proces zaproszenia zamiast ręcznie odtwarzać jego treść.
Otwórz pełne nagłówki odebranej wiadomości lub widok jej oryginału. Zapisz widoczny From, domenę kopertową widoczną po dostarczeniu oraz domenę podpisującą DKIM.
Następnie znajdź wyniki uwierzytelniania dodane przez usługę odbierającą. Korzystaj z zaufanych wyników tej usługi. Linia dopisana wcześniej przez nadawcę nie jest równoważnym dowodem.
Karta weryfikacji może być prosta:
| Sposób wysyłki | Widoczna domena From | Domena kopertowa | DKIM d=
|
Wyniki odbiorcy | Kierowanie odpowiedzi |
|---|---|---|---|---|---|
| Skrzynka pracownika | Faktyczna wartość | Faktyczna wartość | Faktyczna wartość | SPF, DKIM, DMARC | Odpowiedź dotarła do oczekiwanej skrzynki? |
| Odpowiedź do kandydata z ATS | Faktyczna wartość | Faktyczna wartość | Faktyczna wartość | SPF, DKIM, DMARC | Odpowiedź dotarła do oczekiwanej aplikacji? |
| Zaproszenie na rozmowę | Faktyczna wartość | Faktyczna wartość | Faktyczna wartość | SPF, DKIM, DMARC | Odpowiedzi działają zgodnie z założeniem? |
Zapisz datę, konfigurację wysyłki, dostawcę poczty odbiorcy i osobę odpowiedzialną.
Osobno odnotuj, czy wiadomość testowa pojawiła się w folderze Odebrane, czy w spamie. Zachowaj dość informacji do zbadania błędu, ale nie umieszczaj prywatnych nagłówków ani treści rozmów z kandydatami w publicznym zgłoszeniu.
Na końcu kliknij Odpowiedz i wyślij krótką wiadomość.
Sprawdź, czy trafia do właściwej skrzynki lub wątku kandydata i czy widzi ją odpowiednia osoba z zespołu. Narzędzie do planowania rozmów może celowo kierować odpowiedzi gdzie indziej. Udokumentuj ten wybór zamiast zakładać, że każde zaproszenie odsyła do ATS.
Pozytywny wynik w jednym wierszu mówi coś użytecznego o tej wiadomości, sposobie wysyłki, konfiguracji i odbiorcy. W razie potrzeby powtórz test u innego ważnego dostawcy poczty. Przekazywanie wiadomości i listy mailingowe zmieniają zachowanie uwierzytelniania. Zbadaj te przypadki osobno, zanim uznasz błąd SPF za dowód nieuprawnionego nadawcy.
Czego Gmail i Yahoo wymagają od domeny wysyłającej?
Obaj dostawcy publikują wymagania dla nadawców oraz dodatkowe obowiązki dla nadawców masowych. Zanim wykorzystasz je w checkliście, ustal dostawcę poczty odbiorcy, wielkość wysyłki i przeznaczenie wiadomości.
Wytyczne Google dla nadawców dotyczą wiadomości kierowanych na osobiste konta Gmail. Każdy nadawca potrzebuje SPF lub DKIM, poprawnych rekordów DNS dla wyszukiwania zwykłego i odwrotnego, TLS, zgodnego formatu oraz niskiego poziomu zgłoszeń spamu. Nadawcy masowi potrzebują SPF, DKIM, DMARC i zgodności domen, obok pozostałych wymagań z listy.
FAQ Google dla nadawców opisuje klasyfikację nadawcy masowego przy wysyłce rzędu 5000 wiadomości dziennie na osobiste konta Gmail.
Google sumuje wiadomości wysyłane ze wszystkich subdomen danej domeny głównej i wskazuje, że raz nadana klasyfikacja pozostaje w mocy. Policz wszystkie objęte nią wysyłki domeny, nie tylko codzienne maile rekrutera. Te reguły dotyczą odbiorców na osobistych kontach Gmail, a nie na kontach Google Workspace.
Wymagania Yahoo również przewidują SPF lub DKIM dla każdego nadawcy, a oba mechanizmy i pozytywny wynik DMARC dla nadawców masowych. Yahoo akceptuje co najmniej politykę p=none i łagodną zgodność domen. Jego FAQ celowo nie podaje liczbowego progu wysyłki masowej, więc wartość Google nie jest regułą Yahoo.
Wymagania dotyczące rezygnacji z subskrypcji powiąż z kategorią wiadomości. Google zwalnia wiadomości transakcyjne z wymogu rezygnacji jednym kliknięciem, ale nie oznacza to, że każda wiadomość rekrutera jest transakcyjna. Odpowiedź na aplikację i promocyjny newsletter rekrutacyjny służą innym celom. Sprawdź konkretną wiadomość i wytyczne dostawcy.
Dla objętych tym wymogiem wiadomości Gmail wymaga mechanizmu POST opisanego w RFC 8058; sam link mailto nie wystarczy. Yahoo obecnie akceptuje mailto, choć zaleca POST, i wymaga łatwej rezygnacji dla masowych wiadomości marketingowych lub subskrybowanych. To, że obaj dostawcy używają określenia „jedno kliknięcie”, nie oznacza identycznych zasad wdrożenia.
Dlaczego uwierzytelniony mail rekrutacyjny nadal może trafić do spamu?
Uwierzytelnianie jest jednym z elementów filtrowania. Odbiorca może przyjąć uwierzytelnioną wiadomość i mimo to umieścić ją w spamie ze względu na reputację, skargi, treść lub preferencje odbiorcy.
Wytyczne Gmail i wskazówki Yahoo opisują te szersze czynniki. Żaden dostawca nie traktuje pozytywnego uwierzytelniania jako gwarancji umieszczenia w folderze Odebrane. Jeśli wiadomość testowa przechodzi uwierzytelnianie, ale trafia do spamu, zbadaj ten wynik filtrowania zamiast ponownie zastępować poprawne rekordy DNS.
Podziel błędy według etapu, na którym występują:
| Obserwacja | Co sprawdzić dalej |
|---|---|
| Brakuje oczekiwanego rekordu DNS | Opublikowaną nazwę, wartość, dostawcę i propagację |
| SPF daje pozytywny wynik dla niepowiązanej domeny kopertowej | Czy inny mechanizm z pozytywnym wynikiem zapewnia zgodność domen |
| Oczekiwanego podpisu DKIM nie ma lub jest niepoprawny | Konfigurację podpisu, selektor i odebraną wiadomość |
| DMARC kończy się błędem | Mechanizmy z pozytywnym wynikiem i zgodność z widocznym From |
| Uwierzytelnianie działa; wiadomość trafia do spamu | Informacje od dostawcy, reputację, treść i skargi |
| Serwer odmawia przyjęcia wiadomości przez SMTP | Błąd transportu i konfigurację usługi wysyłającej |
| Odpowiedź trafia do niewłaściwej skrzynki | Reply-To, kierowanie poczty przychodzącej i powiązanie z procesem |
Wcześniej istnieje jeszcze jedna granica. Udane przekazanie wiadomości przez SMTP oznacza, że serwer przyjmujący bierze za nią odpowiedzialność na tym etapie, zgodnie z RFC 5321. Przekazanie poczty przez narzędzie do serwera wysyłającego poprzedza jej umieszczenie w skrzynce odbiorcy.
W języku zespołu rozróżniaj cztery zdarzenia: przekazanie do SMTP, zaobserwowane umieszczenie wiadomości u odbiorcy, przeczytanie i odpowiedź. Timestamp „wysłano” nie potwierdza trzech późniejszych zdarzeń. Brak odpowiedzi także nie pozwala zdiagnozować błędu uwierzytelniania; może wynikać z decyzji kandydata lub treści wiadomości.
Co sprawdzić po zmianie dostawcy?
Powtórz odpowiednie wiersze karty weryfikacji po zmianie nadawcy, domeny, konfiguracji podpisu lub integracji narzędzia do planowania rozmów. Politykę DMARC i raporty przejrzyj z osobą odpowiedzialną za domenę.
DMARC p=none nie wskazuje preferencji kwarantanny ani odrzucania wiadomości, które nie przechodzą weryfikacji. Zbieranie raportów zbiorczych konfiguruje się osobno. Sama publikacja nie blokuje podszywania się. Żeby korzystać z raportów, skonfiguruj istniejący adres odbiorczy, przypisz komuś ich przeglądanie i sprawdź uprawnienia wymagane dla zewnętrznego adresu. Zasady raportowania DMARC opisują tę zewnętrzną autoryzację.
Zanim przejdziesz do kwarantanny lub odrzucania, zidentyfikuj uprawnionych nadawców i zbadaj ich błędy. Potwierdź, że poczta pracowników, odpowiedzi z ATS, planowanie rozmów i pozostałe zachowane usługi działają z zamierzoną zgodnością domen. Uzgodnij zmianę polityki z osobą odpowiedzialną za domenę i zbadaj jej skutki po wdrożeniu. RFC 9989 definiuje polityki, ale odbiorcy zachowują swobodę decyzji o obsłudze wiadomości.
Usunięcie dostawcy też zaplanuj jako osobną zmianę. Ustal, które uprawnienie SPF i który selektor DKIM należały do starej usługi, zachowaj pozostałe i zdecyduj, dokąd mają trafiać odpowiedzi na stare wiadomości. Kandydat może odpowiedzieć na zaproszenie wysłane przed migracją. Nowy test wysyłki nie dowodzi, że wcześniejsza droga poczty przychodzącej nadal działa.
Jak Kit obsługuje domenę rekrutacyjną i odpowiedzi kandydatów
Hostowana domena rekrutacyjna potrzebuje skonfigurowanej tożsamości wysyłającej i działających rozmów z kandydatami. Sprawdź odebraną wiadomość nawet wtedy, gdy strona konfiguracji informuje o sukcesie.
Konfiguracja Startupkit Email w Kit pokazuje rekordy MX, DKIM, SPF i DMARC dla skonfigurowanej domeny.
Kit generuje parę kluczy DKIM dla konkretnej domeny i konfiguruje podpisywanie przez swój serwer pocztowy. Proponowana polityka DMARC zaczyna się od p=none.
Wiadomości do kandydatów spełniające wymagania mogą używać skonfigurowanej skrzynki rekrutacyjnej jako widocznego From i nadawcy kopertowego. Wysyłka pod tą tożsamością wymaga aktywnej integracji, kluczy podpisujących, zweryfikowanych rekordów wysyłki i wyraźnej aktywacji. Weryfikacja DNS i stan uruchomienia usługi są oddzielne: „Aktywna” oznacza, że usługa została uruchomiona, a nie że wszystkie rekordy DNS zostały rozpropagowane.
Te testy mają określony zakres. Kit sprawdza oczekiwaną treść klucza, swój znacznik autoryzacji SPF i znacznik wersji DMARC. Korzysta ze stanu weryfikacji zapisanego w pamięci podręcznej i aktualizowanego przez asynchroniczne sprawdzanie DNS.
Nie jest to pełna ocena polityki SPF, panel analizy raportów DMARC ani nowe zapytanie DNS przy każdej wiadomości.
Kit zapisuje także odpowiedzi do kandydatów w rozmowie rekrutacyjnej. Kit zapisuje timestamp udanej wysyłki po przekazaniu wiadomości do transportu SMTP; nie dowodzi umieszczenia w folderze Odebrane ani przeczytania.
Własny test u odbiorcy dostarcza dowodów na to, co dzieje się dalej.
Zacznij od odpowiedzi do fikcyjnego kandydata: wyślij ją przez skonfigurowany sposób wysyłki Kit, sprawdź wyniki uwierzytelniania odebranej wiadomości i odpowiedz, żeby odpowiedź wróciła do Kit. Następnie uzupełnij wiersze skrzynki pracownika i narzędzia do planowania rozmów.
Jeśli oceniasz Kit do rekrutacji, uwzględnij ten test w okresie próbnym i wyznacz osobę odpowiedzialną za aktualizowanie wyników.
Powiązane artykuły
Wypróbuj Kit przez 30 dni.
Rekrutacja, zgłoszenia podatności i szkolenia w jednym koncie, dla zespołów, w których nikt nie robi tego na pełny etat. Kartę podajesz na starcie; zrezygnuj przed końcem okresu próbnego, a nic nie zapłacisz.
Zacznij za darmo