SPF, DKIM, DMARC — co to jest i jak skonfigurować domenę pod cold mailing

Zanim wyjdzie pierwszy mail kampanii adresowanego cold mailingu z domeny firmowej, trzy rekordy DNS muszą być opublikowane i zweryfikowane: SPF, DKIM i DMARC. Bez nich nawet najlepiej napisana wiadomość do konkretnego decydenta ma niższą szansę dotrzeć do skrzynki odbiorczej, a proces konfiguracji różni się w szczegółach między Google Workspace a Microsoft 365 — pomylenie kolejności to jedna z najczęstszych przyczyn słabej dostarczalności nowej domeny.

Czym są SPF, DKIM i DMARC — krótko i bez żargonu

SPF (Sender Policy Framework) to lista serwerów, które mają prawo wysyłać maile w imieniu danej domeny. Gdy serwer odbierający dostaje wiadomość, sprawdza w DNS, czy nadawca jest na tej liście — jeśli nie, traktuje mail jako potencjalnie podszywający się pod domenę.

DKIM (DomainKeys Identified Mail) to cyfrowy podpis dodawany do każdej wysyłanej wiadomości, potwierdzający, że treść nie została zmieniona po drodze i rzeczywiście pochodzi z domeny, która ją podpisała. Działa niezależnie od SPF — sprawdza integralność wiadomości, nie serwer, z którego wyszła.

DMARC co to w praktyce: to rekord, który mówi serwerowi odbierającemu, jak traktować maile niezgodne z SPF lub DKIM — ma je przepuścić (p=none), umieścić w kwarantannie (p=quarantine) czy odrzucić (p=reject) — oraz gdzie wysyłać raporty o próbach podszywania się pod domenę. To trzeci, spinający element całej układanki uwierzytelnienia poczty.

Zanim zaczniesz: co jest potrzebne i gdzie się to publikuje

Wszystkie trzy rekordy publikuje się w DNS domeny, nie wewnątrz Google Workspace czy Microsoft 365. Potrzebny jest dostęp do panelu, w którym domena jest zdelegowana — może to być panel rejestratora domeny, Cloudflare albo panel dostawcy hostingu. Bez tego dostępu żaden kolejny krok nie ma sensu.

Zalecana kolejność to najpierw SPF, potem DKIM, na końcu DMARC — bo DMARC opiera się na tym, że przynajmniej jeden z dwóch poprzednich mechanizmów działa poprawnie. Pominięcie kolejności nic nieodwracalnie nie psuje, ale znacznie utrudnia diagnozowanie błędu, gdy coś nie działa — łatwiej zweryfikować jeden rekord naraz niż trzy jednocześnie.

Warto też z góry ustalić, kto w organizacji odpowiada za panel DNS, zanim ruszy konfiguracja — w firmach, gdzie domenę kupował dział marketingu, a pocztą zajmuje się IT, hasło do panelu rejestratora bywa zaskakująco trudne do odnalezienia, a to właśnie ten dostęp, nie konto Microsoft 365 czy Google Workspace, jest tu wąskim gardłem całego procesu.

SPF w Microsoft 365 i Google Workspace

Microsoft 365 używa include:spf.protection.outlook.com do autoryzacji własnych serwerów wysyłkowych. Typowy rekord dla firmy korzystającej wyłącznie z Microsoft 365 wygląda tak: v=spf1 include:spf.protection.outlook.com -all. Google Workspace stosuje analogicznie include:_spf.google.com — logika rekordu jest identyczna, zmienia się tylko nazwa include.

Jeśli oprócz poczty firmowej wysyłkę realizuje też platforma do cold mailingu albo CRM, jej serwer musi znaleźć się w tym samym rekordzie SPF, nie w osobnym. Standard SPF nie dopuszcza dwóch rekordów typu spf1 na tej samej domenie — jeśli oba istnieją, większość serwerów odbierających unieważnia je całkowicie, co realnie obniża dostarczalność wszystkich wiadomości z domeny, nie tylko kampanii cold mailingowej.

DKIM: różnica między Microsoft 365 a Google Workspace

W Microsoft 365 DKIM trzeba aktywować ręcznie — nie działa automatycznie po samym założeniu konta. Robi się to w Centrum administracyjnym Microsoft 365, w Microsoft Defender, w sekcji ustawień uwierzytelniania poczty (Email authentication settings). Po wybraniu domeny i włączeniu podpisu DKIM system generuje dwa rekordy CNAME o nazwach w rodzaju selector1._domainkey i selector2._domainkey, które trzeba dokładnie skopiować do DNS.

