Наша компания хочет работать с внешним сторонним поставщиком, которому необходимо отправлять и получать электронные письма. Мы хотели бы, чтобы эти электронные письма приходили с нашего домена (или поддомена), чтобы помочь клиентам доверять легитимности электронных писем и снизить вероятность того, что они посчитают это фишингом или спамом. Мы также считаем, что это помогает улучшить фирменное ощущение взаимодействия. Вторичная цель заключается в том, что мы хотели бы, чтобы третья сторона управляла брендингом и шаблонами, такими как стандартные юридические нижние колонтитулы электронных писем.
Мы уже используем поставщиков SAAS, таких как Mandrill (только исходящие) и Intercom (входящие и исходящие), которые могут отправлять электронные письма от имени нашего домена, проверяя право собственности, а затем изменяя наши записи DNS, чтобы гарантировать, что такие вещи, как SPF и DKIM, применяются в соответствии с нашей политикой DMARC. Затем у нас есть правило маршрутизации приложения GSuite GMail, которое перенаправляет входящую почту в Intercom.
В этом случае третья сторона предлагает нам предоставить им прямой доступ к нашему GSuite через учетную запись пользователя или направить свою электронную почту через наши почтовые серверы (которые для нас являются почтовыми серверами Google). Я считаю, что это нежелательно по нескольким причинам:
- SSO (вход через Google), который может предоставить доступ к системам, которые мы считаем внутренними.
- Они не являются внутренними сотрудниками, и наличие учетной записи означает, что мы взимаем плату за учетную запись пользователя, и они будут автоматически добавлены в нашу группу all@ email. Нам также придется быть осторожными и отключить такие приложения, как Drive и Calendar, поскольку все, что нам нужно, это электронная почта.
- Просто нам не приходилось справляться со сложностью при работе с нашими поставщиками SAAS, у которых было достигнуто то же самое.
Если это уместно, третья сторона сообщила нам, что в настоящее время они используют OWA, а взаимодействие осуществляется вручную (например, набор электронных писем человеком). Могут быть некоторые гибкие условия, чтобы заставить их не использовать OWA.
Мой вопрос: есть ли лучшие практики, которые можно рассмотреть, или какие-то хорошо проторенные пути для достижения этого? Бонусом будет, если есть предложение типа SAAS, которое может помочь решить эту проблему (я рассматривал Intercom, но он делает гораздо больше, и это отражается в цене).
решение1
Эти причины, которые вы приводите против предоставления им доступа к вашему GSuite, кажутся мне вполне убедительными. Если бы я был вами, я бы позволил им настроить свой собственный почтовый сервер, который настроен на использование одного из ваших почтовых серверов в качестве исходящего ретранслятора. Я бы также настроил частный IPSec VPN и ограничил бы доступ ретранслятора этим одним IP внутри частного домена IP IPSec VPN. Не стесняйтесь добавлять аутентификацию клиента TLS для повышения безопасности на этом соединении. Это имеет некоторые преимущества:
- Вы можете самостоятельно добавить подпись DKIM и сделать с этими письмами все, что захотите.
- Вы можете добавлять фильтры к этим исходящим письмам, которые третья сторона не может контролировать, так что вы будете контролировать то, что делается от имени вашего бренда/компании.
Надеюсь, поможет!