10 шокирующих причин, почему компании «забывают» DKIM и как это исправить

Вступление

Электронная почта остаётся главным каналом деловой коммуникации, но её надёжность часто ставится под угрозу из‑за простых, но критически важных настроек. Одной из таких настроек является DKIM — механизм цифровой подписи, позволяющий получателю убедиться, что письмо действительно отправлено от имени указанного домена. На практике многие организации, даже крупные, «настраивают и забывают» DKIM, что приводит к отклонению писем, попаданию в спам и потере репутации. В статье мы разберём, почему так происходит, какие последствия это влечёт и как избежать типичных ошибок.

«Тихий ветер шепчет: поддомены ждут подписи, а почта — лишь тень»
— японский хокку, отражающий суть проблемы.

Пересказ оригинального Reddit‑поста

Автор поста делится своим опытом работы с несколькими крупными компаниями, которым пришлось объяснять, что их сервер отклоняет письма из‑за отсутствия DKIM‑подписи на поддомене. Несмотря на то, что эти организации используют один и тот же сторонний сервис рассылки, они часто добавляют поддомен, но забывают завершить процесс настройки DKIM. Автор сам прошёл весь путь от выбора сервиса до проверки подписи, но постоянно сталкивается с тем, что другие IT‑отделы «забывают» включить DKIM, что приводит к массовым отказам доставки.

Суть проблемы и «хакерский» подход

• Неполная автоматизация. Многие компании полагаются на «set‑it‑and‑forget‑it»‑модель, но забывают, что DKIM требует не только создания записи DNS, но и её привязки к сервису рассылки.
• Теневой IT. Отделы маркетинга или продаж часто запускают кампании без участия основной ИТ‑команды, что приводит к пропуску важных шагов.
• Недостаток знаний. Как отмечают комментаторы, сотрудники часто не понимают, как работают сертификаты и подписи, поэтому игнорируют их.
• Отсутствие контроля. Без чёткой политики и мониторинга ошибки остаются незамеченными до момента массовой рассылки.

Детальный разбор проблемы с разных сторон

Техническая сторона

DKIM работает через публичный ключ, размещённый в DNS‑записи типа TXT. При отправке письма сервис подписывает его приватным ключом, а получатель проверяет подпись, сравнивая её с публичным ключом. Ошибки могут возникнуть:

• Отсутствие записи в DNS.
• Неправильный селектор (часть записи, указывающая на конкретный ключ).
• Синхронные изменения: запись обновлена, но кэш DNS ещё не успел обновиться.
• Использование разных поддоменов для разных сервисов без отдельной настройки DKIM.

Организационная сторона

Внутренние процессы часто не учитывают необходимость согласования между маркетингом, безопасностью и операционной поддержкой. Как показывают комментарии:

«Я не забыл, я настроил строгую политику, а потом позволил ей провалиться, потому что маркетинг использовал инструменты без консультации с ops.» — IN‑DI‑SKU‑TA‑BELT

«Они не понимают, как это работает… Это как сертификаты… Люди просто не знают, как работают CA.» — BlackSquirrel05

«Теневой IT. Отделы запускают без участия IT, а потом реагируют после факта.» — PlasticJournalist938

Экономическая сторона

Каждая отклонённая рассылка стоит компании не только в виде потерянных продаж, но и в виде ухудшения репутации домена, что может привести к более строгим фильтрам у получателей и росту расходов на восстановление репутации.

Практические примеры и кейсы

Кейс 1: Университет с массовой рассылкой. После года попыток IT‑отдел не смог заставить маркетинг включить DKIM. В результате крупная рассылка из 10 000 писем была отклонена, а репутация домена упала.

Кейс 2: Финансовая компания. Добавила поддомен mail.example.com для рассылок, но не создала запись DKIM. Партнёрские письма начали попадать в спам, что привело к потере нескольких крупных контрактов.

Экспертные мнения из комментариев

