DMARC без прекида поште: од p=none до p=reject у три корака

За активан домен, DMARC уведите у три корака: попишите пошиљаоце и поравнајте SPF или DKIM, објавите запис са p=none и извештајима, па после исправљања грешака пређите на p=quarantine и p=reject. Тај редослед и проверу пре пооштравања политике описује Мајкрософтово упутство за DMARC као начин да се смањи ризик од одбијања исправне поште.

За условни домен firma.example почетни DNS TXT запис поставите на име _dmarc.firma.example, са вредношћу v=DMARC1; p=none; rua=mailto:[email protected]. Адреса наведена после rua треба да прима агрегатне извештаје. Овим записом тражите податке о проверама, без захтева да примаоци због DMARC неуспеха одбаце поруку.

1. Попишите све пошиљаоце и проверите поравнање

У попис унесите пословне сандучиће, сервисе за билтене, фактурисање, корисничку подршку, обавештења са сајта и сваки други систем који шаље са адресом вашег домена у пољу From. Забележите и повремене токове, попут месечних фактура: проба обављена само са главног сервера неће открити њихове грешке. Ако сервис шаље са поддомена, забележите његову адресу и подешавања засебно.

За сваки ток утврдите домен повратне адресе који се проверава SPF-ом, домен у DKIM потпису и домен видљив у пољу From. DMARC пролази ако је бар једна провера успешна и поравната са доменом у пољу From. На пример, сервис може успешно да прође SPF за сопствени домен, а да DMARC ипак падне ако шаље са адресе firma.example и нема DKIM потпис поравнат са тим доменом. Решење је поравната повратна адреса или DKIM потпис вашим доменом, у зависности од могућности сервиса.

Google смернице за пошиљаоце захтевају SPF, DKIM и DMARC за пошиљаоце великих количина поште ка личним Gmail адресама и препоручују DMARC извештаје за праћење употребе домена. То је посебан захтев за слање Gmail-у: за сам DMARC пролаз довољан је један успешан, поравнат механизам. Зато проверите заглавља стварно послатих порука; само постојање SPF и DKIM записа у DNS-у не показује којим доменима конкретан сервис шаље и потписује.

2. Објавите p=none и упоредите извештаје са пописом

Код DNS провајдера направите један TXT запис за DMARC име домена. Неки панели очекују само _dmarc и сами додају назив домена, док други траже пуно име; после чувања проверите јавним DNS упитом шта је заиста објављено. Проверите и да на истом имену нема другог DMARC записа, јер више таквих записа може спречити примену политике.

Агрегатни извештаји стижу на адресу из rua и приказују изворе порука и исходе аутентификације. Пошто су обично машински читљиви прилози, за већи саобраћај је практичан парсер или сервис за њихову обраду. Упоредите пријављене изворе са својим пописом: познат сервис који пада на поравнању треба поправити пре промене политике. Непознату IP адресу прво повежите са стварним током слања; сама адреса не говори да ли је реч о заборављеном провајдеру или неовлашћеном слању.

Пробне поруке пошаљите из сваког легитимног система и у заглављу Authentication-Results погледајте резултат DMARC-а, као и домене које су проверили SPF и DKIM. Затим посматрајте извештаје довољно дуго да обухвате и ређе пословне поруке. Политика p=none не тражи DMARC блокирање, али прималац и даље може применити друге филтере; успех ове фазе је поуздан попис токова који пролазе проверу.

3. Пооштравајте политику тек када легитимна пошта пролази

Када сте исправили познате легитимне изворе, промените вредност истог записа на v=DMARC1; p=quarantine; rua=mailto:[email protected]. Поруке које падну на DMARC провери тада могу бити премештене у нежељену пошту или карантин, зависно од поступања примаоца. Наставите да упоређујете извештаје са пописом и пратите пријављене проблеме са испоруком пре следеће промене.

За постепено увођење можете најпре подесити засебан поддомен са мање пошиљалаца, па прећи на сложеније токове и главни домен. Поддомен са сопственим DMARC записом може имати своју политику; ако га нема, може бити обухваћен политиком надређеног домена. Зато пре пооштравања главног записа проверите и сервисе који користе поддомене. Овакав редослед ограничава број токова које морате истовремено да дијагностикујете, али не замењује проверу сваког легитимног пошиљаоца.

Актуелни DMARC стандард RFC 9989 уклонио је ознаку pct: раније је служила за примену строже политике на проценат неуспелих порука, али се у пракси примењивала неуједначено. Зато се на pct не ослањајте као на гаранцију да ће само мали део неисправно подешене пословне поште осетити промену. Постепеност заснивајте на попису, извештајима и одвојеном увођењу по доменима или поддоменима.

Када и под p=quarantine легитимни токови стабилно пролазе проверу, замените политику вредношћу v=DMARC1; p=reject; rua=mailto:[email protected]. Ако се јави проблем са испоруком, утврдите који сервис и који домен нису поравнати пре даљег пооштравања других домена. Ни успешан DMARC пролаз не гарантује смештај у пријемно сандуче: примаоци доносе и друге одлуке о прихватању и филтрирању поште.

Домен који не шаље пошту

За условни паркирани домен rezerva.example, за који сте проверили да се уопште не користи за слање, TXT запис на _dmarc.rezerva.example може одмах имати вредност v=DMARC1; p=reject. Нема легитимног саобраћаја који треба постепено уводити. Пре тога ипак проверите веб-формуларе, старе налоге и повезане сервисе: ако било који шаље са тог домена, примените поступак за активан домен.

Прочитајте и:

• n8n или Make: број корака мења јефтинији избор