Defaults.Exposed › رفع اشکال‌ها › SPF (Sender Policy Framework)

چطور SPF (Sender Policy Framework) را رفع کنید

Q: ما از قبل یک رکورد SPF داریم — مگر این به معنای محافظت نیست؟

نه لزوماً. داشتن یک رکورد نیمهی اول است؛ داشتن آن با تنظیم دقیق نیمهی دوم. رکوردی که به '~all' (soft fail) ختم میشود و DMARC پشت آن نیست به سرورهای دریافتکننده میگوید 'این ممکن است جعلی باشد، اما به هر حال تحویل بدهید' — که محافظت کمی ارائه میدهد. دو رکورد SPF، یا یکی که تعداد جستجوی زیادی دارد، شکسته تلقی میشود.

Q: آیا رفع این مشکل ممکن است بهطور تصادفی ایمیل خودم را بشکند؟

اگر رکورد یک فرستندهی مشروع را از قلم بیندازد میتواند — مثلاً برنامهی فاکتورنویسی یا ابزار خبرنامهی شما که با نام شما ایمیل میفرستد. به همین دلیل رویکرد ایمن این است که ابتدا همهی سرویسهایی که برای شما ایمیل میفرستند را فهرست کنید، با '~all' منتشر کنید در حالی که تأیید میکنید چیزی از قلم نیفتاده، سپس به hard fail سفتتر کنید.

Q: تفاوت '~all' و '-all' چیست و کدام را باید استفاده کنیم؟

'-all' (hard fail) به دریافتکنندگان میگوید هر چیزی که در فهرست نیست را رد کنند — قویترین تنظیم. '~all' (soft fail) میگوید 'احتمالاً مشروع نیست، اما به هر حال بپذیر.' توصیهی مدرن '~all' همراه با سیاست DMARC 'reject' است — این جفت همان محافظت '-all' را بدون خطر جهش ایمیلهای فوروارد شده میدهد.

Q: آیا SPF به تنهایی همهی جعل ایمیل را متوقف میکند؟

نه — این لایهی اساسی اول است، نه همهی جواب. SPF میگوید کدام سرورها میتوانند برای شما ارسال کنند، اما به دریافتکنندگان نمیگوید در صورت شکست چه کنند. برای بستن کامل جعل هویت، DKIM و DMARC هم لازم دارید. SPF سریعترین، پرتأثیرترین اقدام اول است.

Q: چقدر طول میکشد تا اثر کند و آیا هزینهای دارد؟

تغییرات DNS معمولاً ظرف چند دقیقه تا چند ساعت اثر میکنند. خود اصلاح همیشه رایگان است — فقط یک تنظیم در ارائهدهندهی DNS شماست. هرکسی که بگوید برای اضافه کردن رکورد SPF باید محصول پولی بخرید اشتباه میکند.

SPF یک خط در تنظیمات دامنه‌ی شماست که مشخص می‌کند کدام سرویس‌های ایمیل مجاز هستند از طرف کسب‌وکار شما ایمیل ارسال کنند. بدون آن، هر کسی در دنیا می‌تواند ایمیلی ارسال کند که به نظر می‌رسد از طرف شما آمده — و ایمیل‌های واقعی شما بیشتر احتمال دارد در اسپم مشتریان قرار بگیرد.

نتیجه نهایی برای کسب‌وکار شما: هر کسی می‌تواند جعل هویت کسب‌وکار شما را بکند — به مشتریان، کارکنان و تأمین‌کنندگان شما — فاکتورها، درخواست‌های تغییر حساب بانکی و هر چیز دیگری. در همین حال، پیشنهادها و فاکتورهای واقعی شما بیشتر احتمال دارد در اسپم گم شوند و معاملات به‌آرامی متوقف می‌شوند.

هزینه این برای شما