• IN‑DI‑SKU‑TA‑BELT: Подчёркивает, что строгие политики часто игнорируются другими отделами.
• BlackSquirrel05: Сравнивает незнание DKIM с непониманием работы сертификатов.
• PlasticJournalist938: Описывает явление «теневого IT» и его последствия.
• _haha_oh_wow_: Указывает на сопротивление вендоров, требующих «белый список», несмотря на современные стандарты.
• boli99: Приводит типичный сценарий от объяснения до массовой неудачной рассылки.

Возможные решения и рекомендации

1. Внедрить чек‑лист при подключении нового сервиса рассылки. Включить в него обязательную проверку DKIM, SPF и DMARC.
2. Автоматизировать проверку DNS‑записей. Скрипты, которые регулярно проверяют наличие и корректность записей.
3. Обучить нетехнические отделы. Провести короткие воркшопы о том, зачем нужны подписи и как они работают.
4. Назначить ответственного за «почтовую безопасность». Человек, который будет контролировать процесс от создания поддомена до проверки подписи.
5. Внедрить систему мониторинга отклонений. Интеграция с SIEM‑системой, чтобы получать алерты при росте отказов доставки.

Прогноз развития ситуации

С ростом количества автоматизированных маркетинговых платформ и увеличением объёма рассылок, проблема «забытых» DKIM‑записей будет только усиливаться. Однако, ожидается, что поставщики облачных сервисов начнут предлагать более «прозрачные» интеграции, где настройка DKIM будет включена в процесс onboarding. Кроме того, регуляторы могут ввести обязательные требования к проверке подлинности писем, что заставит компании более ответственно относиться к DKIM, SPF и DMARC.

Практический пример на Python

Ниже представлен скрипт, который проверяет наличие и корректность DKIM‑записей для заданного домена и селектора. Он использует библиотеку dnspython и может быть включён в CI‑pipeline или плановое задание.

# -*- coding: utf-8 -*-
"""
Проверка DKIM‑записей для домена.
Автор: технический блогер‑аналитик.
"""

import dns.resolver
import sys

def fetch_dkim_record(domain: str, selector: str) -> str:
    """
    Получить DKIM‑запись из DNS.
    
    :param domain: Домен, для которого проверяется запись (например, example.com)
    :param selector: Селектор, указанный в настройках сервиса рассылки
    :return: Текст записи или пустую строку, если запись не найдена
    """
    # Формируем полное имя записи: selector._domainkey.domain
    dkim_name = f"{selector}._domainkey.{domain}"
    try:
        # Запрашиваем TXT‑записи
        answers = dns.resolver.resolve(dkim_name, 'TXT')
        # Возвращаем первую найденную запись (обычно их одна)
        for rdata in answers:
            # rdata.strings может быть кортежем байтов; объединяем их
            return b"".join(rdata.strings).decode('utf-8')
    except (dns.resolver.NoAnswer, dns.resolver.NXDOMAIN):
        # Запись отсутствует
        return ""
    except Exception as e:
        # Любая другая ошибка – выводим в stderr и завершаем
        sys.stderr.write(f"Ошибка DNS‑запроса: {e}\\n")
        return ""

def validate_dkim(domain: str, selector: str) -> bool:
    """
    Проверить, что DKIM‑запись существует и содержит публичный ключ.
    
    :return: True, если запись найдена и выглядит корректно, иначе False
    """
    record = fetch_dkim_record(domain, selector)
    if not record:
        return False
    # Простейшая проверка: наличие строки "p=" (публичный ключ)
    return "p=" in record

if __name__ == "__main__":
    # Пример использования: python dkim_check.py example.com default
    if len(sys.argv) != 3:
        sys.stderr.write("Использование: python dkim_check.py  \\n")
        sys.exit(1)

    dom = sys.argv[1]
    sel = sys.argv[2]

    if validate_dkim(dom, sel):
        print(f"DKIM‑запись найдена и выглядит корректно для {sel}._domainkey.{dom}")
    else:
        print(f"DKIM‑запись НЕ найдена или некорректна для {sel}._domainkey.{dom}")

Скрипт можно запускать в автоматическом режиме, передавая домен и селектор, используемый в вашем сервисе рассылки. При отсутствии записи он выдаст предупреждение, позволяя быстро отреагировать и добавить нужную запись в DNS.