SPF Запис на синтаксиса

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

Не са един dmarcian сметка? Все още можете да питате съдържанието на вашето SPF запис с помощта на нашия SPF Инструмент за анкета.

Създай безплатен акаунт сега да има dmarcian следете вашия SPF, DKIM и DMARC записва автоматично за вас. Получавайте видимост на инстанциите в грешки при доставката, фишинг и опити за представяне dmarcianЕ SaaS платформа.

Използвайте навигационното меню малко по-долу, за да преминете към конкретния елемент от вашия SPF въпросния запис. Допълнителна информация за SPF може да намерите в свързаните статии в долната част на този документ.

механизми

Механизми могат да се използват за описване на множеството хостове, които са определени за изходящи пощенски кутии за домейна и могат да бъдат предшествани с един от четирите квалификатора:

+ (Проход)
- (Fail)
~ (SoftFail)
? (Neutral)

Ако даден механизъм води до хит, се използва неговата квалификационна стойност. Квалификаторът по подразбиране е „+“, Т.е.“ Pass ”.

Механизмите се оценяват по ред. Ако няма съвпадение на механизъм или модификатор, резултатът по подразбиране е „Neutral“.

По-подробна информация за разликите между „~"А"-" може да се намери тук

Примери:

"v = spf1 -all"

"v = spf1 a-all"

"v = spf1 a mx-all"

"V = spf1 + a + mx -all"

Ако домейн няма SPF запишете въобще, резултатът е „Няма“. Ако един домейн има временна грешка по време на обработка на DNS, получавате резултата „TempError“ (наричан „грешка“ в по-ранните чернови). Ако възникне някаква грешка в синтаксиса или оценката (напр. Домейнът определя неразпознат механизъм), резултатът е „PermError“ (по-рано „неизвестен“).

Оценка на SPF запис може да върне всеки от тези резултати:

Резултат Обяснение Предвидено действие
Pass SPF записът означава, че на хостът е позволено да изпраща приеми
Fail SPF записът е определил че на хоста НЕ е позволено да изпраща отхвърли
SoftFail SPF записът е определил, че на хоста НЕ е позволено да изпраща, но е в преход приеми, но маркирай
Neutral Най- SPF запис изрично уточнява, че нищо не може да се каже за валидност приеми
None Домейнът няма SPF запис или SPF записът не води до резултат приеми
PermError Възникнала е постоянна грешка (например неправилно форматиран SPF запис) неуточнен
TempError Възникна преходна грешка приеми или отхвърли

Механизмът "всички"

all

Този механизъм винаги съвпада. Винаги трябва да е в края на SPF запис.

Примери:

"v = spf1 mx -all"
Разрешаване на MX от домейн да изпращат поща за домейна, да забраняват всички останали.

"v = spf1 -all"
Домейнът изобщо не изпраща поща.

"v = spf1 + all"
Домейнът позволява на всички IP адреси в интернет да изпращат поща. Въпреки че е „валидно“, това не се препоръчва.

Механизмът "ip4"

ip4: <ip4-адрес>
ip4: <ip4 мрежа> / <префикс дължина>

Аргументът за механизма “ip4:” е мрежовият обхват на IPv4. Ако не е сrefix дължина е дадено, / 32 се приема (обозначава индивидуален адрес на хост). Внимавайте да включите дължина на префикса по-голяма от / 16, тъй като може да се повлияе доставката на малки по-малки приемници.

Примери:

"v = spf1 ip4: 192.168.0.1 / 16 -all"
Позволете всеки IP адрес между 192.168.0.1 и 192.168.255.255.

Механизмът "ip6"

ip6: <ip6-адрес>
ip6: <ip6 мрежа> / <префикс дължина>

Аргументът за механизма “ip6:” е мрежовият обхват на IPv6. Ако не префикс дължина е дадено / 128 (приема се отделен адрес на хост).

Примери:

“v=spf1 ip6:1080::8:800:200C:417A/96 -all”
Разрешаване на всеки IPv6 адрес между 1080 :: 8: 800: 0000: 0000 и 1080 :: 8: 800: FFFF: FFFF.

“v=spf1 ip6:1080::8:800:68.0.3.1/96 -all”
Разрешаване на всеки IPv6 адрес между 1080 :: 8: 800: 0000: 0000 и 1080 :: 8: 800: FFFF: FFFF.

Механизмът "а"

a
а / <префикс дължина>
а: <домейн>
а: <домейн> / <префикс дължина>

Всички записи на A за домейн са тествани. Ако клиентският IP е намерен сред тях, този механизъм съвпада. Ако връзката е направена през IPv6, вместо това се извършва търсене в AAAA.