یک کلاهبردار ایمیلی به مشتری شما ارسال می‌کند که شبیه فاکتور شماست، با حساب بانکی خودش. مشتری پول را واریز می‌کند. هفته‌ها بعد وقتی مشتری دنبال سفارشش می‌گردد متوجه می‌شوید — و حالا اعتبار شما و احتمالاً مسئولیت حقوقی‌تان در خطر است.
پیشنهادها، فاکتورها و پاسخ‌های شما به‌آرامی در پوشه‌ی اسپم مشتریان قرار می‌گیرند چون ارائه‌دهندگان بزرگ نمی‌توانند تأیید کنند که واقعاً از شما آمده‌اند. معاملات سرد می‌شوند و هیچ‌وقت نمی‌فهمید چرا.
یک کلاهبردار جعل هویت مالک یا مسئول مالی شما را می‌کند و به کارکنان ایمیل می‌فرستد و درخواست پرداخت فوری یا خرید کارت هدیه می‌کند — چون پیام واقعاً از دامنه‌ی شما به نظر می‌رسد، کسی آن را زیر سؤال نمی‌برد.
بررسی امنیتی یک مشتری بزرگ‌تر دامنه‌ی شما را چک می‌کند، هیچ محافظت فرستنده‌ای نمی‌بیند، و یا شما را رد می‌کند یا می‌خواهد قبل از امضا آن را درست کنید — که معامله یا هفته‌ها تأخیر به همراه دارد.
فکر می‌کنید محافظت دارید چون یک رکورد SPF وجود دارد — اما روی 'soft fail' تنظیم شده و هیچ‌چیزی آن را اجرا نمی‌کند، یا به‌آرامی شکسته است، پس ایمیل‌های جعلی همچنان از آن رد می‌شوند.

چرا اهمیت دارد. جعل آدرس 'از' در یک ایمیل بسیار آسان است و برای مهاجم هیچ هزینه‌ای ندارد. SPF ارزان‌ترین و سریع‌ترین راه برای سخت‌تر کردن جعل هویت دامنه‌تان و دور نگه داشتن ایمیل‌های مشروع از اسپم است. Google و Yahoo اکنون فعالانه ایمیل از دامنه‌هایی که احراز هویت ندارند را رد یا در اسپم قرار می‌دهند، بنابراین این دیگر اختیاری نیست — پیش‌نیاز اساسی است.

نسخه‌ی کوتاه

در حال حاضر، مگر اینکه SPF را به درستی راه‌اندازی کرده باشید، هر کسی در دنیا می‌تواند ایمیلی ارسال کند که به نظر می‌رسد از کسب‌وکار شما آمده. می‌توانند به مشتریان شما فاکتور جعلی بزنند، به کارکنانتان درخواست‌های پرداخت جعلی بفرستند، و به تأمین‌کنندگانتان به عنوان شما ایمیل بزنند — و پیام‌ها واقعی به نظر می‌رسند، چون هیچ‌چیزی در دامنه‌ی شما خلاف آن نمی‌گوید.

SPF (Sender Policy Framework) راه‌حل است. این یک خط متن در تنظیمات DNS دامنه‌ی شماست که سرویس‌های ایمیلی را که واقعاً مجاز هستند از طرف شما ارسال کنند فهرست می‌کند. ارائه‌دهندگان ایمیل دریافت‌کننده — Gmail، Outlook و همه — قبل از اینکه تصمیم بگیرند پیامی واقعی است یا نه آن فهرست را بررسی می‌کنند.

این صفحه دو چیزی را پوشش می‌دهد که باید هر دو درست باشند: آیا اصلاً رکورد SPF وجود دارد، و آیا به اندازه‌ی کافی سختگیرانه تنظیم شده تا واقعاً کارش را انجام دهد.

این چقدر ممکن است برای شما هزینه داشته باشد

اینها روش‌های روزمره و واقعی هستند که یک رکورد SPF گمشده یا ضعیف تبدیل به از دست دادن پول و اعتماد می‌شود.

