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

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

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

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

Доменные имена Вы отправляете от, имеют записи SPF и если так, IP, который Вы отправляете от включенного в запись SPF?

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

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

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

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

Существует много вещей, которые могли отметить Вас как спаммера. Вот пара для проверки:

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, ins злость URL)

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

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

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

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

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

3. Доменные имена Вы отправляете от, имеют записи SPF и если так, IP, который Вы отправляете от включенного в запись SPF?

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

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

Куда NDR прибывает из, по-видимому, Ваш сервер SMTP IIS, хотя я не работаю с IIS SMTP очень часто, таким образом, я не уверен, способен ли сервер SMTP IIS к генерации NDR's.

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

Удостоверьтесь, что Вы указываете Отправителя и Обратный тракт в почтовом заголовке. Чтение этот: Пошлите электронное письмо от имени клиентов

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

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

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

1. Инвертируйте запись DNS
2. SenderID / SPF
3. Доменные ключи

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

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

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

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

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

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

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

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

Шаг 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.x.x.x. Это было немедленно идентифицировано как проблема, и мы отследили ее до проблемы с 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. Если он выводит вас обратно в командную строку, он не подключается или сервер отказывается от него.