Престаните да нагађате свој DNS: водич за програмере кроз MX, SPF, DKIM и DMARC

Зашто су DNS записи за имејл сада важни

Аутентификација имејла некада је била опциона. У 2026. години, то је основни услов. Gmail и Outlook примењују SPF и DKIM за пошиљаоце масовне поште, а DMARC убрзано постаје обавезан за сваки домен који шаље трансакционе имејлове. Ако су ваши DNS записи погрешни, ваши имејлови не стижу — без bounce поруке, без упозорења, само тишина.

Проблем је у томе што су ови записи документовани као RFC-ови, а не као алати. Већина програмера копира и налепи примере из водича за подешавање свог провајдера имејла и нада се најбољем. То функционише све док не треба да отклањате проблеме, додате другу услугу за слање или објасните клијенту зашто имејлови са његовог контакт формулара завршавају у spam-у.

Овај водич пролази кроз MX, SPF, DKIM и DMARC редоследом којим ћете их заиста сретати, са довољно детаља да их исправно конфигуришете и довољно контекста да их отклоните када се покваре.

MX записи: куда иде долазни имејл

MX записи говоре интернету који mail сервери прихватају имејл за ваш домен. Они су најједноставнији од ова четири, али их је и најлакше погрешно конфигурисати.

MX запис има два дела: број приоритета и hostname. Нижи бројеви приоритета покушавају се први. Ако користите Google Workspace, ваши MX записи могу изгледати овако:

example.com.  MX  1  aspmx.l.google.com.
example.com.  MX  5  alt1.aspmx.l.google.com.
example.com.  MX  5  alt2.aspmx.l.google.com.

Завршне тачке су важне — оне означавају да је hostname потпуно квалификован. Већина DNS провајдера их додаје аутоматски, али не сви.

Честе грешке: усмеравање MX записа на A запис уместо на hostname, постављање свих приоритета на исти број (што поништава сврху резервних сервера) или заборављање да уклоните старе MX записе када мигрирате провајдере. Застарели MX записи не стоје само безазлено тамо — могу да изазову mail loop-ове или подељену испоруку у два inbox-а.

Ако покрећете сопствени контакт формулар и желите да избегнете spam без ослањања на услуге трећих страна, разумевање како формулари постају spam вектори је корисна полазна тачка.

SPF: којим серверима је дозвољено да шаљу као ви

SPF (Sender Policy Framework) је TXT запис који наводи IP адресе и домене овлашћене да шаљу имејл у име вашег домена. То је прва провера коју већина mail сервера извршава када прими поруку која тврди да је од вас.

Основни SPF запис изгледа овако:

v=spf1 include:_spf.google.com ~all

Разложено:

• v=spf1 декларише SPF верзију
• include:_spf.google.com делегира на Google-ов SPF запис
• ~all је soft fail — одбиј пошту из ненаведених извора, али немој бити превише строг

Такође можете користити ip4: или ip6: да додате конкретне адресе на allowlist, или a и mx да референцирате A и MX записе свог домена. Механизам all на крају контролише шта се дешава са поштом из извора које нисте навели: -all је hard fail (одбаци), ~all је soft fail (означи као сумњиво), ?all је neutral (без става), а +all је потпуно отворено за све (немојте ово користити).

SPF има две оштре ивице. Прво, пуца када се имејл прослеђује, јер сервер који прослеђује није у вашем SPF запису. Друго, SPF записи имају ограничење претраге од десет DNS упита. Ако укључите превише услуга трећих страна, прећи ћете ограничење и SPF ће престати да ради. Решење је да flatten-ујете SPF запис — замените include: директиве стварним IP опсезима — али то захтева одржавање када провајдери промене своје IP адресе.

DKIM: криптографски доказ идентитета пошиљаоца

DKIM (DomainKeys Identified Mail) додаје дигитални потпис вашем одлазном имејлу. Сервер који прима поруку проверава потпис у односу на јавни кључ објављен у вашем DNS-у. Ако је потпис важећи и порука није мењана, DKIM пролази.

За разлику од SPF-а, DKIM преживљава прослеђивање, јер потпис путује са поруком. Такође је флексибилнији — можете имати више DKIM кључева за различите услуге слања, сваки са сопственим селектором.

DKIM DNS запис изгледа овако:

default._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Селектор (default у овом примеру) је произвољан — бира га ваш провајдер имејла. Вредност p= је јавни кључ, обично дугачак base64-енкодовани стринг. Ваш провајдер имејла генерише приватни кључ и користи га за потписивање одлазних порука.

Подешавање DKIM-а скоро увек обавља ваш провајдер имејла. Ваш посао је да копирате TXT запис који вам дају и налепите га у свој DNS. Трик је у томе што неки DNS провајдери не рукују добро дугачким TXT записима — или их скраћују или траже да вредност поделите у више стрингова под наводницима.

Да бисте проверили да DKIM ради, пошаљите тест имејл на Gmail адресу и проверите заглавља. Потражите dkim=pass у заглављу Authentication-Results.

DMARC: спровођење политике и извештавање

DMARC (Domain-based Message Authentication, Reporting and Conformance) повезује SPF и DKIM и говори серверима који примају пошту шта да ураде када аутентификација не успе. Такође омогућава извештавање, тако да можете видети ко шаље имејл као ваш домен — и легитимно и spoofed.

Минимални DMARC запис изгледа овако:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• p=none значи само надгледање — немој одбацивати нити стављати у quarantine поруке које нису прошле проверу
• rua=mailto:[email protected] одређује где се шаљу агрегирани извештаји

Када сте сигурни да SPF и DKIM раде, можете пооштрити политику на p=quarantine (шаљи неуспеле поруке у spam) или p=reject (одбиј их одмах). Такође можете поставити политику за поддомен помоћу sp= и одредити проценат порука на које се политика примењује помоћу pct=.

DMARC извештаји су XML датотеке које велики примаоци шаљу свакодневно. Опширни су и тешко их је читати сирове, али вам тачно говоре које поруке су прошле или нису прошле аутентификацију и зашто. Ако видите да се легитимна пошта одбија, извештаји ће вам показати која SPF или DKIM провера пада.

Једна замка: DMARC захтева alignment. За SPF, домен у заглављу Return-Path мора да се подудара са доменом у заглављу From (или да буде поддомен). За DKIM, d= домен у DKIM потпису мора да се подудара са From доменом. Ако користите услугу слања треће стране, она мора да подржава прилагођене return path-ове или DKIM потписивање вашим доменом, а не својим.

Како да проверите тренутно подешавање

Већина DNS проблема је невидљива док не изазове проблем. Ево како да проверите своје записе пре него што се нешто поквари:

1. Упитајте своје MX записе: dig MX example.com треба да врати hostname-ове и приоритете ваших mail сервера. Проверите да ли се поклапају са документацијом вашег провајдера имејла.

1. Проверите SPF синтаксу: dig TXT example.com и потражите v=spf1 запис. Провуците га кроз SPF валидатор да ухватите синтаксне грешке и прекорачења ограничења претраге.

1. Проверите DKIM кључеве: Пошаљите тест имејл и прегледајте заглавље DKIM-Signature. Извуците селектор и домен, затим упитајте dig TXT selector._domainkey.example.com да потврдите да јавни кључ постоји.

1. Валидирајте DMARC политику: dig TXT _dmarc.example.com треба да врати ваш DMARC запис. Уверите се да rua= показује на адресу коју заиста надгледате.

1. Тестирајте од краја до краја: Користите услугу као што је mail-tester.com или пошаљите на Gmail адресу и проверите пуна заглавља. Потражите spf=pass, dkim=pass и dmarc=pass у заглављу Authentication-Results.

Ако отклањате зашто имејлови не стижу, заглавља су ваш најбољи алат. Већина mail клијената омогућава преглед сирових заглавља — у Gmail-у отворите поруку, кликните на три тачке и изаберите 'Show original'. Заглавље Authentication-Results ће вам тачно рећи која провера није успела и зашто.

Када користити политике за поддомене

Ако шаљете имејл са више поддомена — рецимо, newsletter.example.com за маркетинг и app.example.com за трансакциону пошту — можете поставити DMARC политике по поддомену. То вам омогућава да спроводите строге политике на поддоменима које контролишете, док на главном домену задржавате лабавију политику.

Цена је сложеност. Сваки поддомен треба сопствене SPF, DKIM и DMARC записе, а ви морате да пратите које услуге слања су овлашћене за које поддомене. За већину малих тимова, један добро конфигурисан домен је једноставнији и једнако безбедан.

Шта урадити када аутентификација пукне