تغییر مسیر فاکتور. یک مجرم به یکی از مشتریان شما ایمیلی می‌فرستد که دقیقاً مثل فاکتور شما به نظر می‌رسد، با حساب بانکی خودش. مشتری پول را واریز می‌کند. اولین باری که می‌فهمید زمانی است که مشتری پیگیر سفارشی می‌شود که قبلاً پرداخت کرده.
کلاهبرداری مدیرعامل/مالی. کسی به حسابدار شما «از طرف» مالک ایمیل می‌زند: «یک لطف سریع — می‌توانی این پرداخت را قبل از پایان روز انجام دهی؟» چون پیام واقعاً از دامنه‌ی شما به نظر می‌رسد، شک کسی برانگیخته نمی‌شود. پول از ساختمان خارج می‌شود.
مالیات تحویل‌پذیری پنهان. پیشنهادها و فاکتورهای شما در پوشه‌ی اسپم مشتریان قرار می‌گیرند چون Gmail و Yahoo نمی‌توانند تأیید کنند واقعاً از شما هستند. هیچ خطایی نمی‌بینید — معاملات فقط آرام می‌شوند.
قرارداد از دست رفته. خرید بزرگ‌تر یک مشتری یا تیم امنیتی آن‌ها بررسی ابتدایی روی دامنه‌ی شما انجام می‌دهد. هیچ احراز هویت فرستنده‌ای نمی‌بینند و شما را به عنوان ریسک علامت‌گذاری می‌کنند.
موج مسموم‌سازی برند. دامنه‌ی شما در یک کمپین فیشینگ علیه عموم مردم استفاده می‌شود. افرادی که آسیب دیده‌اند حالا به هر ایمیل با نام شما بی‌اعتماد هستند.

نخ مشترک در همه‌ی اینها: مهاجم هیچ هزینه‌ای نمی‌کند، و کسب‌وکار شما هزینه و سرزنش را تحمل می‌کند.

در واقع چیست

وقتی یک ایمیل می‌رسد، سرور ایمیل دریافت‌کننده می‌خواهد یک چیز بداند: آیا این واقعاً از کسی است که ادعا می‌کند؟ SPF بخشی از آن سؤال را پاسخ می‌دهد.

شما یک خط کوتاه متن در تنظیمات DNS دامنه‌تان منتشر می‌کنید — یک «رکورد TXT» — که سرویس‌های ایمیل مجاز برای ارسال از طرف شما را نام می‌برد. چیزی شبیه:

v=spf1 include:_spf.google.com include:sendgrid.net -all

به زبان ساده: «ایمیل واقعی از ما از سرورهای Google و SendGrid می‌آید — هر چیز دیگری که ادعا می‌کند ما هستیم را رد کنید.»

دو بخشی که برای نمره‌ی شما اهمیت دارند:

آیا رکورد وجود دارد؟ این مهم‌ترین است. بدون رکورد، دریافت‌کنندگان هیچ فهرستی برای بررسی ندارند. همچنین اگر دامنه‌ی شما دو یا بیشتر رکورد SPF داشته باشد، قوانین می‌گوید همه‌ی آن‌ها نامعتبر هستند — پس حتی اگر به نظر برسد وجود دارند، عملاً هیچ SPF ندارید.
آیا سیاست به اندازه‌ی کافی سختگیرانه است؟ یک رکورد می‌تواند وجود داشته باشد اما همچنان بی‌خاصیت باشد. پایان رکورد — مکانیسم «all» — دستورالعملی به دریافت‌کنندگان است:
- -all (hard fail) — هر چیزی که در فهرست نیست را رد کن. قوی‌ترین. نمره‌ی کامل.
- ~all (soft fail) + DMARC تنظیم شده روی reject — تنظیم مدرن توصیه شده. محافظت معادل hard fail. نمره‌ی کامل.
- ~all + DMARC تنظیم شده روی quarantine — قابل قبول، کمی ضعیف‌تر.
- ~all به تنهایی (بدون اجرای DMARC) — ضعیف. ایمیل جعلی همچنان از آن رد می‌شود.
- ?all (خنثی) — هیچ محافظتی ارائه نمی‌دهد.
- +all — فعالاً خطرناک: به دنیا می‌گوید هر کسی می‌تواند به عنوان شما ارسال کند. هرگز استفاده نکنید.

