DNS за имейл: записи, настройка и доставяне

Начало » Питон » DNS за имейл: записи, настройка и доставяне

Имейлът разчита много повече на DNS, отколкото повечето хора осъзнаватВсеки път, когато натиснете „Изпрати“, цяла верига от DNS търсения тихомълком решава дали съобщението ви ще достигне до входящата поща, ще попадне в спама или ще бъде блокирано напълно. Ако вашият DNS за имейл е конфигуриран неправилно, дори най-добрата кампания или най-важното транзакционно съобщение може просто да изчезне.

Ако DNS ви се струва мистериозен или прекалено технически, не сте самиМного опитни ИТ специалисти все още смятат, че хостингът на уебсайтове и имейлът трябва да се намират на един и същ сървър, когато DNS всъщност ви позволява да разделяте услугите по какъвто и да е начин. Добрата новина: след като разберете основните DNS записи за имейл – MX, SPF, DKIM, DMARC и няколко други – можете да изградите солидна, сигурна и лесно доставяема имейл система, която до голяма степен работи самостоятелно.

Какво е DNS и защо е важен за имейла

DNS (Domain Name System) е адресната книга в интернетХората харесват имена като yourcompany.comно компютрите общуват, използвайки IP адреси като 203.0.113.10 or 2001: db8 :: 1DNS преобразува домейна в тези числови адреси, така че браузърите, приложенията и пощенските сървъри да знаят къде да се свържат.

Когато въведете домейн в браузър, DNS търсенето започва едно малко пътешествиеУстройството ви пита рекурсивен резолвер (обикновено управляван от вашия интернет доставчик или публичен DNS като Google или Cloudflare), който може вече да има кеширан отговор. Ако не, резолверът обхожда верига от сървъри: коренен сървър за имена, тогава TLD сървър за имена (за .com, .net, .org и др.) и накрая авторитетен сървър за имена за този конкретен домейн. Този последен сървър съхранява DNS записите, които казват на интернет как да обработва трафика за домейна.

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

Как имейлите преминават през DNS

Всеки изходящ имейл стартира поне едно DNS търсенеКогато някой изпрати съобщение до потребител@вашатакомпания.com, изпращащият пощенски сървър пита DNS: „Кой сървър обработва пощата за този домейн?“ Той търси MX записи първо. Ако съществуват, те сочат към имената на домейните на получаващите пощенски сървъри. Ако MX записи не съществуват, повечето системи се връщат към домейна Запис A или AAAA, но това не се препоръчва за професионална настройка.

Доставимостта и сигурността изискват повече от това просто да знаете къде да изпратите имейлаСъвременните приемащи сървъри също така запитват DNS за SPF (Рамка на политиката на подателя), DKIM (Поща, идентифицирана от DomainKeys) и по избор DMARC (Удостоверяване, отчитане и съответствие на съобщения, базирани на домейн). Тези записи казват на получателя дали съобщението наистина идва от оторизиран източник и как да третира подозрителни съобщения.

Зад кулисите, няколко различни типа сървъри си сътрудничат, за да преместват съобщениятаИзходящата поща обикновено тръгва чрез SMTP сървър (Simple Mail Transfer Protocol), който работи с агент за прехвърляне на поща (MTA), за да прехвърли съобщението през интернет. От страната на получателя, потребителите получават поща, използвайки или POP3 (което обикновено изтегля и премахва поща от сървъра) или IMAP (който съхранява съобщенията на сървъра и синхронизира между устройствата). Всички тези компоненти разчитат на DNS записи, за да знаят с кои имена на хостове и IP адреси да се свържат.

Основни типове DNS записи, които трябва да знаете за имейл

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

A и AAAA записи: съпоставяне на вашия домейн с IP адреси

А-записът свързва домейн с IPv4 адрес (например, 93.184.216.34). Без поне един валиден A запис, вашият домейн на практика не съществува в интернет. Много услуги разчитат на него и когато MX запис липсва или е неправилно конфигуриран – нещо, което искате да избегнете, като публикувате правилни MX записи.

Записът AAAA е IPv6 еквивалентът на записа A.Той съпоставя домейна с IPv6 адрес, което е все по-важно с изчерпването на IPv4 пространството. Въпреки че A и AAAA не определят къде трябва да се доставя пощата, те свързват вашия домейн с реална инфраструктура и могат да се използват за резервно маршрутизиране на поща, ако липсват MX записи.

