بررسی بلاک شدن آی‌پی سرور ایمیل و راهکارهای رفع مشکل ارسال ایمیل

ایمیل‌های سرور ناگهان به مقصد نمی‌رسند، یا مستقیم در پوشه Spam گیرنده می‌افتند و در Bounce برگشتی نام یک لیست سیاه دیده می‌شود. در بیشتر این موارد محتوای ایمیل مقصر نیست؛ آی‌پی سرور در یکی از RBLها (Realtime Blackhole List) قرار گرفته یا رکورد PTR سرور اشتباه یا اصلاً تعریف نشده است. مسیر درست، از تشخیص دقیق شروع می‌شود و بعد به رفع علت و درخواست حذف از لیست می‌رسد.

قدم صفر: متن Bounce را بخوانید

قبل از هر ابزار آنلاینی، متن ایمیل برگشتی (NDR) را باز کنید. سرور مقصد معمولاً دقیقاً می‌گوید چرا ایمیل را نپذیرفته است. نمونه‌های رایج:

550 5.7.1 Service unavailable; Client host [45.90.XX.10] blocked using zen.spamhaus.org
450 4.7.1 Client host rejected: cannot find your reverse hostname
554 5.7.1 Your access to this mail system has been rejected due to the sending MTA's poor reputation

پیام اول یعنی بلاک‌لیست، پیام دوم یعنی مشکل رکورد PTR و پیام سوم یعنی مشکل اعتبار (Reputation) نزد همان ارائه‌دهنده، که لزوماً در هیچ RBL عمومی ثبت نشده است. هر سه مسیر رفع متفاوتی دارند.

به عدد ابتدای پیام دقت کنید: کدهای ۴xx یعنی رد موقت و سرور مقصد بعداً دوباره تلاش می‌کند، ولی کدهای ۵xx یعنی رد دائم و ایمیل همان‌جا برگشت خورده است. مشکل PTR در Postfix به‌صورت پیش‌فرض با کد ۴۵۰ (موقت) برگردانده می‌شود، اما بعضی سرورها همان بررسی را با کد ۵۵۰ دائمی می‌کنند.

تشخیص بلاک شدن آی‌پی سرور ایمیل

۱. ابزار MXToolbox

وب‌سایت mxtoolbox.com یکی از معتبرترین ابزارهای آنلاین برای بررسی وضعیت آی‌پی ایمیل در لیست‌های اسپم است. کافی است آی‌پی یا دامنه خود را وارد کرده و لیستی از RBLهایی که شما را مسدود کرده‌اند مشاهده کنید.

سایت multirbl.valli.org هم همین کار را روی تعداد بیشتری لیست انجام می‌دهد و برای بررسی اولیه گزینه خوبی است.

۲. بررسی در سایت UCEPROTECT

UCEPROTECT یکی از سرویس‌های تخصصی در لیست‌های بلاک است. در این ابزار می‌توان مشاهده کرد که آی‌پی شما در سطح (Level) ۱، ۲ یا ۳ بلاک شده است یا نه:

• Level 1 — فقط خود آی‌پی شما به دلیل رفتار همان آی‌پی لیست شده است.
• Level 2 — رنج شبکه (معمولاً /۲۴) به دلیل تعداد زیاد آی‌پی‌های آلوده در همان رنج لیست شده است.
• Level 3 — کل AS یا شبکه ارائه‌دهنده لیست شده است.

تفاوت مهم است: اگر در Level 2 یا ۳ هستید، مشکل از سرور شما نیست و با تمیز کردن سرورتان هم برطرف نمی‌شود؛ باید موضوع را به ارائه‌دهنده سرور اطلاع بدهید. نکته دیگر اینکه بسیاری از سرویس‌دهنده‌های بزرگ ایمیل اصولاً Level 2 و ۳ را ملاک رد کردن ایمیل قرار نمی‌دهند، بنابراین حضور در آن سطوح همیشه به معنی مسدود شدن واقعی ایمیل‌های شما نیست.

برای بررسی سریع اینکه کدام آی‌پی‌ها در یک رنج خاص (مثلاً ۴۵٫۹۰٫XX.0/24) بلاک شده‌اند، می‌توانید از یک اسکریپت لینوکسی استفاده کنید که با ابزار dig آی‌پی‌ها را در برابر لیست UCEPROTECT تست می‌کند.

