Defaults.Exposed › رفع اشکالها › Guides
ایمیل Forwarded شده SPF را شکست میدهد — چرا نمیتوانید آن را رفع کنید، و چه چیزی واقعاً کار میکند (۲۰۲۶)
منتشرشده 2026-07-08
دادهها تا 2026-06-29 · روششناسی v7. دادههای سرشماری جمعی در 261 میلیون دامنه درجهبندیشده. ببینید چطور درجهبندی میکنیم.
نمیتوانید SPF را برای ایمیل forwarded شده تأیید کنید — forwarding به طور طراحی SPF را خراب میکند، و رفع صادقانه DKIM همراستا است که از forwarding جان سالم به در میبرد. مقیاس گسترده است: 7,355,985 از 138,927,207 دامنه منتشرکننده SPF به تنهایی include forwarding Namecheap را مجاز میدانند، با یک سهم strict-SPF <0.1٪، بر اساس سرشماری Defaults.Exposed از 261 میلیون دامنه.
در ادامه: چرا هیچ رکورد SPFی که بتوانید بنویسید از forwarding جان سالم به در نمیبرد، چرا SRS و ARC ابزارهایی نیستند که شما کنترل کنید، و رفعی که پایدار میماند — امضای DKIM با دامنه خودتان به عنوان تأیید DMARC — به علاوه یک حالتی که DKIM را هم خراب میکند (لیستهای پستی که پیامها را بازنویسی میکنند) و کار در آن مورد.
چرا forwarding SPF را خراب میکند؟
گیرندهها SPF را در مقابل دامنه Return-Path (RFC5321.MailFrom)، نه هدر From ارزیابی میکنند. وقتی مستقیم ارسال میکنید، IP سرور شما در رکورد SPF شما است و بررسی تأیید میشود. وقتی گیرندهتان پیام را به طور خودکار forward میکند — به یک Gmail شخصی، از طریق یک alias دانشگاهی، از طریق محصول forwarding یک registrar — سرور forwarder آن را مجدداً ارسال میکند، معمولاً دامنه شما را روی Return-Path نگه میدارد. گیرنده نهایی اکنون میپرسد: آیا این سرور forwarding در رکورد SPF شما مجاز است؟
نیست، و هرگز نخواهد بود: شما forwarder را انتخاب نکردید، نمیدانید وجود دارد، و همین پیام که فردا از طریق یک سرویس متفاوت forward شود از یک IP متفاوت شکست میخورد. SPF یک سؤال میپرسد — «آیا این IP از سروری که دامنه Return-Path مجاز دانسته آمده؟» — و برای ایمیل forwarded شده پاسخ واقعی خیر است. شکست، SPF است که طبق مشخصات کار میکند، نه رکورد شما که اشتباه است.
سرشماری نشان میدهد این مسیر چقدر رایج است: 7,355,985 دامنه include forwarding ایمیل Namecheap (spf.efwd.registrar-servers.com) را مجاز میدانند — محصول forwarding یک ارائهدهنده واحد، از 139 میلیون ناشر SPF — با سهم strict-SPF <0.1٪ و فقط 0.2٪ که DMARC را اجرا میکنند. آن الگوی soft بیتوجهی نیست: forwarding دقیقاً جایی است که یک -all سختگیرانه عمل نمیکند، و ارائهدهندهای که محصولش forwarding است بر این اساس ارسال میکند. داستان کامل qualifier در گزارش ~all در مقابل -all ما، و تصویر به تفکیک ارائهدهنده در کدام ارائهدهنده ایمیل قویترین SPF را میدهد.
آیا نمیتوانم فقط سرور forwarder را به رکورد SPF خودم اضافه کنم؟
خیر — و چرا کل مقاله است:
۱. نمیتوانید forwarder ها را شمارش کنید. هر گیرندهای، هر جایی، میتواند ایمیل شما را از طریق هر سرویسی forward کند. رکورد SPF شما باید سرورهایی را که نمیتوانید از قبل بدانید فهرست کند. ۲. فهرست کردن آنها هدف را شکست میدهد. سرویسهای forwarding بزرگ برای میلیونها مشتری ایمیل relay میکنند. محدوده آنها را در رکورد بگذارید و هر پیامی که هر کدام از کاربرانشان relay میکنند — از جمله جعلکننده — SPF را به عنوان شما تأیید میکند.
همان منطق qualifier شل کردن «برای کار کردن forwarding» را رد میکند: qualifier دلیل شکست ایمیل forwarded نیست، و وقتی DMARC در کار باشد کمتر از آنچه بیشتر راهنماها ادعا میکنند تغییر میکند — دادههای qualifier را ببینید. رکورد اینجا اهرم نیست. دست از کشیدن آن بردارید.
SRS و ARC چطور؟ آیا آنها forwarding را رفع نمیکنند؟
آنها به آن میپردازند — اما هیچکدام مال شما نیستند که deploy کنید:
| مکانیزم | وقتی ایمیل forward میشود چه میکند | چه کسی کنترل میکند | آیا DMARC شما را رفع میکند؟ |
|---|---|---|---|
| SPF | شکست میخورد: IP forwarder در رکورد شما نیست | شما آن را منتشر میکنید؛ forwarding آن را شکست میدهد | خیر |
| SRS (Sender Rewriting Scheme) | Forwarder Return-Path را به دامنه خودش بازنویسی میکند تا ارسال مجددش SPF را تأیید کند | Forwarder | خیر — تأیید SPF اکنون متعلق به دامنه forwarder است که با From شما همراستا نیست |
| ARC (RFC 8617) | Forwarder نتایج احراز هویت اصلی را مهر و موم میکند؛ گیرنده نهایی ممکن است به زنجیر مهر و موم شده اعتماد کند | Forwarder و گیرنده | بعضی اوقات — به اختیار گیرنده، نه شما |
| DKIM همراستا | امضا داخل پیام میرود و بعد از forwarding همچنان تأیید میکند، با دامنه شما روی آن | شما | بله |
وضعیت دادهها و مکانیزم تا 2026-06-29.
SRS مشکل SPF forwarder را از بین میبرد، نه مشکل شما: بازنویسی Return-Path تغییر میدهد SPF چه کسی بررسی میشود، در حالی که هدر From شما — دامنهای که DMARC از آن دفاع میکند — دست نخورده است. ARC یک تصمیم اعتماد بین اپراتورهای زیرساخت است. اگر یک راهنما به شما میگوید «SRS را به عنوان یک صاحب دامنه پیادهسازی کنید»، شما را با ارائهدهنده forwarding اشتباه گرفته است.
چطور ایمیلم را از forwarding جان سالم به در ببرم؟
DKIM همراستا با دامنهتان را به عنوان تأیید DMARC خود درست کنید. یک امضای DKIM رمزنگاری حمل شده در هدرهای پیام است: هر جایی که پیام برود، هر تعداد سرور که آن را relay کنند، تأیید میکند، مادامی که محتوای امضا شده تغییر نکرده باشد. DMARC فقط به یک تأیید همراستا نیاز دارد — SPF یا DKIM — پس وقتی forwarding پای SPF را از بین میبرد، DKIM همراستا پیام را احراز هویت شده نگه میدارد.
۱. قبل از لمس DNS، اسکن رایگان در defaults.exposed را اجرا کنید. نشان میدهد آیا اصلاً DKIM دارید، آیا با دامنه خودتان امضا میکند، و DMARC شما کجا ایستاده — پس شکاف واقعی را رفع کنید نه اینکه با رکورد SPF خود بجنگید.
۲. تأیید کنید forwarding واقعاً مشکل شما است. در هدر Authentication-Results یک پیام آسیب دیده، ایمیل مستقیم SPF را تأیید میکند در حالی که نسخه forwarded از IP سرویس forwarding شکست میخورد. اگر SPF و DKIM تأیید شوند اما DMARC همچنان شکست بخورد، به جای آن یک مشکل alignment دارید — DMARC شکست میخورد اما SPF و DKIM تأیید میشوند را ببینید.
۳. امضای DKIM با دامنه خودتان را در هر سرویس ارسالکننده روشن کنید — ابتدا ارائهدهنده صندوق پستی، سپس ESP ها و فرستندههای transactional. پیشفرضهای ارائهدهنده اغلب با دامنه ارائهدهنده امضا میکنند، که همراستا نیست؛ شما d=yourdomain میخواهید. از چطور DKIM را رفع کنیم شروع کنید، با مسیرهای کلیک برای Google Workspace و Microsoft 365.
۴. alignment را تأیید کنید، نه فقط یک تأیید. دامنه d= در امضا باید با دامنه From شما مطابقت داشته باشد؛ dkim=pass روی دامنه شخص دیگری برای DMARC شما هیچ کاری نمیکند.
۵. رکورد SPF خود را به حال خودش بگذارید. برای ایمیل مستقیمتان دقیق نگه دارید — همچنان بیشتر ترافیک شما را احراز هویت میکند و پای دوم DMARC شما باقی میماند. فقط دیگر سعی نکنید آن را به forwarder ها تعمیم دهید.
۶. دوباره اسکن کنید، سپس enforcement DMARC را عمداً مرحلهای پیش ببرید — بخش بعدی، و راهنمای rollout مرحلهای از p=none به p=reject.
این ترکیب — SPF به علاوه DMARC اجرایی سوار بر DKIM همراستا — الگوی مقاوم در برابر forwarding است، و نادر است: از 77.5 میلیون دامنهای که ~all منتشر میکنند، فقط 9.2٪ (7,116,774) آن را با یک سیاست DMARC اجرایی پشتیبانی میکنند، و فقط 3.87٪ از 261 میلیون دامنه درجهبندیشده (10,092,481) سهگانه کامل SPF + DKIM + DMARC-اجرایی را تکمیل میکنند، بر اساس سرشماری (2026-06-29).
لیستهای پستی که پیامها را بازنویسی میکنند چطور؟
یک مسیر forwarding که DKIM همراستا از آن جان سالم به در نمیبرد: لیستهای پستی که محتوا را اصلاح میکنند — یک تگ موضوع [list-name]، یک footer unsubscribe، یک پیوست striped شده. محتوای امضا شده را تغییر دهید و hash body دیگر مطابقت ندارد، پس DKIM نیز شکست میخورد (dkim=fail: body hash did not verify راهنمای آن شکست است). حالا هر دو پای DMARC مردهاند، و فقط لیست میتواند آن را کاهش دهد (بازنویسی From، مهر و موم ARC).
این باقیمانده دقیقاً همان چیزی است که enforcement مرحلهای DMARC برای آن است. حرکت از طریق p=quarantine با یک ramp pct در حالی که گزارشهای aggregate را تماشا میکنید نشان میدهد چقدر از ایمیل واقعی شما از طریق لیستهای بازنویسیکننده جاری میشود قبل از اینکه یک سیاست p=reject شروع به بانس کردن آنها کند. به reject در یک دامنهای که کاربرانش روی لیستهای پستی زندگی میکنند نپرید؛ در p=none هم برای همیشه متوقف نشوید. راهنمای rollout مرحلهای ramp را توضیح میدهد.
پرسشهای متداول
آیا forwarding DKIM را هم خراب میکند؟ forwarding ساده، خیر: امضا با پیام میرود و در گیرنده نهایی تأیید میکند. DKIM فقط وقتی محتوای امضا شده در حین انتقال تغییر میکند شکست میخورد — تگهای موضوع لیستهای پستی و footer ها حالت کلاسیک هستند — که به همین دلیل باقیمانده لیست با مرحلهبندی سیاست DMARC مدیریت میشود، نه با چیزی در DNS.
آیا باید از -all به ~all تغییر دهم تا forwarding دیگر شکست نخورد؟ تغییر qualifier باعث نمیشود forwarder ها تأیید شوند — این دلیل شکست آنها نیست. این نکتهای است که include forwarding Namecheap، 7,355,985 دامنه و بزرگترین جمعیت forwarding اختصاصی سرشماری (2026-06-29)، با یک سهم strict-SPF <0.1٪ ارسال میکند: soft SPF احتمالاً الگوی صحیح برای یک محصول forwarding است. برای آنچه qualifier واقعاً تغییر میدهد گزارش ~all در مقابل -all را ببینید.
چرا ایمیلم وقتی مستقیم ارسال میشود SPF را تأیید میکند اما وقتی کسی آن را forward میکند شکست میخورد؟ گیرنده بررسی میکند آیا IP آخرین سرور ارسالکننده توسط رکورد SPF دامنه Return-Path مجاز شده است. مستقیم: سرور شما، در رکورد شما، تأیید. Forwarded: سرور forwarder، نه در رکورد شما، شکست. رکورد شما تغییر نکرد — IP ارسالکننده تغییر کرد.
آیا میتوانم SRS را برای رفع این تنظیم کنم؟ فقط اگر شما forwarder باشید. SRS روی سرور انجامدهنده forwarding اجرا میشود، و حتی جایی که اجرا میشود، تأیید SPF بهدستآمده متعلق به دامنه forwarder است و با From شما همراستا نیست — DMARC شما همچنان به پای DKIM نیاز دارد.
آیا SPF اگر forwarding آن را خراب کند بیفایده است؟ خیر. بیشتر ایمیلها مستقیم تحویل میشوند، جایی که SPF دقیقاً طبق طراحی کار میکند، و یکی از دو پای DMARC شما باقی میماند. از 261,086,232 دامنه در سرشماری (2026-06-29)، 138,927,207 SPF را منتشر میکنند — مال خودتان را از طریق صفحه رفع SPF دقیق نگه دارید، و اجازه دهید DKIM باقیمانده forwarded را حمل کند.
گزارش را به صاحب ارسال کنید
اگر این را برای یک مشتری یا کارفرمایتان رفع میکنید، حلقه را با شواهد ببندید. وقتی DKIM دامنه سفارشی زنده است و DMARC مرحلهبندی شده، اسکن رایگان را دوباره اجرا کنید و گزارش درجهبندیشده را برای صاحب کسبوکار ارسال کنید: تاریخدار، با زبان ساده، نشاندهنده اینکه دامنه حتی وقتی ایمیلش forward میشود احراز هویت شده باقی میماند. این همان چیزی است که برای تمدید بیمه سایبری و پرسشنامه بعدی تأمینکننده نیاز است — یک قبلوبعد مستند، نه «یک چیزی روشن کردم».
دامنهتان را بررسی کنید ← · DMARC شکست میخورد اما SPF و DKIM تأیید میشوند ← · رفع DKIM ← · چطور درجهبندی میکنیم ← · فقط دادههای جمعی. دادهها ذخیره و پردازش شده در اتحادیه اروپا.