В настоящее время я собираю требования для небольшого (надеюсь) проекта миграции с SendGrid на Mandrill в качестве поставщика услуг транзакционной электронной почты. Мы используем SendGrid около 3-4 лет и в среднем около 5-10 тысяч писем в день. У нас есть записи SPF и DKIM, настроенные должным образом, и, как следствие, у нас очень низкий показатель отказов / спама и довольно хорошая репутация отправителя.
Было принято решение о переходе на Mandrill, и теперь я должен обеспечить плавный переход с минимальным количеством перерывов в обслуживании, чтобы заново запустить процесс утверждения / репутации.
Я знаю, что для записей SPF можно добавить несколько элементов, поэтому пока я оставлю и для SendGrid, и для Mandrill. Однако я не уверен на 100% в записях DKIM. Некоторые службы рекомендуют записи CNAME, а другие предлагают записи TXT.
Это заставляет меня задаться вопросом, возможно ли иметь запись CNAME DKIM для одной службы и запись TXT DKIM для другой. Мне любопытно, к чему приведет такое изменение. Зависит ли проверка / верификация этой записи от посредника / получателя? Или они обычно видят оба и выбирают только первое?
По сути, я бы хотел найти способ медленного перехода от одной службы к другой с минимальными перерывами. У нас и раньше были проблемы с занесением в черный список интернет-провайдеров, и я бы очень хотел избежать этого.
Большое вам спасибо за ваше время!
Возможен вариант использования нескольких записей DKIM.
Ключи и записи DKIM следует периодически заменять. Во время процесса обновления старая запись сохраняется в течение определенного периода времени, чтобы можно было проверить передаваемые сообщения. Это также может позволить повторно проверить полученные сообщения.
Я не вижу смысла в использовании CNAME для записей DKIM. Он только добавит дополнительные поиски DNS перед чтением необходимой записи TXT. Записи DKIM следует добавлять каждый раз при изменении ключа. Для этого требуются новые записи TXT, а также могут потребоваться новые записи CNAME.
Чтобы ответить на ваш вопрос.
CNAME для записи DKIM - это всего лишь метод для ESP для обработки поворота ключа не имея доступа к вашему DNS и не прося вас изменять TXT-запись DNS каждый раз, когда они меняют ключ.
sector._domainkey.example.com. IN TXT "DKIM KEY"
sector._domainkey.example.org. IN CNAME sector._domainkey.example.com.
Если вы добавляете запись TXT, либо провайдер не меняет ключи за вас, либо вы сами меняете ключи.
Вы также можете настроить несколько ключевых селекторов для каждой службы и запустить sendgrid и mandrill параллельно, это также позволяет вам протестировать mandrill перед переключением на них. Примечание. Нет ограничений на количество секторов DKIM, есть ограничения на количество DNS-запросов для SPF (10).
Это одно из основных применений поля селектора. Очень часто у интернет-провайдеров есть записи ключей домена, подобные следующим:
201604._domainkey.mydomain.com
201604 относится к году и месяцу, когда в этом примере был создан ключ (но на самом деле это может быть что угодно) и будет установлен в качестве селектора при подписании исходящих писем.
При замене ключа или переносе в другое место вы можете просто создать новую запись DKIM (например, 201705._domainkey.mydomain.com). Любые электронные письма, проходящие через старую систему, по-прежнему будут ссылаться на селектор 201604, а электронные письма из новой системы будут ссылаться на новый. Обе записи DKIM, очевидно, могут существовать в DNS без каких-либо проблем, и серверы получателей будут запрашивать тот, который указан в заголовках электронной почты.
Именно так большинство провайдеров регулярно меняют свои dkim-ключи без того, чтобы электронная почта была неправильно подписана или проверена во время обновлений DNS / сервера.