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

Google прямо указывает на 3 настройки для отправителя, с помощью которых он может подтвердить что он не спамер а честный владелец домена с которого пришло письмо... Три настройки — это SPF, DKIM и DMARC.

Разберём их по порядку:

1. SPF – Sender Policy Framework. Это посто запись в DNS’ке домена, в которой мы прописываем какие исходящие IP-адреса проходящих через наш домен сообщений считать корректными, а какие спамом... Нам просто нужно указать там свои IPшки, которые нужно считать корректными, и указать, что остальные IPшки сообщений, которые маскируются под наш домен и у которых даже исходящий мейл может иметь название нашего домена — следует считать спамом.
   
   Почтовый сервер принимает сообщения от какой-то домена, и сверяется с его DNS’кой на предмет, соответствует ли этому домену IPшка отправителя. После проверки решает, доставлять ли сообщение получателю, или зарезать сообщение как spam.
   
   С SPF всё проще простого. Просто берём и прописываем всё что гугл хочет в DNS. Создаём следующую TXT-запись:
   
   v=spf1 a mx include:mydomain.com ~all
   
   Кстати, некоторые DNS-редакторы имеют user-friendly интерфейс, и уже имеют поле SPF, в котором можно указать эту же самую запись: v=spf1 a mx include:mydomain.com ~all. Но дублировать её не надо. SPF это тот же TXT, и нет необходимости прописывать одну и ту же запись дважды.
   
   Параметры записи:
     v — это версия SPF, в данном случае spf1 означает первую версию.
     a и mx указывают что IPшки перчисленные в A и MX-записях домена автоматически считать хорошими.
     include:... перечисляем IPшки и хосты которые сервер получателя должен считать хорошими.
    -all или ~all или ?all — определяет, что сервер получателя должен делать с письмом.
   
   ?all (безотказная доставка) означает что желательно доставлять все письма домена отправленные с любой IPшки независимо ни от чего.
   -all (жёсткий отказ) означает что сервер получателя должен однозначно резать все письма от IPшек, которые не соответствуют домену как спам. (Но тут могут возникнуть проблемы с автоматическим форвардингом почтовых сообщений. К примеру, кто-то отправляет письмо на ваш почтовый адрес, с которого письмо немедленно форвардится дальше, например на ваш @gmail’овский ящик. -all по идее должен рубить такие сообщения, но в реальности тесты показали что гугл принимает такие отфорварженые сообщения, считая их, однако, немного подозрительными, помечая статус проверки SPF’ки как softfail (Received-SPF: softfail...)
   ~all (мягкий отказ) означает что решение о доставке или о зарубывании письма остаётся на усмотрение сервера. Такие письма помечаются в заголовке письма отметкой (Received-SPF: pass...) при успешной проверке, и (Received-SPF: softfail...) при неуспешной. Решение об отправке письма в спам или о доставке отстаётся за алгоритмом сортировки письмем на сервере получателя. Я у себя прописал именно мягкий отказ, с тильдой (~all), поскольку я форваржу некоторую свою почту (публичные адреса, на которые валит куча спама) на свой gmail-аккаунт. Просто на моём сервере у меня нет своего спам-фильтра, и я хочу чтобы работу по сортировке спама за меня сделал google/gmail.
    
2. DKIM. Тут чуток посложнее. Здесь нам нужно сгенерить электронный ключ, состоящий из приватной и 1024-байтной публичной части. Приватную часть подвязываем к EXIM’у на нашем сервере, а публичную, опять таки, суём в DNS.
   
   Пошагово:
   1. Идём куда-то, и генерим себе RSA-ключ для домена. Сгенерить ключ для DKIM’a себе можно например здесь: https://luxsci.com/extranet/dkim.html или здесь: https://www.socketlabs.com/domainkey-dkim-generation-wizard/ или тут: http://www.port25.com/support/domainkeysdkim-wizard/.
      (Только, помним, что он должен быть как минимум 1024-байтным. Гугл не считается с ключами меньшей длины. считая их ненадёжными.)
      При генерации ключа нам нужно указать своё домен и какой-то идентификатор ключа, selector. Пусть будет key1, для этого примера, но он может называться как угодно, например dkim.
       
   2. Публичную часть ключа прописываем себе в DNS’ку. Создаём две новых TXT-записи и пишем
      в первую:
      _domainkey.mydomain.com  TXT o=~;
      Кстати, некоторые генераторы пытаются подсунуть ещё параметр t=y, но это параметр для теста. Тест нам не нужен, поэтому пишем только o=~;
      
      во вторую:
      key1._domainkey.mydomain.com  TXT v=DKIM1; k=rsa; p=MIGfMA0G.....IDAQAB
      
      (Вместо mydomain.com конечно подставляем имя своего домена, вместо key1 выбранный селектор, а в параметре p= указываем собственно публичную часть RSA-ключа.)
      Ещё, важно!, чтобы в публичном ключе не было пробелов, символов переноса строки, табуляций и т.д.. Публичный ключ — это одна строка, пишущаяся слитно. Тестировать DKIM-запись прописанную в DNS’ке можно тут http://dkimcore.org/c/keycheck (но возможно придётся подождать до 48 часов до обновления DNS’ок.
       
   3. Приватную часть ключа сохраняем в какой-то файлик, который записываем в секретное место на сервере, а в конфиге EXIM’a (exim.conf) прописываем следующее:
      
      Где-то вначале так:
      # DKIM
      DKIM_ENABLE      = yes # если мы захотим отключить DKIM в будущем, можно будет закомментировать эту строку
      DKIM_DOMAIN      = ${lc:${domain:$h_from:}}
      DKIM_FILE        = /etc/exim/dkim/${lc:${domain:$h_from:}}.key
      DKIM_PRIVATE_KEY = ${if exists{DKIM_FILE}{DKIM_FILE}{0}}
      
      а в блоке описания транспортов пишем как-то так:
      begin transports
          remote_smtp:
              driver = smtp
      .ifdef DKIM_ENABLE
              dkim_domain      = DKIM_DOMAIN
              dkim_selector    = key1
              dkim_private_key = DKIM_PRIVATE_KEY
      .endif
      
      Домен здесь подставится автоматически, вместо key1 нужно будет указать выбранный нами селектор, а файлик с приватной частью ключа положить по адресу, указанному в переменной DKIM_FILE.
      Это будет что-то вроде /etc/exim/dkim/mydomain.com.key
       
   4. Это всё. Для начала подписывания — перезапускаем EXIM: /etc/init.d/exim restart
      Ещё возможно потребуется подождать до 48 часов для обновления DNSок, чтобы сервер получателя увидел публичную часть ключа.
       
3. DMARC. Настройка DMARC описана тут, но повторяться лень, просто создаём парочку новых TXT-записей у себя в DNS’ках и прописываем правила:
   
   _adsp._domainkey.mydomain.com  TXT dkim=all
   _dmarc.mydomain.com  TXT v=DMARC1; p=quarantine; adkim=s; aspf=s;
   
   Популярно о параметрах-тэгах DMARC’a — описано на http://dmarc.org/draft-dmarc-base-00-01.html#iana_dmarc_tags (тестировать DMARC-запись можно тут: http://mxtoolbox.com/SuperTool.aspx).
   
   Параметры:
   • v — version (версия DMARC)
   • p — policy (политика, может быть none, quarantine или reject).
     • none — никаких активных действий со стороны принимающего сервера не будет, кроме записи в логе (или отчёта к отправителю, если у того настроен параметр rua, в котором можно указать мейл, на который будут поступать отзывы от принимающих серверов. Подробно можно изучить в доках DMARC’a, я этот параметр не использую, логи получать и читать не хочу).
     • quarantine — сообщение будет доставлено, но помечено как спам (получатель сам будет выуживать его из спама/карантина).
     • reject — письмо получателю не доходит, происходить отлуп отправителю, указанному в поле From. (Примерный вид отлупа — ниже.)
   • adkim и aspf — режим сверки (alignment mode) подписей DKIM и SPF. Последние два параметра могут иметь значения r (relaxed) или s (strict). Если вы используете почту в поддоменах, типа @news.domain.com, то ставьте r (совпадение по организации, по главному домену). Если все почтовые ящики находятся в пределах одного домена @domain.com — ставьте s (будет строгая проверка по полному названию домена).
   • ...больше параметров в описании на https://support.google.com/a/answer/2466563?hl=ru.
      
   Нам здесь важен лишь один параметр, параметр p (Policy). Это даёт указание почтовику адресата, что делать с письмами, которые поступили НЕ с домена указанного в mydomain.com. У этого p[olicy] возможны три значения: none, quarantine или reject. Скажу лишь о reject’е (который, на первый взгляд, кажется самой правильной политикой. Это типа указание отклонять все письма от @mydomain.com в поле From, которые реально поступают от другого сервера, не mydomain.com)...
   
   Я тестировал все три настройки, пересылая письма через @hotmail.com на @gmail.com. Дальнейший текст — мой личный опыт, без претензии на объективность.

   REJECT. По идее reject — самая правильная настройка. Письма, которые идут не с вашего домена, но в полях From указывают ваш домен, должны быть отклонены. Однако, люди зачастую пользуются форвардерами. Например, адресат, имея почтовый ящик на @hotmail.com в реальности не пользуются им, настраивая редирект на свой @gmail.com. И вот при политике такой reject-политике, вместо благополучной доставки письма на имя@hotmail.com, вы получите отлуп. Из-за того, что SPF-тест будет провален, письмо пришло с IP-шки отличающейся от домена. DKIM-тест, который содержит публичный ключ, будет пройеден, но отлуп произойдёт даже из-за заваленного SPF. Так происходит, например, при отправке письма на @hotmail.com, когда адресат настроил перенаправление на @gmail. Получается такой вот отлуп:

   Delivery Status Notification (Failure)
   --------------------------------------
   
   
   This is an automatically generated Delivery Status Notification.
   
   Delivery to the following recipients failed.
   
   
    someemail@gmail.com
   
   --------------------------------------
   Reporting-MTA: dns;COL004-OMC4S7.hotmail.com
   Received-From-MTA: dns;EUR02-AM5-obe.outbound.protection.outlook.com
   Arrival-Date: Fri, 9 Dec 2016 05:34:01 -0800
   
   Final-Recipient: 
   Action: failed
   Status: 5.5.0
   Diagnostic-Code: smtp;550-5.7.1 Unauthenticated email from yourdomain.com is not accepted due to
   550-5.7.1 domain’s DMARC policy. Please contact the administrator of
   550-5.7.1 yourdomain.com domain if this was a legitimate mail. Please visit
   550-5.7.1 https://support.google.com/mail/answer/2451690 to learn about the
   550 5.7.1 DMARC initiative. f16si33975676pli.56 – gsmtp
   

   NONE. Я поставил none, для гарантии того, что письма не будут отвергнуты. Однако, мне кажется, что gmail не воспринимает политику none и игнорирует её. По меньшей мере при пересылке почты с hotmail. Именно с hotmail, потому что при пересылке через yandex всё прошло. Детальнее не углублялся, мне для моей задачи важна именно пересылка через hotmail/outlook. Я даже указал параметр rua, так что моя запись выглядела следующим образом:
       v=DMARC1; p=none; adkim=s; aspf=s; rua=mailto:postmaster@mydomain.com
   Однако в приходящих отчётах видел следующее:

     <policy_published>
       <domain>mydomain.com</domain>
       <adkim>s</adkim>
       <aspf>s</aspf>
       <p>reject</p>
       <sp>reject</sp>
       <pct>100</pct>
     </policy_published>

   То есть, очевидно, политика none не срабатывала, преобразуясь в reject.
   
   QUARANTINE. Внезапно с p=quarantine всё заработало. Письма через hotmail проходят, и даже не попадают в спам. (Но в моём случае меня бы устраивало даже если бы и попадало в спам, я бы обращал на это внимание адресата.)
   
   Таким образом, лично я для себя решил, что безопаснее всего сделать политику quarantine (для большей гарантии получения письма адресатом, в случае, если он пользуется форвардерами).

Тестирование всего:

1. DKIM-запись с публичным RSA-ключём тестируем тут: http://dkimcore.org/c/keycheck. Отличная тулза, которая укажет на ошибки синтаксиса.
   Альтернативно — тут: https://www.mail-tester.com/spf-dkim-check. Эта тулза заодно проверит и SPF, но на ошибки не укажет.
    
2. Проверка доставки писем (тестирует ВСЁ, и SPF, и DKIM и DMARC):
   https://www.port25.com/authentication-checker/.
   Вкратце... Чтобы потестить результаты по IPшке отпрпавителя — отправьте тестовое письмо на check-auth@verifier.port25.com.
    
3. Ещё DMARC и кучу других записей DNS: http://mxtoolbox.com/SuperTool.aspx

И ещё:

Если что-то не получается, не переживайте. Всё получится. Настройка всех этих записей для неопытного человека — задача не на один день. Здесь проблема в том, что обновления DNS-записей можно ожидать до 2 суток. Пока DNS не обновится, нет повода нервничать о том, что что-то всё ещё не работает. Если настройки правильные, то через некоторое время заработают сами собой.

Однако, даже когда всё будет настроено и заработает при прямой доставке на gmail, обязательно тестируйте доставку письма при пересылке. Например, через hotmail.com. Там легко настраивается форвардер.