SPF на практика: картографиране на всички изпращачи

Модул 4: Доставимост: SPF, DKIM и DMARC на практика · Време за четене: 12 минути

Учебна цел: След този урок ще можете да откриете всички услуги, които изпращат поща от името на Вашия домейн, да ги включите в един SPF запис, да преброите рекурсивно справките до границата от десет и съзнателно да изберете между ~all и -all.

Основни понятия: инвентаризация на изпращачите, envelope подател (Return-Path), един SPF запис, include, redirect, лимит от 10 DNS справки (RFC 7208, параграф 4.6.4), празни справки (void lookups, максимум 2), рекурсивно броене, permerror, flattening, SPF за поддомейни, SPF на домейн, който не изпраща поща, ~all и -all

Кратко припомняне

SPF записът е TXT запис на Вашия домейн, който започва с v=spf1 и изброява кои сървъри имат право да изпращат поща от името на Вашия домейн. Структурата, знаците + - ~ ? и трите най-известни грешки (два записа, +all, повече от десет справки) са описани в DNS курса, урок 4.3. Прочетете го първо, ако SPF е нещо ново за Вас. Този урок разглежда трудната част: на практика почти никой не знае точно кои всички изпращат поща от името на неговия домейн.

Стъпка 1: инвентаризацията

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

Два добри начина да ги откриете:

1. Четене на копрегелите. Изпратете си от всяка система имейл до себе си (фактура, възстановяване на парола, тестов бюлетин) и проверете в копрегелите Return-Path и Authentication-Results (урок 1.5). Там виждате през кой домейн и кой сървър е пристигнал.
2. DMARC отчети. Задайте DMARC на p=none с адрес за отчети (урок 4.4). След няколко седмици в отчетите (урок 4.5) ще видите всеки сървър, който е изпращал поща от името на Вашия домейн, включително такива, за които сте забравили. Това е най-надеждната инвентаризация.

Не всяка услуга принадлежи към Вашия SPF

Тук често се допускат грешки. SPF проверява envelope подателя (Return-Path), а не адреса в полето От. Много услуги за бюлетини и изпращане използват Return-Path на собствения си домейн, например bounce-123@mail.mailer.example. Получателят тогава проверява SPF записа на mailer.example, а не Вашия. Включването (include) на тази услуга във Вашия запис тогава не прави нищо, освен че Ви коства една справка.

Това, от което тази услуга наистина има нужда, за да премине DMARC, е DKIM подпис с Вашия домейн (урок 4.3), или собствен поддомейн на Return-Path от Вас (например bounce.example.com като CNAME към услугата). Затова прочетете в документацията на услугата какво изисква тя. Ако пише „добавете include: във Вашия SPF“, направете го. Ако пише само „създайте тези CNAME записи за DKIM и bounce домейна“, тогава не е нужно нищо в основния Ви запис. Модул 7 разглежда това по-подробно.

Стъпка 2: един запис и правилно броене

Всички изпращачи влизат в един запис. Да предположим, че инвентаризацията Ви показва следното: пощенският сървър на Вашия хостинг доставчик, Microsoft 365 за няколко служители, Вашата счетоводна програма и helpdesk. Тогава записът изглежда например така:

example.com.  3600  IN  TXT  "v=spf1 a mx include:spf.hosting.example include:spf.protection.outlook.com include:_spf.boekhoud.example include:mail.helpdesk.example ~all"

Колко справки е това? Пребройте всеки a, mx, include, exists, ptr и redirect, и след това пребройте и всичко, което стои в записите зад всеки include:

При 11 получателят връща permerror: целият SPF запис тогава не се зачита, за нито един изпращач. Пощата от Вашия собствен пощенски сървър тогава се оценява по-зле, защото helpdesk-ът коства три справки. И коварното е, че Вашият запис може днес да е 9, а утре 11, без Вие да сте променили каквото и да било, защото дадена услуга разширява собствения си запис.

Освен това: максимум две празни справки

RFC 7208 споменава и void lookups: справки, които не дават никакъв резултат (името не съществува или няма SPF или адресен запис). Повече от две от тях също водят до permerror. Това се случва най-вече при стари include записи на услуги, които вече не ползвате и които са премахнали собствения си запис, или при a: към сървър, който вече не съществува. Затова е нужно почистване.

Стъпка 3: обратно под десет

Ако сте над десет, има четири решения, подредени от най-добро до най-слабо:

1. Премахнете ненужното. Услуги, които вече не ползвате. Услуги, които изпращат със собствен Return-Path (вижте по-горе) и затова не принадлежат към Вашия SPF. a, ако Вашият уебсайт сам по себе си не изпраща поща. mx, ако Вашият MX сочи към услуга, която вече фигурира с include във Вашия запис.
2. Използвайте поддомейн. Нека дадена услуга изпраща от nieuws.example.com или factuur.example.com. Този поддомейн получава собствен SPF запис само с тази услуга и не се брои в десетте справки на основния Ви домейн. Подравняването при DMARC (урок 4.4) по подразбиране работи и за поддомейни.
3. Използвайте ip4: и ip6: за собствените си постоянни сървъри. Те не изискват справка. Правете това само за адреси, които управлявате сами и които не се променят.
4. Flattening (замяна на всички include с IP адресите, които стоят зад тях към момента). Това намалява броя до 0, но записът вече не отговаря на действителността веднага щом дадена услуга промени своите адреси, а големите услуги правят това редовно. Правете го само с инструмент, който го поддържа автоматично, а най-добре изобщо не го правете.