سپس روی لینکی که سایت می‌دهد کلیک می‌کنیم؛ آی‌پی‌های بلاک‌شده و تاریخی که به‌صورت خودکار از بلاک خارج می‌شوند مشخص می‌شود.

بررسی کل رنج /۲۴ با dig

نصب dig

ابزار dig در بسته dnsutils (خانواده دبیان) یا bind-utils (خانواده RHEL) قرار دارد. بسته به سیستم‌عامل یکی از دستورات زیر را اجرا کنید.

اوبونتو / دبیان (Ubuntu / Debian)

sudo apt update && sudo apt install dnsutils -y

آلمالینوکس / راکی لینوکس / RHEL 8 و ۹ و آمازون لینوکس ۲۰۲۳ (AlmaLinux / Rocky Linux / Amazon Linux 2023)

sudo dnf install bind-utils -y

سنت‌اواس ۷ و آمازون لینوکس ۲ (CentOS 7 / Amazon Linux 2)

sudo yum install bind-utils -y

روی توزیع‌های جدید، yum فقط یک نام مستعار برای dnf است و هر دو دستور یک کار می‌کنند. توجه داشته باشید که CentOS 7 از پایان ژوئن ۲۰۲۴ به پایان پشتیبانی رسیده و مخازن رسمی آن به vault منتقل شده‌اند؛ اگر روی CentOS 7 خطای مخزن گرفتید، همین است. برای سرور ایمیل، مهاجرت به AlmaLinux یا Rocky Linux را در برنامه بگذارید.

آرچ لینوکس (Arch Linux)

sudo pacman -S bind

در آرچ، بسته جداگانه bind-tools در بسته bind ادغام شده و همین یک بسته ابزار dig را نصب می‌کند.

بررسی نصب dig

dig google.com

اگر خروجی شامل بخش ANSWER SECTION و آی‌پی‌های گوگل باشد، dig درست نصب شده است.

اگر نصب با خطای امضای GPG متوقف شد

راه اصولی این است که کلید GPG درست را وارد کنید، نه اینکه بررسی امضا را دور بزنید. ابتدا ببینید چه کلیدهایی روی سیستم موجود است:

ls /etc/pki/rpm-gpg/

سپس کلید مربوط به همان توزیع و همان نسخه را وارد کنید. برای مثال روی AlmaLinux:

# AlmaLinux 8
sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux-8

# AlmaLinux 9
sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux-9

روی Rocky Linux نام فایل کلید متفاوت است، به همین دلیل اول خروجی ls را ببینید و نام دقیق را از آنجا بردارید. بعد کش را پاک و بازسازی کنید و دوباره نصب کنید:

sudo dnf clean all
sudo dnf makecache
sudo dnf install bind-utils -y

دستور dnf install bind-utils --nogpgcheck -y هم بسته را نصب می‌کند، اما امضای دیجیتال بسته را بررسی نمی‌کند. این کار یعنی هر بسته دستکاری‌شده‌ای بدون هشدار نصب می‌شود؛ روی سرور تولیدی از آن استفاده نکنید و فقط در صورت اضطرار و به‌صورت موقت سراغش بروید.

ساخت اسکریپت بررسی رنج

فایل اسکریپت را بسازید:

nano check_blacklist.sh

و این محتوا را داخل آن قرار دهید (اسکریپت بررسی UCEPROTECT Level 1):

#!/bin/bash

rbl="dnsbl-1.uceprotect.net"   # لیست سیاه UCEPROTECT Level 1
prefix="45.90.XX"              # رنج مورد بررسی

for i in {1..254}; do
    ip="$prefix.$i"
    reversed_ip=$(echo "$ip" | awk -F'.' '{print $4"."$3"."$2"."$1}')
    result=$(dig +short "$reversed_ip.$rbl" A)
    if [ -n "$result" ]; then
        echo "Blocked:     $ip  ($result)"
    else
        echo "Not blocked: $ip"
    fi
done

نکته: مقدار prefix همان رنج مدنظر شماست و کل ۲۵۴ آی‌پی قابل استفاده آن بررسی می‌شود. آدرس .0 آدرس شبکه و .255 آدرس Broadcast است و بررسی آن‌ها معنایی ندارد.

