Имейл на собствен домейн с SPF, DKIM и DMARC стъпка по стъпка

Имейл на собствен домейн стига надеждно до получателите, когато в DNS на домейна има записи за удостоверяване. От 1 февруари 2024 г. Gmail иска от всеки подател поне SPF или DKIM, а от изпращащите над 5000 писма на ден иска и трите записа заедно (Google (Gmail Help)). Outlook.com въведе същия праг на 5 май 2025 г. Там неудостовереното писмо първо попада в нежелана поща, а ако проблемът остане, може да бъде отхвърлено (Microsoft Outlook.com Postmaster).

Малка фирма рядко изпраща 5000 писма на ден, затова формално ѝ стига SPF или DKIM (Google (Gmail Help)). Съветваме ви все пак да сложите и трите записа. Cloudflare ги препоръчва дори за домейни, които изобщо не изпращат поща (Cloudflare Docs). Без DMARC никой не ви съобщава за писма, пратени от ваше име, а приемащите сървъри нямат указание какво да правят с тях (Google Workspace, Cloudflare Blog).

Какво правят SPF, DKIM и DMARC за имейл на собствен домейн

SPF изброява сървърите и адресите, от които домейнът позволява изпращане (RFC Editor (IETF), Cloudflare Docs). DKIM поставя криптографски подпис на всяко писмо. Публичният ключ стои в DNS и по него получателят проверява, че съдържанието не е променено по пътя (Cloudflare Blog). DMARC казва на приемащия сървър какво да прави с писмо, което не мине проверката, и къде да праща сборни отчети (RFC Editor (IETF)).

Записите са от тип TXT и се въвеждат в зоната на домейна, там, където се управлява DNS (Cloudflare Blog, Cloudflare Docs). Ако не сте сигурни дали зоната е при регистратора или при хостинга, първо прочетете как работи DNS и проверете именните сървъри.

Как се пише SPF записът

Редът започва с v=spf1, следват разрешените източници, а накрая стои правило за всички останали (RFC Editor (IETF)). Домейн, който праща от един сървър, би имал ред като v=spf1 ip4:192.0.2.10 -all (адресът е примерен). Минусът означава отказ, а тилдата е мек отказ. Въпросителният знак дава неутрален резултат, а плюсът разрешава и се подразбира, когато не е изписан.

Два отделни SPF записа са класическа грешка. Обикновено единият идва от хостинга, а другият от външна пощенска услуга, чиито адреси Google Workspace съветва да добавите в SPF (Google Workspace). Стандартът позволява само един такъв запис на име и при два проверката завършва с постоянна грешка (RFC Editor (IETF)). Обединете всички източници в един ред.

Втората клопка е лимитът от 10 механизма с DNS заявки, като include, mx и redirect (RFC Editor (IETF)). Всяка външна услуга, която добавяте по съвета на Google, изразходва поне една от тях (Google Workspace). След десетата резултатът отново е грешка, затова броете наново при всяко ново include.

Дължината също има граница. RFC 7208 препоръчва отговорът на заявката да се събира в 512 октета, макар Cloudflare да приема записи до 4096 байта (RFC Editor (IETF), Cloudflare Docs). Някои проверяващи сървъри могат да пренебрегнат прекалено дълъг SPF.

DKIM ключът идва от доставчика на пощата

Ключовете създава услугата, която изпраща писмата. Вие публикувате само публичния ключ като TXT запис с име от вида селектор._domainkey (Cloudflare Blog, Cloudflare Docs). Gmail приема ключ от поне 1024 бита и препоръчва 2048 бита, ако DNS доставчикът позволява толкова дълъг запис (Google (Gmail Help)).

Дългият ключ често се въвежда като няколко низа в двойни кавички. В Cloudflare несъответстващите кавички дават грешка при запазване (Cloudflare Docs). Копирайте стойността без никакви промени, защото при сгрешен ключ подписът не минава, а Gmail изисква работещ SPF или DKIM (Google (Gmail Help)).

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

DMARC от p=none до p=reject

Записът стои на име _dmarc пред името на домейна (Google Workspace, RFC Editor (IETF)). Началният вариант е v=DMARC1; p=none; rua=mailto:, като след двоеточието се изписва адресът на кутията за сборни отчети. Google Workspace съветва да изчакате 48 часа след включването на SPF и DKIM, иначе доставката от домейна може да пострада.