Најчешћи режим отказа је додавање нове услуге слања без ажурирања DNS-а. Ако почнете да користите новог провајдера трансакционог имејла, треба да додате њихов SPF include или IP опсег, конфигуришете DKIM потписивање вашим доменом и проверите DMARC alignment.

Други најчешћи проблем је прослеђивање. Ако корисници проследе ваш имејл на другу адресу, SPF ће пасти јер сервер који прослеђује није у вашем SPF запису. DKIM обично преживљава прослеђивање, па све док DKIM пролази и ваша DMARC политика дозвољава делимичан alignment, порука би и даље требало да буде испоручена. Ако видите да се прослеђена пошта одбија, проверите DMARC политику — p=reject са строгим alignment-ом ће покварити прослеђивање.

Трећи проблем је DNS пропагација. Променама DNS записа могу бити потребни сати да се пропагирају, а различити mail сервери кеширају записе на различито време. Ако сте управо ажурирали запис и не ради, сачекајте неколико сати и тестирајте поново. Пропагацију можете проверити алатом као што је whatsmydns.net.

Кључни закључци

• MX записи рутирају долазну пошту; SPF, DKIM и DMARC аутентификују одлазну пошту. Решавају различите проблеме и потребна су вам сва четири.
• SPF пуца при прослеђивању и има ограничење од десет претрага. DKIM преживљава прослеђивање, али захтева конфигурацију по услузи. DMARC их повезује и омогућава извештавање.
• Почните са p=none у DMARC-у, пратите извештаје неколико недеља, затим пооштрите на p=quarantine или p=reject када будете сигурни да легитимна пошта пролази.
• DNS грешке су тихе. Тестирајте конфигурацију стварним имејлом и прегледајте заглавља да потврдите да SPF, DKIM и DMARC пролазе.
• Ако аутентификација пукне након додавања нове услуге слања, проверите SPF include-ове, DKIM селекторе и DMARC alignment. Заглавља ће вам рећи која провера није успела.

FAQ

Q: Могу ли да имам више SPF записа?

A: Не. Више SPF записа ће довести до тога да се сви игноришу. Ако треба да овластите више услуга, користите include: директиве унутар једног SPF записа или директно наведите IP опсеге. Пазите на ограничење од десет претрага.

Q: Да ли ми треба DMARC ако шаљем само неколико имејлова дневно?

A: Да. DMARC није питање обима — већ доказивања да сте оно за шта се представљате. Чак и мали домени имају користи од DMARC-а јер спречава spoofing и даје вам видљивост у проблеме са испоруком. Почните са p=none и адресом за извештаје.

Q: Шта се дешава ако и DKIM и SPF падну, али имејл изгледа легитимно?

A: Зависи од ваше DMARC политике. Ако је p=none, пошта се испоручује уз упозорење. Ако је p=quarantine, иде у spam. Ако је p=reject, одбија се. Зато треба да пратите DMARC извештаје пре него што спроведете строгу политику — можда имате легитимне пошиљаоце за које нисте знали.

Q: Могу ли да користим исти DKIM кључ за више домена?

A: Технички да, али немојте. Сваки домен треба да има сопствени пар DKIM кључева. Дељење кључева отежава ротацију и повећава blast radius ако приватни кључ буде компромитован.

Q: Колико често треба да ротирам DKIM кључеве?

A: Не постоји универзално правило, али једном годишње је разумно за већину домена. Ако сумњате да је кључ компромитован, ротирајте одмах. Обавезно објавите нови јавни кључ у DNS-у пре него што почнете да потписујете новим приватним кључем, и оставите стари кључ у DNS-у неколико дана након ротације да бисте обрадили закаснелу пошту.

<!-- tool-cta:start -->

💡 Испробајте ово: Прегледајте објављену политику било ког домена помоћу DMARC Lookup да бисте видели како се MX, SPF и DMARC записи уклапају у пракси.

<!-- tool-cta:end -->

Извори

• RFC 7208: Sender Policy Framework (SPF) — SPF спецификација, укључујући правила синтаксе и ограничење од десет претрага.
• RFC 6376: DomainKeys Identified Mail (DKIM) — DKIM спецификација, која покрива генерисање и верификацију потписа.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — DMARC спецификација, укључујући синтаксу политике и формат агрегираних извештаја.
• Google Workspace: Prevent spoofing and spam — Практичне смернице за конфигурацију SPF, DKIM и DMARC за Google Workspace домене.