DKIM на практика: селектори, ключове и услуги

Модул 4: Доставимост: SPF, DKIM и DMARC на практика · Време за четене: 12 минути

Цел на урока: След този урок ще можете да анализирате кополовка DKIM-Signature, да настроите DKIM със собствен домейн за всяка услуга за изпращане, да проверите дали даден селектор работи, и да обясните как безопасно се сменят ключовете.

Основни понятия: DKIM-Signature, d= (подписващ домейн), s= (селектор), h= (подписани кополовки), bh= и b=, каноникализация (c=), <selector>._domainkey.<domein>, TXT с p= или CNAME към услугата, дължина на ключа 2048 бита (RFC 8301), части от 255 знака, ed25519 (RFC 8463), смяна на ключ, празен p= (оттеглен), DKIM и пренасочване

Защо DKIM е най-важният от трите

SPF казва кои сървъри имат право да изпращат поща, но се проваля при пренасочване и гледа на Return-Path, който при много услуги не е Ваш. DKIM поставя подпис в самото писмо. Този подпис преживява пренасочване (докато писмото не бъде променено) и е свързан с домейн, който Вие избирате. Затова на практика DKIM често е единственото нещо, което кара DMARC да премине успешно за бюлетини, фактури от счетоводна програма и пренасочена поща.

Основите (как ключът стои в DNS, какво е селектор) са описани в курса по DNS, урок 4.4. Тук продължаваме нататък: какво точно се съдържа в подписа и как настройвате DKIM за всяка услуга?

Анализ на подпис

Отворете кополовките на получено писмо (урок 1.5). Най-горе, ако писмото е подписано, ще видите нещо подобно на:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=x;
	t=1762588800; h=from:to:subject:date:message-id:mime-version:content-type;
	bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
	b=Gm7yW3q...lange reeks tekens...Qx9A==

Получателят извлича публичния ключ от <s>._domainkey.<d>, тук тоест x._domainkey.example.com, и проверява дали b= съответства на кополовките от h= и контролната сума bh=. Ако по пътя е променена дори една буква в текста или в подписана кополовка, проверката се проваля.

В Authentication-Results виждате резултата, например dkim=pass header.d=example.com header.s=x. Едно писмо може да има няколко подписа, например един от Вашия домейн и един от самата услуга. За DMARC се брои само подпис, чийто d= съответства на Вашия домейн From.

Всяка услуга със свой селектор

Един домейн може да има много DKIM ключове едновременно, всеки под свой селектор. Точно това е идеята: всяка услуга, която изпраща писма от Ваше име, подписва със собствен ключ.

TXT или CNAME?

• При TXT запис Вие самите поставяте публичния ключ в своя DNS. Ако услугата поиска нов ключ, трябва сами да промените записа.
• При CNAME запис насочвате селектора към име при услугата, например k2._domainkey.example.com CNAME dkim2.mailer.example. Тогава услугата сама управлява ключа и може да го замени, без Вие да правите нещо. Затова големите услуги избират CNAME и често използват два записа: така могат да сменят между активен и нов ключ.

Внимание: CNAME не може да стои заедно с друг запис на същото име. Ако вече има TXT запис на selector1._domainkey, премахнете го.

Най-важното: включване на DKIM при услугата

При много услуги DKIM със собствен домейн не е включен по подразбиране. Тогава те подписват с техен собствен домейн (d=mailer.example). Писмото е подписано, но не е подравнено с Вашия адрес From. За DMARC това не се брои. В администрацията на услугата това често се нарича "верифициране на домейн", "домейн верификация", "автентикация" или "собствен домейн на подателя". Едва когато зададете записите и включите функцията в услугата, тя ще подписва с d=example.com.

Ключове: дължина, части и алгоритъм

• Дължина. RFC 8301 гласи: поне 1024 бита, като подателите следва да използват поне 2048 бита. Използвайте 2048. Ключ от 512 бита се счита за невалиден от получателите.
• Части от 255 знака. Един TXT запис се състои от текстови низове с максимална дължина 255 знака. Ключ от 2048 бита е приблизително 400 знака и не се побира в един низ. Записът тогава се състои от два или повече низа един след друг ("v=DKIM1; k=rsa; p=MIIBIj..." "...IDAQAB"), които получателят слепва заедно. Повечето панели правят това автоматично. Ако нещо се обърка, получавате отрязан ключ и всеки подпис се проваля. Затова винаги копирайте ключ изцяло, без допълнителни интервали или кавички по средата.
• ed25519 (RFC 8463) е по-съвременен алгоритъм с кратки ключове. Все още не всички получатели го проверяват. Затова който го използва, подписва с два подписа: един RSA и един ed25519.

