Mapuj konta na domenę wysyłającą
Uwierzytelnianie Emma łączy DNS na poziomie domeny z etapem weryfikacji specyficznej dla konta. Zacznij od wyszczególnienia każdego konta lub subkonta, które będzie wysyłać wiadomości z domeny, jego właściciela i docelowego adresu e-mail domyślnego nadawcy. Ta sama domena występująca na dwóch kontach kampanii nie powoduje wymienności ich tokenów weryfikacyjnych.
Dostawcy Przewodnik konfiguracji DKIM instruuje użytkowników, aby domyślny adres e-mail nadawcy odpowiadał uwierzytelnianej domenie. Potwierdź to ustawienie, zanim DNS zacznie działać. W przeciwnym razie administrator może pomyślnie skonfigurować jedną domenę, podczas gdy właściciel kampanii będzie kontynuował wysyłanie z inną tożsamością.
Opublikuj rekordy domeny i dowód konta
Emma dokumentuje trzy DKIM CNAME rekordy, używając selektorów e2ma-k1, e2ma-k2 i e2ma-k3 w _domainkey i odpowiednich obiektów docelowych w dkim.e2ma.net . Podczas implementowania pobierz bieżące wartości z instrukcji dostawcy i użyj poprawnej składni nazwy właściciela hosta DNS . Ten przewodnik nie opisuje konfiguracji konta prywatnego ani nie zapewnia, że istniejące rekordy zostały przetestowane.
Przepływ pracy wymaga również wartości TXT rozpoczynającej się od e2ma-verification= i własnego skrótu walidacyjnego konta. Znajdź ten skrót w Konto > Dostarczalność, aby uzyskać właściwy kontekst konta. Emma twierdzi, że każde konto lub subkonto ma unikalny skrót i że konta wielopoziomowe wymagają oddzielnych rekordów weryfikacyjnych TXT dla odpowiednich subkont. Nie zastępuj rekordu weryfikacyjnego innego aktywnego konta tylko dlatego, że współdzieli domenę.
Inaczej SPF, gdy wiele kandydujących zasad u jednego właściciela powoduje błąd, mogą współistnieć niepowiązane wartości TXT weryfikacji domeny. Zachowaj cel każdego z nich Rekord TXT wyraźne, więc operacja czyszczenia nie usunie dowodu potrzebnego na innym koncie kampanii. Nigdy nie wnioskuj, że jakakolwiek wartość TXT rozpoczynająca się od tokena innej usługi jest przestarzała Rekord SPF.
Weryfikuj nazwy bez uszkadzania istniejących selektorów
Przed publikacją sprawdź rzeczywistą autorytatywną usługę DNS i istniejących właścicieli rekordów. Logowanie rejestratora może nie kontrolować aktywnej strefy. Przy każdym selektor, porównaj istniejący typ rekordu i miejsce docelowe z zatwierdzoną zmianą. CNAME nie może być łączony ze zwykłymi, konkurencyjnymi danymi u tego samego właściciela, dlatego należy rozwiązać kolizję, zamiast zmuszać dwóch dostawców do korzystania z jednej nazwy selektora.
Po zapisaniu sprawdź pełnego właściciela publicznego i cel. Edytory etykiet względnych i w pełni kwalifikowane formaty wejściowe różnią się; zduplikowany sufiks domeny może sprawić, że wizualnie wiarygodny rekord stanie się bezużyteczny. Dokończ ostateczną weryfikację Emmy na właściwym koncie i zachowaj status każdego subkonta osobno. Źródło opisuje przepływ pracy, ale nie stwierdza, czy Twój własny DNS lub konto przeszło przez niego.
Wykorzystaj rzeczywistą tożsamość kampanii
Oryginalny arkusz weryfikacji: jeden wiersz na konto/subkonto, z domyślną domeną nadawcy, właścicielem tokena, odpowiedziami selektora, ostatecznym statusem weryfikacji i dowodem wiadomości kontrolowanej. Wyślij nieszkodliwą kampanię do kontrolowanej skrzynki pocztowej za pośrednictwem każdej zasadniczo innej ścieżki konta. Podczas testowania unikaj adresów klientów i odbiorców produkcyjnych.
Przechwyć wynik DKIM odbiorcy, podpisując domenę i selektor obok widocznej domeny Od i nadawca kopertowy. Ważny podpis potwierdza weryfikację w ramach domeny podpisującej; DMARC dodatkowo wymaga wyrównanie z From dla tej ścieżki uwierzytelniania. Token własności TXT nie jest kluczem używanym do weryfikacji podpisu wiadomości i samo jego sprawdzenie nie może rozstrzygnąć wyrównania.
Przykładowy scenariusz: konto nadrzędne zostało pomyślnie zweryfikowane, podczas gdy subkonto nadal ma wprowadzony hash rodzica jako własny dowód weryfikacji. Następnym właściwym krokiem jest pobranie odrębnej wartości subkonta i sprawdzenie poprawności tego konta, a nie ponowne generowanie wszystkich trzech rekordów CNAME domen bez dowodów na defekt DNS .
Zachowaj możliwy do odzyskania inwentarz konta
Zapisz ustawienia i zapisy sprzed zmian. Jeśli weryfikacja się nie powiedzie, wstrzymaj kampanię, której dotyczy problem i sprawdź, czy domyślny nadawca, token konta lub selektor publiczny są nieprawidłowe. Po sprawdzeniu zależności przywróć tylko zmienioną konfigurację. Zachowaj ważne tokeny i selektory innych kont w nienaruszonym stanie.
Sprawdź ponownie przy dodawaniu subkonta, zmianie domyślnego nadawcy lub migracji DNS . Przegląd dokumentacji odbył się 8 listopada 2026 r. Arkusz ćwiczeń i scenariusz są oryginalnymi przykładami; nie testowano tutaj żadnego konta Emmy, żadnego rejestru publicznego ani dostarczanej kampanii.
Użyj księgi uzupełnień z dwoma kontami
Pisemna sprawa EM-01 zakłada, że zarówno Rodzic, jak i Zdarzenia mają na celu Od news@example.com . Rodzic posiada własny token weryfikacyjny i zakończył ostateczną walidację. Zdarzenia błędnie odwołują się do tokena Rodzica; brakuje własnego tokena i ostatecznej walidacji. W tym przykładzie trzy domeny CNAME są określone jako poprawne i nie są sprawdzane. Zachowaj działający token Rodzica, pobierz wartość specyficzną dla konta Wydarzeń i zakończ weryfikację w Wydarzeniach. Nie generuj ponownie selektorów współdzielonych, aby naprawić brakujący dowód konta. Uwierzytelnianie wiadomości w przypadku zdarzeń pozostaje nieznane do czasu sprawdzenia kontrolowanej kampanii. Nie zebrano ani nie opublikowano żadnego tokena ani nie wysłano żadnej kampanii.
Aktualny przewodnik dostawcy ogranicza każde konto lub subkonto do jednej uwierzytelnionej domeny. Jeśli zamiast tego w Wydarzeniach potrzebny jest news@other.example , zapisz tę odrębną tożsamość i wybór konta przed wymianą działającej konfiguracji. Sukces domeny konta nadrzędnego nie usuwa tego limitu produktów.
Zachowaj granicę egzekwowania
RFC 9989 Sekcja 7.4 wymaga prawidłowego DKIM , a nie samego SPF , do publikowania domen p=rejecti ostrzega o współdziałaniu poczty pośredniej i list mailingowych. Pojedynczy pomyślny test wiadomości bezpośredniej nie jest dowodem na to, że każda legalna droga jest gotowa na silniejszą politykę. Zachowaj istniejącą zatwierdzoną ochronę podczas diagnozowania rzeczywistej luki; każda zmiana polityki wymaga własnej decyzji.