Я работаю над проектом, который включает использование службы транзакционной электронной почты (например, sendgrid). Мой вопрос: можем ли мы создать CNAME в нашем доменном DNS (например, smtp.example.com или client1.example.com), который ссылается на smtp-сервер почтовой службы?
Это замаскирует SMTP-сервер службы (например, sendgrid, mailgun), которую мы используем.
Наша цель - варьировать запись DNS в зависимости от нашего клиента. Например, у нас может быть client1.example.com, client2.example.com и т. Д. Каждый клиентский поддомен будет CNAME для почтовой службы. Мы также можем переключить почтовые службы, просто изменив при необходимости место CNAME. Например:
NAME TYPE VALUE
--------------------------------------------------
client1.example.com CNAME smtp.emailservice.com
client2.example.com CNAME smtp.emailservice.com
При проведении исследования это, похоже, работает, но я хотел посмотреть, есть ли какие-то проблемы, которые я должен искать. Мы не имея дело с записями MX, POP3 или любыми входящими сообщениями электронной почты, мы не можем использовать API для отправки. Он должен проходить через SMTP.
Спасибо!
Наивный ответ на ваш вопрос - простое «да». Ты очевидно жестяная банка создайте записи CNAME RR предложенным способом. Какие из них могут возникнуть проблемы, это совсем другой вопрос - CNAMES обычно понимают неправильно, и их использование подвержено ошибкам.
Основные моменты, которые следует учитывать:
Итак, если взять определения RR из вашего вопроса в качестве предварительного условия, следующие случаи будут представлять собой недопустимое использование:
; these are INVALID RR definitions, don't even try!
mail.example.com. IN MX client1.mydomain.com. ; no MX to CNAME RRs
client1.mydomain.com. IN A 198.51.100.203 ; no other RR types for CNAMEd labels
В будущих публикациях при использовании IP-адресов и пространств имен, например, и / или в целях документации, рассмотрите возможность придерживаться определений Блоки адресов IPv4 зарезервированы для документации (RFC 5737) и Особые доменные имена (RFC 6761) чтобы избежать путаницы.