SPF Flattening: رفع محدودیت 10 lookup

توضیح محدودیت 10 lookup

SPF (چارچوب سیاست فرستنده) زمانی با permerror شکست می‌خورد که سرور ایمیل گیرنده برای resolve کردن رکورد SPF شما مجبور به انجام بیش از 10 lookup در DNS شود. این به‌دلیل دستورهای تودرتوی include رخ می‌دهد: اگر رکورد شما یک ارائه‌دهنده را include کند و آن ارائه‌دهنده سرویس دیگری را include کند، هر مرحله در این محدودیت شمرده می‌شود. برای رفع آن باید از SPF flattening استفاده کنید که این lookupهای بازگشتی را با فهرستی ثابت از نشانی‌های IP جایگزین می‌کند.

به‌عنوان مهندسی که تحویل‌پذیری را مدیریت می‌کند، دیده‌ام این مشکل بیشتر در دوره "انباشت ارائه‌دهندگان" بروز می‌کند. شرکتی با یک ارائه‌دهنده ایمیل تراکنشی شروع می‌کند، یک ابزار بازاریابی اضافه می‌کند، یک CRM اضافه می‌کند و ناگهان رکورد SPF آن مثل خانه‌ای پوشالی شکننده می‌شود. وقتی lookup یازدهم رخ می‌دهد، سرور گیرنده جست‌وجو را متوقف می‌کند و یک خطای دائمی برمی‌گرداند. یعنی ایمیل شما نه‌تنها اسپم علامت می‌خورد، بلکه ممکن است کاملاً رد شود، چون بررسی احراز هویت از اساس شکست خورده است.

محدودیت lookup چگونه کار می‌کند

طبق RFC 7208، این محدودیت برای جلوگیری از حملات منع سرویس (DoS) علیه زیرساخت DNS وجود دارد. بدون محدودیت، یک عامل مخرب می‌توانست یک ارجاع چرخه‌ای یا زنجیره‌ای عظیم از includeها بسازد که سرور گیرنده را برای یک ایمیل مجبور به انجام صدها query کند.

چه چیزی lookup حساب می‌شود؟

همه سازوکارهای رکورد SPF شما رایگان نیستند. موارد زیر یک query در DNS ایجاد می‌کنند:

• include: رایج‌ترین مقصر. به سرور می‌گوید رکورد SPF دامنه دیگری را بررسی کند.
• a: رکورد A دامنه را query می‌کند.
• mx: رکوردهای MX دامنه را query می‌کند.
• ptr: DNS معکوس را query می‌کند (البته منسوخ شده و باید از آن پرهیز کرد).
• exists: یک دامنه مشخص را query می‌کند تا ببیند وجود دارد یا نه.

سازوکارهایی مانند ip4 و ip6 رایگان‌اند، چون نشانی IP به‌صراحت در رکورد آمده است.

ساختار یک زنجیره lookup

این رکورد SPF فرضی را در نظر بگیرید:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendhq.cc ~all

در ظاهر، این 3 lookup است. اما اگر _spf.google.com شامل سه دستور include دیگر و spf.protection.outlook.com شامل چهار دستور باشد، از همین حالا به 10 lookup رسیده‌اید. اگر رکورد SendHQ هم یک include داشت، به محدودیت می‌رسیدید. این یک "زنجیره include" است.

شناسایی permerror

اگر مطمئن نیستید به محدودیت رسیده‌اید یا نه، می‌توانید رکوردهای خود را با بررسی DNS ایمیل SendHQ اعتبارسنجی کنید. در یک لاگ خام یا ابزار تحلیل هدر، نتیجه‌ای مانند این می‌بینید:

spf=permerror (too many DNS lookups)

این با softfail (~all) یا fail (-all) متفاوت است. permerror یعنی بررسی SPF نتوانسته کامل شود. در این حالت، گیرنده نمی‌تواند مجاز بودن فرستنده را تأیید کند و این اغلب باعث می‌شود ایمیل کنار گذاشته شود یا فیلترهای سخت‌گیر آن را علامت بزنند.

SPF Flattening چیست؟

SPF flattening فرایند resolve کردن همه سازوکارهای include، a و mx به فهرستی تخت از نشانی‌های ip4 و ip6 است.

مثال: قبل و بعد

قبل (بازگشتی):

v=spf1 include:_spf.example.com include:_spf.vendor.com ~all

(فرض کنید _spf.example.com به 1.2.3.4 و _spf.vendor.com به 5.6.7.8 resolve می‌شوند)

بعد (flatten‌شده):

v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ~all

با تبدیل رکورد به فهرستی از IPها، تعداد lookupها از 2 (یا بیشتر) به 0 کاهش می‌یابد. سرور گیرنده IPها را فوراً می‌بیند و فرستنده را بدون query اضافه در DNS تأیید می‌کند.

