SPF на практика: всички податели на едно място

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

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

Ключови понятия: инвентаризация на подателите, подател в плика (envelope sender, 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 sender, т.е. Return-Path), а не адреса в From. Много услуги за бюлетини и изпращане използват 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 е преминал успешно и е подравнен“. За DMARC softfail просто означава „неуспешно“. Истинската защита идва от строга 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)
• Gmail и Outlook.com с Вашия собствен домейн 2.4: SPF и DKIM, когато изпращате чрез Gmail