Адміністратори сувора приватна електронна пошта для бізнесу часто стикаються з багатьма проблемами та викликами. З хвиль СПАМ які повинні бути заблоковані спеціальними фільтрами, безпека листування на локальному сервері електронної пошти та на віддалених серверах, Налаштування і моніторинг служб SMTP, POP, Імпус, а також багато і багато інших деталей Конфігурація SPF, DKIM і DMARC для дотримання правил надсилання захищених повідомлень електронної пошти.

Multe probleme de expediere mesaje e-mail або receptionare catre / de la ati provideri, apar din cauza configurarii incorecte a zonei DNS, ce tine de serviciul de e-mail.

Pentru ca de pe un nume de domeniu sa poata fi trimise e-mail-uri, acesta trebuie sa fie hostat pe un server de e-mail configurat corespunzator, iar numele de domeniu sa aibe zonele DNS для SPF, MX, DMARC І DKIM setate corect in managerul DNS TXT al domeniului.

In articolul de azi ne vom opri asupra unei probleme destul de des intalnite pe serverele de e-mail private pentru business. Imposibilitatea de a trimite mesaje e-mail catre conturi de Gmail, Yahoo! sau iCloud.

Повідомлення, надіслані на @Gmail.com, автоматично відхиляються. “Не вдалося доставити лист: повідомлення повертається відправнику”

Am intalnit recent o problema pe un domeniu de e-mail al unei companii, de pe care se expediaza regulat mesaje e-mail catre alte companii si catre persoane fizice, unele dintre acestea avand adrese @gmail.com. Toate mesajele expediate catre conturile de Gmail reveneau imediat la expeditor. “Не вдалося доставити лист: повідомлення повертається відправнику”.

Mesajul de eroare returnat in serverul de e-mail pe Вимірювати arata in felul urmator:

1nSeUV-0005zz-De ** [email protected] R=dnslookup T=remote_smtp H=gmail-smtp-in.l.google.com [142.x.x.27] X=TLS1.2:ECDHE-ECDSA-AES128-GCM-SHA256:128 CV=yes: SMTP error from remote mail server after pipelined end of data: 550-5.7.26 This message does not have authentication information or fails to\n550-5.7.26 pass authentication checks. To best protect our users from spam, the\n550-5.7.26 message has been blocked. Please visit\n550-5.7.26  https://support.google.com/mail/answer/81126#authentication for more\n550 5.7.26 information. d3-20020adff843000000b001f1d7bdaeb7si6107985wrq.510 - gsmtp

In acest scenariu nu este ceva foarte grav, cum ar fi includerea numelui de domeniu expeditor sau IP expeditor intr-o lista de SPAM globala sau o eroare majora de configuratie a serviciilor de e-mail pe sevrer (Вимірювати.).
Chiar daca multi cand vad acest mesaj se duc cu gandul imediat la SPAM sau o la eroare de configurare SMTP, problema este generata de zona DNS TXT поля. У більшості випадків DKIM не налаштовано в зоні DNS або неправильно введено в диспетчері DNS домену. З цією проблемою часто стикаються ті, хто ним користується CloudFlare як менеджер DNS і забули пройти DNS TXT: mail._domainkey (DKIM), DMARC і SPF.

Як повідомляється в повідомленні про відмову від Gmail, автентичність і автентифікація домену відправника виявилася невдалою. “This message does not have authentication information or fails to\n550-5.7.26 pass authentication checks.”. Це означає, що домен не має DNS TXT, налаштованого для забезпечення надійності сервера електронної пошти одержувача. Gmail, у нашому сценарії.

Atunci cand adaugam un domeniu web cu serviciu de e-mail activ pe cPanel sau VestaCP, se creeaza automat si fisierele din zona DNS a domeniului respeciv. Zona DNS care contine inclusiv configuratia serviciului de e-mail: MX, SPF, DKIM, DMARC.
In situatia in care alegem ca domeniul sa fie pe manager DNS CloudFlare, zona DNS din contul de hosting al domeniului respectiv, trebuie copiata in CloudFlare, pentru ca domeniul de e-mail sa functioneze corect. Asta a fost problema in scenariul de mai sus. Intr-un manager DNS tert, nu exista inscrierea DKIM, desi ea exista pe managerul DNS al serverului local.

Що таке DKIM і чому електронні листи відхиляються, якщо ми не маємо цієї функції в домені електронної пошти?

DomainKeys Identified Mail (DKIM) este o solutie standard de autentificare a unui domeniu e-mail, care adauga o цифровий підпис до кожного надісланого повідомлення. Цільові сервери можуть перевіряти через DKIM, чи надходить повідомлення з офіційного домену відправника, а не з іншого домену, який використовує дані відправника як маску. Обов'язково, якщо у вас є домен abcdqwerty.com без DKIM повідомлення електронної пошти можна надсилати з інших серверів за допомогою вашого доменного імені. Це якщо ви хочете крадіжки особистих даних, що в технічних термінах називається підробка електронної пошти.
Поширений прийом, коли повідомлення електронної пошти надсилаються через фішинг і спам.