If домейн не е посочен текущият-домейн се използва.

Записите A трябва да съответстват точно на IP клиента, освен ако a префикс дължина е предоставен, в който случай всеки IP адрес, върнат от търсенето на А, ще бъде разширен до съответния му префикс CIDR, а клиентският IP ще бъде търсен в тази подмрежа.

Примери:

"v = spf1 a-all"
Използва се текущият домейн.

"v = spf1 a:example.com -all"
Еквивалентен, ако текущият домейн е example.com.

"v = spf1 a:mailers.example.com -all"
Може би example.com е избрал изрично да посочи всички изходящи пощенски адреси в специален запис А под mailers.example.com.

„v = spf1 a / 24 a: offsite.example.com/24 -all“
Ако example.com премине към 192.0.2.1, целият клас C на 192.0.2.0 / 24 ще бъде претърсен за клиентския IP. По същия начин за offsite.example.com. Ако са върнати повече от един запис А, всеки от тях ще бъде разширен до CIDR подмрежа.

Механизмът "mx"

mx
х / <префикс дължина>
х <домейн>
х <домейн> / <префикс дължина>

Всички записи на A за всички записи MX домейн се тестват по реда на приоритета MX. Ако клиентският IP е намерен сред тях, този механизъм съвпада.

If домейн не е посочен текущият-домейн се използва.

Записите от А трябва да съвпадат точно с IP клиента, освен ако не е осигурена дължина на префикс, в който случай всеки IP адрес, върнат от търсене, ще бъде разширен до съответния CIDR префикс, а клиентският IP ще бъде търсен в тази подмрежа.

Примери:

"v = spf1 mx mx: deferrals.domain.com -all"
Може би домейн изпраща поща чрез своите MX сървъри плюс друг набор от сървъри, чиято задача е да се опита отново да изпрати поща за отлагане на домейни.

"v = spf1 mx / 24 mx: offsite.domain.com/24 -all"
Възможно е MX сървърите на домейн да получават поща на един IP адрес, но да изпращат поща на различен, но близък IP адрес.

Механизмът "ptr"

PTR
PTR: <домейн>

Името на хоста или имената на хостове за IP клиента се разглеждат с помощта на PTR заявки. След това имената на хостовете се проверяват: поне една от записите на A за име на хост на PTR трябва да съответства на оригиналния клиентски IP. Невалидните имена на хоста се отхвърлят. Ако валидно име на хост завършва с домейн, този механизъм съвпада.

Ако домейнът не е посочен, се използва текущият-домейн.

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

Примери:

"v = spf1 ptr -all"
Домейн, който директно контролира всичките му машини (за разлика от dialup или широколентов ISP), позволява на всичките му сървъри да изпращат поща. Например hotmail.com или paypal.com може да направят това.

"v = spf1 ptr: otherdomain.com -all"
Всеки сървър, чието име на хост завършва в otherdomain.com, е определен.

Механизмът "съществува"

съществува: <домейн>

Извършете A заявка за предоставения домейн. Ако бъде намерен резултат, това представлява съвпадение. Няма значение какъв е резултатът от търсенето - той може да бъде 127.0.0.2.

Когато използвате макроси с този механизъм, можете да изпълнявате обратни IP-заявки в стил RBL или да настройвате изключения на потребител.

Примери:

В следващия пример клиентският IP е 1.2.3.4, а текущият домейн е example.com.

"V = spf1 съществува: example.com-всички"

Ако example.com не разреши, резултатът е неуспешен. Ако се реши, този механизъм води до съвпадение.

Механизмът "include"

include: <домейн>

За посочения домейн се търси съвпадение. Ако търсенето не върне съвпадение или грешка, обработката преминава към следващата директива. предупреждение: Ако домейн няма валидна SPF запис, резултатът е постоянна грешка. Някои приемници на поща ще отхвърлят въз основа на a PermError.

Примери:

В следващия пример клиентският IP е 1.2.3.4, а текущият домейн е example.com.

"v = spf1 включва: example.com -all"

Ако example.com няма SPF запис, резултатът е PermError.
Да предположим, че example.com SPF запис бяха "v = spf1 a-all".
Потърсете запис A за example.com. Ако съвпада с 1.2.3.4, върнете Pass.
Ако няма съвпадение, освен включения в домейна „-всеки“, включването като цяло не съвпада; евентуалният резултат все още е Fail от външната директива, зададена в този пример

