konfiguracja własnego nadawcy

Konfiguracja własnego nadawcy to ustawienie adresu i domeny, z których wysyłane są wiadomości w imieniu organizacji.

Adres nadawcy a domena wysyłająca wiadomość

Konfiguracja własnego nadawcy polega na wskazaniu adresu e-mail oraz domeny, które mają być widoczne przy wiadomościach wysyłanych przez aplikację, formularz internetowy albo usługę do obsługi korespondencji. Adres w polu „From”, nazywany także nagłówkiem From:, identyfikuje nadawcę prezentowanego odbiorcy. Nie musi on być tym samym adresem, który technicznie przekazuje wiadomość między serwerami. Do transportu służy między innymi adres koperty SMTP, określany jako envelope sender lub adres używany przy komendzie MAIL FROM. Rozróżnienie tych dwóch wartości ma znaczenie przy obsłudze zwrotek i weryfikacji autentyczności.

Własny nadawca może korzystać z domeny organizacji, na przykład firma.example, oraz z adresu w rodzaju Ten adres pocztowy jest chroniony przed spamowaniem. Aby go zobaczyć, konieczne jest włączenie w przeglądarce obsługi JavaScript.. Sama zmiana tekstu widocznego w polu nadawcy nie wystarcza jednak do wiarygodnego wysyłania poczty. Usługa wysyłająca zwykle wymaga potwierdzenia prawa do używania domeny lub konkretnego adresu. Weryfikacja może polegać na kliknięciu odnośnika przesłanego na skrzynkę pocztową albo na dodaniu rekordu DNS wskazanego przez dostawcę. Bez tego wiadomości mogą być odrzucane, oznaczane jako podejrzane albo wysyłane z technicznego adresu zastępczego.

Rekordy DNS potrzebne do autoryzacji nadawcy

Najczęściej konfiguracja własnego nadawcy obejmuje trzy mechanizmy DNS: SPF, DKIM i DMARC. SPF, czyli Sender Policy Framework, wykorzystuje rekord TXT przypisany do domeny koperty nadawcy. Rekord określa, jakie serwery lub usługi mogą wysyłać wiadomości w imieniu tej domeny. Serwer odbiorcy porównuje adres IP faktycznego nadawcy z regułą SPF. Przy dodawaniu kolejnego dostawcy należy zmienić istniejący rekord, a nie tworzyć kilka niezależnych rekordów SPF dla tej samej domeny, ponieważ wiele rekordów może prowadzić do błędnej oceny.

DKIM, czyli DomainKeys Identified Mail, dodaje do wiadomości podpis kryptograficzny. Usługa wysyłająca przechowuje klucz prywatny, natomiast klucz publiczny jest publikowany w rekordzie TXT pod nazwą zawierającą selektor, na przykład selektor._domainkey.firma.example. Odbiorca pobiera klucz publiczny z DNS i sprawdza, czy podpis odpowiada treści oraz wybranym nagłówkom wiadomości. Zmiana treści po podpisaniu, nieprawidłowy rekord DNS albo użycie niewłaściwego selektora powoduje niepowodzenie weryfikacji.

DMARC, czyli Domain-based Message Authentication, Reporting and Conformance, określa sposób postępowania z wiadomościami, które nie przechodzą kontroli SPF lub DKIM oraz nie zachowują zgodności domeny z adresem widocznym w polu „From”. Rekord DMARC jest publikowany jako TXT pod nazwą _dmarc.firma.example. Polityka może mieć wartość none, quarantine albo reject. Pierwsza służy głównie do obserwacji, druga sugeruje umieszczenie wiadomości w spamie, a trzecia wskazuje na odrzucenie. Ustawienie restrykcyjnej polityki bez sprawdzenia wszystkich legalnych źródeł wysyłki może spowodować niedostarczanie prawidłowej korespondencji.

Połączenie usługi wysyłającej i obsługa zwrotek

Po stronie aplikacji trzeba wybrać sposób wysyłania wiadomości. Może to być połączenie SMTP z nazwą hosta, portem, metodą uwierzytelniania i szyfrowaniem TLS albo interfejs API, w którym aplikacja przekazuje dane wiadomości za pomocą żądania HTTP. Dane logowania do SMTP i klucze API powinny być przechowywane poza kodem źródłowym, na przykład w zmiennych środowiskowych lub bezpiecznym magazynie konfiguracji. Przy połączeniu SMTP trzeba rozróżnić port używany do połączenia szyfrowanego od portu przeznaczonego do rozpoczęcia sesji bez szyfrowania i późniejszego użycia mechanizmu STARTTLS, ponieważ pomylenie tych trybów może powodować błąd negocjacji.

Adres „Reply-To” może wskazywać skrzynkę, na którą mają trafiać odpowiedzi, i nie musi być identyczny z adresem „From”. Z kolei adres koperty SMTP powinien prowadzić do miejsca, w którym można odbierać komunikaty o niedostarczeniu. Zwrotka może mieć status tymczasowy, zwykle oznaczany kodem SMTP z klasy 4xx, albo trwały, z klasy 5xx. Aplikacja powinna zapisywać identyfikator wiadomości, wynik przekazania oraz odpowiedź usługi, ale nie powinna wielokrotnie ponawiać wysyłki po trwałym odrzuceniu bez analizy przyczyny. W przeciwnym razie jeden błędny adres może generować powtarzające się komunikaty i utrudniać ocenę rzeczywistego stanu dostarczenia.

Testowanie konfiguracji przed użyciem własnego nadawcy

Test należy wykonać z kilku adresów odbiorczych, najlepiej w różnych usługach pocztowych. W otrzymanej wiadomości warto sprawdzić pełne nagłówki, a nie tylko wygląd pola nadawcy. Powinny być widoczne wyniki kontroli SPF, DKIM i DMARC, nazwa domeny podpisującej oraz informacja o serwerze, który przekazał wiadomość. Trzeba również zweryfikować, czy odpowiedź trafia do właściwego adresu „Reply-To”, czy zwrotka jest obsługiwana oraz czy wiadomość nie ma nadmiarowych nagłówków lub nieprawidłowych znaków w temacie i nazwie nadawcy.

Typowe problemy wynikają z literówki w rekordzie TXT, opublikowania rekordu w niewłaściwej domenie, niezgodnego selektora DKIM, opóźnienia aktualizacji DNS albo użycia adresu „From” z domeny innej niż domena objęta autoryzacją. Znaczenie ma także zgodność domen: SPF może przejść dla adresu koperty, lecz DMARC nadal może nie uznać wiadomości, jeżeli domena koperty nie odpowiada domenie z pola „From”. Przy diagnozie lokalnych problemów z aplikacją pocztową, przeglądarką lub komputerem Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów i komputerów PC oraz ich podzespołów.