- Исправни MX, A/AAAA и PTR записи осигуравају да се имејл усмерава и идентификује на исправне поштанске сервере.
- SPF, DKIM и DMARC у TXT записима аутентификују пошиљаоце и дефинишу како се рукује сумњивом поштом.
- Подржавање DNS записа као што су NS, SOA, SRV, TLSA и BIMI побољшава доследност, безбедност и поверење у бренд.
- Већина проблема са испоруком потиче од погрешно конфигурисаног DNS-а, кашњења у пропагацији или недостајуће аутентификације.

Е-пошта се много више ослања на DNS него што већина људи схватаСваки пут када притиснете дугме Пошаљи, читав ланац DNS претрага тихо одлучује да ли ће ваша порука стићи до пријемног сандучета, завршити у непожељној пошти или бити потпуно блокирана. Ако је ваш DNS за е-пошту погрешно конфигурисан, чак и најбоља кампања или најважнија трансакциона порука могу једноставно нестати.
Ако вам се DNS чини мистериозним или превише техничким, нисте самиМноги искусни ИТ стручњаци и даље мисле да веб хостинг и имејл морају да се налазе на истом серверу, док вам DNS заправо омогућава да поделите сервисе како год желите. Добра вест: када једном разумете основне DNS записе за имејл – MX, SPF, DKIM, DMARC и још неколико – можете да направите чврсту, безбедну и високо испоручиву поставку имејла која се углавном сама покреће.
Шта је DNS и зашто је важан за е-пошту
DNS (систем имена домена) је адресар на интернетуЉуди воле имена као што су yourcompany.com, али рачунари комуницирају користећи IP адресе као што су 203.0.113.10 or 2001: дб8 :: 1DNS конвертује домен у те нумеричке адресе како би прегледачи, апликације и поштански сервери знали где да се повежу.
Када унесете домен у прегледач, DNS претрага започиње мало путовањеВаш уређај пита рекурзивни разрешивач (обично га води ваш интернет провајдер или јавни DNS као што су Google или Cloudflare), који можда већ има кеширан одговор. Ако не, резолвер пролази кроз ланац сервера: коренски именски сервер, затим TLD именски сервер (за .com, .net, .org, итд.), и коначно ауторитативни сервер имена за тај одређени домен. Тај последњи сервер чува DNS записе који говоре интернету како да обрађује саобраћај за тај домен.
Потпуно иста ствар се дешава када је у питању имејлСервери који шаљу пошту упућују DNS-у захтеве да би утврдили три важне ствари: где да испоручују пошту за домен, којим серверима је дозвољено да шаљу са тог домена и да ли су поруке аутентичне или фалсификоване. Ако ти DNS записи недостају, погрешни су или непотпуни, видећете одбијене поруке, смештај у фолдер за нежељену пошту или оштећену репутацију пошиљаоца.
Како е-пошта тече кроз DNS
Свака одлазна е-пошта покреће барем једну ДНС претрагуКада неко пошаље поруку korisnik@vasakompanija.com, сервер који шаље пошту пита DNS: „Који сервер обрађује пошту за овај домен?“ Тражи MX записи прво. Ако постоје, они указују на имена домена пријемних поштанских сервера. Ако MX записи не постоје, већина система се враћа на имена домена А или АААА запис, али то се не препоручује за професионално подешавање.
Достављивост и безбедност захтевају више од пуког знања где послати поштуМодерни пријемни сервери такође упућују захтеве DNS-у за заштитни фактор (Оквир политике пошиљаоца), ДКИМ (Пошта идентификована помоћу кључева домена) и опционо ДМАРЦ (Аутентификација, извештавање и усаглашеност порука заснована на домену). Ови записи говоре примаоцу да ли порука заиста долази из овлашћеног извора и како да поступа са сумњивим порукама.
Иза кулиса, неколико различитих типова сервера сарађује како би премештали порукеОдлазна пошта обично одлази путем СМТП сервер (Simple Mail Transfer Protocol), који сарађује са агентом за пренос поште (Mail Transfer Agent, MTA) како би слао поруку преко интернета. На страни пријема, корисници преузимају пошту користећи било који од ПОПКСНУМКС (који обично преузима и уклања пошту са сервера) или ИМАП (који чува поруке на серверу и синхронизује их на свим уређајима). Све ове компоненте се ослањају на DNS записе да би знале која имена хостова и IP адресе да контактирају.
Основни типови DNS записа које морате знати за е-пошту
Нису сви DNS записи директно повезани са имејлом, али неколико њих је апсолутно неопходно. за рутирање, аутентификацију и филтрирање нежељене поште. Други играју споредну улогу у поузданости и поверењу.
А и АААА записи: мапирање вашег домена на ИП адресе
А запис повезује домен са IPv4 адресом (на пример, 93.184.216.34). Без барем једног важећег А записа, ваш домен ефикасно не постоји на интернету. Многи сервиси се такође ослањају на њега када MX запис недостаје или је погрешно конфигурисан — нешто што желите да избегнете објављивањем исправних MX записа.
AAAA запис је IPv6 пандан A записа.Мапира домен на IPv6 адресу, што је све важније како IPv4 простор истиче. Иако A и AAAA не дефинишу где пошта треба да се доставља, они повезују ваш домен са стварном инфраструктуром и могу се користити за резервно усмеравање поште ако MX записи недостају.
MX записи: обавештавање света где да доставља пошту
MX (Mail Exchange) записи су темељ DNS-а за е-поштуОни декларишу који сервери прихватају долазне поруке за ваш домен. Сваки MX запис садржи приоритет (број где је нижи пожељнији) и хоста (не сирова 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 записи могу да садрже било шта, користе се и за проверу власништва над доменом (на пример од стране ESP-ова, веб сервиса или SSL провајдера), као и за напредне функције попут опортунистичких савета за шифровање и BIMI индикатора бренда. За пошиљаоце имејлова, три кључна механизма заснована на TXT-у су SPF, DKIM и DMARC.
SPF: ауторизација сервера који могу слати пошту за ваш домен
SPF је оквир за аутентификацију е-поште који одговара на једно питање„Да ли је овој IP адреси или серверу дозвољено слање поште користећи овај домен у адреси пошиљаоца?“ Објављујете своју политику као TXT запис који обично почиње са в=спф1 и завршава се квалификатором као што је -све, ~све, Или све.
Једноставна SPF политика може дозволити пошту само са MX хостова вашег доменаПример изгледа овако: „v=spf1 mx -све“Тај ред обавештава примаоце да прихвате пошту са IP адреса које користе ваши MX записи и да третирају све остале изворе као неовлашћене. Ако шаљете и путем алата за билтен, CRM-ова или услуга у облаку, проширујете политику са обухватити изјаве за SPF домен сваког провајдера.
Типичне SPF политике за више сервиса повезују неколико укључивања у један записНа пример, ако шаљете са свог главног провајдера плус платформу за помоћ корисницима и трансакциону имејл услугу, могли бисте добити нешто попут: v=spf1 a mx include:service1.com include:service2.com ~свеВаше платформе за е-пошту ће обично пружити тачне стрингове и синтаксу које морате да додате.
Важно је одржавати један SPF TXT запис по доменуСлагање више SPF записа на истом DNS имену може да поквари валидацију. Уместо тога, спојите све потребне механизме у једну пажљиво управљану политику и ажурирајте је сваки пут када додајете или уклањате сервисе за слање.
DKIM: потписивање порука криптографским отиском прста
DKIM (DomainKeys Identified Mail) пружа потпис који је заштићен од неовлашћеног мењања на одлазним порукама. Ваш систем за слање користи приватни криптографски кључ за креирање хеша на основу одређених заглавља, а понекад и тела поруке. Овај потпис се уноси у посебно поље заглавља имејла.
Одговарајући јавни кључ се налази у DNS-уDKIM селектор (мала ознака као пошта 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 (аутентификација, извештавање и усаглашеност порука заснована на домену) налази се на врху SPF-а и DKIM-аНе аутентификује поруке директно; уместо тога, проверава да ли пролазе SPF и/или DKIM и да ли се ти резултати поклапају са видљивим доменом „Од“. Затим примењује политику коју дефинишете да бисте утврдили шта треба да се деси ако провере не успеју.
DMARC политика се налази у TXT запису на посебном имену хоста _dmarc.vasakompanija.comЗапис почиње са v=DMARC1 и укључује ознаке као што су p= (политика: нема, карантин или одбијање) и опције за пријављивање адреса. Помоћу DMARC-а можете да наложите примаоцима да једноставно прате (без спровођења), да шаљу неуспехе у спам или да их директно блокирају.
DMARC-ове функције извештавања су скривени драгуљ за безбедност и испорукуНавођењем адреса у улица трљати ознаке, тражите од прималаца да вам пошаљу збирне или форензичке извештаје о резултатима аутентификације. Ови извештаји вам помажу да откријете неовлашћене пошиљаоце, погрешно конфигурисане услуге или домене који се злоупотребљавају за фишинг.
Остали DNS записи који утичу на имејл
Поред MX, SPF, DKIM и DMARC, још неколико типова DNS записа утиче на то да ли је вашој пошти поуздан и да ли се успешно испоручује.Можда нису строго обавезни, али се често појављују у листама за испоруку и логици против нежељене поште.
PTR (обрнути DNS): валидација IP адресе слања
PTR запис обавља обрнути поступак од нормалне DNS претрагеУместо мапирања имена домена на IP адресу, мапира IP адресу назад на име хоста. Ово обрнуто мапирање се назива обрнути ДНС или рДНС.
Пријемни поштански сервери рутински проверавају обрнути DNS пошиљалачке IP адресеАко нема PTR записа или име хоста које враћа не одговара домену у заглављима имејла, неки провајдери третирају поруку као сумњиву. То може изазвати грешке попут „Обрнути DNS није успео“ или довести до одбијања поште са кодовима који се односе на недостајући PTR.
У пракси, ретко управљате PTR записима у својој редовној DNS зони.Њих контролише онај ко је власник IP опсега — често ваш интернет провајдер, провајдер хостинга или платформа за е-пошту. За наменске мејл сервере, обично захтевате да провајдер подеси PTR који указује на ваше изабрано име хоста, а затим осигурате да то име хоста такође има одговарајући A или AAAA запис.
SRV, NS и SOA: пратећа инфраструктура за конзистентну испоруку
SRV (Service) записи описују хост и порт за одређени протоколЗа имејл, могу усмерити клијенте ка исправним SMTP, IMAP или POP серверима и портовима. Иако не контролишу директно испоруку, SRV записи помажу алатима за аутоматску конфигурацију да открију исправне крајње тачке.
NS (Name Server) записи дефинишу који су name сервери ауторитативни за ваш доменОви сервери чувају и одговарају на ваше 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 записимаНакон што се региструјете за хостовану имејл или cloud платформу, потражите њихову документацију о „DNS подешавањима“ или „записима размене поште“. Они ће навести имена хостова и приоритете које морате користити.
У конзоли за управљање DNS-ом пронађите опцију за додавање новог записа и изаберите тип MXЗа хост или име, домени обично користе @ да представља корен (на пример, yourcompany.com). Налепите име хоста поштанског сервера као вредност, подесите приоритет који им је потребан, задржите подразумевани TTL осим ако није другачије назначено, а затим сачувајте. Поновите за све додатне MX записе које доставе.
Када се MX записи сачувају, постојаће период пропагацијеДНС кеш меморијама широм интернета потребно је време да истекну стари подаци. Очекујте од неколико минута до неколико сати — понекад и до 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-а вашег провајдера.
Многе услуге захтевају да кликнете на дугме „Верификуј“ или „Провери ДНС“ након што додате 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 адресу или услугу пошиљаоца.
Ако се грешка односи на „нема А или MX записа“ или „неважећи домен поште“, прегледајте своју зонуПотврдите да домен у адреси пошиљаоца има важећи А запис, барем један MX запис који указује на име хоста које се може решити и да сама имена хостова имају важеће А или AAAA записе. Било каква грешка у именима хостова може прекинути ланац.
Одбијања која се односе на грешке обрнутог DNS-а или црне листе IP адреса често воде порекло до PTR записаПроверите да ли ваша IP адреса са које пошаљете податке има PTR који се разрешава на име хоста које ви контролишете и да ли то име хоста заузврат има одговарајући A запис. Ако не, отворите тикет код свог провајдера е-поште или хостинга и замолите их да исправе обрнути DNS.
Поруке стално стижу у фасцикле за нежељену пошту
Ако се ваше поруке испоручују, али стално буду нежељене, прво проверите свој стек за аутентификацијуКористите онлајн алате за верификацију SPF, DKIM и DMARC за ваш домен. Било какви неуспеси или упозорења су знакови да системи за пријем поште не верују у потпуности вашем саобраћају.
Проверите да ли се домен у видљивој адреси пошиљаоца поклапа са вашим SPF и DKIMЗа SPF, домен пошиљаоца коверте (Return-Path) треба да буде ауторизован. За DKIM, вредност d= у DKIM заглављу треба да буде домен који поседујете и, идеално, да се подудара или поравна са доменом „Од“. DMARC затим процењује то поравнање када одлучује како да оцени поруку.
Понашање корисника такође доприноси алгоритмима за спамАко многи примаоци бришу поруке без читања, никада их не отварају или их означе као спам, ваш углед ће опадати без обзира на то колико је ваш DNS беспрекоран. Комбиновање јаке DNS аутентификације са добрим праксама слања је победничка формула.
Веб обрасци или апликације шаљу пошту која никада не стиже
Када се чини да обрасци за контакт на веб-сајту или апликације „шаљу“ имејлове, али ништа не стиже, SPF је често погрешно конфигурисанИП адреса веб сервера или поштанска служба платформе можда нису укључени у ваш SPF запис, па примаоци третирају поруке као сумњиве или их одмах одбијају.
Ако ваш сајт шаље пошту користећи домен вашег главног добављача поштанског сандучета, потврдите да се стварни сервер за слање (на пример, ваш веб хост или трансакциони ESP) појављује у SPF политици. У неким случајевима је боље користити наменски поддомен и конфигурисани ESP него се ослањати на подразумевану функцију поште веб хоста.
Суочавање са кашњењима пропагације DNS-а
Кад год промените MX, SPF, DKIM или DMARC записе, дајте интернету времена да то надокнади.DNS ради на принципу кеширања: резолвери памте одговоре током TTL периода, који може бити минут или сат. Током овог периода, неки пошиљаоци виде нову конфигурацију, док други и даље користе стару.
Ако планирате велику миграцију е-поште, смањите TTL-ове дан или два унапредСмањење TTL-а на нешто попут 300 секунди за кључне записе убрзава ширење будућих промена. Након што се прелазак стабилизује, можете поново повећати TTL-ове ради перформанси и мањег броја упита.
Тестирање са више мрежа и коришћење екстерних алата за претрагу DNS-а помаже у потврђивању када је пропагација ефикасно завршенаНе ослањајте се само на ваш локални резолвер, који може агресивно кеширати или бити конфигурисан на неуобичајене начине.
Све заједно, DNS за е-пошту је мање магија, а више пажљиво координисани записи.Када су MX, SPF, DKIM, DMARC, PTR и пратећи уноси тачни и доследни, ваш домен постаје поуздан пошиљалац у очима добављача поште. То поверење, упарено са чистим листама и промишљеним садржајем, је оно што држи ваше поруке у пријемном сандучету, а ваш бренд ван фасцикли са непожељном поштом.