Walka ze spamem - SPF, DKIM, DMARC

UPDATED
Zaktualizowane odnośniki

Kiedy 10 lat temu wprowadzono system Exchange 2007, mechanizmy walki ze spamem były stosunkowo ubogie - weryfikacja nazwy serwera w RevDNS operatora, listy RBL i niewiele więcej. Jednak opracowywany od 2004 roku standard SPF, opublikowany jako draft RFC 4408 oraz jego Microsoftowe rozszerzenie Sender Id - draft RFC 4406 (RFC dla SPF został zaktualizowany jako 6652 i 7208) i , a Sender Id został zaimplementowany w Exchange 2007. Napisałem już kiedyś artykuł na temat SenderId, więc nie będę się powtarzał, warto jednak zająć się nowszymi metodami podniesienia bezpieczeństwa. Na ostatnim spotkaniu PEPUG prezentowany był DMARC, a jakiś czas temu DKIM, więc uznałem, że warto tym razem poświęcić parę słów tym rozwiązaniom.

DKIM czyli DomainKeys Identified Mail (opisana w 2009 roku w RFC 5585) to usługa polegająca na zabezpieczaniu wysyłanych maili kluczem domenowym. Żeby klucz ten można było zweryfikować, w DNS umieszczany jest rekord zawierający klucz publiczny odpowiadający danej domenie.

Od przeszło pół roku usługa Office365 pozwala na weryfikację maili przychodzących poprzez DKIM, możliwości wykorzystania tej usługi posiada również wiele komercyjnych rozwiązań antyspamowych. Od niedawna pojawiła się również możliwość zabezpieczania ruchu wychodzącego.

W tym celu po pierwsze musimy dodać do DNS naszej domeny dwa rekordy CName (nie TXT!).

W przykładzie użyję domeny pepug.net.

Host name:          selector1._domainkey
Wskazanie na hosta: selector1-domainGUID._domainkey.O365Domain
TTL:                3600 

Host name:          selector2._domainkey
Wskazanie na hosta: selector2-domainGUID._domainkey.O365Domain
TTL:                3600

Jakie wartości podstawić pod domainGUID i O365Domain?

DomainGUID to wartość, która jest wstawiana jako początkowy człon rekordu MX (przed suffixem mail.protection.outlook.com), dla tenanta naszej firmy. W omawianym przykładzie jest to ciąg pepug-net, jak pokazuje poniższy rysunek:

O365Domain, to nazwa tenanta, wskazana w konfiguracji usługi - w omawianym przykładzie pepugnet.onmicrosoft.com.

Czyli odpowiednie wartości to selector1-pepug-net._domainkey.pepugnet.onmicrosoft.com i selector2-pepug-net._domainkey.pepugnet.onmicrosoft.com.

Dokumentacja Exchange Online opisuje również ten proces całkiem szczegółowo. Po skonfigurowaniu DNS, możemy włączyć usługę DKIM w ustawieniach domen pocztowych, obsługiwanych przez nasz tenant. W tym celu przechodzimy w konsoli administracyjnej do administracji Exchange, zakładki "Ochrona" - "DKIM". W prawym panelu akcji jest dostępny przycisk "Włącz" (wyróżniony na niebiesko). 

Po włączeniu tej funkcjonalności zmieniają się ustawienia, jak widać na poniższym rysunku:

UPDATED: Analogiczna możliwość dostępna jest w ustawieniach zabezpieczeń poczty w portalu zarządzaniu ochroną naszego tenanta - https://protection.office.com.
Po wysłaniu  wiadomości widać w nagłówku informację o użyciu DKIM i szczegóły podpisu:

Alternatywnie można użyć skryptu Validate-DkimConfig.ps1, opisanego na blogu Terry'ego Zinka, oraz Alexa Veboona, do weryfikacji poprawności utworzonych rekordów. UPDATED: Skrypt w ostatnich miesiącach kilkukrotnie zmieniał miejsce publikacji, ale powyższe linki powinny działać. Wyniki działania skryptu widać na poniższym rysunku:

Niestety dla Exchange Server 2010/2013/2016/2019 on-premises, nie ma jak na razie możliwości włączenia takiej funkcjonalności. Są co prawda zewnętrzne dodatki umożliwiające skorzystanie z tej funkcjonalności, niektóre płatne, jak np. EA DomainKeys/DKIM for Exchange Server lub bezpłatne jak DKIM Signing Agent for Microsoft Exchange Server. Mam nadzieję, że niedługo, przynajmniej w najnowszej wersji Exchange 2016 zostanie dodana opcja konfiguracji DKIM-a.
UPDATED: Niestety, Microsoft nie wprowadził natywnej obsługi DKIM ani w Exchange 2016 ani w Exchange 2019.

W kolejnym poście opiszę funkcjonalność DMARC.