یک شکست نامرئی دیگر هم وجود دارد: SPF فقط مجاز است تا 10 جستجوی DNS هنگام ارزیابی ایجاد کند. تعداد زیادی ورودی include: داشته باشید و رکورد از این محدودیت تجاوز می‌کند، در این نقطه دریافت‌کنندگان همه چیز را شکسته تلقی می‌کنند.

«خوب» چه شکلی است: دقیقاً یک رکورد SPF، فهرست تمام سرویس‌هایی که مشروعاً برای شما ایمیل می‌فرستند، ختم شده به -all (یا ~all جفت شده با DMARC در p=reject)، و راحت زیر حد 10 جستجو.

چگونه آن را رفع کنیم (رایگان، ~۱۰ دقیقه)

این بخش را به هر کسی که دامنه یا وب‌سایت شما را مدیریت می‌کند بدهید — و توجه داشته باشید که اصلاح رایگان است. این یک تغییر در تنظیمات DNS است، نه محصولی که می‌خرید.

مرحله ۱ — فهرست کنید همه‌ی سرویس‌هایی که برای شما ایمیل می‌فرستند. این بخشی است که مردم اشتباه می‌کنند. همه را یادداشت کنید: ارائه‌دهنده‌ی صندوق ایمیل (Google Workspace، Microsoft 365 و غیره)، به علاوه هر ابزار خبرنامه، CRM، helpdesk، پلتفرم تجارت الکترونیک، برنامه‌ی فاکتورنویسی و سیستم رزرو.

مرحله ۲ — یک رکورد TXT منتشر کنید در دامنه‌ی root شما. خطوط “include” را برای همه‌ی فرستندگان در یک رکورد ترکیب کنید. به ازای هر پلتفرم رایج:

Google Workspace: include:_spf.google.com
Microsoft 365: include:spf.protection.outlook.com
SendGrid: include:sendgrid.net
Mailchimp: include:servers.mcsv.net
Zoho: include:zoho.eu (یا دامنه‌ی مناسب منطقه)

یک رکورد ترکیب شده اینگونه به نظر می‌رسد:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net -all

مرحله ۳ — ایمن شروع کنید، سپس اجرا کنید. در حالی که تأیید می‌کنید فهرست فرستنده‌ی شما کامل است، با ~all (soft fail) منتشر کنید تا چیزی مشروع به طور تصادفی بلاک نشود.

مرحله ۴ — مطمئن شوید دقیقاً یک رکورد دارید. اگر رکورد SPF قدیمی موجود است، آن را ویرایش کنید نه اینکه دومی اضافه کنید. دو رکورد v=spf1 یکدیگر را لغو می‌کنند.

مرحله ۵ — تعداد جستجو را زیر نظر بگیرید. اگر فرستندگان زیادی دارید، ممکن است از حد 10 جستجو تجاوز کنید.

مرحله ۶ — دامنه‌ی خود را مجدداً بررسی کنید تا تأیید کنید که حالا از آزمون رد می‌شود.

اشتباهات رایج

دو رکورد SPF. رایج‌ترین شکست پنهان. اضافه کردن یک رکورد جدید به جای ویرایش موجودی، هر دو را نامعتبر می‌کند. باید دقیقاً یکی باشد.
توقف در ~all و فرض اینکه کارتان تمام شده. Soft fail بدون DMARC پشت آن ضعیف است.
فراموش کردن یک فرستنده. سفت کردن به -all قبل از فهرست کردن برنامه‌ی فاکتورنویسی، CRM یا ابزار خبرنامه، ایمیل مشروع خودتان را بلاک خواهد کرد.
تجاوز از حد 10 جستجو. هر include: می‌تواند به جستجوهای بیشتری زنجیر شود.
استفاده از +all. صریحاً کل اینترنت را مجاز می‌کند که به عنوان شما ارسال کند. هرگز آن را منتشر نکنید.

جای این در چه چارچوبی است

