Значимость SPF
Хочу обратить ваше внимание на важную, на мой взгляд, проблему, которой пренебрегают даже самые крупные и инновационные компании мира. Проблема заключается в отсутствии у большинства доменов SPF-записи, которая защищает домен от его несанкционированного использования в электронной почте.
SPF (Sender Policy Framework) представляет из себя текстовую запись в TXT-записи DNS домена. Запись содержит информацию о списке серверов, которые имеют право отправлять письма от имени этого домена и механизм обработки писем, отправленных от других серверов.
Например, SPF-запись «example.com. TXT «v=spf1 +a +mx -all»» говорит о том, что отправлять письма от имени домена «example.com» могут сервера, указанные в A и MX-записях этого домена, а письма, отправленные от других серверов должны быть удалены (Fail).
Важно понимать:
- SPF-запись не наследуется на поддомены. Для каждого домена третьего (и ниже) уровней необходима своя запись.
- SPF проверяет только HELO и MAIL FROM поля.
Всю подробную информацию о данной технологии можно найти на сайте проекта «Sender Policy Framework».
Почему это важно?
- Анализ IP-адреса сервера отправителя: его репутация, корректность A и PTR-записей.
- Анализ SPF/DMARC записей домена и цифровой подписи DKIM.
- Анализ содержимого: заголовки, тема, текст, ссылки и т.д.
Примеры
В качестве примера я отправил 3 простых письма с помощью telnet и SMTP команд. 2 письма покажут работу спам-фильтра SpamAssassin (сервис mail-tester.com), а последнее письмо будет проходить анти-спам фильтр Gmail. Для чистоты экспериментов я использовал «чистый» IP-адрес (найти его было не так и сложно) и текст без ссылок и HTML.
| # | From | To | Результат | SPF домена отправителя |
| 1 | bill.gates@microsoft.ru | *@mail-tester.com | Успешно. Баллов в mail-tester.com: 7/10 | — |
| 2 | bill.gates@microsoft.com | *@mail-tester.com | Неуспешно. Баллов в mail-tester.com: 2.1/10 | v=spf1 include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com include:_spf-ssg-a.microsoft.com include:spf-a.hotmail.com ip4:147.243.128.24 ip4:147.243.128.26 ip4:147.243.1.153 ip4:147.243.1.47 ip4:147.243.1.48 -all |
| 3 | bill.gates@microsoft.ru | *@gmail.com | Успешно | — |
Письмо №1: 
Письмо №2: 
Письмо №3: 
Как видно из результатов, письмо от домена «microsoft.com» не прошло бы анти-спам фильтр, даже если у него идеально чистое содержание. А вот письмо от имени домена «microsoft.ru» прошло проверку и у SpamAssassin и у Gmail, так как оно не защищено.
Советы
- Перед установкой SPF-записи удостоверьтесь, что учтены все сервера, отправляющие письма в интернет. Не забудьте про web-сервера и другие внешние системы, иначе вы можете потерять часть писем, и тем самым навредить себе и бизнесу.
- Правильно выбирайте механизм обработки писем (Pass, Fail, SoftFail, Neutral). При безусловной переадресации вашего письма из одной почтовой системы в другую может возникнуть проблема, так как SPF проверяет только последний «хоп».
- Рекомендуется создавать SPF-записи для всех доменов второго уровня, которые принадлежат вам или вашей компании, даже если вы не отправляете от их имени письма. Для таких доменов желательно использовать простую запись «v=spf1 -all», которая говорит, что никто не можем отправлять письма от этих доменов.
- Домены третьего уровня защитить можно с помощью wildcard-записи типа «*.example.com. IN TXT «v=spf1 -all»». Но, обратите внимание на то, что wildcard работает только для несуществующих поддоменов. Например, если у вас есть поддомен moscow.example.com с MX-записями, запись «*.example.com. IN TXT «v=spf1 -all»» не будет на нее распространяться. Подробнее описано в статье на Wikipedia и RFC 1034.
Moreover, the wildcard is matched only when a domain does not exist, not just when there are no matching records of the type that has been queried for. Even the definition of «does not exist» as defined in the search algorithm of RFC 1034 section 4.3.2 can result in the wild card not matching cases that one might expect with other types of wildcards.
Товарищи айтишники, не подставляйте себя и свою компанию – установите SPF-записи для всех своих доменов и MX-серверов.
Что такое SPF
Думаю, никому не нужно объяснять, какой проблемой является спам в наше время. Борьба с этим злом — дело не простое, и если хочется приблизится к идеалу, требующее сочетания нескольких элементов. Одним из этих элементов является протокол SPF. Будучи опубликованным в апреле 2006 года в RFC 2006 года к настоящему времени протокол имеет статус «экспериментальный», и достаточно неплохую распространенность.
SPF взят на вооружение такими гигантами, как Google, Яндекс, Mail.Ru, Microsoft, Рамблер. Yahoo не поддерживает SPF, а пытается продвигать свою разработку DKIM, к слову, не слишком успешно.
Итак — как же работает SPF?
Общие принципы работы
Основная идея такова — хозяин адреса указывает, с каких адресов следует ожидать его почту, и как интерпретировать ошибку, в случае несоответствия. Важно понимать, что эти данные — всего лишь рекомендация отправителя по проверке. Да-да, конечно же, стандарт описывает, как должна принимающая сторона обрабатывать результат, но по всяким причинам принимающая сторона фактически может с ними делать все, что заблагорассудится — полностью соблюсти, интерпретировать по-своему или же вообще проигнорировать рекомендации.
Технические детали
Для размещения данных используется поле TXT в DNS. Так IANA назначила DNS поле с кодом 99 для SPF. Формат SPF поля идентичен TXT. Вообще, использование поля TXT не является оптимальным, но проблема в том, что не всякий DNS сервер и клиент понимает новый SPF тип записи. Поэтому совместное использование TXT и SPF считается хорошим подходом, обеспечивающим совместимость и будущее развитие.
Стандарт рекомендует доменам, удовлетворяющим требованиям SPF, иметь записи обоих типов. Вместе с тем, как минимум одна запись должна присутствовать обязательно. В случае наличия двух записей они должны быть идентичны. Например:
example.com. IN TXT «v=spf1 +mx a:colo.example.com/28 -all»
example.com. IN SPF «v=spf1 +mx a:colo.example.com/28 -all»
Если установлена запись SPF, то TXT записи должны быть проигнорированы.
Механизм взаимодействия
Почтовый обмен с использованием SPF происходит по следующему алгоритму.
Почтовый сервер mx.example.com отправляет письмо на адрес user@example.net. В DNS записи example.com содержатся такие строки:
mx.example.com. IN A 208.77.188.166
example.com. IN MX 10 mx.example.com.
example.com. IN TXT «v=spf1 +mx -all»
Итак, mx.example.com устанавливает соединение с SMTP example.net и получает от него, нечто вроде
>> 220 example.net ESMTP Service (Mailer v1.0) ready at 30.07.2009 12:28:21 UTC
затем mx.example.com представляется через HELO/EHLO.
В зависимости от настроек принимающей стороны, после данного представления уже может быть проверка на соответствие представленного имени правилам SPF, но в данном месте это не обязательно
>> 250 example.net Hello mx.example.com., pleased to meet you
А вот в этом месте, после выдачи отправителем MAIL FROM должна последовать обязательная проверка, интерпретация результата и реакция на него.
В данный момент модуль, отвечающий за проверку SPF делает следующие вещи. Осуществляется запрос к DNS. Запрашиваются SPF и TXT поля. Если в полученном ответе присутствует правило SPF, то оно разбирается и происходит анализ на соответствие. В нашем примере это правило «v=spf1 +mx -all». Согласно правила проверяются MX записи, и проводится сверка указанных в записях IP-адресов, полученного из представления DNS-имени и IP-адреса подключившегося отправителя. В данном случае все совпадает, управление возвращается почтовику, и он начинает прием сообщения.
Если бы, вдруг, фактический IP подключившегося отправителя был иным, то анализатор сообщил бы почтовику, что входящее сообщение не валидно, и лучше бы его вообще не принимать, ну или на крайний случай отмаркировать отдельно.
Формат записи
Запись SPF выглядит примерно так:
example.com. IN SPF «v=spf1 +mx a:colo.example.com/28 -all»
Эта запись содержит следующую информацию:
версия SPF — 1 (кстати, пока единственная используемая)
письмо может иметь отправителя с IP-адресом, соответствующим записям в MX для домена example.com
письмо может иметь отправителя с IP-адресом, соответствующим одному из адресов в подсети colo.example.com/28
Во всех остальных случаях, когда адрес не соответствует перечисленным условиям, считать отправителя недостоверным.
Вообще, в условии есть 2 части — определитель и механизм.
Определители могут быть: «+» Pass, «-» Fail, «~» SoftFail, «?» Neutral
Механизмы: all, include, A, MX, PTR, IP4, IP6, exists
Результатами проверки условий могут являться следующие определенные результаты:
* None — означает, что либо в домене нет записей, либо вообще не удается проверить домен. В общем никакого внятного ответа не получено.
* Neutral — возникает в ситуации, когда хозяин домена не хочет или не может сообщить разрешен ли IP. Этот результат должен обрабатываться так же, как и None.
* Pass — означает, что все ОК и получатель может принять письмо.
* Fail — явно указывает на то, что письмо принимать не следует. Проверяющая сторона может отмаркировать письмо либо отбросить.
* SoftFail — находится где-то между Fail и Neutral. Принимающая сторона не должна отбрасывать письмо на основании только этого результата.
* TempError — результат, возникающий, если клиент в момент проверки получает временную ошибку. Сообщение можно принять или временно отвергнуть.
* PermError — ошибка, возникающая при невозможности корректной интерпретации DNS записей отправителя.
Возьмем, для примера, какой-нибудь реальный домен. Допустим Google.com. Запрос TXT возвращает
«v=spf1 include:_netblocks.google.com ~all»
тут говорится, что нужно включить правила из записи _netblocks.google.com. Интересно, что у _netblocks.google.com отсутствует A-запись, а есть только TXT-запись. Вот она:
«v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ?all»
Тут перечислены подсети, в которых могут находится почтовые сервера Google. Последний механизм all c определителем Neutral сообщает анализатору о том, что адрес отправителя может быть не из разрешенного диапазона. Письма из чужих адресных пространств рекомендуется проверять дополнительно, а не отвергать безусловно. Для такой масштабной структуры, как Google — это верное решение, ибо в процессе работы адреса могут изменятся, например, при временном отказе и переключении на резерв. И к тому же, адрес может меняться пересылками.
Более хитрая SPF запись у Рамблера:
«v=spf1 ip4:81.19.66.0/23 ip4:81.19.88.0/24 -exists:%.spf.rambler.ru -exists:%.u.spf.rambler.ru ~all»
тут указаны 2 подсети, из которых разрешено принимать почту, и 2 набора источников, почта с которых будет иметь результат проверки Fail.
Проблема пересылки
Представьте себе следующую схему — пользователь отправляет письмо с адреса vasily@xyz.com на pupkin@mylo.ru, а там стоит автоматический форвардинг на pupkin@gmail.com. А у домена xyz.com прописано SPF «v=spf1 +mx -all». В итоге, конечный получатель gmail.com сделает проверку, и получит несовпадение адреса фактического отправителя с указанным, и по правилам SPF не примет письмо. Для решения данной проблемы существует SRS: Sender Rewriting Scheme. В двух словах — происходит переписывание форвардером заголовка return-path.
Вообще, я считаю, что данный момент очень спорный. Использование промежуточного ящика для перенаправления трафика на другой ящик весьма напоминает спам-атаку. Вот, например, я регистрирую ящик, свечу его везде, где только можно, подписываюсь на миллион рассылок, и ставлю редирект на некий ящик, который я хочу завалить спамом. В случае наличия у отправителей SPF и отсутствии SRS на пересылающем почтовике — цель отвергнет эти потоки как спам, а вот при работающем SRS он получит вполне «легитимные» потоки почты.
Заключение
SPF является простым и достаточно эффективным способом оценить легитимность передаваемой почты. Администраторам почтовых серверов стоит минимальных телодвижений добавление SPF записей в DNS. Простота внедрения и поддержка основными популярными MTA делают распространение SPF все шире и шире, что несет всем пользователям электронной почты пользу, почтовым серверам снижение трафика и в целом делает мир лучше 🙂
Настройка SPF-записи. Подробнее о SPF
В данной статье рассмотрим что такое SPF и немного рассмотрим детали её настройки.
SPF (Sender Policy Framework) — это специальная TXT-запись в DNS, в которой указано с каких почтовых серверов может быть отправлена почта для домена.
С помощью данной записи можно снизить общее количество СПАМа, уменьшить вероятность того, что домен будет скомпрометирован и защититься от СПАМа, который использует поле обратного адреса.
domain.ru. IN TXT «v=spf1 include:anymailserver.org ~all»
- Основной синтаксис
- Пример SPF для общего случая
- Пример SPF для индивидуального случая
- Пример 1 — include
- Пример 2 — redirect
- Пример 3 — advantshop + retailcrm
- Пример 4 — advantshop + retailcrm + yandex
Основной синтаксис
1) Любая SPF-запись начинается с v=spf1, этот параметр не изменяется.
2) Далее указываются параметры (механизмы). Чаще всего используются следующие: all, ip4, ip6, a, mx, include, redirect
3) Помимо механизмов используются префиксы (определители):
- «-» — Fail, отклонять почту.
- «~» — SoftFail, «мягко» отклонять (принимать почту, но помещать ее в «Спам»).
- «?» — нейтрально (обрабатывать как обычное письмо).
Подробнее можно почитать тут — Wikipedia SPF
В целом всё, мы выбираем какие почтовые сервисы нам нужны, и перечисляем их как «include:»
v=spf1 include:server1 include:server2 include:server3 ~all
Означает, что мы размещаем отправку сервисам server1, server2, и server3.
Отлично, далее мы покажем SPF-записи для разных вариантов работы с отправкой почты.
Случай #1 Общий — spf.on-advantshop.net
Владельцам интернет-магазина в облаке, кто использует, для отправки писем, следующие службы (одну или несколько сразу):
- Yandex mail
- Mail.ru
- Google Mail
- Unisender и Unione
- Почтовую службу AdvantShop
Нужно прописать унифицированную SPF-запись:
Хост: @ или пустой
Тип: TXT
Значение: «v=spf1 redirect=spf.on-advantshop.net»Если требуется указать TTL, укажите 600.
Если у Вас возникли сложности с добавлением TXT записей, пожалуйста обратитесь в поддержку, мы поможем.
Случай #2 Индивидуальный — spfcore.on-advantshop.net
Если Вы используете какой-то почтовый сервис, отличный от перечисленных выше (в случае 1), и прописали дефолтную SPF запись («v=spf1 redirect=spf.on-advantshop.net»), то нужно сделать следующее:
1. Удалить запись «v=spf1 redirect=spf.on-advantshop.net» (если она была)
2. Добавить нужную запись в соответствии с рекомендациями Вашего сервиса по работе с email.
3. После этого, обязательно, нужно добавить в Вашу новую SPF дополнительный блок:
Это необходимо сделать, чтобы почтовая служба advantshop смогла работать корректно.
Пример 1:
Почтовый сервис выдал Вам запись: «v=spf1 include:XXXXXXXXXXX ~all»
Необходимо в неё добавить блок:
Если в выданной записи присутствует include, то всё просто, добавляем ещё один блок include.
По формату, запись получится вот такая:
v=spf1 include:XXXXXXXXXXX include:spfcore.on-advantshop.net ~all
Где XXXXXXXXXXX это Ваша, почтовая служба.
Пример 2:
Почтовый сервис выдал Вам запись: «v=spf1 redirect=XXXXXXXXXXX«
Необходимо в неё добавить блок:
Если в выданной записи присутствует redirect, то необходимо «redirect=» заменить на «include:» и добавить ещё один блок include.
По формату, запись получится вот такая:
v=spf1 include:XXXXXXXXXXX include:spfcore.on-advantshop.net ~all
Где XXXXXXXXXXX это Ваша, почтовая служба.
Далее рассмотрим несколько реальных примеров.
Реальный пример 1 «advantshop + retailcrm»
Если Вы используете retailcrm и почтовую службу advantshop, то необходимо прописать вот так:
v=spf1 include:spf.retailcrm.pro include:spfcore.on-advantshop.net ~all
Реальный пример 2 «advantshop + retailcrm + yandex»
Если Вы используете retailcrm и почтовую службу advantshop и яндекс, то необходимо прописать вот так:
v=spf1 include:spf.retailcrm.pro include:_spf.yandex.net include:spfcore.on-advantshop.net ~all
Далее по аналогии с примерами можно комбинировать использование SPF от различных сервисов:
- include:_spf.mail.ru
- include:_spf.google.com
- include:_spf.yandex.net
- include:mailer.rees46.com
- include:spf.retailcrm.pro
- include:_spf.amocrmmail.com
- include:mxsspf.sendpulse.com
- include:sendgrid.net
- include:servers.mcsv.net
- include:spf.protection.outlook.com
- include:spf2.esputnik.com
- include:spf.mindbox.ru
- Либо целиком запись вида: «v=spf1 redirect=spf.on-advantshop.net»
- Либо отдельно добавленный, в существующую SPF-запись, блок «include:spfcore.on-advantshop.net»
Как проверить всё ли правильно настроено
Ниже опишем универсальный способ как проверить верно ли синтаксически указана SPF-запись.
1) Находим свою SPF-запись у почтового домена.
Например, если наш почтовый ящик info@m2bee.ru, то наш почтовый домен будет «m2bee.ru»
Указываем свой почтовый домен, в текстовое поле и выбираем тип «TXT», нажимаем кнопку «Resolve» (Рис. 1).
Рисунок 1. Проверяем TXT записи домена.
Находим TXT запись в которая начинается на «v=spf1. » (Рис. 2).
Рисунок 2. Проверяем какие SPF есть у домена.
Важно
Если у Вас 2 или более SPF-записей — это является ошибкой!
Должна присутствовать только одна SPF-запись.
Копируем строчку и переходим к пункту 2.
2) Проверяем SPF-запись
Указываем нашу запись в текстовое поле и нажимаем «Validate», после чего смотрим на результат (Рис. 3).
Рисунок 3. Ошибка в SPF-записи.
Если результат «зелёный» — всё хорошо.
Если показывается ошибка, необходимо внести корректировки.
3) Проверяем SPF-запись по домену.
Так же, можно проверить ещё в одном сервисе, указав только почтовый домен.
Указываем почтовый домен в текстовое поле и нажимаем «Validate DNS», после чего смотрим на результат (Рис. 4).
Рисунок 4. Проверка SPF-записи по домену.
Если один из сервисов выдаёт ошибку и Вам не удаётся исправить свою SPF, обратитесь к нам в поддержку, мы поможем.
Всё готово. В данной статье мы рассмотрели, что такое SPF-запись и как её корректно настроить.
Другие статьи по теме
- Как подключить почту для сайта? Почта для домена.
- Настройка e-mail почты магазина
- Настройка почтовых уведомлений
- Форматы писем
- Шаблоны ответов
Как исправить ошибку 550 SPF Check Failed? [SOLVED]
Аона — менеджер по маркетингу и контенту в PowerDMARC, имеет более чем 5-летний опыт написания статей на темы кибербезопасности, специализируясь на безопасности доменов и электронной почты. Ахона получила диплом о высшем образовании по специальности «Журналистика и коммуникации», а с 2019 года начала работать в сфере безопасности.
Последние сообщения Ахона Рудра (см. все )
- Как вспомнить электронное письмо в Outlook? — 5 января 2024 г.
- Как исправить ошибку «Политика DMARC не включена» в 2024? — 29 декабря 2023 г.
- Лучшие методы защиты от Ransomware для организаций среднего размера — 28 декабря 2023 г.
Сообщение «550 SPF check failed» является распространенной ошибкой, которая может быть вызвана отсутствием SPF в DNS отправителя, наличием недействительной записи или работой сторонних спам-фильтров. Основной вывод, который можно сделать из этой ошибки, заключается в том, что она обычно возникает по вине отправителя, а не получателя, и может быть устранена с помощью нескольких быстрых действий.
О SPF
SPF — это аббревиатура от Sender Policy Framework, протокола, который является основополагающим элементом аутентификации электронной почты и проверки личности отправителя.
Записи SPF для доменов находятся в файле зоны DNS отправителя и предоставляют информацию об IP-адресах или именах доменов, которые уполномочены отправлять электронную почту от имени вашей организации.
Когда вы отправляете электронное письмо с вашего домена, сервер, принимающий почту, проверяет SPF-запись домена, чтобы убедиться, что имя домена в адресе обратного пути письма указано в ней. Если совпадения не найдено, электронное письмо не проходит SPF-аутентификацию.
Что такое ошибка «550 SPF Check Failed»?
Ошибка » 550 SPF Check Failed» в основном вызвана неправильной конфигурацией почтового сервера. Эту ошибку можно исправить, изменив записи DNS или добавив запись TXT в настройки DNS для SPF.
Она может возникнуть, когда сервер электронной почты пытается проверить доменное имя отправителя с помощью Sender Policy Framework, но это не удается. Если вы получаете ошибку такого типа, это означает, что сервер вашего получателя не смог проверить личность отправителя электронной почты.
Вероятные причины ошибки «550 SPF Check Failed»
Существует несколько причин, которые могут привести к ошибке «550 SPF Check Failed».
1. Неверная запись SPF
Наиболее распространенной причиной является то, что SPF-запись отправителя недействительна. Для работы SPF запись типа TXT должна быть добавлена в файл зоны DNS вашего домена, но возможно, что она не была добавлена или в ней отсутствуют некоторые поля.
Обойти эту проблему можно, просмотрев запись SPF вашего домена в Интернете, чтобы подтвердить наличие или отсутствие действительной записи и исключить эту вероятность.
2. Спам-фильтры Microsoft
Средство защиты от спама Sophos от Microsoft — это простой способ защитить себя от хакеров и вредоносных программ в Интернете.
Sophos — это бесплатная служба, которая работает в фоновом режиме на вашем компьютере и сканирует поврежденный код, а также спам, прежде чем он попадет в ваш почтовый ящик. Он также предотвращает загрузку вредоносных программ в вашу систему.
Однако если вы передаете свои сообщения через Microsoft Office 365 Exchange online, ваши электронные письма могут не пройти SPF, если на вашей системе установлен Sophos. В этом случае появится сообщение об ошибке: «SMTP; 550 5.7.1 550 Сообщение отклонено, поскольку проверка SPF не удалась».
3. Неполная запись SPF
В идеале запись SPF должна содержать полный список авторизованных серверов, которым разрешено отправлять электронную почту от имени домена. Однако чаще всего владелец домена упускает возможность указать легитимный сторонний источник отправки. Это может привести к возникновению ошибки 550.
4. Сообщения, передаваемые через одного или нескольких посредников
Многочисленные переходы между вашим почтовым сервером и конечным пунктом назначения (например, если вы отправляете через внешний ретранслятор) означают, что они не будут указаны в SPF-записи вашего домена и могут быть вероятной причиной ошибки.
Это происходит потому, что при пересылке электронной почты, когда сообщение проходит через сервер-посредник, информация заголовка сообщения изменяется во время пересылки, и адрес обратного пути теперь указывает на домен посредника. Сервер получателя может не распознать этот внешний ретранслятор как легитимного отправителя и выдать сообщение «550 SPF Check Failed».
5. Поддельный почтовый адрес «От
Поддельные почтовые адреса «от» используются для создания видимости того, что письмо приходит от законного источника, но на самом деле оно отправлено кем-то другим. Это может быть сделано любым способом, включая подделку заголовков и сообщений или прямое использование законного домена в злонамеренных целях.
Проблема в том, что сообщения, использующие поддельные адреса ‘From’, не проходят проверку SPF, поскольку домен обратного пути не совпадает с доменом ‘From’ (domain misalignment). Обнаруженная поддельная атака может вызвать аналогичный ответ об ошибке и привести к отказ SPF .
6. Многократный поиск
Наконец, еще одной вероятной причиной ошибки «550 SPF check failed» является превышение установленного RFC ограничения на 10 DNS-поисков. Это может быть результатом неправильного формата записи SPF, возвращающей ошибку «hard fail», которая обычно появляется с темой «SPF Permerror».
Устранение ошибки 550 SPF Check Failed
Если вы стали жертвой этой ошибки, обратите внимание, что проблема обычно возникает по вине отправителя электронной почты, а не получателя.
Вы можете устранить неполадки, выполнив следующие действия:
1. Исправьте ошибки записи SPF
Отправитель электронной почты может устранить ошибку 550 SPF Check Failed, найдя и исправив ошибки в SPF-записи своего домена. Именно эти записи позволяют правильно проверить доменное имя. Поэтому даже небольшая орфографическая ошибка или проблема форматирования может помешать принимающему серверу подтвердить ваш домен.
Наиболее распространенными типами ошибок, которые могут возникнуть в записи SPF, являются следующие:
- Дополнительные пробелы до или после строки
- Ошибочные написания
- Дополнительные тире
- Прописные буквы
- Дополнительные запятые и пробелы
Некоторые примеры правильной записи SPF приведены ниже:
v=spf1 include:spf-sender.example.com ~all v=spf1 a mx ip4:143.129.0.2/11 include:example1.com include:example2.net ~all 2. MX должен указывать на правильный сервер
Когда отправитель посылает электронное письмо, оно направляется с его компьютера на почтовый сервер (также известный как SMTP-сервер). Почтовый сервер принимает или отклоняет электронные письма на основании нескольких факторов, таких как IP-адрес и другая информация в заголовке письма.
Если SMTP-сервер получает письмо с недействительными MX-записями, он возвращает сообщение об ошибке 550 SPF Check Failed, указывающее на то, что во время маршрутизации что-то пошло не так.
Чтобы решить эту проблему, необходимо убедиться, что ваша запись MX указывает на правильный сервер. Это можно сделать, отредактировав запись MX вашего домена в DNS Manager или cPanel.
3. Включите IP-адреса ваших поставщиков
Чтобы не пропустить включение IP-адресов ваших поставщиков, вы можете передать управление SPF третьей стороне или вести ручной список источников отправки, который поддерживается и обновляется каждый раз, когда вы используете внешний инструмент или сервис для электронной почты.
В зависимости от этих обновлений вам необходимо изменить записи вашего домена. Существуют специальные рекомендации, установленные поставщиками услуг электронной почты для согласования ваших источников отправки. Например, если вы используете онлайн-серверы exchange для передачи сообщений, запись Office 365 SPF запись в руководстве будут описаны эти спецификации для реализации.
Также важно, чтобы ваша запись SPF содержала как ваши внутренние IP-адреса, так и адреса ваших пересылок.
Станьте частью крупнейшего сообщества безопасных пользователей электронной почты, став участником MSP DMARC сегодня!
2 января 2023 года / по адресу Ахона Рудра Теги: smtp 550 spf check failed exchange
Поделиться этой записью
- Поделиться на Facebook
- Поделиться в Twitter
- Поделиться в Twitter
- Поделиться на WhatsApp
- Поделиться информацией на сайте LinkedIn
- Отправить по почте