نحوه تنظیم رکورد PTR برای سرور ایمیل

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

رکوردهای PTR اغلب چیزی هستند که پس از راه‌اندازی کامل بقیه‌ی پشته‌ی احراز هویت، از دست می‌روند. اکثر فرستندگان هر چیزی را که مستقیماً کنترل می‌کنند پیکربندی می‌کنند و همچنان با مشکلات تحویل مواجه می‌شوند زیرا IP ارسال‌کننده به یک نام میزبان قابل اعتماد اشاره نمی‌کند.

تنظیم یک رکورد PTR به معنای یافتن IP فرستنده، تأیید اینکه چه کسی آن را کنترل می‌کند، انتخاب نام میزبان مناسب، ارسال درخواست به مالک IP و بررسی عملکرد DNS معکوس پس از تغییر است.

نحوه تنظیم رکورد PTR برای سرور ایمیل: 5 مرحله

راه‌اندازی PTR در هر ارائه‌دهنده‌ی هاستینگی، پنج مرحله‌ی اساسی یکسانی را دنبال می‌کند. تنها بخشی که تغییر می‌کند، نحوه‌ی ارسال درخواست PTR است.

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

مرحله ۱: آدرس IP عمومی سرور ایمیل خود را پیدا کنید

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

دستور curl ifconfig.me را از خط فرمان سرور ایمیل اجرا کنید، یا پنل تنظیمات شبکه پلتفرم ابری خود را بررسی کنید. برای سرویس‌های SMTP اختصاصی، IP فرستنده معمولاً مستقیماً در داشبورد ارائه‌دهنده نمایش داده می‌شود.

تأیید کنید که IP ثابت است. رکوردهای PTR به IP ثابت نیاز دارند؛ اگر IP اصلی به صورت دوره‌ای تغییر کند، بی‌فایده هستند. پلتفرم‌های ابری معمولاً IP ثابت را به طور پیش‌فرض برای سرورهای ایمیل اختصاص می‌دهند، اما قبل از رفتن به مرحله بعدی، این موضوع را تأیید کنید.

مرحله ۲: مالک بلوک IP خود را شناسایی کنید

با استفاده از IP جستجو کنید ابزار DNS معکوس MXToolbox یا با اجرای یک کوئری WHOIS در برابر ARIN، RIPE یا APNIC، بسته به منطقه شما. نتیجه، سازمانی را که بلوک IP را کنترل می‌کند، مشخص می‌کند که معمولاً ارائه دهنده ابر، شرکت میزبانی وب یا ISP شما است.

شما نمی‌توانید مالک IP را نادیده بگیرید. آنها منطقه DNS معکوس را که رکورد PTR در آن قرار دارد، کنترل می‌کنند. حتی اگر DNS دامنه خود را مدیریت کنید، DNS معکوس فضای IP که مالک آن نیستید را کنترل نمی‌کنید.

مرحله ۳: یک نام میزبان انتخاب کنید و یک رکورد A مطابق با آن اضافه کنید

نام میزبان (hostname) را انتخاب کنید که به وضوح نقش و دامنه سرور ایمیل را مشخص کند، برای مثال، mail.yourcompany.com یا smtp.yourcompany.com به خوبی کار می‌کنند. از نام‌های میزبان عمومی ارائه شده توسط ISP مانند host-203-0-113-25.example-isp.com که حتی از نظر فنی نیز برای سرورهای دریافت ایمیل مشکوک به نظر می‌رسند، خودداری کنید.

در DNS دامنه خود، یک رکورد A ایجاد کنید که این نام میزبان را به IP عمومی سرور ایمیل شما اشاره کند. این رکورد A باید قبل از ارسال درخواست PTR وجود داشته باشد؛ DNS معکوس با تأیید رو به جلو (FCrDNS) مستلزم آن است که جستجوهای رو به جلو و معکوس با یکدیگر مطابقت داشته باشند.

