وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

رکورد PTR ایمیل چیست؟ رفع ناهماهنگی Reverse DNS سرور ارسال

مراحل پیدا کردن IP ارسال ایمیل، بررسی PTR و A یا AAAA متناظر و اصلاح ناهماهنگی Reverse DNS با ارائه‌دهنده سرور.

انتشار:
توسط تیم دامنه نت‌آرام
۷ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله رکورد PTR ایمیل چیست؟ رفع ناهماهنگی Reverse DNS سرور ارسال در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
ایمیل شما برگشت خورده و در متن خطا عبارتی مانند PTR یا reverse DNS دیده می‌شود. ممکن است سرور گیرنده نتوانسته برای IP فرستنده نام مناسبی پیدا کند، یا نام پیدا شده دوباره به همان IP برنگردد. این مشکل با عوض کردن رمز صندوق یا ساختن یک رکورد دلخواه در پنل دامنه لزوماً حل نمی‌شود.
در این راهنما ابتدا IP واقعی سرور ارسال‌کننده را پیدا می‌کنیم، بعد مسیر رفت و برگشت نام و IP را آزمایش می‌کنیم. تنظیم درست PTR می‌تواند یکی از شرایط تحویل باشد، اما تضمین نمی‌کند همه ایمیل‌ها به Inbox برسند؛ اعتبار فرستنده، SPF، DKIM، محتوای پیام و سیاست گیرنده هم نقش دارند.

PTR را با یک مثال ساده بشناسیم

فرض کنید IP عمومی سرور ارسال 203.0.113.10 و نام انتخاب‌شده برای آن mail.example.com است. این IP و نام صرفاً نمونه‌اند و باید در آزمایش با مقادیر واقعی جایگزین شوند.
دو پرسش جدا داریم:
  1. مسیر معکوس: وقتی IP سرور را می‌پرسیم، PTR چه نامی برمی‌گرداند؟ در مثال انتظار داریم mail.example.com برگردد.
  2. مسیر مستقیم: وقتی رکورد A همان نام را می‌پرسیم، آیا IP ارسال‌کننده در پاسخ وجود دارد؟ در مثال انتظار داریم 203.0.113.10 دیده شود.
برای IPv6 به جای A، رکورد AAAA نام باید با IPv6 واقعی مورد بررسی تطبیق داده شود. این تطبیق را گاهی Forward-confirmed reverse DNS می‌نامند. راهنمای فرستندگان Gmail نمونه‌ای از الزام تطبیق رکورد مستقیم و معکوس را توضیح می‌دهد.
نامی که در بخش From ایمیل به مشتری نشان داده می‌شود، نام میزبان سرور ارسال و نام PTR می‌توانند نقش‌های متفاوتی داشته باشند. در سرور اشتراکی ممکن است چند دامنه از IP و نام میزبان مشترک استفاده کنند؛ قرار نیست بدون هماهنگی PTR آن IP را برای هر دامنه تغییر دهید.

قدم اول: IP واقعی ارسال را پیدا کنید

ابتدا مشخص کنید پیام واقعاً از چه سرویسی ارسال می‌شود: صندوق هاست، افزونه SMTP، سرویس خبرنامه یا یک سرور واسطه. IP سایت یا IP رکورد A دامنه لزوماً همان IP فرستنده ایمیل نیست. اگر سرور از smarthost استفاده می‌کند، ممکن است سرویس واسطه پیام را به گیرنده نهایی تحویل دهد و IP آن برای این بررسی مهم باشد.
یک پیام آزمایشی غیرمحرمانه از همان صندوق یا برنامه مشکل‌دار به صندوقی بفرستید که خودتان آن را کنترل می‌کنید. در برنامه گیرنده از گزینه‌ای مانند Show original یا نمایش سرآیند کامل استفاده کنید و گزارش تحویل یا IP فرستنده‌ای را که سرویس گیرنده برای ارتباط دیده، با مدیر ایمیل تطبیق دهید. سرآیند ممکن است چند خط Received داشته باشد؛ همه IPهای داخل آن الزاماً IP ارسال‌کننده نهایی نیستند. اگر مطمئن نیستید، شناسه پیام و زمان را به ارائه‌دهنده ایمیل بدهید تا IP درست را مشخص کند.
اگر خطای برگشتی صریحاً IP موردنظر را نشان می‌دهد، آن را نیز یادداشت کنید. متن پیام، نشانی گیرنده و شناسه‌ها می‌توانند محرمانه باشند؛ فقط بخش لازم را از مسیر امن با پشتیبانی به اشتراک بگذارید.

قدم دوم: پاسخ PTR را از DNS بپرسید

