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

Администраторите на Тежък частен имейл за бизнес Често се сблъсква с много проблеми и предизвикателства. От вълните на Спам да бъдат блокирани от конкретни филтри, Сигурността на кореспонденцията В локалния имейл сървър и отдалечени сървъри, Конфигуриране и Мониторинг на SMTP услуги, Поп, Imap, плюс много и много други подробности за Конфигурация SPF, DKIM и DMARC да се съобразява с добрите практики на сигурна доставка по имейл.

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

Така че от име на домейн имейлите могат да бъдат изпратени, то трябва да бъде HOSTAT на имейл сървър конфигуриран правилно, отново Име на домейн, за да има DNS области за Spf, Mx, DMARC И Dkim Задайте правилно в мениджъра DNS TXT на домейна.

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

Съобщенията, изпратени до @gmail.com, се отхвърлят автоматично. “Доставката по пощата не бе успешна: Връщане на съобщение до подателя”

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

Съобщение за грешка, върнато на имейл сървъра на Exim изглежда както следва:

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

В този сценарий няма нещо много сериозно, като Включително името на домейна на доставка или IP подател в спам списък глобален или o Основна грешка в конфигурацията на услуги за електронна поща на Sevrer (Exim).
Дори и много, когато видя това съобщение, незабавно с мисълта към спам или грешка в конфигурацията на SMTP, проблемът се генерира от областта 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, в нашия сценарий.

При добавяне на уеб домейн с активна услуга за електронна поща на CPanel или VestACP, файловете в DNS областта на съответния домейн също се създават автоматично. DNS зона, която съдържа, включително конфигурацията на услугата за електронна поща: Mx, Spf, Dkim, DMARC.
В ситуацията, в която избираме домейна, който да бъде на мениджъра DNS CloudFlare, DNS областта на хостинг акаунта на съответния домейн, трябва да се копира в облака, така че областта на електронната поща да работи правилно. Това беше проблемът в горния сценарий. В DNS Tert Manager няма DKIM регистрация, въпреки че тя съществува на DNS мениджъра на локалния сървър.

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

Domainkeys идентифицирана поща (DKIM) Това е стандартно решение за удостоверяване на имейл домейн, който добавя Цифров подпис на всяко изпратено съобщение. Дестинационните сървъри могат да проверят през DKIM дали съобщението идва от закона на подателя, а не от друга област, която използва самоличността на подателя като маска. По смисъла на всички, ако имате домейна abcdqwerty.com Без DKIM съобщенията по електронната поща от други сървъри могат да бъдат изпратени с помощта на вашето име на домейн. Ако искате кражба на самоличност, което в техническо отношение се нарича Имейлна подправка.
Обща техника, когато се изпращат електронни съобщения на електронната поща фишинг и спам.

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

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

Пример за DKIM е:

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

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

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

“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 и защо е важно за безопасната доставка на имейл съобщения?

Точно като DKIM, и Spf има цел да предотврати Mesajele Phishing и Имейлна подправка. По този начин изпращаните съобщения вече няма да бъдат маркирани като спам.

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

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

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

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

@ : "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.
Това е много полезен запис, ако имаме пример a Списание онлайн на адреса “Пример1.com“, но ние искаме съобщенията от онлайн магазина до клиентите да напуснат Адрес на домейна на компанията, това битие “example.com“. В SPF TXT за “example.com”, че трябва да посочим с IP и “Включете: Пример1.com”. Така че съобщенията могат да бъдат изпратени от името на организацията.

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

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

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

След това, след “IP” Може да се използва директива “include” За да добавите оторизирани полета за изпращане.

Какво означава това “~all“, “-all” и “+all” Ale SPF?

Както казах по-горе, доставчикът (ISP) все още може да получава електронни съобщения от името на вашата организация. Дори ако те са изпратени от домейн или IP, който не е посочен в политиката на SPF. Етикет “Всички” Кажете на дестинацията сървърите как да третират тези съобщения от други области, които не са разрешени, и изпращайте съобщения от името на вас или организацията.

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

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

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

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

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

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

Какво означава DMARC и защо е важен за електронната поща сървър?

DMARC (Отчитане и съответствие на съобщения, базирани на домейни) е тясно свързана със стандартите на политиката Spf и Dkim.
DMARC ESTE a система за валидиране замислени за защита Името на вашия домейн за електронна поща на вашата или компания, на практики като подправяне на имейл и Фишинг измами.

Използване на SPF (Рамка на политиката на подателите) и DKIM (Идентифицирани поща на домейни) Добавят много важна функция. доклади.

Когато собственик на домейн публикува 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 – Показва доставчика на интернет / ISP, за да приложи политиката на DMARC само за определен процент от неуспешни съобщения. Например, можем да имаме: “pct=50%” или политики “quarantine” и “reject“. Никога няма да бъде приет “none“.
adkim – Специфично “Режим на подравняване” За DKIM цифрови подписи. Това означава, че цифровият подпис на DKIM вход с домейна се проверява. adkim може да има стойности: r (Relaxed) или s (Strict).
aspf – По същия начин, както в случая на adkim се определя “Режим на подравняване” За SPF и поддържайте същите стойности. r (Relaxed) или s (Strict).
sp – Тази политика се прилага, за да се позволи поддомейни, получени от областта на организацията, да се използва стойността на домейна. Това избягва използването на отделни политики за всяка област. Това е практически едно “Wildcard” За всички под -кодове.
ri – Тази стойност задава интервала, в който ще бъдат получени отчети за XML за DMARC. През повечето време отчитането е за предпочитане да се прави ежедневно.
fo – Опции за доклади за измами. “Криминалистични опции“. Те могат да имат стойностите “0” За да отчитате инциденти, когато не успявате както SPF, така и DKIM, или стойност “1” За сценария, при който SPF или DKIM не съществуват или не проверяват.

Така че, за да сте сигурни, че вашите имейл съобщения или компанията пристигат на получателите на Inbox, трябва да вземете предвид тези три стандарта на “Добра практика за изпращане на електронни съобщения“. Dkim, Spf и DMARC. Всички тези три стандарта са свързани с DNS TXT и могат да се управляват от DNS мениджъра на полето.