Больше нет писем в папке Spam: настройка SMTP-сервера

    Недавно мы настраивали SMTP-сервер для нашего проекта. Вопрос стоял так: что нужно сделать, чтобы письма, отправленные нашим пользователям, не попадали в папку со спамом или попадали туда как можно реже?

    Было найдено несколько интересных и полезных статей на эту тему (ссылки в конце статьи), на основе которых и было всё сделано в итоге. Но получив сегодня утром очередную порцию рассылки от достаточно известных русскоязычных ресурсов и увидев, что они пренебрегают описанными правилами, я решил кратко и в одном месте собрать все действия, которых достаточно для решения проблемы. Надеюсь, что после этого количество сайтов, отправляющих почту как надо, возрастет.

    Приведенные советы актуальны только если вы используете свой собственный SMTP-сервер. При использовании, например, SMTP сервера Google всё уже сделано за нас. Как правило. В любом случае рекомендую проверить (см. подразделы Как проверить?).

    Пункты расположены по степени значимости. Лучше не приступать к следующему, не завершив предыдущий.

    Пропишите Reverse DNS


    Название говорит само за себя. Reverse DNS lookup — процедура обратная DNS lookup. По IP адресу мы, а точнее почтовый сервер пользователя, получаем доменное имя. Если он совпадает с доменным именем в поле From, отправляемого письма, то всё в порядке.

    Как сделать?
    В большинстве случаев вы сами не сможете это сделать, если не являетесь владельцем диапазона IP-адресов. Поэтому единственный способ сделать данную настройку — попросить сделать это вашего хостинг-провайдера.

    Как проверить?
    Используйте любой из online-сервисов Reverse DNS lookup. Например, этот. Достаточно ввести IP-адрес сервера, с которого производится отправка почты. Если в результате отображается ваш домен, то всё в порядке.

    Настройте DomainKeys


    DomainKeys Identified Mail (DKIM) — метод, позволяющий убедиться, что почта отправлена тем, кто имеет на это право. По сути это протокол цифровой подписи письма.

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

    Если нет желания доверять свой приватный ключ внешнему сервису, то можно воспользоваться OpenSSL:
    openssl genrsa -out private.pem 1024
    openssl rsa -pubout -in private.pem -out public.pem
    

    В любом случае дальнейшие шаги следующие:
    1. Настроить ваш SMTP-сервер.
    2. Прописать две записи в DNS.

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

    В DNS своего домена теперь надо прописать две TXT-записи:
    _domainkey.example.com. TXT "t=s; o=~;"
    mail._domainkey.example.com. TXT "k=rsa; t=s; p={REPLACE_WITH_PUBLIC_KEY_CONTENT}"

    mail — это селектор DomainKeys. По факту может быть любым идентификатором, но должен совпадать с тем, что указан в настройках DKIM SMTP-сервера.

    Как проверить?
    Отправьте почту через ваш сервис на любой GMail-аккаунт. Откройте полученное письмо и выберите в меню действий пункт Show Original.

    Если вы найдете следующую строчку, то всё в порядке:
    Authentication-Results: ... dkim=pass

    Настройте DNS записи SPF


    Sender Policy Framework — система, позволяющая указывать IP-адреса, с которых разрешена отправка в DNS-записях домена.

    Как сделать?
    Подробное описание синтаксиса доступно здесь.

    В большинстве случаев достаточно следующей записи:
    example.com. TXT v=spf1 a mx ~all

    Эта запись говорит о том, что почту можно отправлять с любого IP, указанного в записях A (AAAA) и MX данного домена и только с них.

    Как проверить?
    Отправьте почту через ваш сервис на любой GMail-аккаунт. Откройте полученное письмо и выберите в меню действий пункт Show Original.

    Если вы найдете следующие строчки, то всё в порядке:
    Received-SPF: pass
    Authentication-Results: ... spf=pass

    Итого


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

    Ссылки


    So You'd Like to Send Some Email (Through Code)
    DKIM — это просто
    SPF Record Syntax
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 29

      +4
      Есть хороший сервис для проверки всего этого и не только:
      HELO Greeting
      Reverse DNS
      DNSBL (RBL)
      SPF
      Domain Keys
      SPAMAssassin Content Checks
      BATV (Bounce Address Tag Validation)
      Greylisting
      URIBL


      Просто шлем любое письмо на адрес и через несколько минут получаем отлуп, в котором будет ссылка, перейдя по которой получим результаты теста.
        +1
        Иногда не очень удобно вылавливать боунсы у себя на сервере особенно если обработку входящей еще не настроил нормально :)
        а в вебе можно пользоваться этим
        www.brandonchecketts.com/emailtest.php

        Шлем письмо по сгенерированному для вас адресу и сразу после этого смотрим в онлайне результат
          0
          — The following addresses had permanent fatal errors — (reason: 552 Database is temporarily down. Please try after some time.
            0
            Это на сайте или ответ на мыло?
            Сейчас проверил и то и другое, сайт нормально работает, на письмо отлуп получил через 8 минут.
              0
              ответ на мыло) все утро пробую… один хост из 5 пробился, остальные отлуп…
          0
          Всё в одном месте. Спасибо.
            +9
            «example.com. TXT v=spf1 a mx ~all

            Эта запись говорит о том, что почту можно отправлять с любого IP, указанного в записях A (AAAA) и MX данного домена и только с них.»

            вообще-то не так. Эта запись говорит, что про все остальные адреса отправителей мы ничего сказать не сможем. Если нужна строгая spf, то есть И ТОЛЬКО С НИХ, как вы пишите, то надо в конце -all
              +1
              Частая ошибка, даже у mail.ru присутствует софт-фейл, которая позволяет миллионам спамеров рассылать от их имени.
              v=spf1 ip4:94.100.176.0/20 ip4:217.69.128.0/20 ip4:128.140.168.0/21 ip4:195.218.168.66 ip4:188.93.58.0/24 ~all
                0
                Не совсем ошибка. Есть куча провайдеров, которые перекрывают 25 порт у себя и позволяют отправлять почту только через свой релей. Так вот, при -all сервер выдаст однозначный фейл при отправке через релей такого прова. ~all в этом плане более мягок и не выдаст жесткого fail, но и pass не будет.
                  0
                  Настроить авторизацию, которая будет пропускать у релея без проблем?
                  У нас например стоит -all, а все клиенты авторизируются, кто не может, проходит по IP авторизацию. И никого из них нет в SPF, да и не должно быть.
                  0
                  У яндекс такая же «ошибка», а у gmail, о боже, ?all. А когда-то, кстати, был -all — думаете, случайно ошиблись или все-таки о пользователях позаботились?

                  Суть в том, что это не ошибка. Бывают письма отправленные через релеи ISP, бывают письма отправленные в почтовые списки рассылки, бывают пользователи, которые настроили перенаправления с одного ящика в другой. Например, если Вы поставили -all для своего домена (вроде все правильно), некий администратор поднял корпоративный сервер вместо бывшего ящика на Yandex и сделал у себя реджект писем по SPF Fail (тоже вроде все правильно), некий пользователь сделал редирект старого ящика на Yandex в новый корпоративный ящик (тоже все правильно) — то Ваши письма ему не дойдут. И где-то кому-то что-то придется менять.
                    0
                    Только если в этом случае. Но опять же, это надо чтобы пользователи стучали по барабану провайдеру, а не наоборот. Какого черта те фильтруют траффик? Как же сетевой нейтралитет?
                      0
                      Очень сложно объяснить *** (любой случайный оператор сотовой связи из трех букв), например, что нехорошо в регионах закрывать почтовые порты, когда они начинают продвигать собственный почтовый клиент для телефонов. Сетевой нейтралитет ни в одном законе не прописан, а пользовательское соглашение у них составлено грамотно.

                      Но в описанной ситуации, фильтрация трафика провайдером никак не сказывается. Еще чаще бывает ситуация когда просто администратор почтового сервера сделал групповой адрес через алиас, типа
                      webmaster outsorcer1@gdetomail.com,outsorcer2@pupkin.ru,outsourcer3@bangalore.in
                      это общепринятая практика, отучить от нее практически невозможно.

                      Поэтому, прежде чем делать -all в SPF, неплохо бы оценить какой профит Вы с этого будете иметь и каким рискам себя подвергаете. Обычно получается что профита-то особого нет, а риски есть. Из-за этого в свое время и критиковали SPF, что она на принципах альтруизма, жесткая SPF не выгодна тому, кто ее реализует, а от мягкой SPF мало толка.
                        0
                        Как я уже говорил, у нас Авторизация стоит для пользователей + порт 587 и 465, их никто не фильтрует и не закрывает. 25 порт авторизацию не принимает в принципе.
                0
                почему нет упоминания про грейлистинг?
                  0
                  Потому что это ужасная практика задерживающие бизнес-процессы.
                    +1
                    Глупости. При корректной настройке задержка составит несколько минут для первого письма от этого отправителя, после чего его адрес будет помещён в белый список. Кроме того лично я активирую грейлистинг только для тех отправителей, которые засветились во всяких RBL-списках (что сводит к нулю задержку для большинства отправителей).
                      0
                      эти несколько минут сильно зависят от настроек времени прогона очереди отправляющего сервера.
                      А еще некоторые сервера типа гугла пересылают письмо которое не удалось доставить на другой релей и пробует оттуда, потом снова другой и тд. Это тоже надо предусмотреть

                      и да, я использую грейлистинг, но как и вы не для всех пользователей
                    0
                    Он актуален для принимающей стороны, не для отправляющей.
                    +1
                    Честно говоря, этого мало.
                    Стоит вчитаться ещё в рекомендации от ReturnPath например.
                    Тут вам и как правильно составлять письма, тут же про whois (а, кстати, многие любят скрывать оригинального владельца домена, чего делать не стоит), ещё вспоминается про Feedback Loop и многое другое.

                    Собственно документ на сайте ReturnPath.

                    Ах, да… Стоит особое внимание уделить безопасности вашей базы данных пользователей. Если хоть раз она тю-тю… то будите злостным спамером. увы.
                      0
                      А DKIM вообще технология живая? В смысле, кто-то кроме гугла проверяет DKIM?
                        0
                        яндекс проверяет
                          0
                          Достаточно кто еще проверяет. Яндекс, Укр.Нет очень положительно к нему относятся.
                            0
                            в том году нам мейлрушники активно советовали вставить DKIM в письма — правда мы и до этого рассылали несколько миллионов в день нормально, но это советовали сами мейлрушники (работали с ними немного) — послушались и сделали.
                            0
                            А еще стоит упомянуть про Precedence: bulk, про Message-ID (в яндексе про него отдельно упомянуто, на сколько помню) ну и конечно, если это рассылка, то надо чтобы была возможность отписки и не пренебрегайте bounce'ами

                            А если вы в мейл ру вдруг попали в спам (кстати, только у мейла, на сколько я знаю, есть такой чуть чуть полезный сервис postmaster.mail.ru) — то не стесняйтесь писать в саппорт, достаточно оперативно реагируют — на той недели просто извинились и вывели всю рассылку из спама(в течении суток) толком не объяснив, что произошло — типа алгоритм у них сложный и фиг знает :)
                              0
                              Правила рассылок от mail.ru Как то получили от них письмо с просьбой соблюдать их правила.
                                0
                                С ума сойти, я как раз вчера занимался настройкой smtp и новостной рассылкой, напоролся на все эти возможные подводные камни и как раз сегодня собирался написать точь-в-точь такую же статью на хабр. Чудеса.
                                  0
                                  У меня на DNS для одного IP прописано несколько PTR записей.
                                  При этом сервисы типа remote.12dt.com/lookup.php отображают только одну рандомную запись
                                  Как в этом случае настраивать Reverse DNS?
                                    0
                                    Лучше настроить только одну PTR запись на каноническое имя сервера, т.е. то имя, которое он сообщает в баннере и команде HELO/EHLO.

                                    То, что записей несколько, не страшно, при условии что все они нормально разрешаются в обе стороны (т.е. имя, указанное в PTR записи разрешается обратно в тот же IP), но получить проблемы в данном случае гораздо более вероятно, чем если будет единственная работающая PTR-запись.

                                  Only users with full accounts can post comments. Log in, please.