MX записи: казваме на света къде да доставя поща

MX (Mail Exchange) записите са крайъгълният камък на DNS за имейлТе декларират кои сървъри приемат входящи съобщения за вашия домейн. Всеки MX запис съдържа приоритет (число, при което по-ниското е по-предпочитано) и a име на хост (не суров IP адрес) на пощенския сървър. Приемащите сървъри сортират MX записите по приоритет и ги изпробват по ред, което ви осигурява вградена резервираност.

Домейнът може да използва само един MX запис, но силно се препоръчва използването на няколко записа. за устойчивост. Много хоствани имейл решения, като Microsoft 365 или Google Workspace, предоставят една основна MX стойност, но големите инфраструктури често публикуват няколко MX записа с различни приоритети, така че ако един сървър не работи, друг все още може да приема поща.

Когато конфигурирате MX записи, вашият DNS доставчик няма да измисли стойноститеВашият имейл доставчик ви предоставя точните имена на хостове, приоритети и всички специални изисквания. В контролния панел на DNS обикновено задавате: хост или име (често @ за главния домейн), приоритетен номер, името на хоста на пощенския сървър (като smtp.provider.com) и TTL (време за живот), което контролира кеширането.

TXT записи: контейнерът за съвременна сигурност на имейлите

TXT записите съхраняват произволен текст, прикачен към вашия домейнИмейл системите ги използват активно за политики и данни за удостоверяване. SPF и DMARC се намират в TXT записи, а DKIM често прави същото (въпреки че някои доставчици предоставят DKIM чрез CNAME).

Тъй като TXT записите могат да съдържат всичко, те се използват и за проверки на собствеността на домейн. (например от доставчици на електронни платформи, уеб услуги или доставчици на SSL), както и за разширени функции като опортюнистични подсказки за криптиране и индикатори за марка BIMI. За изпращачите на имейли трите ключови механизма, базирани на TXT, са SPF, DKIM и DMARC.

SPF: оторизиране на сървърите, които могат да изпращат поща за вашия домейн

SPF е рамка за удостоверяване на имейли, която отговаря на един въпрос„Разрешено ли е на този IP адрес или сървър да изпраща имейли, използвайки този домейн в адреса на отправителя?“ Публикувате политиката си като TXT запис, който обикновено започва с v = spf1 и завършва с уточнение като например -всичко, ~всички или всички.

Една проста SPF политика може да разрешава поща само от собствените MX хостове на вашия домейн.Пример изглежда така: „v=spf1 mx -всички“Този ред казва на получателите да приемат поща от IP адреси, използвани от вашите MX записи, и да третират всички други източници като неоторизирани. Ако изпращате и чрез инструменти за бюлетини, CRM или облачни услуги, разширявате политиката с include декларации за SPF домейна на всеки доставчик.

Типични SPF политики за множество услуги, свързващи няколко включвания в един записНапример, ако изпращате от основния си доставчик плюс платформа за помощ и услуга за транзакционна електронна поща, може да получите нещо подобно: v=spf1 a mx include:service1.com include:service2.com ~allВашите имейл платформи обикновено ще предоставят точните низове и синтаксис, които трябва да добавите.

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

DKIM: подписване на съобщения с криптографски пръстов отпечатък

DKIM (DomainKeys Identified Mail) осигурява подпис, защитен от неправилно отваряне върху изходящи съобщения. Вашата система за изпращане използва частен криптографски ключ, за да създаде хеш въз основа на определени заглавки, а понякога и на тялото на съобщението. Този подпис се поставя в специално поле на заглавката на имейла.

Съответният публичен ключ се намира в DNSDKIM селектор (малък етикет като поща or mlsend2) плюс домейнът образуват името на хоста за записа на публичния ключ, често нещо подобно selector._domainkey.yourcompany.comКогато приемащата система получи имейл, тя преглежда DKIM заглавката, запитва DNS за този селектор, извлича публичния ключ и проверява дали подписът е валиден и дали съдържанието не е било променено.

DKIM може да бъде публикуван като TXT или CNAME записМного доставчици ви дават голяма TXT стойност, започваща с v=DKIM1 и дълго p= поле, съдържащо публичния ключ, кодиран в base64. Други ви молят да създадете CNAME запис, сочещ от името на вашия селекторен хост към такъв, който те хостват, което им позволява да ротират ключовете централно, без да е необходимо да редактирате DNS всеки път.

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