Також через DKIM можна переконатися, що, зміст повідомлення не було змінено після його відправлення відправником.

Avand DKIM setat corect pe severul gazda al sistemului de e-mail si in zona DNS, se elimina mult si posibilitatea ca mesajele dvs. sa ajunga in SPAM la destinatar sau sa nu ajunga deloc.

Un exemplu de DKIM este:

mail._domainkey: "v=DKIM1; k=rsa; p=MIGfMA0GCSqGfdSIb3DQEBAQUAA4GN ... ocqWffd4cwIDAQAB"

Desigur, valoarea DKIM obtinuta prin algoritmul de cripatre RSA este unica pentru fiecare nume de domeniu si poate fi regenerata de pe serverul gazda al serviciului de e-mail.

Avand DKIM instalat si setat corect in DNS TXT manager, este foarte posibil sa rezolve problema mesajelor returnate catre conturile de Gmail. Cel putin pentru eroarea “Помилка доставки пошти”:

“SMTP error from remote mail server after pipelined end of data: 550-5.7.26 This message does not have authentication information or fails to\n550-5.7.26 pass authentication checks. To best protect our users from spam, the\n550-5.7.26 message has been blocked.”

Як короткий підсумок, DKIM додає цифровий підпис до кожного надісланого повідомлення, що дозволяє серверам призначення перевірити автентичність відправника. Якщо повідомлення надійшло від вашої компанії, а адреса не використовувалася третьою стороною для використання вашої особи.

Gmail (Google) може автоматично відхиляти всі повідомлення які надходять із доменів, які не мають такого цифрового підпису DKIM.

Що таке SPF і чому він важливий для безпечного надсилання повідомлень електронної пошти?

Як і ДКІМ, і SPF спрямована на запобігання фішинг повідомлення і підробка електронної пошти. Таким чином надіслані повідомлення більше не позначатимуться як спам.

Структура політики відправника (SPF)це стандартний метод автентифікації домену, з якого надсилаються повідомлення. Записи SPF встановлено менеджер DNS TXT вашого домену, і в цьому записі буде вказано доменне ім’я, IP або домени, які мають право надсилати повідомлення електронної пошти, використовуючи ваше доменне ім’я або ім’я домену вашої організації.

Домен без SPF може дозволити спамерам надсилати електронні листи з інших серверів, використання вашого доменного імені як маски. Таким чином вони можуть поширюватися неправдива інформація або конфіденційні дані можуть бути запрошені від імені вашої організації

Desigur, mesajele pot fi trimise in continuare in numele dvs. de pe alte servere, insa acestea vor fi marcate ca spam sau vor fi respinse, daca acel server sau nume de domeniu nu este specificat in intrarea SPF TXT a domeniului dvs.

O valoare SPF in DNS manager arata de forma:

@ : "v=spf1 a mx ip4:x.x.x.x ?all"

Де “ip4” reprezinta IPv4 al serverului dvs. de e-mail.

Cum setam SPF pentru mai multe domenii?

Daca dorim sa autorizam si alte domenii care sa trimita mesaje e-mail in numele domeniului nostru, le vom specifica cu valoarea “include” in SPF TXT:

v=spf1 ip4:x.x.x.x include:example1.com include:example2.com ~all

Asta inseamna ca de pe numele domeniul nostru de e-mail se pot expedia mesaje e-mail si de pe example1.com si example2.com.
Este un record foarte util daca avem de exemplu un Журнал в Інтернеті pe adresa “example1.com“, dar dorim ca mesajele din magazinul online catre clienti sa plece de pe adresa de domeniu a companiei, ця істота “example.com“. У SPF TXT для “example.com”, ca fi nevoie sa specificam alaturi de IP si “include:example1.com”. Astfel ca de pe aceasta sa poata fi expediate mesaje in numele organizatiei.

Cum setam SPF pentru IPv4 si IPv6?

Avem un server de mail atat cu Ipv4 а також Ipv6, este foarte important ca in SPF TXT sa fie specificate ambele IP-uri.

v=spf1 ip4:196.255.100.26 ip6:2001:db8:8:4::2 ~all

In continuare, dupa “ip” poate fi folosita directiva “include” pentru a adauga domenii autorizate pentru expediere.

Що це означає “~all“, “-all” і “+all” ale SPF?

Asa cum am spus mai sus, providerii (ISP) pot primi in continuare mesaje e-mail in numele organizatiei dvs. chiar daca aceste sunt trimise de pe un domeniu sau IP care nu este specificat in politica SPF. Eticheta “all” spune serverelor de destinatie cum sa trateze aceste mesaje venite de pe alte domenii care nu sunt autorizate si trimit mesaje in numele dvs. sau al organizatiei.

~all : якщо повідомлення отримано з домену, якого немає в списку SPF TXT, повідомлення будуть прийняті на сервері призначення, але вони будуть позначені як спам або підозрілі. Вони підлягатимуть фільтрам належної практики захисту від спаму постачальника-одержувача.

-all : це найсуворіший тег, який додається до запису SPF. Якщо домену немає в списку, повідомлення буде позначено як несанкціоноване та відхилене постачальником. Він навіть не потрапить у спам.