قبل از ارسال درخواست PTR، حداکثر ۲۴ ساعت برای انتشار رکورد A زمان در نظر بگیرید. اکثر DNS resolverها ظرف چند ساعت به‌روزرسانی می‌شوند، اما منتظر ماندن تا پایان مهلت، از عدم تطابق در طول فرآیند تأیید مالک IP جلوگیری می‌کند.

مرحله ۴: پیکربندی PTR از طریق مالک IP شما

مسیر دقیق کاملاً به ارائه‌دهنده شما بستگی دارد. پلتفرم‌های ابری، مانند AWS، Azure و GCP، و میزبان‌های VPS اختصاصی معمولاً پیکربندی PTR سلف سرویس را مستقیماً در کنسول‌های خود ارائه می‌دهند. میزبانی اشتراکی سنتی و ISPها معمولاً به جای آن نیاز به باز کردن بلیط پشتیبانی دارند.

هنگام ارسال درخواست، سه مورد را ذکر کنید: آدرس IP، نام میزبان مورد نظر و مدرکی که نشان دهد شما دامنه را کنترل می‌کنید (رکورد A مطابق با مرحله ۳ به عنوان مدرک عمل می‌کند). اکثر ارائه دهندگان خدمات ظرف ۱ تا ۳ روز کاری پاسخ می‌دهند. برای مسیرهای دقیق پیمایش، به بخش مربوط به ارائه دهنده در زیر مراجعه کنید.

مرحله ۵: با FCrDNS تأیید کنید

پس از تأیید تنظیم PTR توسط مالک IP، آن را با دو دستور تأیید کنید. ابتدا، دستور dig -x 203.0.113.25 @8.8.8.8 (با جایگزینی IP واقعی خود) را اجرا کنید تا تأیید شود که جستجوی معکوس، نام میزبان انتخابی شما را برمی‌گرداند. سپس دستور dig mail.yourcompany.com @8.8.8.8 (با جایگزینی نام میزبان خود) را اجرا کنید تا تأیید شود که جستجوی مستقیم A همان IP را برمی‌گرداند.

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

قبل از اینکه فرض کنید PTR جدید به طور قابل اعتمادی از همه شبکه‌ها قابل مشاهده است، تا ۲۴ ساعت برای انتشار کامل DNS زمان در نظر بگیرید.

تنظیم رکورد PTR توسط ارائه دهنده خدمات میزبانی وب

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

AWS EC2 و SES

AWS به جای پیکربندی سلف سرویس، به درخواست پشتیبانی نیاز دارد. مرکز پشتیبانی را در کنسول AWS باز کنید، بسته به منبع ترافیک ارسالی خود، «Service: SES» یا «Service: EC2» را انتخاب کنید و یک درخواست Reverse DNS ارسال کنید. IP Elastic و نام میزبان مورد نظر خود را وارد کنید. بررسی‌ها معمولاً ۲۴ تا ۴۸ ساعت طول می‌کشد. مستندات DNS معکوس SES در AWS گردش کار کامل درخواست را با جزئیات پوشش می‌دهد.

مایکروسافت لاورو

Azure از پیکربندی PTR هم از طریق Portal و هم از طریق PowerShell پشتیبانی می‌کند. در Portal، به منبع Public IP خود بروید و فیلد Reverse DNS را مستقیماً پیدا کنید. از طریق PowerShell، از Set-AzPublicIpAddress با پارامتر ReverseFqdn استفاده کنید. مستندات DNS معکوس Azure مایکروسافت، سینتکس دقیق هر دو رویکرد را پوشش می‌دهد.

Google Cloud Platform (GCP)

در کنسول GCP، به مسیر VPC Network → External IP addresses بروید. روی منوی سه نقطه کنار IP مربوطه کلیک کنید و Reverse DNS را انتخاب کنید. نام میزبان خود را وارد کرده و ذخیره کنید. GCP قبل از فعال کردن PTR، تأیید می‌کند که رکورد A نام میزبان به IP اشاره می‌کند، به این معنی که مرحله ۳ بالا باید قبل از موفقیت این مرحله تکمیل شود.

هتزنر، لینود و دیجیتال اوشن

