Спрете да гадаете за своя 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 loops или разделено доставяне между две пощенски кутии.

Ако поддържате собствена контактна форма и искате да избегнете 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 делегира към SPF записа на Google
• ~all е soft fail — отхвърляйте поща от неизброени източници, но не бъдете прекалено строги

Можете също да използвате ip4: или ip6:, за да разрешите конкретни адреси, или a и mx, за да препратите към A и MX записите на домейна си. Механизмът all в края контролира какво се случва с поща от източници, които не сте изброили: -all е hard fail (отхвърляне), ~all е soft fail (маркиране като подозрителна), ?all е neutral (без мнение), а +all е свободен достъп за всички (не използвайте това).

SPF има два остри ръба. Първо, той се чупи при препращане на имейл, защото препращащият сървър не е във вашия SPF запис. Второ, SPF записите имат лимит за lookup от десет DNS заявки. Ако включите твърде много услуги на трети страни, ще надхвърлите лимита и SPF ще спре да работи. Решението е да flatten-нете SPF записа си — да замените директивите include: с действителните IP диапазони — но това изисква поддръжка, когато доставчиците променят своите IP адреси.

DKIM: криптографско доказателство за самоличността на изпращача

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

За разлика от SPF, DKIM оцелява при препращане, защото подписът пътува със съобщението. Той е и по-гъвкав — можете да имате няколко DKIM ключа за различни услуги за изпращане, всеки със собствен selector.

DKIM DNS запис изглежда така:

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

Selector-ът (default в този пример) е произволен — вашият имейл доставчик го избира. Стойността p= е публичният ключ, обикновено дълъг base64-encoded низ. Вашият имейл доставчик генерира private key и го използва, за да подписва изходящите съобщения.

Настройката на DKIM почти винаги се обработва от вашия имейл доставчик. Вашата задача е да копирате TXT записа, който ви дава, и да го поставите във вашия DNS. Трудната част е, че някои DNS доставчици не обработват добре дълги TXT записи — или ги отрязват, или изискват да разделите стойността на няколко quoted strings.

За да проверите дали DKIM работи, изпратете тестов имейл до Gmail адрес и проверете headers. Потърсете dkim=pass в header-а Authentication-Results.

DMARC: прилагане на политика и отчитане

DMARC (Domain-based Message Authentication, Reporting and Conformance) свързва SPF и DKIM и казва на получаващите сървъри какво да правят, когато удостоверяването се провали. Той също така активира reporting, за да можете да видите кой изпраща имейл като вашия домейн — както легитимно, така и чрез spoofing.

Минимален DMARC запис изглежда така:

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

• p=none означава само наблюдение — не отхвърляйте и не поставяйте под карантина неуспешните съобщения
• rua=mailto:[email protected] указва къде да се изпращат aggregate reports

След като сте уверени, че SPF и DKIM работят, можете да затегнете политиката до p=quarantine (изпращане на неуспешните съобщения в spam) или p=reject (директното им bounce-ване). Можете също да зададете политика за subdomain с sp= и да посочите процент от съобщенията, към които да се прилага политиката, с pct=.

DMARC отчетите са XML файлове, изпращани ежедневно от големи получатели. Те са многословни и трудни за четене в raw вид, но ви казват точно кои съобщения са минали или не са минали удостоверяването и защо. Ако виждате отхвърляне на легитимна поща, отчетите ще ви покажат коя SPF или DKIM проверка се проваля.

Една уловка: DMARC изисква alignment. За SPF домейнът в header-а Return-Path трябва да съвпада с домейна в header-а From (или да е subdomain). За DKIM домейнът d= в DKIM подписа трябва да съвпада с домейна From. Ако използвате услуга за изпращане на трета страна, тя трябва да поддържа custom return paths или DKIM signing с вашия домейн, не с нейния.

Как да одитирате текущата си настройка

Повечето DNS проблеми са невидими, докато не причинят проблем. Ето как да проверите записите си, преди нещо да се счупи:

1. Заявете MX записите си: dig MX example.com трябва да върне hostnames и приоритетите на вашите mail сървъри. Проверете дали съвпадат с документацията на вашия имейл доставчик.

1. Проверете SPF синтаксиса: dig TXT example.com и потърсете записа v=spf1. Прекарайте го през SPF validator, за да хванете синтактични грешки и нарушения на lookup лимита.

1. Проверете DKIM ключовете: Изпратете тестов имейл и прегледайте header-а DKIM-Signature. Извлечете selector-а и домейна, след това изпълнете заявка dig TXT selector._domainkey.example.com, за да потвърдите, че публичният ключ съществува.

1. Валидирайте DMARC политиката: dig TXT _dmarc.example.com трябва да върне вашия DMARC запис. Уверете се, че rua= сочи към адрес, който действително наблюдавате.

1. Тествайте от край до край: Използвайте услуга като mail-tester.com или изпратете до Gmail адрес и проверете пълните headers. Потърсете spf=pass, dkim=pass и dmarc=pass в header-а Authentication-Results.