در PowerShell یا Command Prompt ویندوز، پس از جایگزین کردن IP نمونه با IP واقعی، اجرا کنید:
کد / دستورnslookup 203.0.113.10 1.1.1.1
این دستور از DNS عمومی مشخص‌شده درباره نام معکوس IP می‌پرسد. ابتدا اطلاعات سرور پاسخ‌دهنده و سپس نتیجه مربوط به IP موردنظر را ببینید؛ آدرس DNS پاسخ‌دهنده را با آدرس سرور ایمیل اشتباه نگیرید. اگر آن DNS عمومی در شبکه شما قابل دسترسی نیست، می‌توانید از resolver مجاز و در دسترس خود استفاده کنید.
در لینوکس، اگر dig نصب است، نمونه خواناتر زیر هم همین پرس‌وجوی معکوس را انجام می‌دهد:
کد / دستورdig @1.1.1.1 -x 203.0.113.10 +short
اگر نامی مانند mail.example.com برمی‌گردد، آن نام را دقیق یادداشت کنید؛ نقطه پایانی در برخی خروجی‌های DNS بخشی از نمایش نام کامل است. اگر خروجی خالی یا خطا است، قبل از نتیجه‌گیری متن کامل را بدون گزینه short هم ببینید. timeout، نبود رکورد و پاسخ نامعتبر یکسان نیستند. تغییر تازه PTR هم ممکن است برای مدتی در کش برخی resolverها قدیمی دیده شود.

قدم سوم: نام برگشتی را دوباره به IP تبدیل کنید

نام واقعی حاصل از مرحله قبل را به جای mail.example.com قرار دهید و در ویندوز اجرا کنید:
کد / دستورResolve-DnsName -Name mail.example.com -Type A -Server 1.1.1.1 -DnsOnly
در لینوکس با dig:
کد / دستورdig @1.1.1.1 mail.example.com A +short
آیا IP واقعی ارسال که در قدم اول تأیید کردید در پاسخ وجود دارد؟ اگر بله، مسیر معکوس و مستقیم در این آزمایش با هم هماهنگ‌اند. اگر نام وجود ندارد یا فقط IP دیگری برمی‌گرداند، نام PTR، رکورد مستقیم، مسیر خروج ایمیل و محل DNS فعال را با هم بررسی کنید.
برای ارسال IPv6، IP واقعی IPv6 را در پرس‌وجوی معکوس و نوع AAAA را در پرس‌وجوی مستقیم به کار ببرید. اگر سیستم هم IPv4 و هم IPv6 برای ارسال استفاده می‌کند، هر IP ارسال‌کننده باید جداگانه بررسی شود؛ درست بودن فقط یکی از آن‌ها به معنی درست بودن دیگری نیست.

چه کسی می‌تواند PTR را تغییر دهد؟

رکورد A یا AAAA نام میزبان معمولاً در DNS فعال همان نام مدیریت می‌شود، اما PTR مربوط به فضای معکوس IP است و اختیار آن اغلب با مالک شبکه یا ارائه‌دهنده IP است. ممکن است در پنل سرویس گزینه Reverse DNS داشته باشید؛ در غیر این صورت باید از ارائه‌دهنده سرور یا IP درخواست تغییر کنید. راهنمای cPanel درباره Reverse DNS توضیح می‌دهد چرا همه حساب‌ها اختیار تغییر PTR را ندارند.
اگر IP اختصاصی و اختیار نام میزبان دارید، روند معمول چنین است:
  1. با مدیر سرویس ایمیل یک نام میزبان مناسب و واقعی انتخاب کنید؛ برای مثال mail.example.com، نه نامی از دامنه شخص دیگر.
  2. در DNS فعال آن نام، رکورد مستقیم مناسب را طبق طرح سرویس به IP ارسال متصل کنید. اگر نام قبلاً برای سرویس دیگری استفاده می‌شود، قبل از ویرایش اثر آن را بررسی کنید.
  3. از مالک IP یا پنل مجاز بخواهید PTR همان IP را به نام مورد توافق تنظیم کند.
  4. پس از اعمال، هر دو پرس‌وجوی مستقیم و معکوس را دوباره انجام دهید و با IP خروجی واقعی تطبیق دهید.
در سرور اشتراکی، PTR معمولاً متعلق به نام میزبان مشترک است و تغییر آن ممکن است روی فرستنده‌های دیگر هم اثر بگذارد. در این حالت به جای درخواست تغییر به نام دامنه خودتان، متن خطا و IP تأییدشده را برای میزبان بفرستید تا نام مشترک و مسیر ارسال را اصلاح کند.

اگر PTR درست است ولی پیام هنوز رد می‌شود

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

رفع مشکل را چطور تأیید کنیم؟

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

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام