Модул 4 · 4.3
SPF: кой може да изпраща имейли от името на Вашия домейн?
Модул 4: Записи за имейл · Време за четене: 10 минути
Цел на урока: След този урок ще можете да четете SPF запис, да добавяте правилно услуга и да избягвате трите най-известни SPF грешки: два записа, +all и повече от десет справки.
Основни понятия: SPF, v=spf1, механизъм (a, mx, ip4, ip6, include), квалификатор (+ - ~ ?), all, един SPF запис, лимит от 10 DNS справки, envelope подател (Return-Path)
Проблемът: всеки може да използва Вашето име
Имейлът е измислен през осемдесетте години за малък, приятелски настроен интернет. Всеки mail сървър може да изпрати писмо с подател info@example.com, дори ако този сървър изобщо няма връзка с example.com. Измамниците с удоволствие се възползват от това.
SPF (Sender Policy Framework, RFC 7208) е първа стъпка за предотвратяване на това. В SPF запис посочвате кои сървъри имат право да изпращат имейли от името на Вашия домейн. Получаващият mail сървър проверява при всяко входящо писмо: идва ли то от сървър, който е в списъка?
Представете си го като списък с гости на врата. Портиерът (получаващият mail сървър) проверява списъка на Вашия домейн и гледа дали посетителят (изпращащият сървър) е в него.
Как изглежда един SPF запис?
SPF записът е TXT запис на Вашия домейн, който започва с v=spf1:
example.com. 3600 IN TXT "v=spf1 mx ip4:192.0.2.25 include:spf.mailer.example ~all"Четете го отляво надясно. Получателят преминава елемент по елемент и спира на първия, който съвпада.
| Елемент | Значение |
|---|---|
v=spf1 | Това е SPF запис. Трябва да стои най-отпред. |
a | Сървърът(ите), към който(които) сочи A/AAAA записът на Вашия домейн, имат право да изпращат имейли. |
mx | Сървърите от Вашите MX записи имат право да изпращат имейли. |
ip4:192.0.2.25 | Този IPv4 адрес има право да изпраща имейли. Възможен е и диапазон: ip4:192.0.2.0/24. |
ip6:2001:db8::25 | Същото за IPv6. |
include:spf.mailer.example | Всички сървъри, посочени в SPF записа на spf.mailer.example, също имат право. Така добавяте външна услуга. |
~all | Всички останали сървъри: съмнителни. Винаги стои в края. |
Краят: ~all, -all, ?all или +all
Пред всеки елемент може да стои знак, който казва какво се случва, ако елементът съвпадне. При all (който винаги съвпада) именно този знак прави разликата:
| Край | Име | Значение |
|---|---|---|
-all | fail | Другите сървъри нямат право. Получателите могат да отхвърлят писмото. |
~all | softfail | Другите сървъри са съмнителни. Писмото обикновено се приема, но по-често се смята за спам. |
?all | neutral | Няма конкретна позиция. Почти безполезно. |
+all | pass | Всеки сървър по света има право да изпраща имейли от Ваше име. Никога не използвайте това. |
Ако няма знак, важи +. mx означава следователно +mx.
Кое да изберете? ~all е безопасен стандарт. -all е по-строг и подходящ, ако сте сигурни, че всички Ваши подателски сървъри са включени в записа. Ако използвате DMARC (урок 4.5), в крайна сметка DMARC политиката определя какво се случва; много администратори в такъв случай избират ~all.
Грешка 1: два SPF записа
На домейн може да има само един SPF запис. Ако получателят намери два, резултатът е грешка (permerror) и Вашият SPF изобщо не се зачита. Това е по-лошо от липсата на SPF.
На практика това често се случва погрешка. Услуга за бюлетини или Microsoft 365 казва „добавете този SPF запис“, и изведнъж се появява втори запис v=spf1 до стария. Решението: добавете новата услуга към съществуващия запис.
Грешно:
"v=spf1 mx include:spf.oldhost.example ~all"
"v=spf1 include:spf.protection.outlook.com -all"Правилно:
"v=spf1 mx include:spf.oldhost.example include:spf.protection.outlook.com ~all"Внимавайте: при обединяването не премахвайте сървърите, които все още използвате. Ако Вашият уебсайт изпраща имейли чрез сървъра на Вашата хостинг компания, той трябва да остане в записа, дори ако обикновената Ви поща минава през Microsoft 365. Хостинг пакетът често вече има стандартен SPF с include на хостинг компанията (при WebOké например това е include:webawere.nl); оставете го, докато Вашият уебсайт или формуляри изпращат имейли през този сървър.
Грешка 2: +all или твърде широк запис
+all в края, или огромен диапазон като ip4:0.0.0.0/0, означава, че всеки има право. Тогава SPF вече не защитава нищо, а спам филтрите възприемат това като лош знак.
Грешка 3: повече от десет справки
За да провери SPF запис, получателят понякога трябва да направи допълнителни DNS заявки. Всеки include, a, mx, exists, ptr и redirect струва по една справка, а include брои и всички справки в записа, към който сочи. Според RFC 7208 общият брой не трябва да надвишава десет. Ако бъде надвишен, резултатът е permerror и SPF се проваля.
ip4 и ip6 не струват справка. Нито all.
Освен това максимум две справки могат да се върнат „празни“ (име, което не съществува, или липса на отговор). Така че include към услуга, която отдавна не използвате и която е премахнала своя запис, също може да причини проблеми.
Ако използвате много услуги, преброй ги с инструмент за проверка на SPF (урок 8.3) и премахнете услугите, които вече не използвате.
Какво не прави SPF
SPF проверява envelope подателя: техническия адрес на подателя (Return-Path), който mail сървърите използват помежду си. Това не винаги е същият адрес като полето „От:“, което виждате в пощенския си клиент. Услуга за бюлетини често изпраща със собствен Return-Path. Следователно само SPF не спира всеки фалшифициран подател. За това служат DKIM (урок 4.4) и DMARC (урок 4.5).
SPF се проваля и при пренасочване: ако автоматично пренасочвате поща към друг адрес, писмото пристига при крайния получател от сървър, който не е във Вашия SPF.
Защо това има значение
Големите пощенски доставчици станаха по-строги. От февруари 2024 г. Gmail и Yahoo изискват всеки, който изпраща имейли, да има поне SPF или DKIM, а който изпраща много имейли (повече от около 5000 на ден) да има SPF, DKIM и DMARC. Microsoft въведе същото изискване от май 2025 г. за Outlook.com, Hotmail и Live.com. Дори и да изпращате малко имейли, добрият SPF запис помага срещу попадане в папка спам.
На практика: ето как изглежда в панел
В този пример използваме DirectAdmin. В DNS Administration кликвате върху молива до TXT записа, който започва с v=spf1. DirectAdmin отваря помощник за SPF: при Include Domain въвеждате домейна на услугата (без include:), при Mode избирате SoftFail (~all) или Fail (-all). Най-отдолу виждате целия запис. Моят WebOké има подобен помощник за SPF в раздела DNS.
Други панели не винаги имат такъв помощник. Тогава редактирате TXT записа като обикновен текст; съдържанието е точно същото.
Обобщение
- SPF е TXT запис с
v=spf1, който казва кои сървъри имат право да изпращат имейли от името на Вашия домейн. - Точно един SPF запис на домейн. Нова услуга? Допълнете съществуващия запис.
- Завършете с
~allили-all, никога с+all. - Максимум десет DNS справки (
include,a,mx,exists,ptr,redirect),ip4/ip6не се броят. - SPF проверява envelope подателя; за истинска защита са нужни и DKIM, и DMARC.
Тест
Задача
Задача Z4.3: Търсене на SPF. Потърсете SPF записа на google.com (или на Вашия собствен домейн). Поставете пълния запис и попълнете с какво завършва (~all, -all, ?all или +all). При Вашия собствен домейн задачата проверява и дали имате точно един SPF запис.
Задача O4.3: Самостоятелно настройване в тренировъчната Ви зона. В тренировъчната зона използвате фиктивна услуга; при Вашия реален домейн използвате истинския include, посочен от Вашия доставчик на имейл услуги (например include:_spf.google.com). Създайте в тренировъчната си зона <code>.dnspractice.eumx), адреса 192.0.2.25 и тренировъчната услуга _spf.mailsuite-demo.dnspractice.eu. Другите сървъри са съмнителни или нямат право, затова записът завършва на ~all или -all.
Задача O4.3
Тази задача изпълнявате във Вашата собствена тренировъчна зона: истинска DNS зона на DNS сървърите на WebOké, само за Вас. Впишете се с Вашия имейл адрес. Ще получите линк за вход по имейл и след това ще се върнете на този урок. Използваме Вашия адрес само за курса.
За допълнително четене
Стъпките в тези статии важат за панелите на WebOké; в други панели работи по подобен начин.
- Ръководство за DirectAdmin 5.7: Настройка и допълване на SPF
- Как работи SPF записът в DNS?
- Добавяне или промяна на SPF запис в DirectAdmin
- Ръководство на WebOké 5.5: DNS помощници: MX, SPF, DMARC, CAA и SRV
- RFC 7208 (SPF), по-специално параграф 4.6.4 (лимит от десет справки и две празни справки)