Наша организация создает учетную запись в сторонней облачной службе, которая будет отправлять электронные письма от нашего имени. Наш отдел маркетинга хотел бы убрать фрагменты «через» или «от имени», которые показывают некоторые клиенты, чтобы казалось, что электронные письма пришли непосредственно от нас. Просматривая страницу справки третьей стороны по этому вопросу, они просят нас вставить запись DKIM в нашу зону для их сервера. В настоящее время мы внедряем SPF для наших почтовых серверов, но не DKIM.
Если у вас есть запись SPF, которая запрещает серверам вашего поставщика услуг отправлять почту, любой получатель, который проверяет либо только SPF, либо и SPF, и DKIM, скорее всего, не воспримет сбой SPF.
Я бы подумал, что поставщик услуг дает вам SPF include директива или аналогичная, чтобы справиться с этим.
Нет, не должно быть. Ключи DKIM ищутся на основе связанного с ними значения селектора; нет общей записи DKIM для домена в целом, только для определенных селекторов, указанных в подписанном DKIM письме. Добавление записи DKIM не влияет на неподписанную почту или почту, подписанную ключами для других селекторов.
Запись DKIM только позволяет владельцу ключа показать с разумной степенью уверенности *, что отправляемое им письмо одобрено владельцем домена.
*) Если зона, содержащая запись DKIM, не подписана DNSSEC, нет способа проверить подлинность данных записи. Проверка подписи на основе ключа, полученного при таких обстоятельствах, очевидно, значительно ограничит то, что было фактически доказано.
У каждого ESP есть конкретные инструкции по аутентификации электронной почты. Некоторые попросят вас настроить поддомен для маркетинга, например em.example.com IN CNAME wl.sendgrid.net, другие - комбинацию include: SPF.example.com для вашего SPF и текстовой записи dkim.
Следуйте их конкретным указаниям, но обязательно соблюдайте их, для SPF он должен быть меньше 10 DNS-запросов, для DKIM у вас может быть только один ключ для каждого селектора.
Разместите свой ESP, и мы расскажем вам об этом.