DMARC: обвързване на SPF и DKIM с политика

DMARC (Domain-based Message Authentication, Reporting & Conformance) се намира върху SPF и DKIMНе удостоверява съобщенията директно; вместо това проверява дали преминават SPF и/или DKIM и дали тези резултати съответстват на видимия домейн „От“. След това прилага дефинирана от вас политика, за да определи какво трябва да се случи, ако проверките са неуспешни.

DMARC политиката се намира в TXT запис на специалното име на хост. _dmarc.вашатакомпания.comЗаписът започва с v=DMARC1 и включва тагове като p= (политика: няма, карантина или отхвърляне) и опции за докладване на адреси. С DMARC можете да инструктирате получателите просто да наблюдават (без прилагане), да изпращат неуспешните съобщения към спам или директно да ги блокират.

Функциите за отчитане на DMARC са скрит скъпоценен камък за сигурност и доставянеЧрез посочване на адреси в улица намлява RUF тагове, вие искате от получаващите доставчици да ви изпращат обобщени или криминалистични отчети за резултатите от удостоверяването. Тези отчети ви помагат да откриете неоторизирани податели, неправилно конфигурирани услуги или домейни, злоупотребявани за фишинг.

Други DNS записи, които влияят на имейла

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

PTR (обратен DNS): валидиране на изпращащия IP адрес

PTR записът извършва обратното действие на нормалното DNS търсене.Вместо да съпоставя име на домейн с IP адрес, той съпоставя IP адрес обратно с име на хост. Това обратно съпоставяне се нарича обратен DNS или rDNS.

Получаващите пощенски сървъри рутинно проверяват обратния DNS на изпращащите IP адреси.Ако няма PTR запис или името на хоста, което връща, не съвпада разумно с домейна в заглавките на имейла, някои доставчици третират съобщението като подозрително. Това може да предизвика грешки като „Reverse DNS failed“ (Неуспешно обратно DNS) или да доведе до отхвърляне на имейли с кодове, отнасящи се до липсващ PTR.

На практика рядко управлявате PTR записи в обичайната си DNS зона.Те се контролират от този, който притежава IP диапазона – често вашият интернет доставчик, доставчик на хостинг услуги или имейл платформа. За специализирани пощенски сървъри обикновено изисквате доставчикът да настрои PTR, сочещ към избраното от вас име на хост, и след това да се уверите, че това име на хост също има съответстващ A или AAAA запис.

SRV, NS и SOA: поддържаща инфраструктура за последователна доставка

SRV (сервизни) записи описват хоста и порта за специфичен протоколЗа имейл, те могат да насочват клиентите към правилните SMTP, IMAP или POP сървъри и портове. Въпреки че не контролират директно доставяемостта, SRV записите помагат на инструментите за автоматично конфигуриране да откриват правилните крайни точки.

NS (Name Server) записите определят кои нейм сървъри са авторитетни за вашия домейнТези сървъри съхраняват и отговарят с вашите DNS данни. Ако NS записите са грешни, несъответствието между DNS доставчиците може да доведе до непредсказуемо поведение на пощата, тъй като някои податели може да видят остарели или непълни записи.

SOA (Start of Authority) записът идентифицира основния сървър за имена за зоната и предоставя подробности като серийния номер на файла на зоната и стойностите за време, използвани за кеширане и обновяване. Той не контролира директно логиката на имейла, но правилната SOA конфигурация е от съществено значение за надеждното репликация и разпространение на промените, свързани с имейла.

BIMI и TLSA: усъвършенствани сигнали за доверие и криптиране

BIMI (Индикатори на марката за идентифициране на съобщения) ви позволява да показвате логото си в съвместими пощенски кутииТехнически, той използва TXT запис, който сочи към SVG изображение на вашето лого и в много случаи зависи от проверени сертификати за марката и наложена DMARC политика. Въпреки че самият BIMI няма да реши проблеми с доставяемостта, той е визуален сигнал за доверие и може да подобри ангажираността, след като удостоверяването ви вече е стабилно.