هر سه ارائه دهنده VPS اختصاصی، پیکربندی PTR سلف سرویس را مستقیماً از طریق پنل‌های کنترل خود ارائه می‌دهند. در Hetzner Robot یا Cloud، IP را در قسمت Servers پیدا کنید، روی نماد مداد کنار rDNS کلیک کنید و نام میزبان را وارد کنید. در Linode Cloud Manager، تب Network در Linode را باز کنید. در DigitalOcean، PTR را در قسمت Networking از تنظیمات Droplet پیکربندی کنید.

هاست اشتراکی و سی پنل

میزبان‌های اشتراکی سنتی، مانند Bluehost، HostGator، GoDaddy و اکثر ارائه‌دهندگان مبتنی بر cPanel، معمولاً پیکربندی PTR سلف سرویس ارائه نمی‌دهند. یک تیکت پشتیبانی باز کنید و درخواست یک رکورد PTR برای IP خود، با اشاره به نام میزبان سرور ایمیل خود، و ارائه مدرک مالکیت دامنه از طریق رکورد A منطبق، ارائه دهید.

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

سرویس‌های ایمیل میزبانی‌شده (Google Workspace، Microsoft 365)

سرویس‌های ایمیل میزبانی‌شده، رکوردهای PTR را در زیرساخت مشترک خود مدیریت می‌کنند. فرستندگانی که از Google Workspace یا Microsoft 365 استفاده می‌کنند، نیازی به پیکربندی PTR خود ندارند، زیرا ارائه‌دهنده خدمات، این کار را برای IPهایی که در اختیار دارند و کنترل می‌کنند، انجام می‌دهد.

این فقط زمانی اعمال می‌شود که از طریق سرورهای خروجی خود سرویس ارسال کنید. اگر هنگام استفاده از Google Workspace یا Microsoft 365 برای اهداف دیگر، ایمیل را از طریق یک سرور SMTP شخص ثالث هدایت کنید، الزامات PTR برای IP آن سرور شخص ثالث اعمال می‌شود، نه برای زیرساخت‌های گوگل یا مایکروسافت.

چگونه از کارکرد صحیح رکورد PTR خود مطمئن شویم؟

تأیید دو چیز جداگانه را تأیید می‌کند: اینکه PTR اصلاً پیکربندی شده است و اینکه FCrDNS به طور واضح حل می‌شود. نادیده گرفتن این مرحله رایج‌ترین دلیلی است که تیم‌ها معتقدند PTR تنظیم شده است، در حالی که در واقع به درستی کار نمی‌کند.

• تأیید خط فرمان: برای تأیید اینکه جستجوی معکوس، نام میزبان انتخابی شما را برمی‌گرداند، دستور dig -x [your IP] @8.8.8.8 را اجرا کنید. برای تأیید اینکه جستجوی مستقیم، IP شما را برمی‌گرداند، دستور dig [your hostname] @8.8.8.8 را اجرا کنید. هر دو نتیجه باید مطابقت داشته باشند؛ این بررسی FCrDNS است که سرورهای دریافت کننده ایمیل واقعاً انجام می‌دهند.
• ابزارهای تأیید آنلاین: جستجوی معکوس DNS در MXToolbox یک IP را می‌پذیرد و نام میزبان PTR به همراه وضعیت قبولی/ردی را برمی‌گرداند. این برای تأیید غیر فنی و برای درج در تیکت‌های پشتیبانی هنگام کار با صاحب IP شما برای رفع مشکل مفید است.
• تأیید سمت سرور: دستور hostname -f را روی خود سرور ایمیل اجرا کنید تا مطمئن شوید که نام میزبان پیکربندی شده توسط سرور با آنچه PTR برمی‌گرداند مطابقت دارد. اگر این دو با هم متفاوت باشند، دستور HELO/EHLO سرور ایمیل نامی متفاوت از آنچه PTR به آن پاسخ می‌دهد ارسال می‌کند و اکثر سرورهای گیرنده این عدم تطابق را به عنوان یک خطای نرم‌افزاری (soft fail) در نظر می‌گیرند، حتی زمانی که خود PTR از نظر فنی معتبر باشد.

