Странные символы появляются в некоторых средствах проверки DNS, но не появляются в других для DKIM и SPF, что может привести к сбою DMARC.

Письма, отправленные со всех трех адресов электронной почты, которые я установил в надстройке Rackspace Cloudways, попадают в спам в GMail.

Когда я «Просмотр исходного сообщения» в GMail, я вижу…

SPF:    NEUTRAL with IP 173.203.187.81
DMARC:  'FAIL'

… где 173.203.187.81 — это IP-адрес Rackspace.

Мой провайдер DNS — CloudFlare.

Существует настроенная политика DMARC, которая заключается в следующем…

_dmarc.boldstatements.com.au    v=DMARC1; p=none; ruf=mailto:admin@mydomain.net; rua=mailto:admin@mydomain.net

Cloudways предоставил мне эту запись DKIM TXT…

20220817-maluhsjy._domainkey    v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC0PqtvPuYkElqS+b80iEj4aepAdf6n+CDXRFTG/1Q8RMdw/D6hNmQpv8FCTyIuplZt/qTxBbBFrPLJK5tp7bqkSEG2YpPSnHDCGihaOCsRkJP0aAbnuQRmjHq6H0yCwtJKjRhW7H4pbjx9/LA6dXIaw4N1emtSLWcGejVrhVZ+CwIDAQAB

Когда я использую dnschecker.org и несколько других инструментов поиска DNS, чтобы просмотреть свои записи TXT, я получаю следующий странный вывод…

\239\187\191v=spf1 a mx include:_spf.elasticemail.com include:emailsrvr.com -all

Эти персонажи \239\187\191 точно не в записи TXT в CloudFlare.

Служба поддержки CloudWays утверждает, что эти символы вызывают сбой DMARC, но, поскольку они не отображаются в других средствах проверки DNS, таких как https://mxtoolbox.com/ а также https://www.whatsmydns.net/и поскольку SPF возвращает «нейтральный», я подозреваю, что на самом деле это ошибка в https://dnschecker.org/ и средство проверки DNS, которое использует служба поддержки Cloudways.

Какие-нибудь мысли?

ЗАМЕТКИ

Благодаря ответу Патрика Мевзека ниже я смог найти решение.

Просто краткое описание того, как я вообще оказался в этом беспорядке: в основном я копировал и вставлял значения записей DNS из окна чата службы поддержки Cloudways прямо в Cloudflare.

А для удаления символов мне нужно было скопировать значение из Cloudflare в Notepad++, изменить кодировку на ANSII, из-за чего появились посторонние символы, удалить их, потом снова поменять на UTF-8 (на всякий случай) и вставить обратно в CloudFlare .

ПСВ,

\239\187\191 это DNS-кодирование 3 байтов десятичных значений 239, 187, 191, которые отображаются в шестнадцатеричном виде в EF BB BFчто является кодировкой UTF-8 кодовой точки Unicode. U+FEFFкоторый ZERO WIDTH NO-BREAK SPACE

Я подозреваю, что эта запись TXT была создана путем копирования и вставки откуда-то и некоторого «умного» поведения, и, очевидно, пробел не виден на экране в каком-то пользовательском интерфейсе, но попал в запись TXT.

Это должно быть очищено, иначе удалено.

Что касается:

Этих символов \239\187\191 точно нет в записи TXT в CloudFlare.

а также

но поскольку они не отображаются в других средствах проверки DNS, таких как https://mxtoolbox.com/ а также https://www.whatsmydns.net/,

Подозреваю, что разные системы (ошибочно, но стандарта там, к сожалению, вообще нет, DNS изобрели задолго до Unicode/UTF-8, а потом много чего типа SPF просто решил поругаться TXT записи) просто рассмотрите TXT записывать содержимое как строку в UTF-8, чтобы они декодировали его и отображали, но, очевидно, «пробел нулевой ширины» не виден ни на одной HTML-странице.

Лучший пользовательский интерфейс позаботится об этом и правильно отобразит это и/или предупредит об этом. В еще лучшем пользовательском интерфейсе можно было бы просто удалить этот символ при добавлении записи, так как здесь он явно неправильный (но очевидное в TXT запись ограничена… вы должны это видеть v=spf1 или аналогичный, а затем действовать соответственно). Что теперь дает мне хорошее представление о том, что я должен исправить в своем пользовательском интерфейсе, спасибо за идею 🙂