DMARC без изгубена пошта: не преминувајте веднаш од p=none на reject

За да поставите SPF, DKIM и DMARC без да ги прекинете деловните пораки, прво попишете ги сите сервиси што испраќаат од вашиот домен. Проверете ги SPF и DKIM, објавете DMARC-запис со p=none и адреса за извештаи, па заострувајте ја политиката само откако ќе потврдите дека легитимните пораки ја поминуваат проверката. Упатството на Google за постепено воведување препорачува SPF и DKIM да бидат поставени најмалку 48 часа пред DMARC и извештаите да се прегледуваат пред промена на политиката.

Со p=none барате извештаи, без DMARC да побара карантин или одбивање на пораките што не ја поминуваат проверката. Пораката сепак може да биде задржана од други филтри на примателот. Искористете го набљудувањето за да ги откриете заборавените испраќачи, особено платформите за кампањи, фактури, потврди за нарачки и корисничка поддршка.

Попишете ги сите испраќачи што го користат доменот

Почнете од адресите што клиентите ги гледаат во полето From, а не само од главниот поштенски сервер. Побарајте од тимовите список на сервисите што испраќаат билтени, автоматски фактури, известувања од веб-страницата и одговори на барања за поддршка. За секој сервис запишете го доменот во From, доменот во SMTP MAIL FROM и доменот со кој се потпишува DKIM.

Вклучете ги и повремените испраќачи. Сервис што праќа месечни фактури може воопшто да не се појави во краток период на набљудување. Ако надворешна платформа користи адреса од вашиот домен во From, побарајте ги нејзините конкретни упатства за DNS и пробајте порака испратена преку самата платформа. Не е доволно само да ја додадете нејзината IP-адреса во SPF ако доменот што го проверува SPF остане туѓ и неусогласен со From.

Поставете SPF и DKIM за вистинските испраќачи

За SPF објавете еден TXT-запис за доменот што сервисот го користи во SMTP MAIL FROM. Во него внесете ги само овластените сервери или механизмите што ги бараат добавувачите. Условен пример за домен што испраќа исклучиво од адресата 192.0.2.10 е v=spf1 ip4:192.0.2.10 -all; не го копирајте ако користите други испраќачи. Правилата за SPF во RFC 7208 не дозволуваат повеќе SPF-записи за истото име и ја ограничуваат проверката на 10 механизми и модификатори што бараат DNS-пребарување.

За DKIM вклучете потпишување во секој сервис што испраќа од ваше име. Потоа внесете го јавниот клуч или CNAME-записот што ви го дава токму тој сервис. Името на DKIM-записот содржи селектор и _domainkey, но клучот не е универзален пример што може безбедно да се копира. Откако DNS-промената ќе стане достапна, испратете пробна порака од секој сервис, вклучително и од оние што испраќаат ретко.

За DMARC не е доволно SPF или DKIM само да пријави успех. Успешниот SPF мора да се однесува на домен усогласен со видливото From, или успешниот DKIM-потпис мора да има усогласен домен во ознаката d=. Добавувачот може да понуди сопствен домен за повратната адреса или DKIM-потпишување со вашиот домен; изберете поставка што навистина дава усогласување и потврдете ја со примена порака.

Објавете DMARC и прочитајте ги заглавијата

Во DNS додадете TXT-запис на _dmarc.example.com, заменувајќи го example.com со вашиот домен. Условна почетна вредност е v=DMARC1; p=none; rua=mailto:[email protected]. Адресата по rua треба да прима збирни извештаи. Ако DNS-панелот автоматски го додава доменот на крајот од името, внесете само _dmarc и проверете го конечниот запис во јавниот DNS.

Отворете ги целосните заглавија на пробна порака од секој испраќач и побарајте Authentication-Results. Прочитајте ги резултатите spf=pass, dkim=pass и dmarc=pass, но споредете ги и домените: smtp.mailfrom, ознаката d= во DKIM-Signature и доменот во From. DMARC поминува кога барем една успешна проверка е усогласена со From. Два успешни резултата за туѓи домени сè уште можат да завршат со dmarc=fail.

Извештаите покажуваат кои текови сте ги пропуштиле

Збирните извештаи ги групираат пораките според извор и резултат на проверките. Споредете ги прикажаните извори со сопствениот попис: кои се очекувани, кои имаат неусогласен SPF или DKIM и за кои сè уште нема сопственик во компанијата. Самата IP-адреса не кажува секогаш кој сервис стои зад пораката, па непознат извор прво проверете го со тимот што ја користи услугата.

Поправете го секој легитимен извор што не поминува, а потоа повторете ја пробата од неговата вистинска платформа. Проверете и пораки што минуваат низ препраќање или поштенски листи: посредничкиот сервер може да го расипе SPF-резултатот, додека зачуван, усогласен DKIM-потпис може да овозможи DMARC да помине. Ако листата ја измени пораката и потписот престане да важи, тој тек бара посебна процена пред построга политика.

Заострувајте ја политиката според резултатите

Кога пописот, пробните пораки и извештаите покажуваат дека легитимните извори поминуваат, сменете p=none во p=quarantine. Следете ги извештаите и проверете дали очекувани пораки завршуваат во несакана пошта. Не одредувајте го преминот само според календар: ако важен сервис испраќа еднаш месечно, почекајте неговата вистинска порака да помине проверка.

Постари упатства предлагаа ознаката pct за постепени проценти, но стандардот RFC 9989 ја отстрани поради недоследна примена кај примателите. Затоа пример како p=quarantine; pct=10 не е сигурен начин карантинот да се ограничи на 10% од неуспешните пораки. Истиот стандард предупредува дека p=reject може да ги наруши препраќањето и поштенските листи; за домен што се користи за општа кореспонденција, карантинот може да биде разумната постојана политика.

Разгледајте p=reject само ако начинот на користење на конкретниот домен го дозволува тоа и сте ги провериле индиректните текови, покрај директната испорака. Посебен поддомен за автоматски известувања може да има поинаков ризик од главниот домен што го користат вработените. Проверете која политика важи за секој поддомен пред да ја смените: политиката на главниот домен може да се примени и на него ако нема посебен DMARC-запис или политика за поддомени.

Подгответе враќање пред секоја промена

Зачувајте ја претходната вредност на DMARC-записот и утврдете кој може веднаш да го измени DNS. Ако легитимни пораки почнат да одат во несакана пошта по p=quarantine, вратете p=none додека не го поправите конкретниот испраќач. Ако се појават одбивања по p=reject, вратете ја претходната политика и побарајте го SMTP-одговорот или целосните заглавија на засегнатата порака.

Поради DNS-кеширање, вратената вредност може да стигне до примателите со задоцнување; веќе одбиените пораки нема автоматски да бидат доставени. По поправката на SPF или DKIM испратете ги повторно важните пораки и проверете го нивниот DMARC-резултат кај примателот. Тоа ви дава конкретна потврда дека прекинатиот тек повторно работи.

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

• AI-агент пред испраќање е-пошта: паузата мора да ја зачува состојбата