ذخیره، مجوز اجرا و اجرا

برای خروج از nano کلید CTRL + X، برای تأیید ذخیره Y و برای ذخیره با همان نام check_blacklist.sh کلید Enter را بزنید. سپس مجوز اجرا بدهید و اسکریپت را اجرا کنید:

chmod +x check_blacklist.sh
./check_blacklist.sh

گسترش اسکریپت به چند RBL

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

#!/bin/bash

# رنج آی‌پی مورد نظر (مثلاً 45.90.XX.0/24)
prefix="45.90.XX"

rbls=(
  "dnsbl-1.uceprotect.net"      # UCEPROTECT Level 1
  "dnsbl-2.uceprotect.net"      # UCEPROTECT Level 2
  "dnsbl-3.uceprotect.net"      # UCEPROTECT Level 3
  "zen.spamhaus.org"            # Spamhaus (SBL + XBL + PBL)
  "bl.spamcop.net"              # SpamCop
  "b.barracudacentral.org"      # Barracuda (نیازمند ثبت resolver)
  "psbl.surriel.com"            # PSBL
)

for i in {1..254}; do
  ip="$prefix.$i"
  reversed_ip=$(echo "$ip" | awk -F'.' '{print $4"."$3"."$2"."$1}')
  echo "============================"
  echo "Checking $ip ..."
  for rbl in "${rbls[@]}"; do
    result=$(dig +short "$reversed_ip.$rbl" A | head -n 1)
    case "$result" in
      "")
        echo "  OK      - not listed in $rbl" ;;
      127.0.0.1|127.0.0.255|127.255.255.*)
        echo "  SKIP    - $rbl کوئری را نپذیرفت (resolver عمومی یا سقف کوئری)" ;;
      *)
        echo "  LISTED  - $rbl -> $result" ;;
    esac
  done
  echo ""
  sleep 1
done

چهار نکته‌ای که نتیجه اسکریپت را قابل اعتماد می‌کند

• از DNS عمومی استفاده نکنید. اگر resolver سرور شما روی ۸٫۸٫۸٫۸ یا ۱٫۱٫۱٫۱ تنظیم باشد، Spamhaus به‌جای پاسخ واقعی کد 127.255.255.x و UCEPROTECT کد 127.0.0.255 برمی‌گرداند و یک اسکریپت ساده هر دو را «بلاک» تفسیر می‌کند. به همین دلیل در اسکریپت بالا این کدها جدا شده‌اند. برای نتیجه درست، از یک resolver محلی (مثل Unbound یا BIND) استفاده کنید.
• این اسکریپت را روی resolver سرور ایمیل تولیدی خود اجرا نکنید. این مهم‌ترین هشدار این بخش است. بررسی ۲۵۴ آی‌پی در ۷ لیست یعنی نزدیک به ۱۸۰۰ کوئری پشت سر هم. استفاده رایگان از Spamhaus و UCEPROTECT سقف حجمی دارد و این حجم کوئری می‌تواند خود resolver شما را در آن سرویس مسدود کند. نتیجه‌اش این است که از آن لحظه فیلترینگ اسپم ورودی سرور شما هم از کار می‌افتد یا همه ایمیل‌های ورودی را «لیست‌شده» می‌بیند. اسکریپت را از یک سرور یا resolver جداگانه اجرا کنید، sleep 1 را کم نکنید و اگر واقعاً به بررسی مداوم نیاز دارید سراغ سرویس اشتراکی مثل Spamhaus DQS بروید.
• برخی لیست‌ها ثبت‌نام می‌خواهند. برای مثال Barracuda کوئری را فقط از آی‌پی‌های ثبت‌شده پاسخ می‌دهد؛ اگر resolver خود را در سایت آن‌ها ثبت نکرده باشید، نتیجه خالی به‌دست می‌آورید که با «تمیز بودن» اشتباه گرفته می‌شود.
• هر نام لیستی که در اینترنت دیدید را داخل اسکریپت نگذارید. لیست‌های تعطیل‌شده یا اشتراکی همیشه پاسخ خالی می‌دهند و اسکریپت آن‌ها را «تمیز» گزارش می‌کند؛ یعنی یک هشدار واقعی را از دست می‌دهید. پیش از افزودن هر لیست، با dig +short 2.0.0.127.NAME-OF-RBL A رکورد تست آن را بگیرید؛ اگر پاسخی نداد، آن لیست برای شما کار نمی‌کند.