+all : Цей тег використовується дуже рідко і зовсім не рекомендований, але дозволяє іншим надсилати повідомлення електронної пошти від вашого імені чи вашої організації. Більшість провайдерів автоматично відхиляють усі повідомлення електронної пошти, що надходять із доменів із SPF TXT “+all“. Саме тому, що автентичність відправника неможливо перевірити лише після перевірки “заголовок електронної пошти”.

Резюме: Що таке структура політики відправника (SPF)?

• Відключати & Очистити кеш DNS – Windows 7, Vista & Xp
• Використовуйте альтернативні сервери DNS для швидшого завантаження веб -сторінок
• Як ми можемо змінити адресу DNS в OS X
• Як ми можемо скинути кеш DNS в OS X
• Збільште швидкість перегляду Інтернету за допомогою Google Public DNS

Він авторизує через зону DNS TXT / SPF IP-адреси та доменні імена, які можуть надсилати повідомлення електронної пошти з вашого домену або домену вашої компанії. Він також застосовує наслідки, які застосовуються до повідомлень, надісланих із неавторизованих доменів.

Ce inseamna DMARC si de ce este important pentru server de e-mail?

DMARC (Звітування про автентифікацію повідомлень на основі домену та відповідність) тісно пов’язана зі стандартами політики SPF і DKIM.
DMARC - це a система перевірки призначений для захисту доменне ім’я електронної пошти вашої компанії, таких практик, як підробка електронної пошти та фішингові шахрайства.

Використовуючи стандарти керування SPF (Sender Policy Framework) і DKIM (Domain Keys Identified Mail), DMARC додає дуже важливу функцію. звіти.

Коли власник домену публікує DMARC у зоні DNS TXT, він отримає інформацію про те, хто надсилає повідомлення електронної пошти від його імені або від імені компанії, яка володіє доменом, захищеним SPF і DKIM. У той же час постачальники одержувачів повідомлень знатимуть, чи і як контролює ці передові політики власник домену відправника.

Запис DMARC у DNS TXT може мати такий вигляд:

V=DMARC1; rua=mailto:[email protected]; ruf=mailto:[email protected]; p=none; sp=none; fo=0;

У DMARC можна встановити кілька умов звітування про інциденти, а також адреси електронної пошти, на які можна надсилати аналізи та звіти. Бажано використовувати спеціальні адреси електронної пошти для DMARC, оскільки обсяг отриманих повідомлень може бути значним.

Теги DMARC можна встановлювати відповідно до політики, встановленої вами або організацією:

v – наявна версія протоколу DMARC.
p – застосовувати цю політику, якщо не можна виконати перевірку електронної пошти DMARC. Він може мати значення: “none“, “quarantine” або “reject“. Він використовується “none” для отримання звітів про потік повідомлень і їх статус.
rua – Це список URL-адрес, на які провайдери можуть надсилати відгуки у форматі XML. Якщо ми додамо сюди адресу електронної пошти, посилання матиме такий вигляд: “rua=mailto:[email protected]” .
ruf – Список URL-адрес, на які провайдери можуть надсилати звіти про кіберінциденти та злочини, скоєні від імені вашої організації. Адреса матиме такий вигляд: “ruf=mailto:[email protected]“.
rf – Формат звітності про кіберзлочинність. Його можна формувати “afrf” або “iodef“.
pct – Вказує Інтернет-провайдеру/провайдеру застосовувати політику DMARC лише до певного відсотка невдалих повідомлень. Наприклад, ми можемо мати: “pct=50%” або політики “quarantine” і “reject“. Це ніколи не буде прийнято “none“.
adkim – Вкажіть “Режим вирівнювання” для цифрових підписів DKIM. Це означає, що перевіряється збіг цифрового підпису запису DKIM із доменом. adkim може мати значення: r (Relaxed) s (Strict.).
aspf – Так само, як і в справі adkim вказано “Режим вирівнювання” для SPF і підтримує ті самі значення. r (Relaxed) s (Strict.).
sp – Ця політика дозволяє субдоменам, похідним від домену організації, використовувати значення DMARC домену. Це дозволяє уникнути використання окремих політик для кожного окремого домену. В основному це а “символ підстановки” для всіх підполів.
ri – Це значення встановлює інтервал, через який будуть отримані звіти XML для DMARC. У більшості випадків звітування бажано робити щодня.
fo – Параметри повідомлення про шахрайство. “Криміналістичні варіанти“. Вони можуть мати цінності “0” щоб повідомити про інциденти, коли не вдається перевірити як SPF, так і DKIM, або значення “1” для сценарію, у якому SPF або DKIM не існує або не проходить перевірку.

Отже, щоб бути впевненим, що повідомлення електронної пошти вашого або вашої компанії досягають одержувачів у папці «Вхідні», необхідно взяти до уваги ці три стандарти “найкращі методи надсилання повідомлень електронної пошти“. DKIM, SPF і DMARC. Усі ці три стандарти належать до DNS TXT і ними можна керувати з DNS-менеджера домену.