Смяна на ключ

Добре е ключ да се сменя от време на време, и със сигурност ако смятате, че частният ключ е изтекъл (например след хакване на сървъра или напуснал администратор). Процедирайте така:

1. Създайте нов ключ под нов селектор, например s2026, и поставете публичния ключ в DNS.
2. Изчакайте записът да стане видим навсякъде (TTL, вижте курса по DNS, урок 6.1).
3. Накарайте сървъра да подписва с новия селектор.
4. Оставете стария ключ още няколко дни: писма, които вече са били на път или се проверяват повторно, все още сочат към него.
5. Оттеглете стария ключ, като изпразните p= (v=DKIM1; p=), или премахнете записа.

При услуги с CNAME записи това се прави автоматично от самата услуга.

Какво кара DKIM да се провали

• Писмото е променено по пътя: пощенски списък, който добавя [lijstnaam] в темата или добавя долен колонтитул, антивирусен скенер, който добавя ред под писмото, сървър за пренасочване, който преобразува форматирането.
• Грешен или отрязан ключ в DNS.
• Селекторът не съществува: правописна грешка в името, или selector1._domainkey.example.com.example.com (домейнът е повторен двойно, защото панелът сам го добавя отзад).
• Ключът е оттеглен (празен p=), докато сървърът все още подписва с този селектор.

Проверка дали работи

1. Изпратете писмо от услугата до адрес в Gmail или Outlook.com.
2. Отворете кополовките и намерете DKIM-Signature: запишете d= и s=.
3. Проверете в Authentication-Results дали пише dkim=pass, и дали header.d= е Вашият домейн.
4. Потърсете селектора: dig TXT s._domainkey.example.com (или чрез онлайн инструмент). Трябва да има p= с дълъг ключ, или CNAME, който води до такъв запис.

На практика: как изглежда това в панел

При хостинг пакет на WebOké DKIM е включен по подразбиране, със селектор x: записът се нарича x._domainkey.<yourdomain>. В DirectAdmin го виждате в DNS Administration; ако Вашият DNS е при друг доставчик, копирайте този запис там. В Моят WebOké картата Set E-mail показва каква стойност трябва да бъде зададена и дали е намерена. При други доставчици селекторът се нарича различно (default, mail, dkim), но го намирате по същия начин: в панела или в s= на подписано писмо.

Обобщение

• DKIM е проверката, която преживява пренасочване и която свързвате със своя собствен домейн за всяка услуга; за DMARC се брои само подпис с Вашия домейн в d=.
• В DKIM-Signature намирате d= (домейн) и s= (селектор); ключът стои на <s>._domainkey.<d>.
• Всяка услуга получава собствен селектор; CNAME записите позволяват на услугата сама да сменя ключове. Включете DKIM със собствен домейн наистина и в самата услуга.
• Използвайте 2048 бита; внимавайте за отрязани ключове при копиране.
• Сменяйте ключ с нов селектор и оттегляйте стария едва след това.

Тест

Задача

Задача Z4.3: Проверка на DKIM селектор. Изпратете писмо от своя собствен домейн (или от услуга, която изпраща от Ваше име) до собствен адрес при друг доставчик. Отворете кополовките и попълнете стойностите на d= и s= от DKIM-Signature, както и какво пише в Authentication-Results при dkim=. Програмата проверява селектора на живо, проследява евентуален CNAME, проверява ключа (наличен, не празен, дължина) и казва дали d= е подравнен с домейна, който Вие посочвате като подател.

Допълнително четене

Стъпките в тези статии важат за панелите на WebOké; при други доставчици работи по сходен начин.

• Безплатен DNS курс 4.4: DKIM: цифровият подпис под Вашата поща
• Ръководство за DirectAdmin 5.8: DKIM включване и проверка
• Настройване на DKIM, когато DNS е на външен сървър
• Ръководство на WebOké 6.7: Картата Настройване на имейл (MX, SPF, DKIM, DMARC)
• RFC 6376 (DKIM), RFC 8301 (дължина на ключа и алгоритми), RFC 8463 (ed25519)