redirect или include?

redirect= означава: използвайте SPF записа на другия домейн вместо този запис. Коства една справка, точно както include. Полезно е, ако имате много домейни, които трябва да получат точно еднаква политика: v=spf1 redirect=_spf.example.com на всеки домейн, а реалният запис на едно единствено място. Запис с redirect= не може да съдържа all, защото тогава redirect се игнорира. Gmail го използва сам: gmail.com има v=spf1 redirect=_spf.google.com.

Стъпка 4: ~all или -all?

Препоръката на този курс, съвпадаща с тази от DNS курса:

• Започнете с ~all (softfail). Пощата от сървър, който не фигурира във Вашия запис, се счита за подозрителна, но обикновено не се отхвърля веднага. Пропуснете ли изпращач, щетата е ограничена.
• Преминете към -all (fail), когато сте сигурни, че всички изпращачи са включени, например след като сте прегледали DMARC отчетите в продължение на няколко седмици и вече няма неизвестни източници.

При наличие на DMARC разликата е по-малка, отколкото често се смята. DMARC взема решение въз основа на „SPF или DKIM успешни и подравнени“. Softfail за DMARC означава просто „неуспешно“. Истинската защита идва следователно от строга DMARC политика, а не от -all. Някои получатели отхвърлят още при -all, преди оценката на DMARC; това е причина да изберете -all едва когато Вашият запис наистина е пълен.

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

Имате ли домейни, които никога не изпращат поща (старо име на марка, домейн за правописни грешки)? Защитете ги срещу злоупотреба със следното:

example.org.         IN  TXT  "v=spf1 -all"
_dmarc.example.org.  IN  TXT  "v=DMARC1; p=reject"
example.org.         IN  MX   0 .

Тук -all е правилен избор веднага: никой няма право да изпраща поща. Последният ред е null MX (RFC 7505): „този домейн не получава поща“. example.com самият е настроен точно по този начин.

На практика: ето как изглежда това в панел

При хостинг пакет на WebOké по подразбиране стои v=spf1 a mx include:webawere.nl ~all. Добавите ли услуга, коригирате този запис (в DirectAdmin: DNS Management, иконата с молив до SPF записа, поле Include Domain; в Моят WebOké: помощникът за SPF в раздела DNS). Оставете include:webawere.nl, докато Вашата поща или уебсайт минават през тези сървъри. При други доставчици стандартният include се казва различно, но принципът е същият: допълвайте, не създавайте втори запис.

Обобщение

• Направете първо инвентаризация на всички изпращачи; DMARC отчетите и копрегелите помагат за това.
• Услуга със собствен Return-Path не принадлежи към Вашия SPF; на нея ѝ трябва DKIM с Вашия домейн.
• Брройте рекурсивно: всеки include, a, mx, exists, ptr и redirect, включително вътре в include записите. Над десет, или повече от две празни справки, означава permerror.
• Върнете се под десет чрез почистване и използване на поддомейни; flattening само с автоматична поддръжка.
• Започнете с ~all, преминете към -all, когато сте сигурни. Домейни, които никога не изпращат поща: -all, DMARC reject и null MX.

Тест

Задача

Задача Z4.2: Рекурсивно преброяване на SPF на Вашия домейн. Въведете собствения си домейн (или sidn.nl, ако нямате собствен домейн). Пребройте сами първо колко DNS справки струва SPF записът, включително всичко в рамките на include записите, и въведете числото, заедно с края на записа (~all, -all, ?all или +all). Програмата преброява на живо и проверява, включително празните справки, и показва дървото.

Задача O4.2: Вашата инвентаризация на подателите. Съставете с помощта на таблицата от този урок списък на всички системи, които изпращат поща от името на Вашия домейн. За всяка посочете: през кой сървър или услуга, дали трябва да фигурира във Вашия SPF (собствен Return-Path или не), и дали подписва с DKIM с Вашия домейн. Изпратете от поне две системи тестов имейл до себе си и запишете от копрегелите домейна на Return-Path и домейна на DKIM (d=).

Прочетете още

Стъпките в тези статии важат за панелите на WebOké; при други доставчици работи по подобен начин.

• Безплатен курс по DNS 4.3: SPF: кой може да изпраща имейли от името на Вашия домейн?
• Ръководство за DirectAdmin 5.7: Настройка и допълване на SPF
• Как работи SPF записът в DNS?
• Добавяне или промяна на SPF запис в DirectAdmin
• Ръководство на WebOké 5.5: DNS помощници: MX, SPF, DMARC, CAA и SRV
• RFC 7208 (SPF), параграф 4.6.4 (лимити) и 6.1 (redirect); RFC 7505 (null MX)