Defaults.Exposed › Поправки › Guides

Препратената поща не минава SPF — Защо не можете да го поправите и какво действително работи (2026)

Публикувано 2026-07-08

Данни към 2026-06-29 · методология v7. Агрегирани census данни от 261 милиона оценени домейна. Вижте как оценяваме.

Не можете да накарате SPF да мине за препратена поща — препращането чупи SPF по дизайн, а честната поправка е aligned DKIM, оцеляващ при препращане. Мащабът е в целия census: 7,355,985 от 138,927,207 SPF-публикуващи домейна оторизират forwarding include на Namecheap само, с дял строг SPF от <0.1%, според census-а на Defaults.Exposed от 261 милиона домейна.

По-долу: защо никакъв SPF запис не оцелява при препращане, защо SRS и ARC не са инструменти, които вие контролирате, и поправката, издържаща — DKIM подписване с вашия собствен домейн като DMARC pass — плюс единственият случай, чупещ и DKIM (пощенски списъци, презаписващи съобщения), и какво да правите с тази остатъчна фракция.

Защо препращането чупи SPF?

Получателите оценяват SPF спрямо домейна на Return-Path (RFC5321.MailFrom), а не хедъра From. Когато изпращате директно, IP-то на сървъра ви е в SPF записа ви и проверката минава. Когато получателят ви автоматично препраща съобщението — до личен Gmail, чрез университетски псевдоним, чрез продукт за препращане на регистратор — сървърът на препращащия го ретранслира, обикновено запазвайки домейна ви в Return-Path. Крайният получател сега пита: оторизиран ли е този препращащ сървър в SPF записа ви?

Не е, и никога няма да бъде: не сте избрали препращащия, не знаете, че съществува, и същото съобщение, препратено чрез различна услуга утре, ще не мине от различно IP. SPF отговаря на един въпрос — „дошло ли е това IP от сървър, оторизиран от домейна Return-Path?” — и за препратена поща верният отговор е не. Неуспехът е SPF, работещ по спецификация, а не грешен запис.

Census-ът показва колко масов е този маршрут: 7,355,985 домейна оторизират forwarding include на Namecheap (spf.efwd.registrar-servers.com) — продукт за препращане на един доставчик, извлечен от 139 милиона SPF публикуващи — с дял строг SPF от <0.1% и само 0.2% прилагащи DMARC. Този мек шаблон не е небрежност: препращането е именно там, където строг -all се проваля, а доставчикът, чийто продукт е препращане, го предоставя съответно. Пълната история за квалификаторите е в нашия доклад ~all срещу -all, а картината по доставчик е в кой имейл доставчик дава най-силния SPF.

Не мога ли просто да добавя сървъра на препращащия към SPF записа?

Не — и защо е цялата статия:

1. Не можете да изброите препращащите. Всеки получател, навсякъде, може да препрати пощата ви чрез всяка услуга. SPF записът ви ще трябва да изброи сървъри, за които не можете да знаете предварително.
2. Изброяването им би победило целта. Големите услуги за препращане ретранслират поща за милиони клиенти. Поставете техните диапазони в записа и всяко съобщение, ретранслирано от техни потребители — включително на спуфъра — минава SPF като вас.

Същата логика изключва разхлабването на квалификатора „за да работи препращането”: квалификаторът не е причината препратената поща да не минава, а след като DMARC е в игра, променя по-малко от това, което твърдят повечето ръководства — вижте данните за квалификатора. Записът не е лостът тук. Спрете да го дърпате.

Какво да правим за SRS и ARC — нали те поправят препращането?

Те се занимават с него — но никедно от двете не е ваше за внедряване:

Данни и статус на механизма към 2026-06-29.

SRS прави SPF проблема на препращащия да изчезне, не вашия: презаписването на Return-Path променя чий SPF се проверява, докато хедърът ви From — домейнът, защитаван от DMARC — остава непокътнат. ARC е решение за доверие между операторите на инфраструктура. Ако ръководство ви казва да „внедрите SRS” като собственик на домейн, то ви е объркало с доставчика на препращане.

Как да накарам имейла да оцелее при препращане?

Направете DKIM, aligned с вашия домейн, ваш DMARC pass. DKIM подписът е криптография, пренасяна в хедърите на съобщението: верифицира се където и да свърши съобщението, през колкото сървъра е ретранслирало, стига подписаното съдържание да не е модифицирано. DMARC изисква само един aligned pass — SPF или DKIM — така че когато препращането убие крака SPF, aligned DKIM запазва съобщението автентикирано.