Ако дебъгвате защо имейлите не пристигат, headers са най-добрият ви инструмент. Повечето mail клиенти позволяват да преглеждате raw headers — в Gmail отворете съобщението, кликнете върху трите точки и изберете „Показване на оригинала“. Header-ът Authentication-Results ще ви каже точно коя проверка се е провалила и защо.

Кога да използвате политики за subdomain

Ако изпращате имейл от няколко subdomains — например newsletter.example.com за marketing и app.example.com за transactional mail — можете да зададете DMARC политики за всеки subdomain. Това ви позволява да прилагате строги политики към subdomains, които контролирате, като същевременно запазвате по-свободна политика за основния си домейн.

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

Какво да правите, когато удостоверяването се счупи

Най-честият сценарий на отказ е добавяне на нова услуга за изпращане без актуализиране на DNS. Ако започнете да използвате нов доставчик на транзакционни имейли, трябва да добавите неговия SPF include или IP диапазон, да конфигурирате DKIM signing с вашия домейн и да проверите DMARC alignment.

Вторият най-чест проблем е препращането. Ако потребители препращат вашия имейл към друг адрес, SPF ще се провали, защото препращащият сървър не е във вашия SPF запис. DKIM обикновено оцелява при препращане, така че докато DKIM минава и вашата DMARC политика позволява partial alignment, съобщението би трябвало да бъде доставено. Ако виждате отхвърлена препратена поща, проверете DMARC политиката си — p=reject със strict alignment ще счупи препращането.

Третият проблем е DNS propagation. Промените в DNS записите може да отнемат часове, докато се разпространят, а различните mail сървъри кешират записи за различно време. Ако току-що сте актуализирали запис и той не работи, изчакайте няколко часа и тествайте отново. Можете да проверите propagation с инструмент като whatsmydns.net.

Основни изводи

• MX записите маршрутизират входящата поща; SPF, DKIM и DMARC удостоверяват изходящата поща. Те решават различни проблеми и имате нужда и от четирите.
• SPF се чупи при препращане и има лимит от десет lookup-а. DKIM оцелява при препращане, но изисква конфигурация за всяка услуга. DMARC ги свързва и активира reporting.
• Започнете с p=none в DMARC, наблюдавайте отчетите няколко седмици, след това затегнете до p=quarantine или p=reject, когато сте уверени, че легитимната поща минава.
• DNS грешките са тихи. Тествайте конфигурацията си с реален имейл и прегледайте headers, за да потвърдите, че SPF, DKIM и DMARC минават успешно.
• Ако удостоверяването се счупи след добавяне на нова услуга за изпращане, проверете SPF includes, DKIM selectors и DMARC alignment. Headers ще ви кажат коя проверка се е провалила.

FAQ

Q: Мога ли да имам няколко SPF записа?

A: Не. Няколко SPF записа ще доведат до игнориране на всички тях. Ако трябва да упълномощите няколко услуги, използвайте директиви include: в един SPF запис или избройте IP диапазоните директно. Внимавайте с лимита от десет lookup-а.

Q: Нужен ли ми е DMARC, ако изпращам само по няколко имейла на ден?

A: Да. DMARC не е въпрос на обем — той е за доказване, че сте този, за когото се представяте. Дори малките домейни печелят от DMARC, защото той предотвратява spoofing и ви дава видимост върху проблемите с доставянето. Започнете с p=none и адрес за reporting.

Q: Какво се случва, ако DKIM и SPF се провалят, но имейлът изглежда легитимен?

A: Зависи от вашата DMARC политика. Ако p=none, пощата се доставя с предупреждение. Ако p=quarantine, отива в spam. Ако p=reject, се bounce-ва. Затова трябва да наблюдавате DMARC отчетите, преди да наложите строга политика — може да имате легитимни изпращачи, за които не сте знаели.

Q: Мога ли да използвам един и същ DKIM ключ за няколко домейна?

A: Технически да, но не го правете. Всеки домейн трябва да има собствена двойка DKIM ключове. Споделянето на ключове затруднява ротацията и увеличава blast radius, ако private key бъде компрометиран.

Q: Колко често трябва да ротира DKIM ключовете?

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

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

💡 Опитайте това: Проверете публикуваната политика на произволен домейн с DMARC Lookup, за да видите как MX, SPF и DMARC записите се съчетават на практика.

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

Източници

• RFC 7208: Sender Policy Framework (SPF) — Спецификацията на SPF, включително синтактични правила и лимита от десет lookup-а.
• RFC 6376: DomainKeys Identified Mail (DKIM) — Спецификацията на DKIM, обхващаща генерирането и проверката на подписи.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) — Спецификацията на DMARC, включително синтаксис на политиките и формат за aggregate reporting.
• Google Workspace: Prevent spoofing and spam — Практически насоки за конфигуриране на SPF, DKIM и DMARC за домейни в Google Workspace.