رفع خطای SPF PermError؛ وقتی تعداد بررسی‌های DNS از حد مجاز بیشتر می‌شود

ایمیل‌های دامنه گاهی برگشت می‌خورند و در گزارش گیرنده عبارت SPF PermError یا «بیش از حد مجاز DNS lookup» دیده می‌شود. SPF یکی از روش‌هایی است که گیرنده با آن بررسی می‌کند آیا سرور ارسال‌کننده مجاز بوده است یا نه. وقتی خود دستورالعمل SPF قابل بررسی نباشد، نتیجه می‌تواند permerror شود.

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

آدرسی که مشتری در قسمت From می‌بیند همیشه همان نامی نیست که در بررسی SPF استفاده می‌شود. SPF معمولاً دامنه فرستنده پاکتی یا MAIL FROM را بررسی می‌کند؛ در برخی پیام‌ها نامی دیگر برای بازگشت خطا استفاده می‌شود. بنابراین اگر ایمیل از shop.example.com ارسال می‌شود، ممکن است اصلاح SPF دامنه اصلی example.com به‌تنهایی رکورد بررسی‌شده را اصلاح نکند.

از یک ایمیل آزمایشی ارسال‌شده به صندوقی که خودتان کنترل می‌کنید، بخش نمایش جزئیات یا سرآیند اصلی پیام را باز کنید. در بسیاری از برنامه‌ها گزینه‌ای مانند «نمایش نسخه اصلی» یا Show original وجود دارد. به نتیجه spf=permerror و دامنه‌ای که همان گزارش برای بررسی مشخص کرده نگاه کنید. متن نمایش در سرویس‌ها متفاوت است. اگر ایمیل اصلاً تحویل نشده، متن برگشتی و گزارش سرویس ارسال‌کننده را بررسی کنید.

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

در ویندوز، از منوی Start عبارت cmd را جست‌وجو و Command Prompt را باز کنید. نام نمونه زیر را با دامنه‌ای که در نتیجه SPF بررسی شده است جایگزین کنید و Enter بزنید:

این دستور پاسخ TXT را از DNS تنظیم‌شده دستگاه می‌پرسد و چیزی را تغییر نمی‌دهد. در خروجی دنبال مقدارهایی بگردید که با v=spf1 آغاز می‌شوند. ممکن است TXTهای دیگری مانند تأیید مالکیت سرویس، DKIM یا تنظیمات دیگر هم ببینید؛ وجود چند TXT با کاربرد متفاوت عادی است و نباید همه را حذف کرد.

اگر ابزار یک رکورد TXT طولانی را به شکل چند قسمت داخل گیومه نشان می‌دهد، الزاماً چند رکورد SPF مستقل نیست؛ یک رکورد TXT می‌تواند از چند بخش تشکیل شده باشد. اگر دو پاسخ مستقل دارید که هر دو با v=spf1 آغاز می‌شوند، معمولاً برای همان نام بیش از یک رکورد SPF منتشر شده و بررسی می‌تواند به PermError برسد. نام دامنه یا زیر‌دامنه را دقیق ببینید: SPF مربوط به example.com با SPF مربوط به shop.example.com دو نام جدا هستند.

اگر دستور timeout می‌دهد یا پاسخ پیدا نمی‌کند، ممکن است مسئله DNS یا نام انتخاب‌شده باشد. چند بار سرور را تغییر ندهید و رکوردها را پاک نکنید؛ ابتدا نام، DNS مسئول و نتیجه را با ارائه‌دهنده DNS بررسی کنید. پاسخ کش‌شده نیز ممکن است پس از یک تغییر برای مدتی با پاسخ معتبر فرق کند.

ابتدا در پنل DNS از هر دو مقدار و TTL یادداشت یا تصویر بگیرید. سپس فهرست همه سرویس‌هایی را که از همین دامنه پاکتی ایمیل می‌فرستند تهیه کنید: صندوق‌های شرکت، سایت فروشگاهی، سامانه فاکتور و سرویس خبرنامه می‌توانند فرستنده‌های متفاوتی باشند. هرکدام را با مدیر آن سرویس تأیید کنید.

یک مثال فرضی را ببینید:

این دو مقدار برای یک نام به شکل دو رکورد مستقل مشکل‌سازند. اگر هر دو سرویس واقعاً فرستنده مجازند، مدیر DNS باید طبق راهنمای همان سرویس‌ها یک سیاست درست و واحد بسازد. شکل زیر فقط نمایش ایده است و نباید برای دامنه واقعی کپی شود:

در رکورد واقعی، نام‌های نمونه را با مقدارهای مستند ارائه‌دهندگان و سیاست مناسب همان دامنه جایگزین می‌کنند. تفاوت ~all و -all، ترتیب سازوکارها، استفاده از redirect و سرویس‌های دیگر روی نتیجه اثر دارند. بدون شناخت سیاست قبلی، صرفاً دو رشته را به هم نچسبانید یا بخش آخر را تغییر ندهید.

در پنل DNS مسئول، رکورد نهایی صحیح را طبق روش همان پنل ثبت و رکورد تکراری را با دقت حذف کنید تا در نهایت برای آن نام فقط یک سیاست SPF منتشر شود. رکوردهای TXT نامرتبط را دست نزنید. بعد از ذخیره، دوباره خروجی TXT و سپس ارسال از هر سرویس مجاز را آزمایش کنید؛ راهنمای آزمایش در انتهای مقاله آمده است.

