Проверка доставляемости почты
Прежде репутации, прежде содержимого получатели задают один вопрос: может ли этот домен доказать, что почта действительно его? Эта проверка читает доказательство — записи MX, список отправителей SPF (развёрнутый и подсчитанный так, как считает получатель), политику DMARC в _dmarc и ключи DKIM под обычными селекторами — и возвращает выводы простым языком, упорядоченные так, как их исправлял бы оператор.
Хотите, чтобы за этим следили постоянно? Следите бесплатно с myeventwatch — оповещения об истечении и простоях, карта не нужна.
Что измеряет проверка
Фильтрация спама начинается с идентичности, потому что идентичность можно проверить за миллисекунды. Когда приходит почта, утверждающая, что она от домена, принимающий сервер смотрит опубликованные правила этого домена. SPF называет серверы, которым разрешено отправлять. DKIM предлагает подпись для проверки по опубликованному ключу. DMARC требует, чтобы видимый домен From совпал по выравниванию с одним из этих двух доказательств, и устанавливает наказание — нет, карантин, отклонение — для почты, у которой нет ни одного. Страница вызывает GET /api/check/email-auth на сервере sysosx, который читает те же записи через DNS-парсеры, которые использует проверка здоровья, и переводит их в выводы: каждый протокол, каждая проблема, одна серьёзность, в том порядке, в котором их стоит исправлять.
Два из выводов заслуживают слова о честности, потому что оба — места, где проверяющие часто притворяются точными. Подсчёт запросов SPF настоящий: проверяющий разворачивает цепочки include и redirect термин за термином по тем же правилам, что применяет получатель, поэтому число, которое он сообщает, — то, что вычислил бы строгий получатель — включая случаи, когда запись тихо ушла за лимит в десять запросов по мере того, как поставщики меняли свои собственные записи. А результат DKIM — это зондирование, а не перепись: ключи публикуются под именами селекторов, которые выбирает владелец, проверка пробует обычные, и не найти ни одного — не доказывает, что DKIM отсутствует — ключ под любым другим селектором невидим снаружи, и результат говорит это прямо, а не объявляет домен неподписанным. Единственный полный тест DKIM по-прежнему — настоящее сообщение и его заголовок Authentication-Results.
Как читать результат
Начните с неудач; это любимые причины папки спама. Отсутствие MX означает, что домен вообще не может принимать почту. Отсутствие SPF, или запись SPF, заканчивающаяся на +all, означает, что любой может утверждать, что он — это вы; второе хуже, потому что утверждение официально разрешено. Несколько записей SPF тихо полностью аннулируют оценку SPF. Отсутствующая запись DMARC означает, что у провалившейся почты нет заявленного наказания и, столь же дорого, никто не собирает сводные отчёты, показывающие, кто отправляет от вашего домена, — именно из этих отчётов обычно и обнаруживаются кампании подделки. Когда отчёты приходят, они приходят как сырой XML; анализатор отчётов DMARC открывает файлы .xml, .gz и .zip локально и превращает их в таблицу по источникам: кто прошёл, кто провалился и что исправить. Предупреждения — среднее состояние: p=none — хорошее место, чтобы начать DMARC, и плохое, чтобы остановиться; ~all — режим тестирования, а не пункт назначения. Затем возьмите вторую половину картины: аутентификация доказывает идентичность, а проверка по чёрным спискам DNS измеряет репутацию — запускайте обе, потому что идеально аутентифицированный домен на IP из списка всё равно попадает в спам, а чистый IP со сломанным SPF — тоже. Руководство, которое связывает всё вместе, — почему ваша почта попадает в спам.
Частые вопросы
Что такое SPF, DKIM и DMARC и как они сочетаются?
Это три опубликованных в DNS ответа на вопрос «действительно ли эта почта от домена, который она утверждает?». SPF перечисляет серверы, которым разрешено отправлять от домена. DKIM позволяет домену криптографически подписывать сообщения, чтобы получатель мог проверить подпись по ключу, опубликованному в DNS. DMARC связывает их вместе: требует, чтобы отправляющий домен в видимом заголовке From выравнивался с результатом SPF или DKIM, и говорит получателям, что делать — отслеживать, помещать в карантин или отклонять, — когда ни один не выравнивается. SPF без DMARC — неподписанное предложение; DMARC — то, что превращает два других в политику.
Моя почта всё равно попадает в спам, хотя все три проходят. Почему?
Потому что аутентификация — входной билет, а не план рассадки. Прохождение SPF, DKIM и DMARC означает, что получатели верят, что почта действительно ваша — после этого размещение зависит от репутации и содержимого: попаданий в чёрные списки (проверьте их с помощью проверки по чёрным спискам на этом сайте), вовлечённости получателей, частоты жалоб, шаблонов объёма отправки и самого сообщения. Сбои аутентификации — самая частая исправимая причина попадания в спам, поэтому эта проверка идёт первой, но чистый результат здесь плюс устойчивое попадание в спам означает, что проблема живёт в репутации или содержимом, а не в идентичности.
Проверка говорит, что ключ DKIM не найден. Значит ли это, что мой домен не подписывает?
Нет — и результат говорит это теми же словами. Ключи DKIM живут под именами селекторов, которые выбирает владелец домена, и перечислить селекторы домена снаружи невозможно. Эта проверка зондирует обычные селекторы, используемые крупными провайдерами (default, google, selector1, selector2, mail, dkim, s1, s2, k1, mandrill и ещё несколько). Ключ под любым другим именем невидим для зондирования. Окончательный тест — настоящее сообщение: отправьте почту в ящик, который вы контролируете, и посмотрите заголовок Authentication-Results, который сообщает использованный селектор и то, прошла ли подпись проверку.
Почему проверка считает запросы SPF, и почему лимит равен 10?
Оценка записи SPF может потребовать дальнейших DNS-запросов — каждый термин include, a, mx, ptr, exists и redirect стоит один. RFC 7208 ограничивает общее число десятью; сверх него получатели возвращают постоянную ошибку и результат SPF недействителен, что может быть хуже, чем скромная запись, которая оценивается чисто. Записи тихо набирают запросы по мере добавления провайдеров (каждый include приносит свои собственные термины), поэтому запись, которая была законной при настройке, может уйти за лимит, когда поставщики меняют свои записи. Эта проверка разворачивает запись так, как это сделал бы получатель, и сообщает реальное число, чтобы дрейф был виден до того, как он аннулирует вашу аутентификацию.
Что исправлять первым, если несколько выводов — неудачи?
По порядку: несколько записей SPF (объедините в одну — всё downstream ненадёжно, пока это не исправлено), отсутствующую или +all запись SPF (опубликуйте реальный список отправителей, заканчивающийся на -all), отсутствующую запись DMARC (начните с p=none с адресом для отчётов, чтобы вы могли видеть, кто отправляет от вашего имени, до применения), затем повышайте DMARC от p=none к p=reject по мере того, как отчёты приходят чистыми. Попадания в чёрные списки, если они есть, — параллельная работа: исправьте их причину и запросите исключение из списка, пока записи ремонтируются. Наше руководство проходит этот порядок с обоснованием: почему ваша почта попадает в спам.