رکوردهای DNS که ارسال ایمیل به آن‌ها وابسته است

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

• SPF — مشخص می‌کند کدام سرورها مجاز به ارسال ایمیل از طرف دامنه شما هستند.
• DKIM — امضای دیجیتال ایمیل که توسط سرور مقصد بررسی می‌شود.
• DMARC — سیاست بررسی SPF و DKIM و نحوه برخورد با ایمیل‌های مشکوک.
• MX — تعیین‌کننده آدرس سرور دریافت ایمیل دامنه.
• PTR — نگاشت معکوس آی‌پی سرور به نام میزبان آن؛ تنها رکوردی از این فهرست که در DNS دامنه شما نیست.

ابزار Mail Tester به شما امکان می‌دهد با ارسال یک ایمیل آزمایشی، وضعیت رکوردهای بالا، محتوای ایمیل و امتیاز اسپم آن را یکجا ببینید.

رکورد PTR و نقش آن در تحویل ایمیل

کار اصلی DNS این است که یک نام دامنه را به آدرس آی‌پی برساند. رکورد PTR دقیقاً برعکس عمل می‌کند و یک آی‌پی را به یک نام میزبان نگاشت می‌دهد؛ به همین دلیل به آن Reverse DNS یا rDNS هم می‌گویند. این رکورد در دامنه شما ذخیره نمی‌شود، بلکه در ناحیه‌ای به نام in-addr.arpa قرار دارد که به بلوک آی‌پی تعلق دارد، نه به دامنه.

اهمیت آن برای سرور ایمیل جدی است: تقریباً همه سرویس‌دهنده‌های بزرگ ایمیل، هنگام اتصال سرور شما یک جست‌وجوی معکوس روی آی‌پی مبدأ انجام می‌دهند. اگر PTR وجود نداشته باشد، یا نامی که برمی‌گرداند با نام اعلام‌شده در HELO/EHLO هم‌خوانی نداشته باشد، ایمیل یا با خطای cannot find your reverse hostname رد می‌شود یا مستقیم به Spam می‌رود. حالت مطلوب FCrDNS است: PTR آی‌پی باید نام میزبان را بدهد و رکورد A همان نام میزبان باید به همان آی‌پی برگردد.

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

چه کسی اجازه تنظیم PTR را دارد

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

فقط در یک حالت می‌توانید PTR را روی DNS خودتان مدیریت کنید: وقتی ارائه‌دهنده، ناحیه معکوس آن رنج را به نیم‌سرورهای شما واگذار (Delegate) کرده باشد. این کار برای بلوک‌های /۲۴ مستقیم انجام می‌شود و برای بلوک‌های کوچک‌تر با روش واگذاری بدون کلاس (RFC 2317) صورت می‌گیرد. اگر این واگذاری انجام نشده باشد، هر رکورد PTR که در پنل خودتان بسازید هیچ اثری در دنیای بیرون ندارد.

ایجاد رکورد PTR در دایرکت ادمین

در دایرکت ادمین دو مسیر شبیه به هم وجود دارد و فقط یکی از آن‌ها به نتیجه می‌رسد:

• مسیر کاربری (User Level > DNS Management): در نسخه‌های جدید دایرکت ادمین انواع رکورد از جمله PTR در این بخش قابل افزودن است، اما این بخش ناحیه دامنه شما (مثلاً example.com) را ویرایش می‌کند. یک رکورد PTR داخل ناحیه دامنه، هیچ تأثیری بر تحویل ایمیل ندارد.
• مسیر مدیریتی (Admin Level > DNS Administration): جایی که ناحیه‌های DNS سرور مدیریت می‌شوند و ناحیه معکوس هم باید همین‌جا ساخته شود.

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

مرحله ۱ — با کاربر Admin وارد دایرکت ادمین شوید و به بخش DNS Administration بروید.

مرحله ۲ — یک ناحیه جدید بسازید. فرم ساخت ناحیه، نام ناحیه به‌همراه اطلاعات پایه را می‌گیرد؛ چیزی شبیه به این:

domain name: XX.90.45.in-addr.arpa
ip:          45.90.XX.10
ns1:         ns1.example.com
ns2:         ns2.example.com

نام ناحیه معکوس، سه اوکتت اول رنج به‌صورت وارونه به‌علاوه پسوند in-addr.arpa است. یعنی برای رنج ۴۵٫۹۰٫XX.0/24 ناحیه می‌شود XX.90.45.in-addr.arpa.

مرحله ۳ — داخل همین ناحیه، برای هر آی‌پی یک رکورد PTR اضافه کنید. نام رکورد آخرین عدد آی‌پی و مقدار آن نام کامل میزبان با نقطه پایانی است:

10   IN   PTR   mail.example.com.

در ادامه TTL را به‌صورت دلخواه مشخص کرده و روی Save کلیک کنید. برای هر آی‌پی فقط یک رکورد PTR تعریف کنید؛ چند PTR برای یک آی‌پی، رفتار سرورهای مقصد را غیرقابل پیش‌بینی می‌کند. نقطه انتهای mail.example.com. هم اجباری است و نبود آن باعث می‌شود نام ناحیه به انتهای مقدار چسبانده شود.

تست PTR

بعد از اعمال تغییرات (و گذشتن TTL) این دو دستور را اجرا کنید:

dig -x 45.90.XX.10 +short
dig +short mail.example.com

خروجی اول باید mail.example.com. و خروجی دوم باید 45.90.XX.10 باشد. اگر این دو با هم جور بودند، FCrDNS برقرار است. همچنین مطمئن شوید نام میزبان خود سرور با همین نام یکی است:

hostname -f

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

شناسایی ارسال‌کننده اسپم در WHM (cPanel)

اگر آی‌پی شما در Level 1 لیست شده، یعنی ترافیک اسپم واقعاً از سرور شما خارج شده است. تا وقتی منبع را پیدا نکنید، درخواست حذف از لیست فایده‌ای ندارد و لیست شدن دوباره سریع‌تر و طولانی‌تر اتفاق می‌افتد.

در WHM این مسیرهای گرافیکی را دنبال کنید:

• WHM > Email > Mail Delivery Reports
• WHM > Email > Mail Queue Manager
• WHM > Email > Mail Troubleshooter

همچنین بخش Email > View Sent Summary در WHM می‌تواند نشان دهد که کدام یوزرها چه تعداد ایمیل در چه بازه‌ای ارسال کرده‌اند.

از خط فرمان هم می‌توانید وضعیت صف Exim را ببینید (این دستورها فقط خواندنی هستند و چیزی را حذف نمی‌کنند):

# تعداد ایمیل‌های در صف
exim -bpc

# خلاصه صف بر اساس دامنه
exim -bp | exiqsumm

# پیگیری لحظه‌ای لاگ ارسال
tail -f /var/log/exim_mainlog

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

هشدار درباره خالی کردن صف: بعد از بستن منبع، صف را کامل پاک نکنید. در Mail Queue Manager ابتدا بر اساس فرستنده یا دامنه فیلتر کنید و فقط پیام‌های همان کاربر آلوده را حذف کنید. حذف کل صف، ایمیل‌های سالم بقیه مشتریان را هم که هنوز تحویل نشده‌اند از بین می‌برد و این پیام‌ها قابل بازیابی نیستند.

فعال‌سازی و تنظیم SpamAssassin در WHM

برای کاهش احتمال اسپم و مسدود شدن آی‌پی:

• از بخش WHM > Service Configuration > Apache SpamAssassin آن را فعال کنید.
• مقدار threshold را دقیق تنظیم کنید (پیش‌فرض ۵ مناسب است).
• کاربران را نسبت به رعایت نکات ارسال ایمیل سالم و بهینه‌سازی محتوای ایمیل آموزش دهید.

توجه کنید که SpamAssassin روی ایمیل‌های ورودی کار می‌کند و به‌تنهایی جلوی خارج شدن اسپم از سرور شما را نمی‌گیرد. برای سمت خروجی، محدودیت ارسال هر اکانت (Max hourly emails) در WHM ابزار مؤثرتری است.

درخواست حذف از بلاک‌لیست

