Электронные письма отклоняются некоторыми почтовыми провайдерами

Сообщение, которое вы опубликовали, является ошибкой подключения, что не обязательно означает, что они отказались от вашей электронной почты, скорее всего, проблема с DNS или какая-то другая проблема с подключением. Некоторые вещи, которые нужно проверить / подумать:

Можете ли вы проверить свой сервер приложений, чтобы убедиться, что он правильно разрешает записи DNS и MX для домена, который вы пытаетесь отправить по электронной почте.

Можете ли вы телнет с этого сервера на эти домены, если да, какой ответ вы получите?

Есть ли у доменных имен, с которых вы отправляете, записи spf и, если да, включен ли ip, с которого вы отправляете, в запись spf?

Правильно ли настроены обратные записи DNS для IP-адреса, с которого вы отправляете, для доменов, которые вы отправляете?

В идеале, прежде чем кто-либо действительно сможет дать вам окончательный ответ на проблему, вам нужно иметь телнет или что-то еще и получить ответ от сервера, объясняющий, почему вы не можете подключиться в первую очередь.

Одним из возможных вариантов является то, что эти серверы помечают вашу электронную почту как спам. Даже если это не совсем спам, многие провайдеры электронной почты блокируют сообщения, которые не совсем верны или предназначены для большого числа людей.

Однажды мы столкнулись с этим и должны были связаться с несколькими провайдерами, чтобы получить белый список. После того, как мы связались с ними и объяснили нашу программу купонов по электронной почте (согласие полностью совместимо с CAN-SPAM) и предоставили им подробную информацию, они добавили нас в белые списки.

Есть много вещей, которые могут пометить вас как спамера. Вот пара, чтобы проверить:

1. Количество электронных писем, выходящих.
2. Заголовки SMTP в письме не соответствуют домену, с которого вы отправляете. (Пример: использование адреса от @ microsoft.com, когда электронная почта поступает с вашего собственного домена.) Это может произойти случайно, если вы используете домен типа @ yourcompanyname.com, но SMTP-сервер зарегистрирован под другим домен или не зарегистрирован под вашим доменом.

Вот несколько ссылок, которые вы можете найти полезными

http://searchwarp.com/swa209211.htm

http://www.wilsonweb.com/05/020529b.htm

http://searchdomino.techtarget.com/news/article/0,289142,sid4_gci1192720,00.html (не совсем специфично для Domino, несмотря на URL)

Возможно, я опаздываю на один день и у меня не хватает доллара, но я только недавно столкнулся с этим, и, увы, возник вопрос В результате MalwareBytes у меня получилось плохое разрешение DNS.

Я мог видеть сообщения электронной почты, висящие в очереди SMTP IIS, и в конечном итоге это не получалось. Вот некоторые вещи, которые я сделал и в конечном итоге выяснил причину.

Для нас это было специально для одного домена.

Я запустил захват пакетов на нашем брандмауэре, чтобы увидеть, вижу ли трафик, исходящий с сервера электронной почты. Я не знал, что пакеты останавливаются в сети. Я также не видел никаких блокирующих сообщений в журналах брандмауэра, специально блокирующих трафик.

Шаг 1: Перейдите в MXToolbox и подключите их доменное имя для инструмента поиска MX. Это даст вам правильный IP-адрес, который вы подтвердите на шаге 2.

Вы также должны указать свой публичный IP-адрес и выполнить проверку черного списка и SPF.

Шаг 2: Запустить NSLOOKUP из командной строки на SMTP-сервере.

>>nslookup -type=mx domain.com
Server:  domaincontroller1.mydomain.com
Address:  192.168.1.6

Non-authoritative answer:
domain.com   MX preference = 1, mail exchanger = mail.domain.com
mail.domain.com      internet address = 168.144.68.87

Это был вопрос, который у нас был конкретно. Наш локальный DNS-сервер преобразовывал домен в IP-адрес 127.xxx. Это было сразу определено как проблема, и мы отследили ее до проблемы с MalwareBytes, не позволяющей DNS-серверу разрешать домен. Нам пришлось отключить MWB, очистить кэш DNS, а затем снова запросить домен, чтобы получить правильный IP.

Non-authoritative answer:
domain.com MX preference = 10, mail exchanger = mx.domain.com

mx.domain.com      internet address = 127.42.0.2
mx.domain.com      internet address = 127.42.0.4
mx.domain.com      internet address = 127.42.0.5