SPF پایه است، اما یکی از سه لایه است. DKIM یک امضای رمزنگاری اضافه می‌کند که ثابت می‌کند پیام دستکاری نشده، و DMARC دستورالعملی است که SPF و DKIM را به هم وصل می‌کند و به دریافت‌کنندگان می‌گوید با ایمیلی که شکست می‌خورد چه کنند. اول SPF را درست کنید (سریع‌ترین برد است و بیشترین وزن را دارد)، سپس DKIM و DMARC را اضافه کنید. هر سه اصلاح رایگان هستند.

آن را در هاست خود راه‌اندازی کنید

گام‌به‌گام برای ارائه‌دهندگان محبوب:

پرسش‌های متداول

من تکنیکی نیستم — آیا می‌توانم خودم این را حل کنم؟

نیازی نیست جزئیات را بفهمید. تغییر فقط یک یا دو خط به تنظیمات دامنه‌ی شماست، که توسط هر کسی که وب‌سایت یا ارائه‌دهنده IT شما را مدیریت می‌کند انجام می‌شود. بخش 'چگونه آن را رفع کنیم' زیر را به آن‌ها بدهید — معمولاً چند دقیقه طول می‌کشد و رایگان است.

ما از قبل یک رکورد SPF داریم — مگر این به معنای محافظت نیست؟

نه لزوماً. داشتن یک رکورد نیمه‌ی اول است؛ داشتن آن با تنظیم دقیق نیمه‌ی دوم. رکوردی که به '~all' (soft fail) ختم می‌شود و DMARC پشت آن نیست به سرورهای دریافت‌کننده می‌گوید 'این ممکن است جعلی باشد، اما به هر حال تحویل بدهید' — که محافظت کمی ارائه می‌دهد. دو رکورد SPF، یا یکی که تعداد جستجوی زیادی دارد، شکسته تلقی می‌شود.

آیا رفع این مشکل ممکن است به‌طور تصادفی ایمیل خودم را بشکند؟

اگر رکورد یک فرستنده‌ی مشروع را از قلم بیندازد می‌تواند — مثلاً برنامه‌ی فاکتورنویسی یا ابزار خبرنامه‌ی شما که با نام شما ایمیل می‌فرستد. به همین دلیل رویکرد ایمن این است که ابتدا همه‌ی سرویس‌هایی که برای شما ایمیل می‌فرستند را فهرست کنید، با '~all' منتشر کنید در حالی که تأیید می‌کنید چیزی از قلم نیفتاده، سپس به hard fail سفت‌تر کنید.

تفاوت '~all' و '-all' چیست و کدام را باید استفاده کنیم؟

'-all' (hard fail) به دریافت‌کنندگان می‌گوید هر چیزی که در فهرست نیست را رد کنند — قوی‌ترین تنظیم. '~all' (soft fail) می‌گوید 'احتمالاً مشروع نیست، اما به هر حال بپذیر.' توصیه‌ی مدرن '~all' همراه با سیاست DMARC 'reject' است — این جفت همان محافظت '-all' را بدون خطر جهش ایمیل‌های فوروارد شده می‌دهد.

آیا SPF به تنهایی همه‌ی جعل ایمیل را متوقف می‌کند؟

نه — این لایه‌ی اساسی اول است، نه همه‌ی جواب. SPF می‌گوید کدام سرورها می‌توانند برای شما ارسال کنند، اما به دریافت‌کنندگان نمی‌گوید در صورت شکست چه کنند. برای بستن کامل جعل هویت، DKIM و DMARC هم لازم دارید. SPF سریع‌ترین، پرتأثیرترین اقدام اول است.

چقدر طول می‌کشد تا اثر کند و آیا هزینه‌ای دارد؟

تغییرات DNS معمولاً ظرف چند دقیقه تا چند ساعت اثر می‌کنند. خود اصلاح همیشه رایگان است — فقط یک تنظیم در ارائه‌دهنده‌ی DNS شماست. هرکسی که بگوید برای اضافه کردن رکورد SPF باید محصول پولی بخرید اشتباه می‌کند.