Как да настроите DNS TXT зона за SPF, DKIM и DMARC и как да предотвратите отхвърлянето на бизнес имейл съобщения от Gmail - Доставката на поща не бе успешна

Administratorii от тежък личен имейл за бизнес често се сблъсква с много проблеми и предизвикателства. От вълните на SPAM които трябва да бъдат блокирани от специфични филтри, сигурност на кореспонденцията в локалния сървър за електронна поща и отдалечените сървъри, конфигурация si наблюдение на SMTP услуги, POP, IMAP, плюс много и много други подробности SPF, DKIM и DMARC конфигурация да следват най-добрите практики за защитена електронна поща.

Много проблеми изпращайте имейл съобщения или получател до/от вашите доставчици, се появяват поради неправилна конфигурация на зоната DNS, какво ще кажете за услугата за електронна поща.

За да се изпращат имейли от име на домейн, то трябва да бъде хостван на имейл сървър Правилно конфигуриран и име на домейн да има DNS зони Pentru SPF, MX, DMARC SI DKIM зададени правилно в мениджъра TXT DNS на домейна.

В днешната статия ще се съсредоточим върху един доста често срещан проблем частни бизнес имейл сървъри. Не може да се изпрати имейл до Gmail, Yahoo! или iCloud.

Съобщенията, изпратени до @ Gmail.com, се отхвърлят автоматично. "Грешка в доставката на пощата: връщане на съобщението до подателя"

Наскоро срещнах проблем на имейл домейн на фирма, от който редовно се изпращат имейли до други фирми и физически лица, някои от които имат адреси @ Gmail.com. Всички съобщения, изпратени до акаунти в Gmail, незабавно се връщат на подателя. "Грешка в доставката на пощата: връщане на съобщението до подателя".

Съобщението за грешка се върна на сървъра за електронна поща вкл ИВ изглежда така:

1nSeUV-0005zz-De ** reciver@gmail.com 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

В този сценарий не е нещо много сериозно, като напр включете името на изпращащия домейн или изпращащия IP в списък със СПАМ глобален или o голяма грешка в конфигурацията на услуги за електронна поща на сървър (ИВ).
Въпреки че много хора виждат това съобщение веднага, когато си помислят за СПАМ или грешка в конфигурацията на SMTP, проблемът се генерира от областта. TXT DNS на домейна. През повечето време DKIM не е конфигуриран в DNS зоната или не се предава правилно в DNS мениджъра на домейна. Този проблем често се среща при тези, които го използват CloudFlare като DNS мениджър и забрави да премине TXT DNS: mail._domainkey (DKIM), DMARC si SPF.

Както ни казва съобщението за отхвърляне на Gmail, автентичността и удостоверяването на домейна на подателя са неуспешни. “Това съобщение няма информация за удостоверяване или не успява \ n550-5.7.26 да премине проверки за удостоверяване.” Това означава, че домейнът няма конфигуриран DNS TXT, за да гарантира надеждност за имейл сървъра на получателя. Gmail, в нашия скрипт.

Когато добавим уеб домейн с активна услуга за електронна поща в неговия cPanel VestaCP, автоматично се създават и файловете в DNS зоната на съответния домейн. DNS зона, която съдържа конфигурацията на услугата за електронна поща: MX, SPF, DKIM, DMARC.
В ситуацията, когато избираме домейна да бъде мениджър CloudFlare DNS, DNS зоната на хостинг акаунта на домейна трябва да бъде копирана в CloudFlare, за да може имейл домейнът да работи правилно. Това беше проблемът в горния сценарий. В DNS мениджър на трета страна DKIM регистрацията не съществува, въпреки че съществува в DNS мениджъра на локалния сървър.

Какво е DKIM и защо имейлите се отхвърлят, ако нямаме тази функция в имейл домейн?

Идентифицирана поща на DomainKeys (DKIM) е стандартно решение за удостоверяване на домейн на имейл, което добавя a цифров подпис всяко изпратено съобщение. Сървърите на местоназначението могат да проверят чрез DKIM дали съобщението идва от областта на правото на подателя, а не от друг домейн, който използва самоличността на подателя като маска. По всички сметки, ако имате домейна ABCDqwerty.com без DKIM, имейлите могат да се изпращат от други сървъри, използвайки името на вашия домейн. Това е, ако искате кражба на самоличност, което в технически план се нарича имейл спуфинг.
Често срещана техника при изпращане на имейл съобщения Фишинг si спам.

Чрез DKIM може също така да се гарантира, че съдържанието на съобщението не е променено, след като е изпратено от подателя.

