Мой веб-сервер размещен на Amazon EC2, на уровне бесплатного пользования, скажем, на example.com. Поскольку я использую только один эластичный IP-адрес и не хочу платить за другой, я подумал о настройке постфикса на моем веб-сервере, а не о настройке его на mail.example.com (что, вероятно, является лучшей идеей. ).
В большинстве документов говорится о добавлении этих записей в поддомен, но могу ли я поместить их и в свой основной домен (например, example.com). В настоящее время я установил свой SPF как TXT на своем основном домене, и он проходит проверки SPF. Могу ли я сделать то же самое для DKIM?
Я только что сгенерировал ключ https://www.unlocktheinbox.com/dkimwizard/ и он показывает закрытый и открытый ключи, а также запись селектора и запись политики.
Хотя я понимаю, где мне нужно разместить свой частный (постфиксный) и открытый ключ (в записи dns txt / mx), но не уверен, где мне добавить свои 2 сгенерированные записи (селектор и политика). Могу ли я добавить их обе как записи TXT в моем основном домене, вместо того, чтобы создавать поддомен (например, mail.example.com)?
Ваша запись селектора:
rsa._domainkey.example.com IN TXT
"k=rsa;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnfOc9CYLS2I2/mSaDbRoZyJzlHYrS5aSjU3U94FKDmGUkG7HqLUFWRx6TkZVQ5JpKoyTA25PUpBnzdu11945B66EbrZGAYb3YE7kCJ1BSNjaXajd4fzkFfYV06riJgWC83wBc9hoIoDzAZDNFV/HKstjy8Zd2H81HnvpVGnuKeAQsKIdIyazYwv85kHwh8tRm0si4I251VJ9dHByoMu+/e/s8ppBhvaH0Ss1YZr5B7q8PVeoy6V+l9JMPkKt+wsELTBBKVk7LLYdiis3bHXaYL0cfjPerqfwkyX2Hq2xdSUZ90zw7W6pvsoFDVe/1H45ZbqkLJ8klz8YLzwPAJj13wIDAQAB"
Ваша запись о полисе:
_domainkey.example.com IN TXT "o=~"
Спасибо.
Нет, не можешь. У вас должно быть именно то, что указано во всей документации и учебных пособиях, т.е.
selectorname._domainkey.example.com. IN TXT "k=ra;P=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB...
Здесь _domainkey взято из спецификации DKIM (RFC 6376, 7.5) и selectorname это селектор (3.1) для идентификации нескольких ключей подписи друг от друга. Хотя селектор определяется пользователем и может быть любым, он должен быть таким же, как используемый в s= тег в подписи:
DKIM-Signature a=rsa-sha1; q=dns; d=example.com; i=user@example.com; s=selectorname; ...
Это вызовет поиск открытого ключа из Пространство имен DKIM (3.6.2.1), который это субдомен.
Все ключи DKIM хранятся в субдомене с именем
_domainkey. УчитываяDKIM-Signatureполе сd=тегexample.comиs=тегfoo.bar, запрос DNS будет дляfoo.bar._domainkey.example.com.
Это просто определено таким образом и просто отличается от определенных записей SPF (RFC 7208, 3) быть размещается в дереве DNS под именем владельца, к которому он относится, а не в поддомене под именем владельца.
В _domainkey.example.com. IN TXT "o=~" изначально был разработан для предоставления информации о политике подписи в Интернет-проект Политики подписи отправителя DKIM, где o=~ будет указывать, что объект подписывает некоторую, но не всю почту, а - и ! будет строже и . за то, что вообще не отправляет почту.
На самом деле это никогда не использовалось, поэтому тебе не нужно _domainkey.example.com IN TXT "o=~" вообще.
Для реальной замены o= вы должны ориентироваться на DMARC. Без DMARC невозможно определить, использует ли домен DKIM или нет; вы могли только проверить, проходит ли DKIM всякий раз, когда он присутствует, но он не охватывает сообщения без заголовка подписи.
Политика DMARC позволяет отправителю указывать, что его сообщения защищены SPF и / или DKIM, и сообщает получателю, что делать, если ни один из этих методов аутентификации не проходит, например, спам или отклонение сообщения.
При внедрении DMARC у вас уже должны работать SPF и DKIM.