Проверка на SPF запис

Ролята на SPF записите в имейл автентикацията

Sender Policy Framework (SPF) е стандартизиран метод за защита на електронната поща, който позволява на собствениците на домейни да указват кои пощенски сървъри имат право да изпращат съобщения от името на техния домейн. Когато даден имейл сървър получи съобщение, той проверява SPF записа на домейна на подателя в DNS, за да потвърди дали изпращащият IP адрес е оторизиран.

Правилното конфигуриране на SPF е критично за предотвратяване на имейл spoofing (фалшифициране на подателя) и за подобряване на доставяемостта на писмата. Неправилно съставен SPF запис може да доведе до отхвърляне на легитимни имейли или до маркирането им като спам от получаващите сървъри.

Синтаксис и основни термини в SPF

Всеки SPF запис се публикува като TXT запис в DNS системата и се състои от поредица от термини, разделени с интервали. Записът задължително трябва да започва с дефиниране на версията:

• v=spf1: Това е версията на SPF. Тя трябва да бъде първият термин в записа и не се допуска наличието на повече от един такъв термин.

След версията следват механизми и модификатори, които определят правилата за упълномощаване:

• include: Препраща към SPF записа на друг домейн. Този механизъм задейства DNS заявка за извличане на въпросния запис.
• ip4 и ip6: Указват конкретни IPv4 или IPv6 адреси и CIDR диапазони, които са оторизирани да изпращат имейли.
• all: Този механизъм обикновено се поставя в края на записа и определя какво се случва с писмата, изпратени от сървъри, които не съвпадат с никой от предходните механизми.
• redirect: Модификатор, който насочва оценката към SPF записа на друг домейн, като напълно заменя текущите правила.

Всеки механизъм може да има квалификатор, който определя резултата от проверката: + (Pass), - (Fail), ~ (SoftFail) или ? (Neutral).

Ограничението от 10 DNS заявки и неговото значение

Едно от най-важните технически правила при оценка на SPF е ограничението за броя на DNS заявките. По време на пълна оценка на SPF записа от получаващия сървър, максимално разрешените DNS заявки са 10.

Всеки от следните термини в прочетения запис задейства DNS заявка и се брои към този лимит:

• include
• a
• mx
• ptr
• exists
• redirect

Ако оценката на SPF запис надхвърли лимита от 10 DNS заявки, получаващите имейл сървъри трябва да третират това състояние като постоянна грешка (PermError). Това означава, че имейлът може да бъде отхвърлен директно, независимо дали изпращачът е легитимен. Тъй като механизмите include и redirect могат да съдържат вложени записи, които също изискват DNS заявки, рекурсивният брой на заявките често надхвърля първоначалната оценка на единичния запис.

Анализ на синтактични грешки и рискове в правилата

При съставянето на SPF записи администраторите често допускат грешки, които отслабват сигурността или нарушават работата на пощата. Инструментът идентифицира следните проблеми:

• Невалидни адреси: Неправилно въведени IPv4 или IPv6 адреси или CIDR диапазони.
• Излишни или дублирани термини: Наличие на повече от един механизъм all, което затруднява прегледа, или дублирани модификатори.
• Недостижими термини: Всеки термин, поставен след механизма all, остава недостижим по време на SPF оценката и се игнорира.
• Конфликт между redirect и all: Ако записът съдържа едновременно redirect и all, модификаторът redirect се игнорира.
• Остарели механизми: Публикуването на механизма ptr не се препоръчва, тъй като той е бавен и ненадежден.
• Прекалено либерални правила: Квалификаторът +all разрешава изпращането от абсолютно всеки сървър в света, което напълно обезсмисля SPF защитата. Квалификаторът ?all връща неутрален резултат и не дава на получателите ясни насоки за прилагане на правилата.
• Липса на крайна политика: Ако записът няма нито all, нито redirect, несъвпадащите податели получават неутрален резултат по подразбиране.

Локална проверка срещу пълна DNS заявка

Инструментът „Проверка на SPF запис“ извършва локална проверка на синтаксиса и оценка на заявките само за първия въведен запис. Важно е да се разбере разликата между този анализ и реалната оценка от пощенски сървър:

Локалната проверка е изключително полезна за бърз преглед на синтаксиса и откриване на очевидни грешки преди публикуването на записа в DNS. Тя обаче не може да гарантира, че крайният получаващ сървър ще приеме записа като валиден, ако вложените в него външни домейни съдържат грешки или надхвърлят лимита от 10 заявки.

Поверителност и обработка на данните

Когато използвате инструмента „Проверка на SPF запис“, обработката на въведения текст се извършва изцяло локално във вашия уеб браузър. Вашият SPF запис остава в браузъра ви; BroBroGo не го качва и не го запазва на сървъри. Страницата не прави външни DNS заявки, не разгъва записи на доставчици, не тества IP адреси и не комуникира с получаващи пощенски сървъри.

Често задавани въпроси

Как се изчислява прогнозният брой SPF DNS заявки?

Оценката брои термините include, a, mx, ptr, exists и redirect в поставения запис. Включените и пренасочените записи могат да добавят още заявки, затова локалната проверка не може да определи крайния рекурсивен брой.

Какво става, ако SPF изисква повече от 10 DNS заявки?

SPF получателите трябва да третират оценка, която надхвърля ограничението от 10 термина с DNS заявки, като постоянна грешка. Ограничението обхваща цялата верига include и redirect, а не само първия запис.

Чистият резултат доказва ли, че SPF настройката ми работи?

Не. Тази страница проверява само текста, който поставите. Тя не прави DNS заявки, не разгъва записи на доставчици, не тества IP адрес на подател и не потвърждава какво ще върне получаващият пощенски сървър.

Как се обработват оградените с кавички записи?

Приемат се оградени с кавички части от DNS TXT, които се обединяват автоматично преди извършването на анализа.