SPF, DKIM и DMARC на примере обычного письма: как работает email-аутентификация
Когда кто-то отправил письмо и указал в качестве отправителя адрес support@bank.ru или security@google.com — откуда принимающему серверу знать, что письмо действительно отправил банк или Google, а не мошенник? Сам по себе адрес в поле «От кого» вообще ничего не доказывает.
С 1982 года в основе электронной почты лежит SMTP (Simple Mail Transfer Protocol — простой протокол передачи почты, англ.). Его создавали в то время, когда интернет был маленьким, а проблемы массового фишинга вовсе не существовало. Тогда о встроенном механизме проверки отправителя никто не подумал.
Теперь почтовые серверы по всему миру получают миллиарды писем каждый день. Среди них — рабочие переписки, чеки из интернет-магазинов, уведомления банков, маркетинговые рассылки. И, конечно, спам с фишингом: кто угодно может попытаться отправить письмо от имени чужого домена. Такое мошенничество называется email spoofing (подмена имейла, англ.) — подделкой отправителя, которую часто используют в фишинговых схемах.
Чтобы с этим бороться, появилась email-аутентификация — набор технических стандартов, который включает несколько механизмов проверки.
Привет, Хабр! Меня зовут Пётр Пахомов, я продуктовый менеджер CDP Sendsay, и я заметил, что в Рунете сложно найти статью, которая бы понятно рассказывала про SPF-запись, DKIM-подпись и DMARC-политику. Поэтому постараюсь на простом примере объяснить логику их работы, чтобы email-аутентификация перестала выглядеть набором непонятных аббревиатур. А в конце разберу, почему для настройки всего этого платформы рассылок предлагают делегировать поддомен для рассылок — и почему это не означает «отдать сервису свой домен».
Как письмо вообще попадает в почтовый ящик
Прежде чем разбираться с email-аутентификацией, полезно понимать, что происходит с письмом после нажатия на кнопку «Отправить». Предположим, компания отправляет клиенту письмо:
From: <promo@romashka.ru>To: <ivan@gmail.com>
Если сильно упростить, путь письма выглядит так:
Но принимающий сервер не спешит сразу передавать письмо в папку «Входящие». Сначала он проверяет:
откуда пришло соединение;
какой технический адрес указал отправитель;
разрешено ли этому серверу отправлять почту от имени этого домена;
есть ли у письма корректная цифровая подпись;
не изменилось ли письмо после подписания;
связаны ли все эти доказательства c доменом, указанным в поле «От кого».
Только после этого почтовая система решает, что делать дальше: принять письмо, отправить его в спам или вовсе отклонить. Здесь-то и начинают работать механизмы email-аутентификации.
Вернёмся к письму: в поле отправителя получатель видит именно этот адрес — promo@romashka.ru. Вот только это лишь часть самого письма, и без дополнительных проверок здесь можно указать практически любой адрес.
Пожалуй, это похоже на обычное бумажное письмо. На конверте можно написать:
От кого: ООО «Ромашка»
Но сама надпись на конверте ещё не доказывает, что письмо действительно отправила компания «Ромашка» — можно же написать вообще что угодно. В email-письмах происходит то же самое. Поле From — это ничем неподтверждённое заявление: я — письмо от promo@romashka.ru. Собственно, для этого и нужна email-аутентификация — чтобы подтвердить такое заявление.
SPF-запись: кто имеет право отправлять письма от имени домена
Допустим, наше бумажное письмо предназначено партнёрам компании «Ромашка». На нём написано:
От кого: ООО «Ромашка»
Письмо доставляет курьер, но на ресепшене в офисе получателя его вполне могут спросить: «Простите, а ваша служба доставки вообще работает с „Ромашкой"?»
Если «Ромашка» заранее сообщила, каким курьерским службам доверяет доставку своей корреспонденции, вопросов не возникает. Если же письмо доставляет человек с улицы, который просто заявляет: «Я от компании „Ромашка"», доверия будет меньше.
SPF (Sender Policy Framework — система политик отправителя, англ.) работает примерно так же: механизм не проверяет содержимое письма и не пытается установить личность отправителя. Он проверяет источник отправки и отвечает на вопрос: имеет ли сервер право отправлять письмо от имени этого домена?
SPF — это TXT-запись, которая описывает, какие источники разрешены для отправки почты от имени технического домена. В нашем примере это будет список доверенных доставщиков. То есть если письмо привёз Максим Столешников, и это имя есть в числе доверенных курьеров — всё нормально.
Где хранится этот список
Как любая компания может составить список доверенных курьеров, так и каждый владелец домена может опубликовать список серверов, которым разрешено отправлять письма — для этого используется DNS (Domain Name System — система доменных имён, англ.).
DNS умеет хранить не только IP-адреса, но и TXT-записи — например, ту же SPF-запись. Например, она может выглядеть так:
mail.romashka.ru TXT "v=spf1 include:spf.provider-name.ru ~all"
По сути она говорит: «серверы провайдера имеют право отправлять письма с техническим обратным адресом на домене mail.romashka.ru».
Когда приходит письмо, сервер получателя открывает DNS, читает эту запись и сравнивает её с IP отправителя. Если IP найден в списке — проверка проходит (spf=pass), если нет — результат зависит от политики; в нашем примере с ~all это будет spf=softfail.
Зачем нужен Mail From
Когда на конверте указано:
От кого: ООО «Ромашка»
Это аналог поля From — имени отправителя, которое увидит получатель. Но для доставки в другой город письмо кладут в транспортный конверт, на котором есть отдельная служебная пометка: если доставить не получится — вернуть сюда.
Такой адрес предназначен не для человека, который будет читать письмо, а почтовой службе — пригодится, если получателя не удалось найти. В онлайне эту роль выполняет поле Mail From. Во время SMTP-доставки это может выглядеть так:
MAIL FROM: <bounce@mail.romashka.ru>RCPT TO: <client@gmail.com>DATAFrom: ООО «Ромашка» <promo@romashka.ru>Subject: Важные новости
То есть получатель увидит promo@romashka.ru, а bounce@mail.romashka.ru нужен почтовым серверам для технических сообщений о доставке. Например, когда адреса получателя не существует, ящик переполнен или сервер отклонил сообщение. Домен из этого адреса и используется для SPF-проверки.
Здесь возникает логичный вопрос: если получатель видит адрес в поле From, почему бы не проверить его? Дело в том, что к моменту SPF-проверки письмо ещё не передано. Серверу достаточно данных SMTP-сеанса — прежде всего IP отправителя и домена из Mail From.
Этого достаточно, чтобы проверить SPF. Поэтому алгоритм выглядит так:
сервер получает соединение,
смотрит IP отправителя,
берёт домен из
Mail From,проверяет DNS этого домена,
сверяет список — разрешено ли этому IP отправлять письма.
При этом успешная SPF-проверка не говорит о том, что письмо безопасное. Она означает: этот сервер есть в списке доверенных для отправки почты с указанным Mail From.
Вернёмся к аналогии с бумажным письмом. Вот наш курьер успешно прошёл первую проверку — секретарь убедился, что конверт привёз человек из доверенных лиц, всё хорошо. Но возникает следующий вопрос: а точно письмо осталось таким же, каким его отправил автор?
За время пути с конвертом могло произойти что угодно: его могли вскрыть, подменить вложение, исправить текст или добавить ссылку на мошеннический сайт. SPF-проверка этого не заметит — механизм проверяет только право сервера отправлять письма. За целостность письма отвечает другой инструмент — DKIM-подпись.
DKIM-подпись: как убедиться, что письмо никто не изменил
Теперь представим, что перед отправкой письма компания «Ромашка» запечатывает конверт своей фирменной сургучной печатью. Получатель может проверить: печать на месте, она настоящая, конверт никто не вскрывал.
В онлайне вместо сургуча работает криптографический ключ, который лежит в основе механизма DKIM (DomainKeys Identified Mail — почта с идентификацией домена, англ.).
Как работает DKIM
Если упростить, процесс таков:
Перед отправкой сервер создаёт цифровую подпись на основе содержимого письма с помощью закрытого криптографического ключа.
Эта подпись добавляется в заголовки письма.
Когда письмо приходит получателю, получающий сервер находит в DNS соответствующий открытый ключ и проверяет подпись с помощью открытого ключа.
Если проверка проходит — подпись корректна и подписанные части письма не изменились; если нет — подпись не соответствует полученному письму.
Закрытый криптографический ключ хранится только у владельца домена или у сервиса, которому он доверил отправку писем. Он не публикуется и остаётся на стороне системы, которая подписывает письма, поэтому без доступа к закрытому ключу создать корректную DKIM-подпись невозможно.
Как это выглядит в email:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;d=romashka.ru; s=mail;t=1788179600;h=from:to:subject:date:message-id:mime-version:content-type;bh=h3SSh5WTvy6Tvo/xgMPBeHu/Qu+HDCgMO5DOGrXxQD8=;b=lIGV5O4DXLMg1V4i2knX2I2ZD9tcpbjbCDCWadKG2pyJmtSLV/h6tGItQDz/HGnEUZMfP1ym7hx+r1rhE/s7oJ8rf0Cem+dWVS6D3JyIMZeHaF0CW6wGOwoZ5IvnsvCQ+eERbE60pR2bs8ugn/u6tGCY+kKvtWQbihMlUYL3dlSjY/U8215e83qplb3r4lw2gFpXRaDTOQ5kHUBrszHbmyMrKhkEcuCL9ThonnmIW94C8vxnMTZ6j0gj9+iXw+XzUS8qyqWL9F9SXIlPf4WFt33T2NQWwJ3Nd5IhM9tWUcmVbXaufe2XjOFuWTjQPpqhu7XB62xvo5VqKzKng0RBJA==;
Здесь важна часть d=romashka.ru, которая как бы говорит: письмо подписано доменом romashka.ru. А s=mail указывает, какой именно открытый ключ надо искать в DNS. Так, получающий сервер идёт в DNS и ищет публичный ключ:
mail._domainkey.romashka.ru TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwmm48+DYnUOTpx0A1/YSKESPGaoFmqqr5k7yTXXXYXB2jnl6e4Ujuth5Igu+USuyHIpm44jhSAMN2Oz1S2VEfVR4Chf7FV8ZuKzyHMwVqklWTb+OXxxUXL71SlKvHIcxM2xQx9HRFU47K1x+lOhmS8lmeP+ddyScU4PRJtyLtSm6Xf8hpj/xW8VIrOVpF38Ajo/sXQqLsmlSz5b/tHcim2CffgJQyUkZ1S+rUV+0BKyZ52WrNHPL+BzBcIEvXFKAYly37bQioGeFIrvveg/DGCrSpiJ6nElxtlXLd482AH9JdYSE/q8CrdFTvAprPwntulDUyxHxhY+3bEYntIXOvQIDAQAB"
Если подпись валидна, результат будет примерно таким:
dkim=pass header.d=romashka.ru
Что значит: «Подпись корректная, письмо действительно подписано доменом romashka.ru, и важные части письма не были изменены после подписи».
Если же кто-то со стороны решит вскрыть письмо и внутри заменить ссылку http://romashka.ru на http://romashka-security.ru, получатель может и не заметить. Но для DKIM содержимое письма уже будет другим, поэтому существующая подпись перестанет ему соответствовать: в результате сервер отдаст ответ dkim=fail — проверка не будет пройдена.
Почему одного DKIM недостаточно
Итак, у нашего бумажного письма уже есть несколько признаков, которые можно проверить:
на самом письме указано, что письмо пришло от ООО «Ромашка»;
письмо запечатано фирменной печатью «Ромашки»;
на транспортном конверте есть служебный адрес «Ромашки», куда нужно вернуть письмо, если доставить его не получится.
В идеальном мире все эти признаки помогают подтвердить одно и то же: письмо действительно связано с «Ромашкой».
Но на практике бывает сложнее. Допустим, «Ромашка» передала письмо курьерской службе, а та указала на транспортном конверте собственный адрес для возвратов. Курьер настоящий, служба доставки настоящая, проверка доставки проходит успешно. Но она подтверждает курьерскую службу, а не «Ромашку», имя которой указано на письме.
В email это работает похожим образом. Пользователь видит:
From: <news@romashka.ru>
Но технический адрес может принадлежать платформе, через которую отправляется письмо:
Mail From: <bounce@provider.ru>
SPF для неё настроен корректно:
spf=pass smtp.mailfrom=bounce@provider.ru
Получается, этому серверу разрешено отправлять письма для provider.ru. Однако он не подтверждает romashka.ru, который видит получатель.
С DKIM возможна похожая ситуация: платформа для отправки может подписать письмо своим техническим доменом:
DKIM-Signature: v=1; a=rsa-sha256; d=provider.ru; s=mail; ...
Значит, подпись настоящая:
dkim=pass header.d=provider.ru
Но она снова подтверждает provider.ru, а не romashka.ru. Обе проверки успешно подтвердили то, что должны были подтвердить. Проблема в другом: пользователь видит одного отправителя, а технические доказательства относятся к другому. Здесь и нужна DMARC-политика.
DMARC: подтверждают ли проверки видимого отправителя
Допустим, на ресепшене в офисе компании наше письмо прошло проверки, но у письма есть конкретный получатель — ivan@gmail.com, или генеральный директор компании Иван. Он довольно занятой человек, поэтому все входящие сообщения проходят через его помощника. А у помощника, в свою очередь, есть протокол проверки входящей корреспонденции.
В нашей аналогии этим протоколом выступает DMARC-политика (Domain-based Message Authentication, Reporting and Conformance — аутентификация сообщений на основе домена, отчётность и соответствие, англ.).
Как связать проверки с видимым отправителем письма
Помощник Ивана дополнительно сверяет письмо. Протокол обязывает его выяснить, относится ли хотя бы одно доказательство к тому, чьё имя указано на конверте. Это можно подтвердить одним из двух способов:
На конверте есть настоящая сургучная печать — и она принадлежит ООО «Ромашка».
Письмо доставлено доверенным лицом, а служебный обратный адрес на транспортном конверте принадлежит именно «Ромашке».
Так и в email: принимающий сервер сверяет результаты SPF и DKIM с DMARC-записью и смотрит, подтверждает ли хотя бы одна успешная проверка домен из From.
Например, есть письмо:
From: promo@romashka.ruDKIM-Signature: d=romashka.ruAuthentication-Results: dkim=pass header.d=romashka.ruAuthentication-Results: dmarc=pass
Здесь письмо заявляет видимого отправителя на домене romashka.ru, и DKIM-подпись тоже относится к romashka.ru.
Или другой вариант:
From: promo@romashka.ruMAIL FROM: <bounce@mail.romashka.ru> Authentication-Results: spf=pass smtp.mailfrom=bounce@mail.romashka.ruAuthentication-Results: dmarc=pass
Письмо заявляет видимого отправителя на домене romashka.ru, и SPF-проверка проходит по техническому обратному адресу на связанном домене mail.romashka.ru.
Но есть и другие примеры:
From: promo@romashka.ruMAIL FROM: <bounce@provider.ru>
SPF проходит:
spf=pass smtp.mailfrom=bounce@provider.ru
Но DMARC не видит здесь связи:
From → romashka.ruSPF → provider.ru
То же самое возможно с DKIM:
From: promo@romashka.ruDKIM-Signature:d=provider.ru;
Подпись может быть корректной (dkim=pass), но не подтверждать romashka.ru. Технически SPF и DKIM прошли успешно, но ни одна проверка не подтверждает домен, от имени которого письмо отправляется получателю.
DMARC не выполняет SPF и DKIM заново и не требует, чтобы обе проверки обязательно прошли. Он берёт домен из видимого From и смотрит на результаты SPF и DKIM:
Прошёл ли SPF и связан ли проверенный им домен с доменом из
From?Прошёл ли DKIM и связан ли домен подписи с доменом из
From?
Если хотя бы на один из этих вопросов ответ «да» — DMARC проходит. Если же оба ответа «нет» — DMARC не проходит. Поэтому spf=pass или dkim=pass сами по себе ещё не гарантируют dmarc=pass. Для DMARC важно не только успешно ли прошли проверки, но и кого именно они подтверждают.
Эта связь между доменами называется alignment, или выравниванием доменов (англ.). Выравнивание бывает мягким (relaxed) — когда достаточно, чтобы домены относились к одному организационному домену, и строгим (strict), когда домены должны совпадать точно. По умолчанию для SPF и DKIM действует мягкий режим, и большинству доменов его менять не нужно. Но требования можно задать отдельно для каждого механизма тегами aspf и adkim. Для примера возьмём запись, где режимы разные:
v=DMARC1; p=none; adkim=s; aspf=r
Здесь:
adkim=s— для DKIM требуется strict alignment (строгое выравнивание), то есть домен в DKIM-подписи должен точно совпадать с доменом изFrom;aspf=r— для SPF используется relaxed alignment (мягкое выравнивание), поэтому поддомен вродеmail.romashka.ruможет считаться связанным сromashka.ru.
Если для DKIM установлен строгий режим, одного dkim=pass недостаточно. Например:
From: promo@romashka.ru
DKIM-Signature:d=mail.romashka.rudkim=pass
Сама DKIM-проверка прошла успешно, но при adkim=s домены не совпадают точно:
From → romashka.ruDKIM → mail.romashka.ru
Значит, такая проверка не может пройти DMARC. В мягком же режиме (adkim=r) эти домены считались бы связанными.
С SPF работает тот же принцип. Если указано:
aspf=s— домен изMail Fromдолжен точно совпадать с доменом изFrom;aspf=r— достаточно, чтобы они относились к одному организационному домену.
То есть принимающему серверу важно не просто увидеть spf=pass или dkim=pass, а ещё и проверить, соответствует ли этот успешный результат требованиям alignment, заданным в DMARC-записи.
В нашей аналогии всё так же: мало проверить, что курьер доверенный, а печать подлинная. Помощнику Ивана нужно убедиться, что эти доказательства относятся именно к «Ромашке», которая указана отправителем письма. Иначе получится, что на ресепшене письмо прошло проверки, но подтвердили не того отправителя.
Что делать, если DMARC не прошёл: политики none, quarantine и reject
На этом процесс проверки письма не заканчивается. После того как принимающий сервер определил результат DMARC, остаётся понять, что делать с письмом, если проверка не пройдена.
Для этого в DMARC-записи владелец домена задаёт политику обработки таких сообщений. Например:
_dmarc.romashka.ru TXT "v=DMARC1; p=none"
Параметр p как раз и задаёт эту политику. Возможны три основных значения: none, quarantine и reject. Если вернуться к аналогии с бумажным письмом, это и есть протокол проверки входящей корреспонденции. Он указывает, что делать с письмом:
p=none. Мягкая политика, которая означает «проверять, но пока не блокировать». На языке протокола проверки входящей корреспонденции: если DMARC не прошёл — не применяйте к письму специальных мер только из-за этого и обрабатывайте его по обычным правилам.
Политика none полезна, когда DMARC только внедряют. Например, когда компания отправляет почту из нескольких мест — из CRM, с корпоративной почты, из системы поддержки, из платформы рассылок — при строгой политике можно случайно заблокировать собственные письма. Поэтому сначала имеет смысл посмотреть, кто вообще отправляет почту от имени домена и какие источники проходят аутентификацию.
p=quarantine. Здесь владелец домена уже говорит: если письмо использует мой домен, но не может это подтвердить, отнеситесь к нему как к подозрительному. В нашей аналогии помощник не выбрасывает такое письмо, но и не несёт на стол Ивану. Оно отправляется в отдельную папку «сначала разберёмся, что это такое». На практике принимающий сервер может отправить такое письмо в спам.
p=reject. Самая строгая политика рекомендует принимающему серверу отклонять письма, которые используют домен в поле From, но не проходят DMARC. В офлайн-мире инструкция была бы предельно короткой: если письмо пришло от указанного имени, но отправителя подтвердить невозможно, не принимайте его.
Именно эта политика защищает домен от прямого спуфинга. Однако включать её вслепую опасно: если у компании есть хотя бы один легитимный источник писем с неправильной аутентификацией, под блокировку могут попасть собственные сообщения.
Как DMARC-запись помогает собирать отчёты
В полном названии DMARC не просто так есть слово Reporting (отчётность, англ.). Запись может указывать на адрес, на который принимающие серверы смогут отправлять агрегированные отчёты. Например:
v=DMARC1; p=none; rua=mailto:dmarc-reports@romashka.ru
Параметр rua как раз задаёт адрес для таких отчётов. Они помогают понять, какие серверы отправляют сообщения от имени домена и как проходят проверки. Это особенно полезно перед переходом к более строгой политике: по отчётам можно проверить, все ли легитимные источники почты настроены правильно и не остались ли забытые сервисы, которые продолжают отправлять письма от имени домена.
Например, в компании уверены, что от её имени письма отправляются только через корпоративную почту и сервис рассылок, а в DMARC-отчётах обнаруживаются ещё несколько источников. Это необязательно злоумышленники: может оказаться, что отдел продаж подключил отдельную CRM, поддержка использует свой сервис для отправки рассылок, а про старый SMTP-сервер вообще никто не вспомнил.
Почему письмо с SPF, DKIM и DMARC всё равно может попасть в спам
Email-аутентификация похожа на паспорт на проходной — он помогает подтвердить личность, но сам по себе не гарантирует доступ куда угодно.
Это важная часть доставляемости, но не единственная. На попадание во «Входящие» влияет много факторов: репутация отправителя, история отправок, жалобы пользователей, характеристики сообщения и собственные антиспам-механизмы. Поэтому spf=pass, dkim=pass и dmarc=pass означает только то, что почтовый сервер смог подтвердить техническую подлинность письма. И совсем не значит, что он обязан положить письмо во «Входящие». Но с одной частью отправитель может разобраться — сделать техническую аутентификацию корректной и устойчивой.
Пока компания отправляет письма самостоятельно, всем этим нужно управлять внутри собственной системы. Но если для массовых рассылок используется внешняя платформа, появляется дополнительная связка: домен принадлежит компании, а часть почтовой инфраструктуры работает на стороне платформы. Поэтому здесь есть два пути:
Управлять настройками вручную. Платформа сообщает, какие DNS-записи ей нужны, а владелец домена самостоятельно добавляет и поддерживает их у своего DNS-провайдера.
Выделить для рассылок отдельный поддомен и делегировать управление его DNS-зоной платформе. Тогда она сама сможет поддерживать внутри этой зоны необходимые технические записи.
Делегирование поддомена — это стандартный механизм DNS, а не функция одного сервиса: так умеют работать многие платформы рассылок.
Делегирование не даёт письмам волшебный пропуск во «Входящие», не решает проблему попадания в спам и не повышает репутацию домена само по себе. Его задача гораздо прозаичнее: сделать техническую настройку рассылочной инфраструктуры устойчивее и избежать потенциальных ошибок.
Зачем выделять поддомен для рассылок...
Предположим, что romashka.ru — это главный офис компании. Тогда поддомен mail.romashka.ru вполне может быть отдельным офисом, где обрабатывают исходящую корреспонденцию и возвраты.
На основном домене уже работают сайт компании, корпоративная почта и другие сервисы, а техническую структуру рассылок можно вынести на отдельный поддомен mail.romashka.ru. Так удобнее разделить инфраструктуру и независимо управлять техническими записями, Mail From и другими настройками.
Тогда получатель по-прежнему может видеть во «Входящих»:
From: promo@romashka.ru
А ошибки доставки — например, когда адрес не существует или ящик переполнен, — будут уходить на технический адрес письма:
Mail From: <bounce@mail.romashka.ru>
Такие сообщения нужны в первую очередь платформе отправки: она должна понимать, какие адреса работают, а какие — нет.
…и делегировать его
Фраза «настройте домен» звучит как одно действие, но на практике за ней скрывается несколько записей — TXT, MX, CNAME и прочие. У каждой — своё имя, тип, значение, место в DNS-зоне и назначение. Здесь можно ошибиться на каждом шаге: добавить запись не в ту зону, перепутать тип, неверно указать имя хоста, случайно скопировать значение с лишним символом или решить, что настройка не работает, пока DNS ещё не успел обновиться.
Для системного администратора всё это — обычная работа, а вот для маркетолога или владельца собственного проекта уже целый квест. Поэтому один из способов сократить ручную работу — делегировать платформе отдельную техническую DNS-зону.
Есть классический вариант: платформа показывает нужные записи, а владелец домена вручную создаёт их у DNS-провайдера. Но есть и другой подход: делегировать отдельный технический поддомен. Так компания не отдаёт подрядчику ключи от главного офиса, а лишь от отдельного помещения для работы с корреспонденцией.
Вернёмся к нашему примеру с «Ромашкой». Без делегирования служба доставки говорит «Ромашке»: для нашей работы добавьте вот такой образец печати, разрешите вот этих курьеров и укажите такой адрес для возвратов. «Ромашка» сама вносит эти настройки. Если что-то меняется, служба сообщает, что нужно обновить. При делегировании же за все настройки внутри отвечает платформа рассылок.
Если выделить поддомен для рассылок, основной домен остаётся под контролем компании, а платформа управляет только той зоной, которая нужна для рассылок.
Как работает делегирование
Для делегирования не нужно отдельно создавать поддомен mail.romashka.ru. Владелец romashka.ru просто добавляет в DNS несколько NS-записей, где в качестве имени зоны указывает mail.romashka.ru, а в значениях — DNS-серверы платформы, которые будут отвечать за эту зону. Условно это может выглядеть так:
mail.romashka.ru NS ns1.provider.rumail.romashka.ru NS ns2.provider.rumail.romashka.ru NS ns3.provider.rumail.romashka.ru NS ns4.provider.ru
По смыслу эти записи говорят: за всё, что находится внутри DNS-зоны mail.romashka.ru, отвечают вот эти DNS-серверы. И если romashka.ru — это главный офис компании, где на ресепшене отвечали на все вопросы о почтовом отделе сами, то после делегирования по всем вопросам нужно обращаться в отдел mail.romashka.ru.
Также и в email: платформа, которой делегировали поддомен, может управлять необходимыми техническими записями — SPF, DKIM и другими.
Делегирование касается только выбранной DNS-зоны. Если платформе передали mail.romashka.ru, она может управлять записями внутри этого поддомена, но основной romashka.ru и его DNS-настройка остаются у владельца.
Сами технологии не меняются: меняется только тот, кто создаёт и поддерживает записи. То есть это способ автоматизировать управление email-аутентификацией.
Что в итоге
Если вернуться к нашему бумажному письму, вся система становится довольно простой. На конверте написано:
От кого: ООО «Ромашка»
SPF проверяет доставщика: имеет ли он право привозить корреспонденцию с таким техническим обратным адресом. DKIM проверяет «печать» на письме и помогает убедиться, что подписанные части сообщения не изменились по дороге. А затем помощник генерального смотрит в правила «Ромашки» и сверяет результаты: относится ли хотя бы одно из этих доказательств к той компании, чьё имя указано на конверте. Если да — DMARC считается пройденным; если же доказательства настоящие, но относятся к другому отправителю — нет.
То же самое происходит с email. Получается такая схема:
То есть email-аутентификация — это цепочка доказательств:
Откуда пришло письмо и разрешено ли этому серверу отправлять почту с техническим доменом из
Mail From? За эту часть отвечает SPF.Не изменились ли подписанные части письма после подписания? Это проверяет DKIM.
Достаточно ли этих доказательств, чтобы подтвердить указанного отправителя?
Что, собственно, сделать с письмом — пропустить, отклонить или положить в ящик со спамом?
Но даже правильная аутентификация не гарантирует попадание во «Входящие». Она решает другую задачу: помогает почтовому серверу проверить техническую связь письма с заявленным отправителем и, если DKIM-подпись прошла проверку, убедиться, что подписанные части сообщения не изменились после подписания.
Если компания использует внешнюю платформу для отправки рассылок, дальше возникает уже следующий вопрос: кто будет поддерживать всю эту инфраструктуру. Можно делать это вручную, добавлять и обновлять нужные DNS-записи самостоятельно. А можно выделить для рассылок отдельный технический поддомен и делегировать управление его DNS-зоной платформе. Так вы не отдаёте службе доставки ключи от главного офиса, а просто выделяете ей отдельное помещение для работы с корреспонденцией — и позволяете самой следить за курьерами, печатями и адресами возврата.
❯ Куда расти дальше
Почта, DNS и защита от спуфинга — та часть инфраструктуры, которую замечают, только когда что-то сломалось. Разобраться в ней стоит заранее, и начать можно с малого и бесплатного:
открытого занятия «Атаки на сетевое оборудование: как нейтрализовать угрозы» — чтобы разобрать на практике, как ломают роутеры и файрволы и как это закрыть;
записи вебинара «Секретный рецепт DevSecOps» — чтобы понять, почему безопасную разработку внедрили 90% компаний, и с чего начать;
открытого занятия «Информационная безопасность: как построить карьеру в цифровом будущем» с УрФУ — чтобы увидеть реальные угрозы и понять, стоит ли расти в ИБ.
А если хочется не разовое знакомство, а профессию с дипломом и понятным ростом — от настройки инфраструктуры до защиты от атак, — можно рассмотреть системное обучение с практикой и наставниками:
на курсе «Системный администратор» — чтобы с нуля освоить администрирование Windows и Linux, а также изучить работу с ИИ, Docker, Kubernetes, Ansible и Terraform;
на программе «Сетевой инженер» — чтобы понять, как строить и защищать корпоративные сети с практикой в Cisco Packet Tracer и получить дипломом о профпереподготовке;
на курсе «DevOps-инженер PRO» для специалистов с опытом — если нужно вырасти из разработчика или сисадмина в DevOps (Kubernetes, Ansible, Terraform).
А чтобы держать знания в актуальном состоянии без привязки к одной программе, пригодится База знаний Нетологии: 16 000+ видеоуроков и вебинаров по ИТ и диджиталу, до 10 роликов в день — бесплатно.
KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.