ترتیب کار مهم است: اول علت را رفع کنید، بعد درخواست حذف بدهید.

• UCEPROTECT: لیست شدن به‌صورت خودکار و در تاریخی که در همان صفحه نتیجه نمایش داده می‌شود منقضی می‌شود. این سرویس برای حذف فوری هزینه دریافت می‌کند که در اغلب موارد ضرورتی ندارد؛ اگر منبع اسپم را بسته باشید، انقضای خودکار کافی است.
• Spamhaus: از صفحه بررسی خود Spamhaus آی‌پی را جست‌وجو کنید؛ اگر لیست باشد، لینک درخواست حذف در همان نتیجه نمایش داده می‌شود. توجه کنید که لیست PBL مربوط به رنج‌های خانگی/دینامیک است و حذف آن معمولاً باید توسط ارائه‌دهنده انجام شود.
• Barracuda، SpamCop و سایر لیست‌ها: هرکدام فرم درخواست حذف مخصوص خود را دارند که از صفحه نتیجه جست‌وجوی همان سرویس در دسترس است.
• مایکروسافت و گوگل: اگر ایمیل‌های شما فقط به Outlook/Hotmail یا Gmail نمی‌رسند اما در هیچ RBL عمومی نیستید، مشکل از فهرست‌های داخلی خود این شرکت‌هاست. مایکروسافت فرم مجزای Delist برای فرستندگان دارد و گوگل از طریق Google Postmaster Tools وضعیت اعتبار دامنه شما را نشان می‌دهد. این‌ها در MXToolbox دیده نمی‌شوند.

لیست‌های RBL که ارزش بررسی دارند

این لیست‌ها امروز فعال هستند و به کوئری عمومی پاسخ می‌دهند:

• UCEPROTECT (سطوح ۱، ۲ و ۳) — dnsbl-1.uceprotect.net تا dnsbl-3.uceprotect.net
• Spamhaus — zen.spamhaus.org
• SpamCop — bl.spamcop.net
• Barracuda — b.barracudacentral.org (فقط از resolver ثبت‌شده پاسخ می‌دهد)
• PSBL (Passive Spam Block List) — psbl.surriel.com

سه نامی که در آموزش‌های قدیمی و اسکریپت‌های آماده زیاد دیده می‌شوند ولی امروز نباید در اسکریپت شما باشند:

• SORBS (dnsbl.sorbs.net) — این سرویس در سال ۲۰۲۴ تعطیل شد و ناحیه DNS آن دیگر پاسخی نمی‌دهد.
• Lashback UBL (ubl.unsubscore.com) — از سال ۲۰۲۱ آفلاین است و ناحیه آن هیچ رکوردی برنمی‌گرداند.
• Invaluement — این لیست تعطیل نشده اما اشتراکی و پولی است و نام ناحیه‌های آن (ivmSIP و ivmSIP/24) فقط در اختیار مشترکان قرار می‌گیرد. نامی مثل dnsbl.invaluement.com که در بعضی اسکریپت‌های اینترنتی دیده می‌شود اصلاً وجود خارجی ندارد.

خطر هر سه مورد یکی است: کوئری روی یک ناحیه مرده یا اشتراکی همیشه پاسخ خالی می‌دهد و اسکریپت آن را «تمیز» گزارش می‌کند. برای بررسی همزمان در چندین لیست بدون درگیر شدن با این موضوع، MXToolbox یا multirbl.valli.org سریع‌ترین راه هستند، چون فهرست لیست‌های خود را به‌روز نگه می‌دارند.

جمع‌بندی

ارسال ایمیل قابل اعتماد به سه چیز وابسته است: رکوردهای درست (SPF، DKIM، DMARC، MX و مهم‌تر از همه PTR سازگار با نام میزبان)، سروری که از آن اسپم خارج نمی‌شود، و پایش مداوم آی‌پی در RBLها. ترتیب رفع مشکل هم همین است — اول متن Bounce را بخوانید تا بدانید با کدام یک از این سه روبه‌رو هستید، بعد با MXToolbox، UCEPROTECT، اسکریپت dig و ابزارهای WHM دقیقاً منبع را پیدا کنید، علت را ببندید و در آخر درخواست حذف از لیست بدهید.