Spisuj rzeczywistą ścieżkę, a nie etykietę aplikacji
„Używa SMTP ” nie informuje zespołu e-mailowego, w jaki sposób aplikacja może wysyłać. Aplikacja może zostać przesłana za pośrednictwem skrzynki pocztowej, przekazana za pośrednictwem łącznika organizacji lub dostarczona bezpośrednio do systemu odbiorcy. Trasy te mają różne tożsamości, uprawnienia i limity odbiorców. W spisie, w którym rejestrowana jest tylko nazwa dostawcy i adres nadawcy, może nie zostać spełniony warunek, który powoduje, że trasa działa.
Utwórz po jednym wpisie dla każdej znacząco innej ścieżki aplikacji. Przechwyć skonfigurowany punkt końcowy, port, wymagania transportowe, metodę uwierzytelniania, nadawca kopertowy, widoczne Od adresu, oczekiwanych odbiorców i właściciela kolejki. W stosownych przypadkach podaj lokalizację hostingu i publiczny źródłowy adres IP zaobserwowany przez usługę odbierającą. Prywatny adres maszyny nie jest dowodem adresu, który widzi złącze chmury po translacji sieci.
Odróżnij role SMTP od nazw produktów dostawców
Przekaźnik SMTP pełni ogólną rolę transportową, podczas gdy „Przekaźnik SMTP ” i „Wysyłanie bezpośrednie” firmy Microsoft oznaczają określone udokumentowane opcje. W przewodniku konfiguracji aplikacji Microsoft 365 sprawdzonym 8 listopada 2026 r. przesyłanie klientów korzysta z uwierzytelniania skrzynki pocztowej, przekazywanie korzysta z łącznika przychodzącego, a funkcja Direct Send dociera do odbiorców w organizacji w chmurze, a nie zapewnia zewnętrzny przekaźnik. Etykiet tych nie należy bezkrytycznie przekazywać innemu dostawcy. Konfiguracja poczty aplikacji Microsoft.
Na poziomie protokołu klient prezentuje transakcję SMTP i otrzymuje odpowiedzi na poszczególne kroki. Pomyślne połączenie nie powoduje uzyskania pozwolenia na przekazywanie do każdego miejsca docelowego. Zapisz rolę odbierającą przeznaczoną dla wybranego punktu końcowego przed rozwiązywaniem problemów z odrzuconym odbiorcą. Publiczny rekord MX to miejsce docelowe ruchu przychodzącego, a nie zaproszenie do korzystania z jego właściciela jako nieograniczonej usługi wychodzącej. RFC 5321 , sekcje 2.3 i 3.3.
Umieść wymagania dotyczące trasy obok ekwipunku
W przypadku udokumentowanych wyborów firmy Microsoft zarejestruj adres smtp.office365.com w celu przesłania klienta w porównaniu z punktem końcowym MX dzierżawy w przypadku przekazywania lub wysyłania bezpośredniego. Możliwość przekazywania zależy od skonfigurowanego certyfikatu lub kwalifikującego się złącza publicznego adresu IP; uwierzytelnianie skrzynki pocztowej należy do trasy przesyłania. Zachowaj ograniczenia bieżącego przewodnika dotyczące hostingu, domen nadawców, transportu i zasięgu odbiorców, zamiast kopiować ogólny przepis konfiguracyjny. Strona konfiguracyjna firmy Microsoft została zaktualizowana 16 września 2026 r.; Możliwość zastosowania najemcy nadal wymaga potwierdzenia. Konfiguracja poczty aplikacji Microsoft.
Mapa drogi do wymagań to ramy inwentaryzacji dokumentów. Jego celem jest ujawnienie brakujących dowodów, a nie automatyczne wybranie trasy. Jeśli aplikacja potrzebuje odbiorców zewnętrznych, ścieżka przeznaczona wyłącznie dla dzierżawców stanowi niezgodność funkcjonalną, nawet jeśli testy wewnętrzne powiodą się. Jeśli trasa zależy od łącznika, zapisana nazwa hosta bez zweryfikowanego dopasowania łącznika jest niekompletnym dowodem. Jeśli ustawienia uwierzytelniania są celowo ograniczone, wybierz autoryzowany obsługiwany projekt zamiast wyłączać kontrolę bezpieczeństwa, aby stary przepis działał.
Należy odróżniać autoryzację nadawcy od wyników uwierzytelniania
Zezwolenie usługi na przesyłanie poczty jest odrębne od zezwolenia wiadomości SPF, DKIM I DMARC wyniki u dalszego odbiornika. Pomyślne uwierzytelnienie skrzynki pocztowej nie oznacza, że widoczny adres Od jest autoryzowany dla tej skrzynki pocztowej. Łącznik pasujący do źródła nie dowodzi, że każda wynikowa wiadomość ma dopasowane uwierzytelnianie. I odwrotnie, zmiana społeczeństwa Rekord SPF nie przyznaje pozwolenia na przekazywanie usługi SMTP .
Zapisz zezwolenie administracyjne i dowód tożsamości w oddzielnych polach inwentarza. DMARC ocenia domenę autora pod kątem uwierzytelnionych identyfikatorów; nie jest to rejestr, w którym aplikacje przechowują dane uwierzytelniające. Ostateczny wynik odbiorcy powinien być powiązany z dokładną wiadomością i lokalizacją oceny. RFC 9989 , sekcja 4.4. Poświadczenia i tokeny nigdy nie powinny pojawiać się w ekwipunku ani na zgłoszeniu diagnostycznym; zamiast tego zapisz zatwierdzone odniesienie do ich właściciela i procesu zarządzania.
Użyj fikcyjnej aplikacji, aby ujawnić ukrytą zależność
Załóżmy, że fikcyjny skaner magazynu wysyła powiadomienia o wysyłce do pracowników za pośrednictwem punktu końcowego MX dzierżawy. W wykazie widnieje informacja „przekaźnik SMTP ”, ale nie załączono żadnych dowodów potwierdzających złącze. Później zespół dodaje adres zewnętrznego kuriera, a dostawa nie udaje się. Awaria nie oznacza, że domena kuriera lub SPF skanera są wadliwe. Pierwsze pytanie dotyczy tego, czy trasa była kiedykolwiek autoryzowana dla przekaźnika zewnętrznego lub czy pomyślna poczta wewnętrzna korzystała z innej ścieżki usługi.
Druga fikcyjna zmiana przenosi ruch skanera przez nową bramę sieciową. Ustawienia aplikacji pozostają takie same, zmienia się jednak źródło publiczne widziane przez usługę. Jeśli zatwierdzona trasa zależała od tożsamości źródła, niezmieniony ekran aplikacji wprowadza w błąd. Przed jakąkolwiek zmianą konfiguracji porównaj dowody autoryzowanego złącza i rzeczywistą ścieżkę sieciową z poprzednim rekordem roboczym. Żaden scenariusz nie jest testem na żywo ani diagnozą konta.
Zaplanuj kontrolowany test akceptacyjny
Wybierz autoryzowanego odbiorcę dla każdej wymaganej kategorii odbiorców, nieszkodliwą, jednoznacznie zidentyfikowaną wiadomość i okno czasowe z odpowiedzialnym operatorem. Rejestruj pełne odpowiedzi SMTP oraz etap, identyfikator kolejki, trasę i ostateczne wyniki zaufanego uwierzytelnienia, jeśli są dostępne. Odpowiedź na przyjęcie zgłoszenia potwierdza przekazanie, a nie ostateczne umieszczenie w skrzynce odbiorczej. Serwer niższego szczebla przejmuje odpowiedzialność za transport po pozytywnej odpowiedzi na zakończenie po przesłaniu danych komunikatu. RFC 5321 , sekcja 4.2.5.
Uwzględnij negatywne oczekiwania bez sondowania niepowiązanych odbiorców lub przekazów publicznych. Jeżeli trasa celowo ma charakter wyłącznie wewnętrzny, wymagane jest udokumentowanie tego ograniczenia, a nie znalezienie sposobu na jego obejście. Zachowaj jawność własności ponownych prób, aby aplikacja nie utworzyła drugiej wiadomości, podczas gdy jej usługa pocztowa ma już pierwszą w kolejce.
Zachowaj wersjonowanie inwentarza
Przejrzyj wpis po migracji sieci, odnowieniu certyfikatu, zmianie zasad uwierzytelniania lub rozszerzeniu zakresu odbiorców. Dokumentacja dostawcy stanowi dowód przestarzały, natomiast faktyczna konfiguracja dzierżawcy stanowi odrębny dowód. Nie należy ratować przestarzałej receptury uwierzytelniania poprzez udostępnianie haseł lub osłabianie zabezpieczeń.
Mapa drogi do wymagań z aktualnymi danymi dostawcy i kontrolowanym komunikatem testowym. Ten dokładny wymóg pozostaje otwarty. Nie sprawdzono ani nie zmieniono żadnych ustawień dzierżawy, łącznika, poświadczeń, trasy sieciowej ani kontrolowanego komunikatu. Dostarczona mapa i przykłady przygotowują dochodzenie; nie poświadczają, że aplikacja jest poprawnie skonfigurowana.