DMARC не почиње са „reject“ — прво откријте ко шаље пошту

DMARC за свој домен подесите редом: попишите сервисе који шаљу пошту у ваше име, проверите SPF и DKIM, објавите p=none са адресом за извештаје и исправите откривене грешке пре строже политике. Ако одмах поставите p=reject, прималац може да одбије и исправну поруку из вашег билтена или система за рачуне када тај сервис није правилно аутентификован.

За слање више од 5.000 порука дневно на личне Gmail налоге, Google-ова правила за пошиљаоце траже SPF, DKIM и DMARC, при чему DMARC политика може остати p=none. И при мањем обиму слања, надзор пре блокирања помаже да откријете сопствене изворе који још не пролазе проверу.

Попис пошиљалаца обухвата и повремене поруке

Забележите сваки систем који шаље поруке са адресом вашег домена у видљивом пољу From. Поред службене поште, то могу бити интернет продавница, алат за билтен, систем за подршку, апликација за резервације и сервис за ресетовање лозинке. За сваки ток упишите провајдера који стварно шаље поруку, домен у пољу From и особу која може да промени подешавања сервиса.

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

Непознату IP адресу у извештају прво упоредите са списком добављача и начина на који они шаљу пошту. Провајдер може користити више сервера, па непозната адреса сама по себи не доказује лажно представљање. Исто тако, извор не треба прогласити легитимним само зато што шаље велики број порука са именом вашег домена.

SPF и DKIM морају да одговарају видљивом пошиљаоцу

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

За сваки пописани сервис примените његова упутства за DNS записе и омогућите потписивање DKIM-ом за свој домен када је доступно. Пошаљите пробну поруку из самог сервиса, па у заглављима упоредите From, домен коришћен за SPF и вредност d= у DKIM потпису. Ако сервис користи само сопствени домен за обе провере, тражите подешавање које омогућава усклађен DKIM или усклађен SPF.

Разликујте директно слање од прослеђивања. Прослеђена порука може пасти SPF јер је до примаоца стигла са другог сервера; очуван DKIM потпис и даље може омогућити DMARC пролаз. Ако посредник мења потписани садржај, проверите и тај ток пре пооштравања политике.

Објавите запис за надзор и обезбедите пријем извештаја

Према Cloudflare-овом упутству за аутентификацију, DMARC се објављује као TXT запис под именом _dmarc, а препоручени редослед је p=none, затим p=quarantine и на крају p=reject када легитимна пошта пролази проверу. За условни домен primer.rs почетна вредност може бити v=DMARC1; p=none; rua=mailto:[email protected]. Ознака rua упућује агрегатне извештаје на адресу која мора да прима пошту.

Проверите јавним DNS упитом да се запис види на _dmarc.primer.rs и да је објављена вредност она коју сте унели. Ако извештаје прима сервис на другом домену, од њега затражите упутство за овлашћивање спољне адресе за извештаје. Без тог DNS овлашћења примаоци могу прескочити слање извештаја на ту адресу.

Политика p=none тражи праћење резултата DMARC провере без захтева да прималац због њеног неуспеха издвоји или одбије поруку. То није гаранција испоруке у пријемно сандуче: прималац и даље примењује друга правила за нежељену пошту. У овој фази циљ је да видите грешке у сопственим токовима пре него што DMARC политика почне да утиче на њих.

Извештаје повежите са конкретним изворима

Преглед Cloudflare DMARC Management-а приказује изворе слања, обим порука и исходе DMARC, SPF и DKIM провера. Упоредите изворе са својим пописом, уместо да гледате само укупан удео успешних провера. Велики исправан ток може прикрити мали, али важан ток који шаље потврде куповине или поруке за приступ налогу.

Када препознат легитиман сервис пада проверу, утврдите да ли недостаје SPF овлашћење, да ли DKIM потпис изостаје или су успешне провере везане за домен који није усклађен са From пољем. Исправите подешавање код тог сервиса, пошаљите нову пробну поруку и сачекајте извештај који обухвата ново слање. Ранији неуспех остаје у историји извештаја и не показује да ли је исправка успела.

За извор који не препознајете, најпре проверите да ли припада неком добављачу са пописа. Ако се не може повезати са вашим слањем, немојте га додавати у SPF да бисте уклонили неуспех из извештаја. Извештаје пратите довољно дуго да се појаве и повремени токови; за важне поруке упоредите агрегатни исход са заглављем стварне пробне поруке.

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

На p=quarantine пређите када познати легитимни извори пролазе DMARC и када сте обухватили повремене токове. Та вредност тражи да прималац издвоји поруке које падају проверу, често у нежељену пошту. Наставите да пратите извештаје и испоруку важних порука: нови неуспех легитимног извора је разлог да исправите његово слање пре следећег пооштравања.

На p=reject пређите тек када у извештајима више нема познатих исправних токова који падају DMARC. Тада политика тражи од примаоца да одбије неусаглашене поруке, па пропуштен сервис може изгубити испоруку уместо да његова грешка остане само видљива у извештају. Одлуку донесите на основу извора и порука које сте заиста обухватили, а не на основу унапред одређеног броја дана.

После промене политике задржите попис и адресу за извештаје у употреби. Нови алат за билтен, промена добављача поште или кампања која раније није слала поруке могу поново створити неусклађен ток. При таквој промени проверите пробну поруку и нове извештаје пре редовног слања.

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

• DMARC без прекида поште: од p=none до p=reject у три корака
• CSP без поквареног сајта: прво Report-Only, па тек онда блокирање
• Квантна миграција почиње пописом — Сингапур тражи план до 2027.