Доверителни отношения - Механизмът „include:“ е предназначен да прекоси административните граници. Необходима е голяма грижа, за да се гарантира, че механизмите „include:“ не поставят домейни, които са изложени на риск, за да дадат SPF Pass резултати на съобщения, които са резултат от фалшифициране на фалшиви потребители. Освен ако не са налице технически механизми в посочения друг домейн, за да се предотврати фалшифицирането на кръстосани потребители, „include:“ механизмите трябва да дават неутрален резултат, а не резултат. Това се прави чрез добавяне на “?” Пред “include:”.

След това примерът ще бъде:

"v = spf1? include: example.com -all"

Модификатори

Модификаторите не са задължителни. Модификаторът може да се появи само веднъж за запис. Неизвестните модификатори се игнорират.

Модификаторът "redirect"

redirect = <домейн>

Най- SPF запис за домейн замени текущия запис. Макро-разширения домейн също се заменя с текущият-домейн в тези прегледи.

Ако се използва модификатор за пренасочване, то SPF записът също не трябва да включва механизма „всички“. Ако и двете присъстват, модификаторът за пренасочване се игнорира. Всички модификатори за пренасочване извън първия ще бъдат игнорирани.

Примери:

В следващия пример клиентският IP е 1.2.3.4, а текущият домейн е example.com.

"v = spf1 redirect = example.com"

Ако example.com няма SPF запис, това е грешка; резултатът е неизвестен.
Да предположим, че example.com SPF запис беше "v = spf1 a-all".
Потърсете запис A за example.com. Ако съвпада с 1.2.3.4, върнете Pass.
Ако няма съвпадение, екзекуцията не може да съвпадне и се използва всяка стойност.

Модификаторът "exp"

ехр = <домейн>

Ако SMTP приемник отхвърля съобщение, той може да включва обяснение. Една SPF издателят може да посочи обяснителния низ, който виждат изпращачите. По този начин ISP може да насочи несъответстващите потребители към уеб страница, която предоставя допълнителни инструкции за конфигуриране на SASL.

Домейнът е разширен; се извършва TXT търсене. Резултатът от TXT заявката след това се разширява макро и се показва на подателя. Други макроси могат да бъдат използвани за предоставяне на персонализирано обяснение.

Модификаторът на exp може да съдържа само отпечатвани ASCII символи.

Твърде много търсения?

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

В рамките на SPF RFC спецификация (по същество закон за интернет) е тяхната практическа граница за това колко „DNS-механизми за запитване“ са единични SPF запис може да съдържа. Тази граница е десет. Десетте максимални търсения заявяват, че администраторът на домейн (това сте вие!) Няма да изисква харесванията на Gmail или други приемници, за да извърши повече от десет последователни DNS търсения, за да провери дали упълномощавате определен IP адрес за изпращане на поща от ваше име.

Тъй като е станало някак обичайно за всяка отделна организация да разрешава голям брой разнопосочни мрежови блокове (поради външния вид на имейл инфраструктурата), остава това, което изглежда като постоянното и ненужно посегателство върху десетте макс търсене. Този лимит обаче остава изцяло практичен и трябва да се спазва, за да се гарантира навременна доставка и изгодни цени за входящи съобщения. Освен това решението за избягване на лимита е адресирано пряко от други най-добри практики за електронна поща, дълго насърчавани от основните входящи приемници като Gmail и Yahoo.

Единственото най-практично решение за избягване на проблема с „твърде много търсения“ е използването на поддомейни. Тъй като всеки отделен поддомейн се предлага, той притежава десет максимум търсене, SPF е ефективно безграничен. Пример: hello.com е позволено десет търсения + sub.hello.com е позволено десет търсения. Казано по-просто, никога не трябва да се изпълнявате до десетте максимални условия за търсене, ако правилно сегментирате различни пощенски потоци (напр. Транзакционни, корпоративни, маркетингови и т.н.), за да дискретизирате пространството с имена.

В този подраздел „Съвети за доставка“ на Сайт за пощенски майстори в Gmail, препоръчва се да;

  • Използвайте отделни имейл адреси
  • Изпращайте поща от различни домейни и / или IP адреси

В обобщение, никога не бива да влизате в максимума за търсене на 10. Ако го направите, ние очертахме някои допълнителни стратегии и материали на базата на знания за това как да навигирате.

Допълнителна Reading:

- Видео: Как SPF върши работа - връзка
- Допълнително четене на „твърде много търсения“ - връзка
- Чести погрешни схващания за SPF - връзка
- SPF Инструмент за геодезия - връзка

Искате ли да продължите разговора? Насочете се към dmarcian форум