Вопрос или проблема
Включение домена A.example также включает все домены, которые домен A.example имеет в своих SPF-записях.
Так что, если я хочу дать A.example разрешение отправлять электронные письма от моего имени, я также даю разрешение всем, кому A.example предоставил разрешение.
Это не всегда идеально. Я понимаю, например, что A.example мог сказать: “Microsoft может отправлять электронные письма от моего имени”, так что если A.example позволяет Microsoft отправлять письма за меня, мне нужно добавить Microsoft в свои SPF-записи тоже.
Но что, если есть SPF-записи, которые на самом деле не отправляют письма за меня? Например, если тот пример с Microsoft — это просто отправка писем для собственных нужд A.example, а не для меня?
Я знаю, что могу выделить IP-адреса в этом случае, но есть ли лучший способ? Нужно ли мне просить A.example выделить часть, которую я хочу, в поддомен (если я могу попросить их об этом), или есть какой-то способ просто выбрать и выбрать SPF-записи на A.example, которые я хочу, помимо использования IP-адресов?
Но что, если есть spf-записи, которые на самом деле не отправляют письма за меня?
Организация, которую вы пытаетесь авторизовать для отправки от вашего имени, должна публиковать различные записи именно для этой цели.
Предпочтительно короткий, но описательный поддомен, содержащий только минимальный набор адресов (диапазонов), необходимых для клиентов/партнеров.
Например, A.example может иметь такие записи:
# почтовые серверы, которые они используют сами, включая сторонние MSP
A.example. TXT "v=spf1 ip4:192.0.2.64/26 include:spamhost.example include:micosoft.example ~all"
# почтовые серверы, которые они используют для своих клиентов/партнеров
eucustomers._spf.A.example. TXT "v=spf1 ip4:192.0.2.80/28 ~all"
Проблема, которую вы упоминаете, не единственная. Есть также лимит на количество записей, которые нужно учесть при проверке SPF (10, за исключением некоторых особых случаев) — поэтому включение записей, которые сами включают больше записей, может быть технически неосуществимо, потому что это превысит лимит.
Нужно ли мне попросить A.com выделить часть, которую я хочу, в поддомен (если я могу их уговорить)
Если они действуют в области MSP, они, вероятно, уже так делают, и вам просто не предоставили правильные инструкции, как называется этот поддомен. Если они не хотят это настраивать, вероятно, они не те, кому вы хотите доверить отправку от вашего имени. Необходимость избегать авторизации непричастных третьих сторон (как в вашем примере с Microsoft) — это такая основная вещь, которую, если не хотят грамотно решать, то, вероятно, будут и более серьезные проблемы.
есть ли способ просто выбрать и выбрать SPF-записи на A.com, которые я хочу, помимо использования IP-адресов?
Возможно, но я бы не рекомендовал идти этим путем. Как только вы копируете частичную информацию, управляемую третьей стороной, вы принимаете на себя ответственность за ее актуализацию. Которую, вероятно, не сможете делать надежно, потому что если бы организация, с которой вы работаете, публиковала эту информацию в отдельном месте, удобном для автоматизации (см. выше), вам бы не пришлось заниматься этим в первую очередь.
Ответ или решение
Ваша проблема связана с механизмом SPF (Sender Policy Framework), который используется для предотвращения подделки отправителя в электронной почте. Ваша задача — разрешить домену A.example отправлять электронные письма от вашего имени, но без включения всех доменов, которые также включаются в SPF-записи домена A.example. Это может привести к несанкционированному доступу третьих сторон, что не всегда желательно. Давайте разберем это детально.
Теория
SPF-запись — это текстовая запись в DNS, которая указывает серверам, какие IP-адреса разрешены отправлять электронную почту от имени данного домена. Когда вы используете оператор include в SPF-записях, вы разрешаете домену, например A.example, отправлять почту от вашего имени, но при этом также автоматически разрешаете это делать всем доменам и IP-адресам, которые указаны в SPF-записях A.example. Это может быть проблемой, если A.example включает нежелательные или ненужные для вас домены.
Пример:
A.example. TXT "v=spf1 ip4:192.0.2.64/26 include:spamhost.example include:microsoft.com ~all"Если вы включаете A.example в свою SPF-запись, тогда spamhost.example и microsoft.com также получают право отправлять почту от вашего домена, даже если это не релевантно для ваших операционных нужд.
Пример
Представим, что компания, с которой вы работаете, использует различные SMTP-серверы для отправки электронной почты: некоторые для внутренних нужд, другие для клиентов и партнеров. В таком случае, наилучшей практикой было бы создание поддоменов, связанных с определенными функциями. Например:
# Серверы, используемые только для внутренних нужд
A.example. TXT "v=spf1 ip4:192.0.2.64/26 include:internal-services.example ~all"
# Серверы для клиентов и партнеров
customers._spf.A.example. TXT "v=spf1 ip4:192.0.2.80/28 include:partners.example ~all"С подобной структурой вы можете более точно выбрать, какие SPF-записи включать, чтобы минимизировать риски нежелательных отправлений от вашего имени.
Применение
-
Коммуникация с владельцем домена: Если A.example — это домен вашей компании-партнера, самое простое решение — проконсультироваться с владельцами этого домена. Попросите их создать отдельные SPF-записи для разных бизнес-сегментов или задач, чтобы вы могли включать только те, которые релевантны для вас.
-
Использование поддоменов: Как предложено выше, использование поддоменов для сегментирования SPF-записей на разные задачи и функции может стать эффективным решением.
-
Избегание избыточной информации: Не копируйте части SPF-записей вручную в свои настройки. Это может привести к устаревшим и неверным конфигурациям, потому что изменения в оригинальной записи не будут автоматически применяться в вашем домене.
-
Анализ и стратегическое планирование: Перечислите все включенные домены и проанализируйте их, чтобы понять, действительно ли они необходимы для вашего бизнеса. Ограничивайте доступ только тем доменам, которые точно поддерживают ваши бизнес-процессы.
-
Ограничение количества DNS-запросов: Имейте в виду, что в SPF есть ограничение на 10 DNS-запросов, что может стать проблемой, если включать длинные цепочки доменов друг в друга.
-
Контроль и мониторинг: Постоянно следите за изменениями в SPF-записях ваших партнеров и регулярно обновляйте свои записи в соответствии с оптимальными бизнес-практиками.
Возможно, также стоит рассмотреть другие механизмы аутентификации электронной почты, такие как DKIM и DMARC, чтобы дополнить ваши меры по защите от подделки отправителя. Успешная реализация этой стратегии требует постоянного управления и анализа, но в долгосрочной перспективе это защитит вас от неприятных инцидентов с электронной почтой.