مشکلات رایج ضبط PTR و نحوه رفع آنها

این چهار مشکل باعث ایجاد اکثر مشکلات مربوط به تحویل PTR می‌شوند. در بیشتر موارد، رفع آنها به معنای تماس با صاحب IP است.

رکورد PTR به طور کامل وجود ندارد

تشخیص دادن: اجرای دستور dig -x [your IP] @8.8.8.8 هیچ نتیجه PTR را برنمی‌گرداند، یا NXDOMAIN را برمی‌گرداند.

ثابت: با مالک IP تماس بگیرید و درخواست یک رکورد PTR که به نام میزبان سرور ایمیل انتخابی شما اشاره می‌کند را بدهید. مدرک مالکیت دامنه و رکورد A منطبق از DNS دامنه خود را به عنوان مدرک پشتیبان ارائه دهید.

نام میزبان PTR با رکورد A مطابقت ندارد (خطای FCrDNS)

تشخیص دادن: جستجوی معکوس، یک نام میزبان را برمی‌گرداند، اما جستجوی رو به جلوی آن نام میزبان، یک IP متفاوت یا بدون IP را برمی‌گرداند. این الگوی شکست کلاسیک FCrDNS است.

ثابت: یا رکورد A را به‌روزرسانی کنید تا به IP فرستنده‌ی واقعی اشاره کند، یا از مالک IP بخواهید رکورد PTR را به‌روزرسانی کند تا با یک رکورد A موجود مطابقت داشته باشد. برای اینکه FCrDNS بتواند عبور کند، هر دو رکورد باید به یکدیگر تبدیل شوند.

نام میزبان عمومی ISP به جای نام میزبان برند

تشخیص دادن: PTR به جای یک نام میزبان برند تحت دامنه خودتان، یک نام میزبان مانند host-203-0-113-25.example-isp.com را برمی‌گرداند.

ثابت: از مالک IP بخواهید PTR را به‌روزرسانی کند تا به یک نام میزبان تحت دامنه شما (mail.yourcompany.com یا smtp.yourcompany.com) اشاره کند. نام‌های میزبان عمومی ISP از نظر فنی FCrDNS را از کار نمی‌اندازند، اما برای سرورهای گیرنده مشکوک به نظر می‌رسند و سیگنال‌های اعتماد کلی را کاهش می‌دهند.

رکورد IPv6 PTR موجود نیست

تشخیص دادن: PTR برای ترافیک IPv4 به درستی کار می‌کند، اما Gmail ایمیل‌های دریافتی از IPv6 را که دارای خطاهای «reverse DNS failed» یا «sender identity mismatch» هستند، رد می‌کند.

ثابت: درخواست یک رکورد PTR جداگانه مخصوص آدرس IPv6. رکوردهای PTR IPv6 در ناحیه ip6.arpa با نمادگذاری nibble-reversed قرار دارند، به این معنی که آنها کاملاً جدا از رکوردهای IPv4 پیکربندی می‌شوند، حتی زمانی که هر دو به یک سرور ایمیل یکسان سرویس می‌دهند.

رکوردهای PTR به درستی انجام شده است

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

تأیید FCrDNS مهمترین بررسی پس از تکمیل پیکربندی است. اکثر مشکلات مربوط به تحویل‌پذیری مربوط به PTR به عدم تطابق بین PTR و رکورد A منطبق برمی‌گردد. با رفع این عدم تطابق، مشکلات مربوط به تحویل‌پذیری معمولاً خود به خود حل می‌شوند.

اعتبار قوی دامنه و IP به رکوردهای PTR که در کنار SPF، DKIM و DMARC کار می‌کنند بستگی دارد. رکوردهای PTR هویت را در سطح شبکه تأیید می‌کنند، اما جایگزین سلامت خوب لیست نمی‌شوند. برای قابلیت تحویل قابل اعتماد، احراز هویت و کیفیت لیست هر دو باید برقرار باشند.

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