Ustal, czy Openprovider obsługuje aktywną strefę
Ten przewodnik dotyczy publikowania rekordów uwierzytelniających w Openprovider DNS . Nie jest to przewodnik konfiguracji oddzielnej skrzynki pocztowej ani produktów do przesyłania dalej firmy Openprovider. Twoja domena może zostać zarejestrowana w Openprovider, podczas gdy Microsoft 365 , usługa kampanii lub inny dostawca wysyła swoją pocztę. Nadawca dostarcza swoje instrukcje uwierzytelniania; autorytatywny operator DNS publikuje zatwierdzone rekordy. Przydzielając pracę, oddzielaj te role.
Openprovider obsługuje własne serwery nazw i zewnętrzne serwery nazw. Przewodnik po serwerze nazw wyjaśnia, że strefy hostowane zewnętrznie muszą być skonfigurowane u zewnętrznego dostawcy DNS , natomiast strefy hostowane przez Openprovider są zarządzane poprzez Zarządzanie DNS i przegląd stref DNS . Zacznij od faktycznego przekazania uprawnień publicznych i dokładnej strefy podlegającej zmianom. Zarejestrowana domena i strefa widoczna na koncie nie wystarczą do ustalenia uprawnień. Wskazówki dotyczące serwera nazw Openprovider
Nie zmieniaj serwerów nazw tylko po to, aby utworzyć SPF dostępny edytor. Jest to osobna migracja, która może mieć wpływ na witrynę, pocztę przychodzącą, tokeny weryfikacyjne i DNSSEC. Jeśli dostawca zewnętrzny jest autorytatywny, przekaż zatwierdzone zmiany w zapisach administratorowi tego dostawcy. Jeśli Openprovider jest autorytatywny, potwierdź, że edytujesz strefę aktywną, a nie szablon przeznaczony do wykorzystania w przyszłości.
Zbierz zmiany rekordów z usługi wysyłającej
Poproś o aktualną autoryzację SPF wydaną przez nadawcę, DKIM właścicieli i wartości, wszelkie instrukcje dotyczące niestandardowej koperty oraz dokładną domenę, do której każda z nich ma zastosowanie. Unikaj uniwersalnego rekordu zwanego ustawieniem SPF Openprovider: host DNS nie staje się autoryzowanym nadawcą poczty po prostu udostępniając strefę. To samo rozróżnienie dotyczy DKIM . Artykuł Openprovider dotyczący DKIM mówi, że serwer wysyłający pocztę określa treść rekordu, a dostawca lub inżynier systemu dostarcza ją. Publikacja Openprovider DKIM
Wyeksportuj lub w inny sposób zachowaj kompletne zestawy rekordów, których to dotyczy, w tym nazwy właścicieli, typy, TTL i wartości. Zachowaj niepowiązane tokeny TXT w stanie nienaruszonym. Zapisz każde proponowane działanie jako dodaj, zamień lub wycofaj, wraz z właścicielem usługi i powodem. A selektor który wydaje się stary, może nadal sprawdzać pocztę oczekującą w kolejce lub obsługiwać inną aplikację. Dyspozycja nowej usługi nie upoważnia do usunięcia klucza starej usługi.
Oddziel w pełni kwalifikowanego zamierzonego właściciela od danych wejściowych edytora. W przypadku DKIM etykiety selektora i _domainkey są niezbędne; nie można ich zastąpić wierzchołkiem domeny. Dla DMARC, zidentyfikuj odpowiedniego właściciela _dmarc . W przypadku SPF zidentyfikuj rzeczywistą domenę koperty SMTP . Pobrany przewodnik po rekordach DNS nie ustanawia aktualnej uniwersalnej konwencji wpisów wierzchołkowych. Przed zapisaniem potwierdź bieżącą obsługę interfejsu właściciela root i dołączone sufiksy; nie zakładaj, że pole jest puste lub @ jest akceptowane w każdym trybie wprowadzania. Konwencje rekordów DNS Openprovider
Publikuj SPF jako jedną zasadę ze zweryfikowanym formatowaniem TXT
Używany jest przewodnik SPF Openprovider Rekordy TXT i wyraźnie instruuje użytkowników, aby ująć treść w prosty cudzysłów. Postępuj zgodnie z udokumentowaną konwencją wprowadzania bieżącego redaktora, a następnie sprawdź opublikowaną odpowiedź TXT , aby sprawdzić, czy formatowanie zostało poprawnie zinterpretowane. Cudzysłowy cudzysłów skopiowany z edytora tekstu nie są równoważne. Nie dodawaj wielokrotnie warstw cudzysłowów, gdy moduł rozpoznawania nazw wyświetla już ciągi znaków z cudzysłowami. Publikacja Openprovider SPF
Semantyka protokołu jest kryterium akceptacji. U ocenianego właściciela powinna istnieć jedna kandydująca polityka SPF . Rekord TXT może zawierać wiele ciągów znaków, które są łączone w celu przetwarzania SPF , zatem podział wyświetlania niekoniecznie oznacza wiele zasad. I odwrotnie, dwa oddzielne rekordy rozpoczynające się od znacznika wersji SPF nie są prawidłowym sposobem obsługi dwóch nadawców. Zachowaj wymagane spacje i pełną sekwencję mechanizmu w zrekonstruowanej wartości. SPF RFC 7208
Ogólny artykuł SPF dostawcy zawiera uproszczony język dotyczący długości TXT , podczas gdy jego przewodnik po rekordach DNS wyraźnie opisuje dzielenie dużej wartości TXT na mniejsze ciągi w jednym rekordzie. Limitu ciągu znaków nie można traktować jako całkowitego limitu rekordów. Potwierdź obsługę bieżącego redaktora i zweryfikuj zrekonstruowaną odpowiedź. Wskazówki dotyczące rekordów TXT Openprovider Jeśli długa wartość zostanie odrzucona, uzyskaj wskazówki od dostawcy; nie skracaj klucza publicznego ani nie dziel polityki SPF na niezależne rekordy.
Przed zapisaniem połączonych zasad oceń limity wyszukiwania rekurencyjnego SPF . Wizualnie krótkie zasady mogą nadal przekraczać limit dzięki dołączonym zasadom. Nie zastępuj mechanizmów obsługiwanych przez dostawcę migawką dzisiejszych adresów IP, chyba że ten model konserwacji jest celowo zatwierdzony i wspierany. Statyczne zmiany spłaszczające, które muszą śledzić przyszłe zmiany w infrastrukturze.
Zachowaj nienaruszone typy rekordów DKIM i własność selektora
Niektóre usługi wysyłania dostarczają klucz publiczny TXT ; inni dostarczają CNAME alias. Opublikuj dostarczony typ u podanego właściciela selektora. Nie umieszczaj celu CNAME w polu TXT ani nie publikuj klucza na wierzchołku. Odbiorca uzyskuje wyszukiwanie z domeny podpisującej wiadomości i selektora, dlatego też wiarygodnie wyglądający rekord dotyczący innego właściciela nie pomaga. DKIM RFC 6376
Openprovider dokumentuje błędy, gdy CNAME udostępnia swojego właściciela innym zwykłym danym rekordu. Jeśli redaktor zgłosi duplikat lub konflikt CNAME , sprawdź pełny zestaw rekordów tego właściciela. Nie usuwaj sprzecznego rekordu TXT przed zidentyfikowaniem nadawcy, który jest jego właścicielem. Poproś nowego nadawcę o obsługiwany, niekonfliktowy selektor lub zaplanuj kontrolowaną rotację. Konflikt jest kwestią własności zaufania, a nie jedynie problemem sprawdzania poprawności danych wejściowych. Wskazówki dotyczące konfliktu CNAME Openprovider
Rekord klucza publicznego lub delegowania nie powoduje rozpoczęcia podpisywania przez usługę wysyłającą. Dokonaj osobnej aktywacji po stronie nadawcy i zweryfikuj podpis prawdziwej wiadomości. Nigdy nie publikuj kluczy prywatnych, danych uwierzytelniających API ani haseł SMTP w strefie lub arkuszu.
Odróżnij ręczne DMARC od delegacji hostowanej
Integracja Openprovider EasyDMARC opisuje dwie ścieżki zarządzania: politykę hostowaną dostępną poprzez alias CNAME oraz ręcznie utrzymywaną politykę TXT . Ostrzega, że cel delegowania pokazany w przykładzie nie jest wartością, której należy użyć; panel sterowania podaje rzeczywisty cel. Opisuje także automatyczne tworzenie rekordu CNAME w procesie kwalifikującego się zakupu lub aktywacji przy użyciu serwerów nazw Openprovider. Dlatego przed ręcznym dodaniem czegokolwiek sprawdź istniejącego właściciela _dmarc . Zarządzanie Openprovider EasyDMARC
Wybierz jeden zatwierdzony model zarządzania. W przypadku delegowania hostowanego zasady operacyjne mogą ulec zmianie w usłudze hostowanej bez odpowiedniej edycji w strefie Openprovider. Przypisz właściciela tej usługi i zachowaj zatwierdzone ustawienia zasad. W przypadku ręcznego TXT zmiany muszą zostać odzwierciedlone w opublikowanej wartości. Unikaj pozostawiania zasad TXT i CNAME u tego samego właściciela i nie zastępuj istniejących miejsc docelowych raportowania jedynie postępując zgodnie z kreatorem integracji.
DMARC ocenia widoczną domenę From pod kątem przekazywania dopasowanych tożsamości SPF lub DKIM . Publikacja jest jedną z części tego procesu; nie dowodzi, że nadawcy domeny są wyrównani. Przed zaostrzeniem egzekwowania zasad należy odróżniać zachowanie odbiorców od żądanych zasad i zachować spis nadawców w całej domenie. DMARC RFC 9989
Arkusz publikowania Openprovider wielokrotnego użytku
Utwórz po jednym wierszu dla każdego zmienionego właściciela i zachowaj udostępniony rekord zmian dla domeny.
- Domena, autorytatywne serwery nazw i identyfikator aktywnej strefy: ______.
- Administrator DNS , administrator nadawcy i osoba zatwierdzająca zmiany: ______.
- Wysyłanie usługi i dowód jej aktualnej konfiguracji: ______.
- Przeznaczony w pełni wykwalifikowany właściciel i osobne wejście hosta redaktora: ______.
- Typ rekordu, pełna zatwierdzona wartość i TTL: ______.
- Wcześniejszy zestaw rekordów i zależności, które muszą przetrwać: ______.
- SPF ocenił właściciela koperty i kontrolę zasad rekurencyjnych: ______.
- Własność selektora DKIM , przegląd konfliktów i aktywacja nadawcy: ______.
- DMARC ręczny wybór TXT lub hostowanego CNAME i właściciel zasady: ______.
- Wiarygodna odpowiedź po zmianie i porównanie rekurencyjne: ______.
- Odniesienie do otrzymanej wiadomości, od, koperta, podpisy i zaufane wyniki: ______.
- Kroki wycofania, ponowny test właściciela, kontrola wizualna i akceptacja przez człowieka: w toku.
Fikcyjna diagnoza kolizji selektora
Ten przykład jest fikcyjny. Sprzedawca dodaje nową usługę marketingową do domeny, której DNS jest hostowany przez Openprovider. Nowa usługa żąda CNAME u selektora, który już posiada klucz TXT dla nadawcy faktury. Openprovider odrzuca zmianę jako konflikt. Sprzedawca proponuje usunięcie TXT ponieważ nowy przewodnik konfiguracji mówi, że selektor jest wymagany.
Bezpieczne dochodzenie identyfikuje nadawcę faktury i potwierdza, że nadal podpisuje on wiadomości wychodzące za pomocą tego selektora. Proponowane odzyskanie polega na złożeniu wniosku o inny obsługiwany selektor w usłudze marketingowej lub skoordynowaniu zweryfikowanego przeniesienia klucza z obydwoma właścicielami. Nie chodzi o ślepe usuwanie klucza faktury. Po zatwierdzeniu zmiany testowane będą osobne faktury i komunikaty marketingowe. W tym scenariuszu nie jest reprezentowana żadna rzeczywista strefa, nadawca ani pomyślny test.
Zamknij za pomocą DNS i dowodów wiadomości
Po zapisaniu i zachowaniu odpowiedzi zapytaj dokładnych właścicieli na autorytatywnych serwerach nazw. Porównaj osobno odpowiedź rekurencyjną, rozpoznając buforowanie. Następnie poproś każdego nadawcę, którego to dotyczy, o przesłanie kontrolowanej wiadomości do niezależnej skrzynki pocztowej i zapisanie wyników dla zaufanego odbiorcy. Walidator działający wyłącznie w systemie DNS nie może potwierdzić, którego selektora faktycznie używa nadawca ani czy przekazana przez niego tożsamość jest zgodna.
Jeśli konieczne jest odzyskanie, przywróć tylko poprzedni zestaw rekordów, którego dotyczy problem, i powtórz odpowiednie testy przepływu pracy. Zachowaj dowody ustawień zasad hostowanych oraz wartości DNS , ponieważ te pierwsze mogą zmieniać się niezależnie. Bieżący dostęp do konta, zrzuty ekranu interfejsu, wiarygodne przechwytywania danych przed i po, dowody otrzymanych wiadomości oraz zatwierdzenie przez MŚP pozostają w oczekiwaniu na publikację tego przewodnika. Nie przeprowadzono żadnych edycji DNS ani testów na żywo.
Trzymaj rejestry publiczne oddzielnie od operacji kryptograficznych
Opublikowanie klucza publicznego nie szyfruje treści wiadomości e-mail, nie tworzy podpisu ani nie gwarantuje, że cała wiadomość jest bezpieczna. Do semantyki podpisywania używaj standardu DKIM , a nie uproszczonego wyjaśnienia dotyczącego szyfrowania zawartego w artykule dostawcy. Sprawdź rzeczywistą podpisaną treść i wynik odbiorcy po zakończeniu aktywacji przez operatora nadawcy.
Oddziel akceptację wiadomości od wdrożenia zasad
Dopasowany wynik SPF może spełnić kryteria oceny wiadomości, ale sam w sobie nie uzasadnia przeniesienia całej domeny w celu odrzucenia. RFC 9989 Sekcja 7.4 wymaga ważnego DKIM do publikowania domen p=reject i ostrzega o interoperacyjności poczty pośredniej. Zrób inwentaryzację wszystkich legalnych nadawców i tras pośrednich, zanim właściciel polityki zatwierdzi egzekwowanie zasad. Dla tego artykułu nie wykonano żadnej zmiany DNS , operacji dzierżawy ani testu odebranych wiadomości.