Настройването на DKIM правилно на стриктния хост на системата за електронна поща и в областта на DNS също така елиминира възможността вашите съобщения да достигнат до СПАМ до получателя или да не достигнат изобщо.

Пример за DKIM е:

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

Разбира се, стойността на DKIM, получена от RSA алгоритъм за криптиране е уникален за всяко име на домейн и може да бъде регенериран от имейл сървъра на хоста.

След като DKIM е инсталиран и настроен правилно TXT DNS мениджър, много е възможно да се реши проблемът с върнатите съобщения в акаунти в Gmail. Поне за грешката „Доставката на пощата не бе успешна“:

„SMTP error от отдалечен пощенски сървър след края на конвейера на данните: 550-5.7.26 Това съобщение няма информация за удостоверяване или не успява \ n550-5.7.26 да премине проверки за удостоверяване. За да защитим най-добре нашите потребители от спам, съобщението \ n550-5.7.26 е блокирано. ”

Като кратко обобщение, DKIM добавя цифров подпис към всяко изпратено съобщение, което позволява на целевите сървъри да проверят автентичността на подателя. Ако съобщението идва от вашата компания и адресът на трета страна не е бил използван, за да се използва вашата самоличност.

Gmail (Google) може би автоматично отхвърля всички съобщения идващи от домейни, които нямат такава DKIM цифрова семантика.

Какво е SPF и защо е важен за сигурното изпращане на имейли?

Точно като DKIM и SPF има за цел да предотврати фишинг съобщения si имейл спуфинг. По този начин изпратените съобщения вече няма да бъдат маркирани като спам.

Рамка на политиката за подаване (SPF) е стандартен метод за удостоверяване на домейна, от който се изпращат съобщенията. SPF записите са зададени на TXT DNS мениджър на вашия домейн и този запис ще посочи името на домейна, IP или домейните, на които е разрешено да изпращат имейл съобщения, използвайки името на вашия домейн или името на вашата организация.

Домейн без SPF може да позволи на спамърите да изпращат имейли от други сървъри. като използвате името на вашия домейн като маска. По този начин те могат да се разпространят фалшива информация или могат да бъдат поискани чувствителни данни от името на вашата организация

Разбира се, съобщенията все още могат да се изпращат от ваше име от други сървъри, но те ще бъдат маркирани като спам или отхвърлени, ако този сървър или име на домейн не са посочени в SPF TXT записа на вашия домейн.

Стойността на SPF в DNS мениджъра изглежда така:

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

Където "ip4" е IPv4 на вашия имейл сървър.

Как да задам SPF за множество домейни?

Ако искаме да упълномощим други домейни да изпращат имейл съобщения от името на нашия домейн, ще ги посочим със стойността "include”В SPF TXT:

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

Това означава, че имейл съобщенията могат да се изпращат и от името на нашия домейн до example1.com и example2.com.
Това е много полезен запис, ако имаме например такъв Shop Online На адреса"Пример1.com“, Но ние искаме съобщенията от онлайн магазина до клиентите да напуснат адрес на домейн на компанията, това е "example.com". в SPF TXT за "example.com", както е необходимо, за да посочите до IP и "include: example1.com". Така че съобщенията могат да се изпращат от името на организацията.

Как да задам SPF за IPv4 и IPv6?

Имаме пощенски сървър и с двете IPv4 и IPv6, много е важно и двата IP адреса да са посочени в SPF TXT.

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

След това след "ip" директивата "include”За добавяне на домейни, оторизирани за доставка.

Какво означава "~all","-all"А"+allОт SPF?

Както беше посочено по-горе, доставчиците (ISP) все още могат да получават имейли от името на вашата организация, дори ако са изпратени от домейн или IP, които не са посочени в SPF политиката. Тагът "всички" казва на целевите сървъри как да обработват тези съобщения от други неоторизирани домейни и да изпращат съобщения от името на вас или вашата организация.

~all : Ако съобщението е получено от домейн, който не е посочен в SPF TXT, съобщенията ще бъдат приети на целевия сървър, но ще бъдат маркирани като спам или подозрителни. Те ще бъдат обект на анти-спам филтрите на добрата практика на доставчика получател.

-all : Това е най-строгият етикет, добавен към SPF запис. Ако домейнът не е в списъка, съобщението ще бъде маркирано като неоторизирано и ще бъде отхвърлено от доставчика. То също няма да бъде доставено macв спам.

+all : Използва се много рядко и изобщо не се препоръчва, този маркер позволява на други да изпращат имейли от името на вас или вашата организация. Повечето доставчици автоматично отхвърлят всички имейл съобщения, които идват от домейни със SPF TXT."+all“. Именно защото автентичността на подателя не може да бъде проверена, освен след проверка на "заглавка на имейла".