TLSA записите поддържат DANE (DNS-базирано удостоверяване на именувани обекти), който свързва TLS сертификатите с DNS имена чрез DNSSEC. За имейл, TLSA може да защити STARTTLS връзките между пощенските сървъри, като посочи кои сертификати са валидни. Това помага за предотвратяване на атаки от типа „човек по средата“ срещу SMTP, въпреки че на практика изисква DNSSEC и все още е по-рядко срещан от SPF/DKIM/DMARC.

Конфигуриране на DNS за вашия доставчик на имейл

По-голямата част от тежката работа се извършва от вашия имейл хост, който предоставя точните DNS записи, които трябва да добавите. Вашата задача е да копирате тези стойности в правилните типове записи при вашия регистратор на домейни или DNS хост и да проверите отново за правописни грешки.

Стъпка по стъпка: добавяне и проверка на MX записи

За да насочите имейла на вашия домейн към конкретен доставчик, започнете с MX записиСлед като се регистрирате за хоствана имейл или облачна платформа, потърсете тяхната документация за „DNS настройки“ или „записи за обмен на поща“. Те ще изброят имената на хостовете и приоритетите, които трябва да използвате.

В конзолата за управление на DNS намерете опцията за добавяне на нов запис и изберете тип MXЗа хоста или името, домейните обикновено използват @ да представи корена (например, yourcompany.com). Поставете името на хоста на пощенския сървър като стойност, задайте необходимия приоритет, запазете TTL по подразбиране, освен ако не е указано друго, след което запазете. Повторете за всички допълнителни MX записи, които предоставят.

След като MX записите бъдат запазени, ще има период на разпространениеDNS кешовете в интернет се нуждаят от време, за да изтекат старите данни. Очаквайте от няколко минути до няколко часа — понякога до 24-48 часа — новото маршрутизиране на пощата да стане видимо навсякъде. През този период някои податели все още може да доставят до старата дестинация.

Публикуване на SPF във вашия DNS

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

Повечето доставчици ви показват точния SPF фрагмент, от който се нуждаетеНапример, платформата за изпращане може да каже: „Добавяне на TXT запис с име @ и стойност v=spf1 включва:_spf.example.com ~всички„Ако вече имате SPF запис, обединете новото включване с него, вместо да създавате втори запис със същото име.“

Изборът между -all и ~all влияе върху това колко стриктно приемниците третират неуспехите.Тежък провал (-всичко) казва, че всеки източник на изпращане, който не е изрично посочен, трябва да бъде отхвърлен, докато мек неуспех (~всички) обикновено пропуска съобщения, но може да ги маркира като спам. Много организации започват с „меки грешки“, докато одитират всичките си системи за изпращане, след което с течение на времето преминават към по-строги политики.

Добавяне на DKIM ключове от вашите доставчици

Настройката на DKIM обикновено е лесна, след като намерите правилния екран в таблото за управление на вашия доставчик.Потърсете секции с етикети „удостоверяване на домейн“, „DKIM“ или „подписване на имейли“. Ще видите един или повече селектори и TXT стойности или CNAME цели.

Ако вашият доставчик предоставя TXT запис, създайте DNS запис на името на хоста на селектора. (например, selector._domainkey.yourcompany.com) и поставете дългия DKIM низ, който предоставят. Ако вместо това поискат CNAME, ще насочите името на хоста на вашия селектор към тяхното, като по този начин ефективно ще кажете на света да извлече ключа директно от DNS на вашия доставчик.

Много услуги изискват да кликнете върху бутона „Проверка“ или „Проверка на DNS“ след като добавите DKIM. Това задейства търсене от тяхна страна; след като видят правилния ключ, ще започнат да подписват изходящата поща. Докато тази проверка не премине, съобщенията може да се изпращат без DKIM, което отслабва вашата история за удостоверяване.

Безопасно внедряване на DMARC политики

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

Един основен DMARC запис може да изглежда като TXT на адрес _dmarc.yourcompany.com със стойност като например v=DMARC1; p=няма; rua=mailto:reports@yourcompany.comСлед като анализирате отчетите и отстраните евентуални пропуски, можете да повишите нивото на политиката до карантина (изпращане на подозрителни имейли до спам) и евентуално до отхвърли ако искате максимална защита срещу подправяне.

Много имейл клиенти, особено големите доставчици, вече очакват домейните, изпращащи значителни обеми, да имат настроен DMARCВ комбинация с правилно конфигурирани SPF и DKIM, силната DMARC политика е един от най-ясните сигнали, че вашият домейн се управлява добре и не е източник на злоупотреба.