بده‌بستان‌های flattening

Flattening راه‌حل قدرتمندی است، اما بار نگهداری قابل‌توجهی ایجاد می‌کند.

1. مشکل IP کهنه

وقتی از دستور include استفاده می‌کنید، مدیریت نشانی‌های IP را به ارائه‌دهنده واگذار می‌کنید. اگر Amazon SES یا SendGrid بازه IP جدیدی به زیرساخت خود اضافه کنند، رکورد SPF خودشان را به‌روز می‌کنند و ایمیل‌های شما همچنان ارسال می‌شوند.

اگر آن رکوردها را در DNS خودتان flatten کنید، اکنون مسئولیت آن IPها با شماست. اگر ارائه‌دهنده یک IP را تغییر دهد و شما فهرست flatten‌شده خود را به‌روز نکنید، ایمیل‌هایتان در احراز هویت SPF شکست می‌خورند. این دلیل اصلی خطرناک بودن flattening دستی برای ایمیل تراکنشی پرحجم است.

2. محدودیت طول رکورد

رکوردهای DNS حداکثر طول دارند. هر رشته در یک رکورد TXT به 255 نویسه محدود است. هرچند می‌توانید چند رشته را به هم متصل کنید، برخی parserهای قدیمی DNS با رکوردهای بسیار طولانی مشکل دارند. اگر ارائه‌دهندگان زیادی را flatten کنید، رکورد SPF شما ممکن است بزرگ‌تر از آن شود که به‌درستی پردازش شود.

چگونه زنجیره‌های include را اصلاح کنیم

اگر به محدودیت 10 lookup می‌رسید، این سلسله‌مراتب راه‌حل‌ها را از امن‌ترین تا تهاجمی‌ترین دنبال کنید.

گام 1: بازبینی و هرس

رکورد خود را برای ارائه‌دهندگان قدیمی بررسی کنید. بسیاری از تیم‌ها هنوز دستورهای include برای سرویس‌هایی دارند که سه سال پیش استفاده از آن‌ها را کنار گذاشته‌اند. هر ارائه‌دهنده‌ای را که دیگر از طرف شما ایمیل نمی‌فرستد حذف کنید.

گام 2: استفاده از زیردامنه‌ها برای ترافیک‌های مختلف

این حرفه‌ای‌ترین راه‌حل معماری است. به‌جای اینکه همه سرویس‌ها را روی دامنه اصلی قرار دهید، آن‌ها را بر اساس کارکرد تفکیک کنید:

• دامنه اصلی (example.com): ایمیل سازمانی (Google Workspace/Outlook).
• زیردامنه تراکنشی (mail.example.com): SendHQ یا Amazon SES.
• زیردامنه بازاریابی (news.example.com): Mailchimp یا Klaviyo.

هر زیردامنه رکورد SPF و محدودیت 10 lookup مخصوص به خود را دارد. این کار ریسک را ایزوله می‌کند و مانع می‌شود زنجیره پیچیده SPF یک ابزار بازاریابی، ایمیل‌های تراکنشی حیاتی شما را از کار بیندازد.

گام 3: SPF flattening پویا

Flattening پویا سرویسی است که زنجیره‌های include ارائه‌دهندگان شما را به‌صورت بی‌درنگ پایش می‌کند و رکورد DNS شما را به‌طور خودکار با نشانی‌های IP فعلی به‌روز می‌کند. این کار با خودکارسازی فرایند به‌روزرسانی از طریق API، مشکل "IP کهنه" را حل می‌کند.

SPF در بستر تحویل مدرن

مهم است بدانید SPF فقط بخشی از پازل احراز هویت است. برای اطمینان از پذیرش ایمیل توسط سرور گیرنده، باید SPF را با DKIM و DMARC هماهنگ کنید. توضیح مفصل این روابط را در راهنمای DKIM، SPF و DMARC در SendHQ بیابید.

پذیرش در برابر تحویل در برابر رسیدن به صندوق ورودی

به‌عنوان مهندس، این سه مرحله را از هم تفکیک می‌کنم:

1. پذیرش: سرور گیرنده اتصال و پیام را می‌پذیرد. permerror در SPF می‌تواند باعث شود سرور پیام را در سطح SMTP رد کند؛ یعنی پیام هرگز پذیرفته نمی‌شود.
2. تحویل: پیام پذیرفته می‌شود و به صندوق ایمیل کاربر (یا یک پوشه) منتقل می‌شود.
3. رسیدن به صندوق ورودی: پیام به‌جای پوشه اسپم در صندوق ورودی اصلی قرار می‌گیرد.