Резюме: Какво означава рамка за политика на изпращача (SPF)?

• Деактивиране и изчистване на DNS кеша - Windows 7, Vista и XP
• Използвайте алтернативни сървъри DNS-бързо зареждане на уеб страници
• Как да променя адреса DNS в OS X
• Как да нулирате DNS кеша в OS X
• Увеличете скоростта на сърфиране в Интернет с Google Public DNS

Упълномощава чрез TXT / SPF DNS зона, IP адреси и имена на домейни, които могат да изпращат имейл съобщения от вашия домейн или компания. Той също така прилага последствията, които се отнасят за съобщения, които се изпращат от неоторизирани домейни.

Какво означава DMARC и защо е важен за вашия имейл сървър?

DMARC (Отчитане и съответствие за удостоверяване на автентичността на съобщения, базирано на домейн) е тясно свързана със стандартите на политиката SPF si DKIM.
DMARC е a система за валидиране предназначени за защита вашето име или име на имейл домейн на вашата компания, практики като имейл спуфинг и фишинг измами.

Използвайки Sender Policy Framework (SPF) и стандартите за контрол на идентифицираната поща с ключове на домейни (DKIM), DMARC добавя много важна функция. доклади.

Когато собственик на домейн публикува DMARC в областта на DNS TXT, той или тя ще получи информация за това кой изпраща имейл съобщения от негово или нейно име или компанията, която притежава домейна, защитен от SPF и DKIM. В същото време получателите на съобщенията ще знаят дали и как тези политики за най-добри практики се наблюдават от собственика на изпращащия домейн.

DMARC запис в DNS TXT може да бъде:

V=DMARC1; rua=mailto:report-id@rep.example.com; ruf=mailto:account-email@for.example.com; p=none; sp=none; fo=0;

В DMARC можете да поставите повече условия за докладване на инциденти и имейл адреси за анализ и отчети. Препоръчително е да използвате специални имейл адреси за DMARC, тъй като обемът на получените съобщения може да е значителен.

DMARC таговете могат да бъдат зададени в съответствие с правилата, наложени от вас или вашата организация:

v - версия на съществуващия DMARC протокол.
p - прилагайте тази политика, когато DMARC не може да бъде проверен за имейл съобщения. Може да има стойността: „none","quarantine"Или"reject“. Се използва "none”, за да получите отчети за потока на съобщенията и състоянието на ПИНsora.
rua - Това е списък с URL адреси, за които доставчиците на интернет услуги могат да изпращат обратна връзка в XML формат. Ако добавим имейл адреса тук, връзката ще бъде:rua=mailto:feedback@example.com".
ruf - Списъкът с URL адреси, на които интернет доставчиците могат да изпращат доклади за кибер инциденти и престъпления, извършени от името на вашата организация. Адресът ще бъде:ruf=mailto:account-email@for.example.com".
rf - Формат за докладване за киберпрестъпления. Може да се оформя"afrf"Или"iodef".
pct - Инструктира интернет доставчика да приложи политиката DMARC само за определен процент неуспешни съобщения. Например, може да имаме:pct=50%"Или политики"quarantine"А"reject“. Никога няма да бъде прието."none".
adkim – Посочете „Подравняване Mode” за DKIM цифрови подписи. Това означава, че се проверява съответствието на цифровия подпис на DKIM запис с домейна. adkim може да има стойности: r (Relaxed) Или s (Strict).
aspf - По същия начин, както в случая adkim Посочено е "подравняване". Mode” за SPF и поддържа същите стойности. r (Relaxed) Или s (Strict).
sp – Тази политика се прилага, за да позволи на поддомейните, получени от домейна на организацията, да използват стойността на DMARC на домейна. Това избягва използването на отделни политики за всяка област. Това е практически "уместен знак" за всички поддомейни.
ri - Тази стойност задава интервала, през който ще се получават XML отчети за DMARC. В повечето случаи отчитането е за предпочитане на дневна база.
fo - Опции за сигнали за измами. “съдебен options“. Те може да имат стойности на "0", за да докладват за инциденти, когато SPF и DKIM проверката не успеят, или стойността "1" за сценария, при който SPF или DKIM не съществуват или не преминават проверката.

Ето защо, за да гарантирате, че имейлите на вашата или на вашата компания достигат до входящата ви кутия, трябва да вземете предвид тези три стандарта."най-добри практики за изпращане на имейли". DKIM, SPF si DMARC. И трите стандарта са свързани с DNS TXT и могат да се управляват от DNS мениджъра на домейна.