Google Workspace działa inaczej: DKIM włącza się w panelu administracyjnym, w sekcji Apps, Google Workspace, Gmail, Uwierzytelnianie poczty e-mail, i generuje jeden rekord TXT z własnym selektorem, zamiast dwóch CNAME jak w Microsoft 365. Po opublikowaniu rekordu wraca się do panelu i potwierdza aktywację — status zmienia się z wyłączonego na włączony.

Propagacja CNAME w Microsoft 365 zwykle trwa nieco dłużej niż zwykłego TXT, więc przed uznaniem weryfikacji za nieudaną warto odczekać kilka godzin.

• Microsoft 365: DKIM aktywowany ręcznie w Microsoft Defender, dwa rekordy CNAME
• Google Workspace: DKIM aktywowany w panelu administracyjnym Gmaila, jeden rekord TXT
• W obu przypadkach: dokładne skopiowanie wartości bez zmiany wielkości liter i dodatkowych kropek
• Po publikacji rekordów trzeba wrócić do panelu i ręcznie potwierdzić aktywację DKIM

DMARC: ten sam rekord niezależnie od dostawcy poczty

DMARC nie zależy od tego, czy firma korzysta z Microsoft 365, czy z Google Workspace — to rekord TXT publikowany w _dmarc.twojadomena.pl, o wartości w rodzaju v=DMARC1; p=none; rua=mailto:dmarc-raporty@twojadomena.pl. Polityka p=none to obowiązkowy punkt startowy — włącza zbieranie raportów bez blokowania jakiejkolwiek wiadomości.

Przez pierwsze dwa-trzy tygodnie warto przeglądać raporty zbiorcze przychodzące na adres z rua. Widać w nich na przykład, że poczta transakcyjna z narzędzia do fakturowania nie przechodzi weryfikacji, bo nikt nie dodał jej do SPF. Dopiero gdy raporty pokazują, że cała legalna poczta przechodzi weryfikację, ma sens podniesienie polityki do p=quarantine, a później do p=reject.

Kilka dostawców wysyłki na jednej domenie

W praktyce adresowanego cold mailingu B2B domena rzadko wysyła pocztę tylko z jednego źródła. Oprócz skrzynek zespołowych w Microsoft 365 czy Google Workspace, tę samą domenę często wykorzystuje platforma do cold mailingu, narzędzie do fakturowania i czasem system CRM wysyłający powiadomienia. Każdy z nich musi znaleźć się jako osobny include w tym samym rekordzie SPF — nie w oddzielnych rekordach, bo standard dopuszcza tylko jeden rekord typu spf1 na domenę.

Standard SPF ogranicza też liczbę zagnieżdżonych zapytań DNS do dziesięciu na jeden rekord — każdy include, który sam w sobie odwołuje się do kolejnych includów, zbliża rekord do tego limitu. Przy czterech, pięciu różnych dostawcach wysyłki na jednej domenie warto sprawdzić w narzędziu diagnostycznym, czy rekord nie przekracza tego limitu, bo przekroczenie skutkuje tym, że serwery odbierające przestają w ogóle poprawnie weryfikować SPF, nawet jeśli sama treść rekordu wygląda składniowo poprawnie.

DKIM w tej sytuacji działa inaczej niż SPF — każdy dostawca wysyłki aktywuje własny podpis niezależnie, bez ograniczenia liczby dostawców. To sprawia, że przy wielu źródłach wysyłki łatwiej upilnować poprawność DKIM niż SPF, gdzie wszystkie źródła muszą zmieścić się w jednym, wspólnym rekordzie.

Weryfikacja przed startem kampanii

Gdy wszystkie trzy rekordy są opublikowane i się rozpropagowały, ostatni krok to wysłanie realnego testowego maila z konta, które ma obsługiwać kampanię, na adres Gmail i Outlook, które kontrolujesz. W Gmailu wybierasz „Pokaż oryginał” i sprawdzasz, czy przy spf, dkim i dmarc widnieje wynik pass.

Jeśli którykolwiek mechanizm zawodzi, kampanii jeszcze nie warto uruchamiać. Naprawa błędu na tym etapie, przy niskim wolumenie testowym, jest tania. Ten sam błąd wykryty po wysłaniu stu kilkudziesięciu maili do realnych decydentów kosztuje reputację domeny, którą odbudowuje się potem tygodniami.

Najczęściej zadawane pytania