DNS-базирано предотвратяване на спам и репутация на подателя

Съвременните спам филтри разчитат в голяма степен на DNS данни, за да преценят дали да се доверят на даден имейлТе разглеждат MX, SPF, DKIM, DMARC, PTR и дори съгласуваността на A и NS записите, когато решават какво да правят с всяко съобщение.

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

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

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

Отстраняване на често срещани проблеми с имейла, причинени от DNS

Когато пощата не работи, DNS често е виновникътСимптомите варират – от връщане на съобщения с цифрови SMTP кодове до съобщения, които тихо изчезват в спама – но в много случаи първопричината се крие в липсващ или невалиден DNS запис.

Отхвърляне на имейли или пълно отхвърляне

Трудните откази с кодове като 550, 554 или грешки, споменаващи невалидни домейни, обикновено сочат към проблеми с DNS конфигурацията.Два чести нарушителя са липсващите MX записи и SPF политиките, които не включват действителния IP адрес или услуга на изпращача.

Ако грешката е за „няма A или MX запис“ или „невалиден домейн на имейла“, прегледайте зоната сиУверете се, че домейнът в адреса на изпращача има работещ A запис, поне един MX запис, сочещ към разрешимо име на хост, и че самите тези имена на хостове имат валидни A или AAAA записи. Всяка печатна грешка в имената на хостове може да прекъсне веригата.

Отхвърлянията, отнасящи се до грешки в обратния DNS или IP адреси в черния списък, често водят до PTR записи.Проверете дали вашият изпращащ IP адрес има PTR, който се разрешава към име на хост, което контролирате, и дали това име на хост от своя страна има съответстващ A запис. Ако не, отворете заявка при вашия доставчик на имейл или хостинг услуги и ги помолете да коригират обратния DNS.

Съобщенията постоянно попадат в папките за спам

Ако съобщенията ви се доставят, но постоянно попадат в нежелана поща, първо проверете стека си за удостоверяване.Използвайте онлайн инструменти, за да проверите SPF, DKIM и DMARC за вашия домейн. Всякакви неуспехи или предупреждения са индикация, че получаващите пощенски системи не се доверяват напълно на вашия трафик.

Проверете дали домейнът във видимия адрес на „От“ съвпада с вашите SPF и DKIMЗа SPF домейнът на подателя на плика (Return-Path) трябва да бъде оторизиран. За DKIM стойността d= в заглавката на DKIM трябва да е домейн, който притежавате, и в идеалния случай да съвпада или да се подравнява с домейна From. DMARC след това оценява това подравняване, когато решава как да оцени съобщението.

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

Уеб формуляри или приложения, изпращащи имейли, които никога не пристигат

Когато формулярите за контакт на уебсайтове или приложенията изглеждат сякаш „изпращат“ имейл, но нищо не пристига, SPF често е неправилно конфигуриран.IP адресът на уеб сървъра или пощенската програма на платформата може да не са включени във вашия SPF запис, така че получателите третират съобщенията като подозрителни или ги отхвърлят направо.

Ако вашият сайт изпраща имейли, използвайки домейна на основния ви доставчик на пощенски кутии, потвърдете, че действителният изпращащ сървър (например вашият уеб хост или транзакционен ESP) се появява в SPF политиката. В някои случаи е по-добре да използвате специален поддомейн и конфигуриран ESP, вместо да разчитате на функцията за поща по подразбиране на уеб хоста.

Справяне със забавяния на разпространението на DNS

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

Ако планирате голяма миграция на имейли, намалете TTL-тата ден или два предварително.Намаляването на TTL до около 300 секунди за ключови записи прави бъдещите промени разпространяващи се по-бързо. След като превключването се стабилизира, можете да увеличите TTL отново за по-висока производителност и по-малко заявки.

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

Обединявайки всичко, DNS за имейл е по-малко въпрос на магия и повече на внимателно координирани записи.Когато MX, SPF, DKIM, DMARC, PTR и поддържащите записи са точни и последователни, вашият домейн се превръща в надежден подател в очите на доставчиците на поща. Това доверие, съчетано с изчистени списъци и внимателно обмислено съдържание, е това, което предпазва съобщенията ви във входящата поща и вашата марка от папките за спам.