1. Стартирайте безплатното сканиране на defaults.exposed преди да докосвате DNS. Показва дали имате DKIM изобщо, дали подписва с вашия домейн и каква е позицията ви за DMARC — за да поправите реалната пропаст вместо да се борите с SPF записа.
2. Потвърдете, че препращането действително е проблемът. В хедъра Authentication-Results на засегнато съобщение, директната поща минава SPF, докато препратеното копие не минава от IP-то на препращащата услуга. Ако SPF и DKIM минават, но DMARC все пак не минава, имате проблем с alignment вместо — вижте DMARC не минава, но SPF и DKIM минават.
3. Включете DKIM подписване с вашия собствен домейн при всяка изпращаща услуга — първо при доставчика на пощенска кутия, след това при ESP и транзакционни изпращачи. Стандартните настройки на доставчика часто подписват с домейна на доставчика, несъвпадащ; искате d=yourdomain. Започнете от как да поправите DKIM, с пътеводители за Google Workspace и Microsoft 365.
4. Верифицирайте alignment-а, а не само pass. Домейнът d= в подписа трябва да съвпада с вашия From домейн; dkim=pass при чужд домейн не прави нищо за DMARC-а ви.
5. Оставете SPF записа си непроменен. Запазете го точен за директната ви поща — все още автентикира по-голямата част от трафика ви и остава вторият ви DMARC крак. Просто спрете да се опитвате да го накарате да покрива препращащи.
6. Направете ново сканиране, след това планирайте DMARC прилагане — следващ раздел и ръководството за внедряване от p=none до p=reject.

Тази комбинация — SPF плюс прилагащ DMARC, носен от aligned DKIM — е шаблонът, устойчив на препращане, и е рядкост: от 77.5 милиона домейна, публикуващи ~all, само 9.2% (7,116,774) го подкрепят с прилагаща DMARC политика, а само 3.87% от 261 милиона оценени домейна (10,092,481) завършват пълната триада SPF + DKIM + приложен DMARC, по данните от census-а (2026-06-29).

Какво да правя с пощенски списъци, презаписващи съобщения?

Единственият маршрут за препращане, при който aligned DKIM не оцелява: пощенски списъци, модифициращи съобщението — таг [list-name] в темата, footer за отписване, премахнато прикачване. Сменете подписаното съдържание и body hash-ът вече не съвпада, така че DKIM не минава и (dkim=fail: body hash did not verify е собственото ръководство на тази грешка). Сега и двата DMARC крака са мъртви, а само списъкът може да смекчи (презаписване на From, ARC запечатване).

Именно за тази остатъчна фракция съществува поетапното DMARC прилагане. Преминаването през p=quarantine с pct рамп, докато следите агрегираните доклади, показва каква реална поща тече през презаписващите списъци преди политика p=reject да започне да я отхвърля. Не прескачайте до reject при домейн, чиито потребители живеят в пощенски списъци; не стойте на p=none завинаги. Ръководството за поетапно внедряване разглежда постепенното повишаване.

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

Препращането чупи ли и DKIM? Обикновено препращане — не: подписът пътува с съобщението и се верифицира при крайния получател. DKIM се чупи само когато подписаното съдържание е модифицирано при транзит — тагове в темата и footer-и на пощенски списъци са класическият случай — ето защо остатъкът от списъците се обработва от планиране на DMARC политика, а не от нищо в DNS.

Трябва ли да превключа от -all към ~all, за да спра препращането да не минава? Промяната на квалификатора няма да накара препращащите да минат — не затова не минават. Показателно е, че forwarding include на Namecheap, 7,355,985 домейна и най-голямото население, посветено на препращане в census-а (2026-06-29), се доставя с дял строг SPF от <0.1%: мекият SPF е може би правилният шаблон за продукт за препращане. Вижте доклада ~all срещу -all за това какво всъщност променя квалификаторът.

Защо пощата ми минава SPF при директно изпращане, но не минава при препращане? Получателят проверява дали IP-то на последния предаващ сървър е оторизирано от SPF записа на домейна Return-Path. Директно: вашият сървър, в записа ви, pass. Препратено: сървърът на препращащия, не в записа ви, fail. Записът ви не се е променил — предаващото IP се е променило.

Мога ли да настроя SRS, за да поправя това? Само ако сте препращащият. SRS работи на сървъра, правещ препращането, и дори там, където работи, полученият SPF pass принадлежи на домейна на препращащия и не е aligned с вашия From — DMARC-ът ви все пак се нуждае от крака DKIM.

SPF безсмислен ли е, ако препращането го чупи? Не. По-голямата parte от пощата се доставя директно, където SPF работи точно по предназначение, и остава един от двата ви DMARC крака. От 261,086,232 домейна в census-а (2026-06-29), 138,927,207 публикуват SPF — запазете вашия точен чрез страницата за поправка на SPF и оставете DKIM да носи препратения остатък.

Изпратете доклада на собственика

Ако поправяте това за клиент или работодател, затворете цикъла с доказателства. След като персонализираният DKIM е активен и DMARC е планиран, пуснете отново безплатното сканиране и препратете оценения доклад на собственика на бизнеса: датиран, разбираем за обикновен човек, показващ, че домейнът остава автентикиран дори когато пощата му е препратена. Това е артефактът за подновяването на киберзастраховката и следващия въпросник на доставчик — документирано „преди и след”, а не „включих нещо”.

Проверете домейна → · DMARC не минава, но SPF и DKIM минават → · Поправете DKIM → · Как оценяваме → · Само агрегирани данни. Данните се съхраняват и обработват в ЕС.