SPF flattening مشکل پذیرش را حل می‌کند. رسیدن به صندوق ورودی را تضمین نمی‌کند. رسیدن به صندوق ورودی به اعتبار فرستنده، محتوا و معیارهای تعامل بستگی دارد.

ملاحظات ویژه برای ایجنت‌های هوش مصنوعی

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

Idempotency و تأیید

ایجنت‌ها هرگز نباید بدون سازوکار ایمنی در یک حلقه ایمیل بفرستند. از کلید idempotency استفاده کنید تا منطق تلاش مجدد ایجنت شما یک ایمیل تراکنشی را ده بار برای مشتری نفرستد. علاوه بر این، برای ایمیل‌های حساس، پیش از فراخوانی API یک مرحله تأیید با حضور انسان در حلقه پیاده‌سازی کنید.

تحلیل هزینه ارائه‌دهندگان ارسال

هنگام انتخاب ارائه‌دهنده‌ای برای include در رکورد SPF، هزینه حجم ارسالی خود را در نظر بگیرید. بر اساس قیمت‌های سپتامبر 2026:

• Amazon SES: در مدل a la carte برابر 0.10 USD به‌ازای هر 1,000 ایمیل (قیمت‌گذاری Amazon SES). برای 50,000 ایمیل، این حدود 5 USD است. پلن‌های سطح‌بندی‌شده جدید که در 21 ژوئیه 2026 معرفی شدند شامل Essentials (0.16 USD به‌ازای هر 1,000)، Pro (0.22 USD به‌ازای هر 1,000 به‌علاوه 105 USD/ماه/region) و Enterprise (0.23 USD به‌ازای هر 1,000 به‌علاوه 500 USD/ماه) هستند.
• Postmark: ماهانه 15 USD برای 10,000 ایمیل، با مصرف مازاد بین 1.80 تا 1.20 USD به‌ازای هر 1,000 (قیمت‌گذاری Postmark). 50,000 ایمیل در سطوح Postmark تقریباً 66 USD هزینه دارد.
• Resend: سطح رایگان 3,000 ایمیل در ماه است (با سقف 100 در روز). پلن Pro ماهانه 20 USD برای 50,000 ایمیل است و مصرف مازاد 0.90 USD به‌ازای هر 1,000 محاسبه می‌شود (قیمت‌گذاری Resend).
• Mailgun: ماهانه 15 USD برای 10,000 ایمیل، با مصرف مازاد از 1.80 تا 1.10 USD به‌ازای هر 1,000 (قیمت‌گذاری Mailgun).
• SendGrid: سطح رایگان اکنون یک دوره آزمایشی 60 روزه است و پلن Essentials از 19.95 USD در ماه شروع می‌شود (قیمت‌گذاری SendGrid).

چک‌لیست عیب‌یابی SPF

اگر به مشکل محدودیت lookup مشکوک هستید، این چک‌لیست را مرور کنید:

• روی دامنه ریشه و همه زیردامنه‌های ارسال‌کننده، بررسی DNS اجرا کنید.
• تعداد کل مکانیزم‌های include، a، mx و exists را بشمارید.
• زنجیره‌های include هر ارائه‌دهنده را دنبال کنید تا ببینید lookupهای تو در تو دارند یا نه.
• ارائه‌دهنده‌های استفاده‌نشده را شناسایی و حذف کنید.
• بررسی کنید آیا می‌توان ترافیک را به یک زیردامنه اختصاصی (برای مثال notifications.example.com) منتقل کرد.
• اگر همچنان از محدودیت فراتر می‌رود، SPF flattening پویا را پیاده‌سازی کنید.
• تأیید کنید رکورد نهایی از محدودیت 255 کاراکتر برای هر رشته فراتر نمی‌رود.

جدول خلاصه: سازوکارهای SPF

سازوکار | lookup در DNS؟ | ریسک | توصیه

ip4 / ip6 | خیر | کم | برای IPهای ثابت استفاده کنید

include | بله | بالا | با احتیاط استفاده کنید، زنجیره‌ها را پایش کنید

a | بله | متوسط | در صورت امکان پرهیز کنید، از ip4 استفاده کنید

mx | بله | متوسط | در صورت امکان پرهیز کنید

ptr | بله | بالا | استفاده نکنید (منسوخ)

با مدیریت پیش‌دستانه رکوردهای SPF، از permerror پرهیز می‌کنید؛ خطایی که پیش از اینکه ایمیل شما حتی به فیلتر اسپم برسد تحویل‌پذیری را نابود می‌کند. چه از یک API ساده استفاده کنید و چه از یک سیستم ایجنتی پیچیده، سبک نگه داشتن DNS بهترین راه برای اطمینان از پذیرش ایمیل تراکنشی شماست.

برای مجموعه کاملی از ابزارهای مدیریت احراز هویت دامنه، به https://sendhq.cc سر بزنید.