Работали ли вы с mail сервисами
Что проверяют
Понимаете ли вы доставляемость, а не только настройку клиента. Отправить письмо умеет любой скрипт, вопрос в том, дойдёт ли оно во «Входящие» и узнаете ли вы вовремя, что перестало доходить.
Как отвечать
Опишите схему целиком: приложение отдаёт письмо релею по SMTP или через API провайдера, провайдер доставляет получателю и возвращает события. Свой почтовый сервер поднимают редко, потому что репутация адреса и разбор жалоб стоят дороже подписки.
Дальше про обязательное:
- аутентификация домена: SPF в записи TXT, DKIM с публичным ключом в DNS и подписью на стороне отправки, DMARC с политикой и отчётами. Без этой тройки крупные почтовые системы раскладывают письма в спам;
- транспорт: порт отправки с обязательным TLS, отдельный порт для неявного TLS, исходящий порт для межсерверной передачи у облаков чаще всего закрыт;
- эксплуатация: разделять транзакционные письма и рассылки по потокам, прогревать новый домен, обрабатывать возвраты и жалобы, вести список подавления;
- наблюдаемость: метрики по отказам и задержкам, алерт на всплеск возвратов, хранение идентификатора сообщения в логах приложения;
- секреты: пароль релея в хранилище секретов, а не в образе или репозитории.
Где спотыкаются
Отвечают названием вендора вместо принципов. Следующий вопрос обычно звучит как «письма перестали доходить, ваши действия», и тут нужны записи в DNS, логи релея, отчёты DMARC и заголовки конкретного письма, а не имя сервиса.
Второе: рассказывают про снижение числа недоставленных писем в процентах, не уточняя, что считали. Возврат, жалоба и попадание в спам это три разных события, и только первое видно отправителю напрямую.
Третье: проверяют доставку на своём ящике и считают вопрос закрытым. Чужая почтовая система может принять письмо и молча положить его в спам: сервер ответит успехом, а пользователь ничего не получит. Нужны отчёты, проверочные ящики у разных провайдеров и разбор заголовков.