SPF, DKIM и DMARC: настройка стъпка по стъпка

01Защо изобщо ви трябват

Всеки може да напише писмо с подател [email protected]. Трите записа позволяват на получаващия сървър да провери дали писмото наистина идва от вас. Google изисква от 01.02.2024 г. всички, които пишат до адреси в Gmail, да имат SPF или DKIM, валиден обратен DNS запис (PTR) за сървъра, TLS и процент на сигнали за спам под 0,3 %. Yahoo въведе същите основни изисквания от февруари 2024 г.

Масов подател за Google е този, който праща повече от 5000 писма на ден до Gmail. За него са задължителни SPF, DKIM и DMARC (политиката може да е p=none), домейнът в полето „От“ трябва да съвпада със SPF или DKIM домейна, а рекламните писма трябва да имат отписване с едно щракване. Yahoo изисква отписването да се изпълни до 2 дни. Дори да пращате малко писма, трите записа помагат писмата ви да не стигат в спам.

02SPF: един запис, най-много 10 заявки

SPF (RFC 7208) е TXT запис на самия домейн. Започва с v=spf1, изброява разрешените източници и завършва с правило за всички останали. Примери от официалните страници:

• Само Google Workspace: v=spf1 include:_spf.google.com ~all
• Само Microsoft 365: v=spf1 include:spf.protection.outlook.com -all
• Сървърът на хостинга и Google заедно, в един запис: v=spf1 mx include:_spf.google.com ~all

-all значи „отхвърли всички други“ (fail), а ~all – „вероятно не са разрешени“ (softfail). RFC 7208 забранява повече от един SPF запис за домейн: при два проверката връща грешка (permerror). Microsoft също казва изрично да не създавате втори запис, а да добавите новия източник към съществуващия.

Второто правило: механизмите include, a, mx, ptr, exists и модификаторът redirect правят DNS заявки и общо не може да са повече от 10 при една проверка, включително вложените в чуждите include. ip4, ip6 и all не се броят. Ако ползвате много услуги за изпращане (бюлетин, фактури, онлайн магазин), лесно минавате границата.

03DKIM: подпис, който публикувате в DNS

DKIM (RFC 6376) подписва всяко изходящо писмо с частен ключ, а публичният ключ стои в DNS под име от вида selector._domainkey.example.bg. Записът се генерира от пощенския доставчик – в панела на хостинга, в Google Workspace или в Microsoft 365. Вие само го копирате в DNS. Microsoft 365 например дава два CNAME записа: selector1._domainkey и selector2._domainkey.

Ако пращате от няколко услуги, всяка има собствен селектор и собствен DKIM запис – те не си пречат, за разлика от SPF.

04DMARC: от наблюдение към отхвърляне

DMARC е TXT запис на адрес _dmarc.example.bg. Той казва на получателя какво да прави с писмо, което не минава проверка и чийто домейн в „От“ не съвпада с проверения SPF или DKIM домейн. Текущата спецификация е RFC 9989 от май 2026 г., която замени RFC 7489. Политиката p има три стойности:

Запис за начало: v=DMARC1; p=none; rua=mailto:[email protected]. Тагът rua е адресът за обобщените отчети. RFC 9989 нарича p=none режим на наблюдение и изисква пропуските в легитимната поща да се оправят, преди да минете към quarantine или reject. Старият таг pct за частично прилагане е премахнат в новата спецификация. С sp задавате политика за поддомейните, а с новия np – за несъществуващите поддомейни.

05Чести грешки

• Два TXT записа, започващи с v=spf1 – слейте ги в един.
• Забравен източник: формата за контакт на сайта праща от сървъра на хостинга, а в SPF е само Google.
• Минаване направо на p=reject без отчети – писмата от бюлетина или фактурите спират.
• DMARC записът е сложен на самия домейн вместо на _dmarc.
• При смяна на хостинга или DNS сървърите записите не са пренесени в новата зона.

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

→Стъпка по стъпка

1. Направете списък на всичко, което праща поща от домейна

   Пощенските кутии, формата за контакт на сайта, онлайн магазина, системата за фактури, бюлетина. За всяка услуга намерете в документацията ѝ какво да добавите в SPF и DKIM.

2. Вижте текущите записи

   С DNS проверката проверете TXT записа на домейна и на _dmarc. Ако вече има SPF, ще го редактирате, а не ще добавяте нов.

3. Запишете един SPF запис

   Съберете всички източници в един TXT запис, например v=spf1 mx include:_spf.google.com ~all. Преброете механизмите, които правят DNS заявки – общо трябва да са до 10.

4. Включете DKIM при всеки доставчик

   В панела на хостинга или на пощенската услуга генерирайте DKIM ключ и публикувайте записа, който ви дадат, под посочения селектор. После включете подписването в същия панел.

5. Публикувайте DMARC в режим на наблюдение

   Добавете TXT запис на _dmarc.вашият-домейн със стойност v=DMARC1; p=none; rua=mailto:адрес-за-отчети. Ползвайте адрес, който четете.

6. Четете отчетите няколко седмици

   Отчетите показват кои сървъри пращат от ваше име и дали минават SPF и DKIM. Оправете всеки легитимен източник, който не минава.

7. Затегнете политиката

   Сменете на p=quarantine, наблюдавайте още известно време и накрая минете на p=reject. След всяка промяна проверете записа с DNS инструмента.

?Чести въпроси