Шаг 2: Telnet к домену почтового обменника на порту 25. Вы должны увидеть следующее. Попробуй набрать EHLO domain.com если он подключится, и вы должны увидеть еще несколько вещей всплывающих.

>> telnet mail.domain.com
220 xmail03.domain.com ESMTP  648143d3667b3045487bb901cdbbf649
EHLO domain.com
250-xmail03.domain.com
250-PIPELINING
250-SIZE 100000000
250-DATAZ
250-STARTTLS
250-AUTH LOGIN PLAIN
250 8BITMIME

Если он не подключается или просто показывает черный экран, нажмите ENTER. Если он возвращает вас обратно в командную строку, он не подключается или сервер отказывает в этом.

Сообщение, которое вы опубликовали, является ошибкой подключения, что не обязательно означает, что они отказались от вашей электронной почты, скорее всего, проблема с DNS или какая-то другая проблема с подключением. Некоторые вещи, которые нужно проверить / подумать:

1. Можете ли вы проверить свой сервер приложений, чтобы убедиться, что он правильно разрешает записи DNS и MX для домена, который вы пытаетесь отправить по электронной почте.

2. Можете ли вы телнет с этого сервера на эти домены, если да, какой ответ вы получите?

3. Есть ли у доменных имен, с которых вы отправляете, записи spf и, если да, включен ли ip, с которого вы отправляете, в запись spf?

4. Правильно ли настроены обратные записи DNS для IP-адреса, с которого вы отправляете, для доменов, которые вы отправляете?

В идеале, прежде чем кто-либо действительно сможет дать вам окончательный ответ на проблему, вам нужно иметь телнет или что-то еще и получить ответ от сервера, объясняющий, почему вы не можете подключиться в первую очередь.

Откуда исходит отчет о недоставке, предположительно, ваш SMTP-сервер IIS, хотя я не часто работаю с SMTP IIS, поэтому я не уверен, что SMTP-сервер IIS способен генерировать отчеты о недоставке.

В любом случае не забудьте включить ведение журнала в свойствах SMTP-сервера IIS, а затем проверять журналы после получения отчета о недоставке. Если в файле журнала нет записей, соответствующих электронной почте, сгенерировавшей отчет о недоставке, я бы заподозрил проблему с тем, что клиент dns сервера IIS может разрешить запись MX для домена получателя. Если в файле журнала есть записи, соответствующие электронной почте, сгенерировавшей отчет о недоставке, то коды состояния SMTP в файле журнала должны подсказать вам, что происходит.

С кем вы размещаете свое приложение? У меня были проблемы с общими хостами, когда все сайты, размещенные на их серверах, занесены в черный список в спам.

То, что ваше приложение не отправляет спам, не означает, что другое приложение на общем хосте не отправлено. Поскольку это общий хост, весь SMTP-трафик поступает из одного и того же источника, который может оказаться заблокированным.

Сначала вы должны убедиться, что вы можете подключиться к целевому почтовому SMTP-серверу со своего внутреннего сервера. Вы можете сделать это, telnet <destination server> 25 и посмотрим, получишь ли ты приветствие. Иногда, некоторые места отфильтровывают соединения порта 25 как политику предотвращения спама.

Другая потенциальная проблема с почтой - обратная настройка DNS. Иногда серверы назначения проверяют, на кого вы претендуете, сверяя ваш исходный ip с доменом, который вы представляете. Возможно, вам придется настроить это с вашим поставщиком DNS.

Некоторые почтовые серверы будут ограничивать ваши соединения, пока вы не установите этот IP-адрес в качестве безопасного отправителя. Это занимает несколько вещей - вы должны придерживаться лучших правил для настройки:

1. Обратный DNS-вход
2. SenderID / SPF
3. Доменные ключи

Вам также будет лучше, если вы отправите IP-адреса в различные списки белых / массовых отправителей, такие как AOL и Yahoo.

Количество пользователей, которые сообщают о вас как о спаме, и количество отправленных вами неправильных адресов электронной почты также влияют на вашу возможность отправки.

Habeas и Returnpath также могут дать вам дополнительные "очки", чтобы улучшить ваш счет спама.

Наконец, если вы отправляете электронные письма от пользователей, которых нет в вашем домене, у вас, вероятно, всегда будут возникать некоторые проблемы. Вы можете попробовать отправить письмо с определенного адреса электронной почты и просто изменить имя и адрес для ответа в электронном письме.

Убедитесь, что вы указали Sender и Return-Path в заголовке письма. Прочитайте это: Отправить письмо от имени клиентов