В настоящее время мы пытаемся перейти от использования «локального» почтового (обменного) сервера к облачному предложению для всех наших автоматических электронных писем. Проблема в том, что мы отправляем и получаем тысячи электронных писем в день, и время безотказной работы весьма критично, поэтому бизнес не хочет класть все свои яйца в одну корзину, поэтому, если мы хотим использовать облачное предложение (mailgun), они бы как резервная копия, если это выйдет из строя. Итак, мой вопрос:
Можно ли установить многоплановые записи A, TXT и CNAME на несколько IP-адресов, чтобы, если один почтовый сервер выйдет из строя, мы могли автоматически начать отправку электронных писем из сбойного (без их блокировки при обратном поиске в DNS)? Я знаю, что нам все равно нужно будет настроить запись MX для входящих писем, но это приемлемо, чтобы не получать электронные письма в течение короткого (1-2 часа) времени.
Имеет ли это смысл?
поэтому, если один почтовый сервер выйдет из строя, мы можем автоматически начать отправку писем с ошибочного
Вы не можете (легко) иметь машины в разных местах с одним и тем же IP-адресом. Для отправки электронной почты с сервера вам не нужна запись «А». Невозможно реализовать аварийное переключение путем изменения записей DNS.
Важно иметь любой сервер, который отправляет электронные письма, указанные в ваших записях SPF TXT (если у вас действительно есть опубликованный SPF).
Если вы говорите о машине-шлюзе MTA (сообщения SMTP исходят на других машинах и все маршрутизируются через этот сервер перед доступом к остальному миру), то это другое дело - вы можете повлиять на это с помощью DNS, но не ожидая отключение для изменения записей. SMTP разработан для обеспечения такого сценария путем публикации нескольких записей MX DNS с разными приоритетами. Клиенты должны попытаться подключиться к каждому серверу в зоне, упорядоченной по приоритету MX - если он не может подключиться, он должен попробовать следующий. на практике большинство MUA не утруждают себя поиском дальше основного MX, но если клиент является MTA, то IME, все они работают правильно. Вы не сказали нам, как ваши исходящие электронные письма попадают в MTA, поэтому сложно сказать, будет ли это работать на практике.
Извините, но вы явно не понимаете DNS и SMTP. Вам нужно гораздо больше читать, чем просто смотреть здесь ответы.
Итак, ваша проблема двоякая:
Относительно 1:
Нет ничего, что мешало бы вам иметь несколько серверов, отправляющих электронную почту. На данный момент основным методом показать, что ваши серверы не являются спамом, является SPF. (Структура политики отправителя) Записи. Все, что вам нужно сделать, это убедиться, что оба набора исходящих серверов указаны в вашей записи SPF, и вы должны быть готовы к работе (конечно, при условии, что ваши внутренние системы, которые генерируют электронные письма, настроены для взаимодействия с обоими наборами почтовых серверов). Кроме того, если у вас есть несколько записей MX, проблема обратного поиска DNS в некоторой степени устраняется.
Относительно 2:
Вы используете несколько записей MX:
10 CLOUD.MAIL.SERVER
20 LOCAL.MAIL.SERVER
или что угодно. Если один не отвечает, отправитель попытается ответить другому, и вы не потеряете почту. Сложность здесь в том, как ваши внутренние системы / пользователи переключаются между тем или другим. Вы можете настроить несколько профилей Outlook или несколько учетных записей электронной почты в одном профиле Outlook и т. Д. Для пользователей. Если ваши автоматизированные системы отправки также получают электронную почту, вам необходимо убедиться, что вы знаете, как заставить их проверять каждый набор почтовых серверов или как переключаться между ними при необходимости.
Это в основном то, что делает вторичный или резервный MX. Вы можете в основном настроить локальный или внешний MX-ящик, который может ставить почту в очередь до тех пор, пока основной не вернется в сеть, а затем доставит всю почту на основной.
Таким образом, никакая почта не будет возвращена вашим отправителям. В любом случае вам потребуется, чтобы первичные серверы почтовых ящиков снова подключились к сети, чтобы фактически маршрутизировать и доставлять почту.