طبق استاندارد SPF، هنگام ارزیابی یک پیام، تعداد اصطلاحاتی که بررسی DNS ایجاد می‌کنند محدود است. مواردی مثل include، a، mx، ptr، exists و سازوکار redirect می‌توانند در این شمارش اثر داشته باشند. محدودیت، ساده‌شمردن تعداد کلمه‌های خط اول رکورد یا تعداد همه بسته‌های DNS شبکه نیست.

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

وقتی در همان ارزیابی از سقف مجاز عبور شود، نتیجه معمولاً permerror است. محدودیت‌های دیگری هم در استاندارد وجود دارد؛ هر PermError را صرفاً با شمردن includeها به این علت نسبت ندهید. چند رکورد SPF، دستور نامعتبر یا include بدون سیاست معتبر نیز باید بررسی شوند.

یک جدول ساده بسازید: نام سرویس، نوع ایمیل ارسالی، دامنه پاکتی مورد استفاده، مسئول سرویس و آخرین باری که واقعاً استفاده شده است. برای مثال، سایت ممکن است رسید خرید بفرستد، بخش مالی فاکتور و بازاریابی خبرنامه. هر سه ممکن است به فرستنده‌های جدا متکی باشند.

برای هر include یا سازوکار موجود، از مالک سرویس بپرسید آیا هنوز لازم است و مقدار رسمی فعلی چیست. سپس مسیر بررسی DNS هر فرستنده را با ابزار تشخیصی معتبر ارزیابی کنید. تعداد جست‌وجوهایی که ابزار گزارش می‌دهد را همراه نام فرستنده و زمان ثبت کنید؛ نتیجه یک سرویس لزوماً نماینده همه مسیرها نیست.

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

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

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

عوض‌کردن پایان سیاست به +all، حذف همه محدودیت‌ها یا خاموش‌کردن DMARC راه‌حل اصولی محدودیت نیست و می‌تواند حفاظت دامنه را ضعیف کند. همچنین انتشار یک رکورد SPF دوم برای جا دادن سرویس اضافه، مشکل جدیدی می‌سازد.

رکورد باید در DNS معتبر و فعال دامنه تغییر کند؛ ممکن است پنل DNS سایت، ثبت‌کننده دامنه و کلودفلر سه حساب متفاوت باشند. برای شروع، در Command Prompt نام دامنه اصلی خودتان را جایگزین نمونه و این پرس‌وجوی فقط‌خواندنی را اجرا کنید:

نام نیم‌سرورهای پاسخ را با اطلاعات ارائه‌دهنده DNS و پنلی که دامنه در آن اضافه شده مقایسه کنید. نام‌های اختصاصی یا واگذاری جداگانه یک زیردامنه همیشه از روی ظاهر قابل شناسایی نیستند؛ در آن حالت نام و خروجی را به مدیر دامنه بدهید تا مرجع Zone مربوط را مشخص کند. تغییر در یک پنل قدیمی که دیگر پاسخ‌گوی آن Zone نیست، اثر مورد انتظار نخواهد داشت.

پیش از ذخیره، مقدار قبلی، مقدار پیشنهادی، نام دقیق رکورد و TTL را ثبت کنید. در صورت اشتباه و با هماهنگی مسئول ایمیل، همان مقدار ثبت‌شده می‌تواند مبنای بازگشت باشد. پس از تغییر، به‌روزرسانی پاسخ در همه resolverها آنی و هم‌زمان نیست؛ TTL و پاسخ کش‌شده را در نظر بگیرید. از حذف MX یا تغییر نیم‌سرورها برای حل یک خطای SPF خودداری کنید، مگر اینکه بررسی مستقل دلیل آن را نشان دهد.

۱. با nslookup یا ابزار معتبر، رکورد TXT نام درست را دوباره ببینید و مطمئن شوید سیاست جدید در پاسخ مورد بررسی ظاهر شده است. ۲. از هر فرستنده مجاز، یک ایمیل آزمایشی به صندوق تحت کنترل خودتان بفرستید؛ مثلاً یکی از صندوق عادی، یکی از سایت و یکی از سرویس خبرنامه. از ارسال انبوه برای آزمایش خودداری کنید. ۳. در جزئیات هر پیام، نتیجه SPF و دامنه بررسی‌شده را بخوانید. هدف این است که برای مسیرهای درست، permerror برطرف شود و فرستنده مجاز نتیجه مناسب بگیرد. pass برای یک سرویس، سلامت بقیه سرویس‌ها را اثبات نمی‌کند. ۴. اگر ایمیل هنوز رد یا اسپم می‌شود، متن خطا و نتیجه DKIM و DMARC را نیز جداگانه بررسی کنید. رفع PermError تضمین رسیدن همه پیام‌ها به Inbox نیست.

اگر مسئله ادامه دارد، نام دامنه بررسی‌شده، رکورد منتشرشده، گزارش تعداد lookup برای مسیر هر سرویس و زمان آزمایش را بدون اطلاعات محرمانه به پشتیبانی DNS و ایمیل بدهید. برای آشنایی با انتخاب و مدیریت دامنه، می‌توانید صفحه ثبت دامنه نت‌آرام را ببینید؛ تا قبل از تشخیص DNS فعال، سرویس دامنه را برای رفع این خطا تغییر ندهید.