Как настроить DNS с доменом посередине для DKIM и SPF?

Я работаю над инструментом, который помогает пользователям отправлять электронные письма. Я планирую использовать MTA (агент передачи почты) в серверной части, такой как AWS-SES или Sendgrid и т. д. Чтобы электронные письма успешно доставлялись в почтовые ящики рецептов, пользователям необходимо настроить DKIM/SPF, настроив DNS. настройки соответствующих доменов.

Теперь, если я возьму, например, SES, я знаю, что они иметь API, который позволяет мне чтобы добавить «Идентификацию» и получить все необходимые записи DNS для нее с помощью API. Я уверен, что Sendgrid и другие MTA имеют аналогичные API, которые позволяют добавлять удостоверения и возвращать записи DNS для применения пользователем.

Я показываю возвращенные настройки DNS DKIM пользователю, и они добавляют их к своему DNS-провайдеру, и после этого, когда они отправляют электронные письма, рецепты получают их правильно (без каких-либо «через amazonses.com» в заголовках)

Теперь для примера — давайте предположим, что инструмент, который я создаю, размещен на chillybilly.xyz, и у одного из пользователей, использующих мой инструмент, есть домен с именем frankthetank.xyz, который они хотят использовать для отправки электронных писем через мою платформу. .

Когда пользователь попытается подтвердить свой домен через мою платформу, я нажму на упомянутый выше API в AWS SES и покажу пользователю что-то вроде этого:

После чего они могут добавить эти записи CNAMES и TXT для успешных DKIM/SPF и могут начать отправлять электронные письма. Но если присмотреться, они увидят, что я использую SES из-за значений этих записей CNAMES и TXT. И это то, чего я хочу избежать, вместо этого я хочу, чтобы те назывались как-то вроде 7nuk24xywyawocu6ctqjxmjasiaiq3vq.dkim.chillybilly.xyz который будет показывать мой брендинг, но в фоновом режиме он все равно будет указывать на правильный SES.

Теперь я знаю, что такое возможно, потому что, когда я подписался на ConvertKit, мне показали что-то вроде этого:

Эти два значения, как вы можете видеть, указывают на converkit.com, НО когда я запускаю их через поиск DNS:

https://dnschecker.org/all-dns-records-of-domain.php?query=spf.dm-5mk8zo6m.sg7.convertkit.com.&rtype=ALL&dns=google

https://dnschecker.org/all-dns-records-of-domain.php?query=dkim.dm-5mk8zo6m.sg7.convertkit.com.&rtype=ALL&dns=google

Я вижу, что в фоновом режиме он указывает на записи MX и TXT, принадлежащие Sendgrid. Как я могу этого добиться? (Я считаю, что те же принципы применимы и к SES или любому другому MTA)

РЕДАКТИРОВАТЬ: Я попробовал несколько вещей: и я установил CNAME, MX и TXT в chillybilly.xyz (домен моего проекта), и я указал на него два CNAMES из frankthetank.xyz под названием spf.frankthetank.xyz и dkim.frankthetankxyz

https://dnschecker.org/all-dns-records-of-domain.php?query=spf.frankthetank.xyz&rtype=ALL&dns=google

https://dnschecker.org/all-dns-records-of-domain.php?query=dkim.frankthetank.xyz&rtype=ALL&dns=google

Как видите, мне удалось добиться результатов, очень похожих на то, что ConvertKit делает с Sendgrid. Но это не проверяется таким образом. :(

Единственная разница, которую я вижу, когда я проверяю эти поисковые запросы DNS (ссылки выше), заключается в том, что CNAME также отображаются в поиске для меня, но не в случае convertkit. Итак, я думаю, что близок к решению, но не уверен, что мне не хватает, есть идеи? :)

Первый SPF: если вы замените, например. исходящей SPF-записи sendgrid, которая включена в вашу SPF-запись, с вашим собственным брендом, вы в то же время взяли на себя работу по отслеживанию всех динамических вещей, которые sendgrid может делать с именами и адресами их исходящих почтовых серверов. Вы не хотите этого делать, поэтому, если вы отправляете через sendgrid, вам нужно включить SPF sendgrid. Так что, поскольку вы используете sendgrid, вы никак не можете избавиться от этого «include: sendgrid.net» в своей SPF-записи, не причинив себе боли.

DKIM похож, пример amazonses создает CNAME для записей, которые существуют в DNS Amazon. Если вы хотите заменить его своим собственным (что вы можете, без проблем), вы должны поместить эти записи в свой собственный DNS. Это не проблема, однако вам нужно каким-то образом передать ключ подписи тому, кто подписывает эти электронные письма, и это может быть проблемой. С помощью решения Amazon они создают ключ и дают вам ссылку на открытый ключ, который они помещают в свой DNS, который соответствует закрытому ключу, которым они подписывают вашу электронную почту.

Однако, если вы хотите удалить «бренд» с почтовых серверов Amazon или sendgrid, единственный способ — выкупить их, потому что это делается с помощью обратного DNS, и они НИКОГДА не будут указывать свои исходящие серверы на имена в вашем пространстве имен DNS.

Таким образом, вы можете просто сделать записи CNAME, которые указывают на исходную запись, или просто поместить правильный SPF, как в примере с convertkit, но под своим доменом.

или у вас есть промежуточное программное обеспечение, которое проходит процесс проверки домена в sendgrid/AWS, создавая записи DNS в вашем домене, которые вы затем сообщаете своему клиенту CNAME для новых записей DNS, которые вы создали, а затем завершает проверку, как только клиент щелкает кнопку, чтобы сказать, что они сделали это

это не остановит заголовки электронной почты или отслеживание записей DNS, чтобы найти исходного провайдера, но для обычного человека это вероятно отлично.

Однако я хочу предостеречь: уровни обфускации на самом деле вредят уровню DNS.

Например, SPF имеет явное жестко запрограммированное ограничение в 10 запросов в RFC — сами Sendgrid пишут об этом — https://docs.sendgrid.com/ui/account-and-settings/spf-limitations

• Оригинальный RFC. Вы подвергаетесь высокому риску столкнуться с этой проблемой, если будете выполнять какие-либо обфускации для SPF.

дополнительные поисковые запросы DNS увеличат время отклика для любого поиска на основе DNS в потоке доставки почты и/или в вашем приложении — это может привести к много боли на многих уровнях, особенно когда MTA обрабатывают в режиме реального времени, любая задержка может иметь огромные потенциальные последствия.

Чтобы добавить немного математики, представьте, что одно электронное письмо обрабатывается и отправляется через MTA с DNS за 20 мс — это пример наилучшего случая, предполагающий эта логика Справедливо. Вы можете отправить около 180 тысяч писем в час. Если нам нужно удвоить это, добавив хотя бы 1 дополнительный DNS-запрос, это уменьшится вдвое до 90 000 писем в час. Если вы зависите от объема, вам нужно будет использовать вдвое больше оборудования для поддержания той же пропускной способности.