Режимът p=none не спира нищо и само събира данни (Google Workspace, RFC Editor (IETF)). За отчетите отделете група или самостоятелна кутия, защото голяма организация получава стотици и дори хиляди на ден. Прегледът им разкрива забравени сървъри и външни услуги, които пращат от ваше име без подпис, а този етап може да продължи много месеци.

Google Workspace все още описва тага pct, с който политиката обхваща първо част от неудостоверените писма и после стига до 100% (Google Workspace). RFC 9989, публикуван през май 2026 г. като стандарт, замества RFC 7489, премахва pct и изисква непознатите тагове да се пренебрегват (RFC Editor (IETF)). Нашият извод е, че получател по новия стандарт може да подмине pct. Затова не разчитайте на този таг като на предпазна мрежа и минавайте към reject чак когато отчетите са чисти.

Защитата често остава недовършена. В края на 2020 г. под 50% от домейните са имали DMARC запис, а над 65% от тях са били само на p=none (Cloudflare Blog). По наше изчисление по данни на Cloudflare под 18% от домейните тогава са имали политика, която реално спира подправени писма. Outlook.com изисква само p=none, но препоръчва p=reject (Microsoft Outlook.com Postmaster).

Съвпадение на домейна в полето From

DMARC проверява дали домейнът, потвърден от SPF или DKIM, съвпада с домейна в полето From (RFC Editor (IETF)). По подразбиране режимът е свободен и стига да съвпада основният домейн. Gmail изисква такова съвпадение от изпращащите над 5000 писма на ден, а Outlook.com съветва то да е и по двата механизма (Google (Gmail Help), Microsoft Outlook.com Postmaster).

Типичен проблем е бюлетинът. Услугата праща с вашия адрес, но подписва със своя домейн и писмото не е подравнено (Google Workspace, RFC Editor (IETF)). Проверете, че външният подател има SPF и DKIM и че домейнът му за обратни писма съвпада с вашия.

Домейн, от който не се пращат писма

Регистрираните само за защита имена също имат нужда от записи, иначе могат да послужат за фалшиви писма (Cloudflare Blog, Cloudflare Docs). Това важи например за кирилския вариант.бг или за сходни имена, взети заради марката (правилата са в материала за регистрация на.bg домейн).

Нужни са три реда. За SPF това е v=spf1 -all, за DKIM на *._domainkey е празният ключ v=DKIM1; p=, а за DMARC е v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; (Cloudflare Blog). С тях всяко писмо от името на домейна се проваля, а буквата s включва строгото съвпадение на имената (RFC Editor (IETF)).

Как да проверите, че пощата минава

Gmail иска и валиден обратен DNS запис (PTR) за изпращащия сървър, връзка през TLS и писма във формат по RFC 5322 (Google (Gmail Help)). Outlook.com връща отказ с код 550 5.7.515, когато домейнът не достига нужното ниво на удостоверяване (Microsoft Outlook.com Postmaster). Щом видите такъв върнат имейл, проверете първо записите в зоната. За PTR и TLS питайте доставчика на пощата.

Бюлетинът има още едно изискване. Gmail иска оплакванията за спам в Postmaster Tools да са под 0,3% и препоръчва да стоят под 0,1% (Google (Gmail Help)). По наше изчисление при 1000 получатели 3 сигнала вече стигат прага, а препоръчителната граница се достига още с 1 сигнал. Търговските писма трябва да имат отписване с едно кликване и видима връзка за отписване в текста.

Въпроси и отговори

Трябва ли DMARC, ако пращам малко писма? Gmail го изисква само от изпращащите над 5000 писма на ден (Google (Gmail Help)). Без него обаче нямате отчети и не можете да кажете на получателите да отхвърлят подправени писма (Google Workspace, Cloudflare Blog).

Може ли да започна направо с p=reject? Технически може, но писмата от услуги, които още не подписват правилно, ще бъдат отхвърлени. Стандартът предвижда първо период на наблюдение с p=none, а Outlook.com препоръчва reject като крайна цел (RFC Editor (IETF), Microsoft Outlook.com Postmaster).