SPF, DKIM и DMARC: една грешна политика може да спре истинската поща

За да защитите фирмения домейн, без да спирате собствената си поща, първо опишете всички услуги, които изпращат писма от него. Настройте SPF и DKIM за тези услуги, проверете дали удостовереният домейн съвпада с видимия адрес From и публикувайте DMARC с p=none. След наблюдение на реалните писма и отчетите преминете към p=quarantine, а после преценете дали е безопасно да използвате p=reject. Описанието на Cloudflare разграничaва ролите им: SPF посочва разрешените изпращачи, DKIM проверява подписа, а DMARC задава предпочитание за обработка и заявява отчети.

Този ред предпазва от грешка с пряко последствие: истинско писмо може да не премине DMARC, ако идва от пропусната външна услуга или тя удостоверява собствения си домейн вместо вашия. Указанията на Microsoft препоръчват постепенно въвеждане и проверка на резултатите именно за да не се отхвърля легитимна поща. Наличието на записи в DNS само по себе си не доказва, че всяко изпратено писмо ги използва успешно.

Открийте всички изпращачи

Запишете всяка система, която поставя фирмения домейн във видимия адрес From: служебните пощенски кутии, сайта с формуляри, фактуриращия софтуер, CRM системата, бюлетина и автоматичните известия. За всяка установете кой я управлява, какъв домейн използва в техническия адрес MAIL FROM и може ли да подписва с DKIM от вашия домейн. Потърсете и рядко изпращаните писма, например известия при възстановяване на достъп; те лесно остават извън инвентара.

Преди промени вижте наличните записи с dig +short TXT example.com и dig +short TXT _dmarc.example.com. Проверете и dig +short MX example.com, но не приемайте резултата за списък на изходящите услуги: MX показва къде се приема поща. В примерите example.com и 192.0.2.10 са условни; заменете ги с вашия домейн и действителните данни на изпращачите.

Обединете разрешените изпращачи в един SPF запис

SPF проверява домейна в техническия адрес MAIL FROM, който може да се различава от адреса From, видим за получателя. Условен TXT запис за изпращане само от един посочен IP адрес е v=spf1 ip4:192.0.2.10 ~all. Ако ползвате и външна услуга, добавете изисквания от нея механизъм към същия SPF запис. Спецификацията RFC 7208 не допуска множество SPF записи за едно и също име и ограничава механизмите, които предизвикват DNS справки, до 10 при една проверка.

Проверете включените чрез include услуги, защото вложените им механизми също участват в този лимит. При превишаването му SPF връща постоянна грешка, а не успешно разрешение за изпращача. Не добавяйте механизма mx само защото домейнът получава поща: сървърът за входящи писма може изобщо да не изпраща от негово име. След редакцията повторете DNS справката и се уверете, че публикуваният запис съдържа всички нужни изпращачи.

Включете DKIM подписване, а не само публичен ключ

При DKIM изпращащата услуга подписва писмото с частен ключ, а получателят намира съответния публичен ключ в DNS. Доставчикът трябва да даде селектор и точни указания за записа. При пряко публикуван TXT запис условно име е selector1._domainkey.example.com, а формата на стойността е v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY. Полето p= трябва да съдържа действителния публичен ключ от услугата. Спецификацията RFC 6376 определя как селекторът от подписа сочи към ключа под _domainkey.

За TXT запис проверете името с dig +short TXT selector1._domainkey.example.com, като замените селектора с реалния. Ако доставчикът изисква CNAME, публикувайте указания от него запис и проверете с dig +short CNAME selector1._domainkey.example.com. После включете самото подписване в услугата и изпратете пробно писмо. Публичен ключ без подпис в изходящото писмо няма какво да удостовери.

Проверете дали SPF или DKIM съвпада с адреса From

За успешен DMARC е достатъчен един успешно преминал механизъм, чийто удостоверен домейн съвпада с домейна във From. При SPF сравнете From с домейна в MAIL FROM; при DKIM сравнете From със стойността d= в подписа. В облекчения режим съвпадението може да обхваща поддомейни на един организационен домейн. Затова писмо от фирмения домейн не получава автоматично успешен DMARC само защото доставчикът му има успешен SPF или DKIM за своя собствен домейн.

Изпратете пробно писмо през всеки установен изпращач до кутия, в която можете да видите пълните заглавки. В Authentication-Results потърсете spf=, dkim= и dmarc=, а след това сравнете smtp.mailfrom, header.d и header.from. Например бюлетинът може да има spf=pass за домейна на доставчика, но този резултат да не съвпада с фирмения From. Решението е поддържано от услугата DKIM подписване с вашия домейн или собствен, съвпадащ домейн за MAIL FROM; проверете промяната с ново действително изпратено писмо.

Наблюдавайте DMARC, преди да затегнете политиката

Създайте TXT запис за _dmarc.example.com с условна стойност v=DMARC1; p=none; rua=mailto:[email protected]. Адресът за отчетите трябва да съществува и да може да ги приема. Преглеждайте агрегирани отчети за обичайните и по-редките потоци, като съпоставяте непознатите източници с инвентара. Отчетите помагат да откриете пропуснат изпращач, но за причината за неуспех на конкретно писмо проверете и неговите заглавки.

След като легитимните потоци преминават DMARC, сменете p=none с p=quarantine и продължете наблюдението. Едва след проверка на засегнатите писма преминете към p=reject. Не копирайте примери с pct=10 за частично прилагане: действащата спецификация RFC 9989 премахва параметъра pct и описва започването с p=none, отчетите и риска легитимни писма да бъдат засегнати. Получаващата система взема окончателното решение за доставянето според собствените си правила.

Преди всяко затягане запазете предишната стойност на DMARC записа и определете кой следи отчетите и известията за недоставени писма. Ако откриете засегнат легитимен изпращач, върнете p=none или последния работещ етап, проверете публикуваната стойност след промяната в DNS и поправете неговите SPF, DKIM или съвпадение на домейните. Повторете пробните изпращания, включително през услугите за редки автоматични писма, преди отново да затегнете политиката.

Прочетете също:

• DNS през HTTPS във Firefox: максималната защита може да счупи локални адреси
• Shopify или WooCommerce: лесният старт може да излезе по-скъп в България
• Slack или Teams: вече платеният чат не решава една и съща работа