محتوای آموزشی وبلاگ نتآرام
ایمیل میفرستید اما پیام برگشتی با عبارتی مانند 550 5.1.1 User unknown دریافت میکنید. در بسیاری از سرویسها این پیام یعنی سامانهای که درخواست را بررسی کرده، گیرنده موردنظر را در مسیر تحویل خود پیدا نکرده است. رایجترین علت میتواند اشتباه در نشانی باشد، اما صندوق حذفشده، قانون فوروارد اشتباه یا مسیر نادرست ایمیل هم ممکناند.
ابتدا پیام برگشتی و آدرس همان گیرنده را میخوانیم و بعد بسته به اینکه فرستنده هستید یا مدیر دامنه، مسیر درست را دنبال میکنیم. این کد با هر پیام دیگری که عدد ۵۵۰ دارد یکسان نیست؛ متن و کد کامل مهماند.
قدم اول: پیام برگشتی را درست بخوانید
در نامه برگشتی، زمان، نشانی گیرندهای که رد شده، نام سرور گزارشدهنده و عبارت خطا را پیدا کنید. اگر فقط یک نفر از چند گیرنده رد شده، بقیه دریافتکنندگان ممکن است وضعیت متفاوتی داشته باشند. وجود پیام برگشتی یعنی تحویل همان مسیر کامل نشده است، اما ممکن است قبل یا بعد از فوروارد در نقطه دیگری رد شده باشد.
در Gmail، کد ۵۵۰ با جزئیات ۵.۱.۱ معمولاً برای حساب مقصدی بهکار میرود که پیدا نشده است؛ جدول رسمی خطاهای Gmail نمونه پیامها را نشان میدهد. در مقابل،
550 5.7.1 اغلب موضوع سیاست یا مجوز متفاوتی دارد؛ راهنمای خطای 550 5.7.1 برای آن مسیر مناسبتر است. ارائهدهندگان مختلف ممکن است متن یا جزئیات متفاوتی نمایش دهند.اگر پیام برگشتی مربوط به ایمیلی است که شما اصلاً ارسال نکردهاید، به پیوستها و لینکهای آن اعتماد نکنید. احتمال جعل فرستنده یا ارسال غیرمجاز را طبق راهنمای ایمیل ظاهراً ارسالشده از آدرس خودتان بررسی کنید. رمز و محتوای کامل نامه را در گزارش عمومی منتشر نکنید.
اگر فرستنده هستید: آدرس را دوباره بسازید
آدرس را از یک منبع معتبر و مستقل با گیرنده تطبیق دهید. بخش قبل از
@، نام دامنه بعد از آن و پسوند را حرفبهحرف ببینید. فاصله اضافه، نقطه نابجا، غلط املایی یا انتخاب دامنه مشابه میتواند نامه را به صندوقی متفاوت بفرستد. از حدسزدن آدرس فرد یا ارسال پیاپی به چند نشانی احتمالی خودداری کنید؛ اطلاعات پیام ممکن است به شخص اشتباه برسد.در برنامهای مانند Outlook، پیشنهاد خودکار گیرنده را حذف و آدرس کامل تأییدشده را دستی وارد کنید. گاهی پیشنهاد ذخیرهشده به نشانی قدیمی یا شناسه داخلی منقضی اشاره میکند. سپس یک پیام کوتاه آزمایشی بدون پیوست و اطلاعات محرمانه بفرستید. اگر این پیام به همان آدرس تأییدشده رسید، مشکل احتمالی مربوط به انتخاب قبلی یا داده تماس بوده است.
اگر گیرنده میگوید صندوقش اخیراً تغییر کرده یا سازمان به سرویس جدید منتقل شده، از او بخواهید آدرس و وضعیت صندوق را با مدیر ایمیل خودش بررسی کند. شما بهعنوان فرستنده نمیتوانید با تغییر تنظیم رمز حساب خودتان یک صندوق حذفشده در سرور گیرنده بسازید.
اگر مدیر دامنه مقصد هستید: وجود صندوق و نام مستعار را ببینید
در پنل رسمی سرویس ایمیل مقصد، صندوق یا alias دقیق را پیدا کنید. در سیپنل معمولاً بخش Email Accounts فهرست صندوقها را نشان میدهد و فورواردها در بخش جداگانهای مدیریت میشوند. نام کاربر و دامنه را با گیرنده موجود در خطا تطبیق دهید. اگر آدرس باید وجود داشته باشد اما حساب حذف یا اشتباه ساخته شده، پس از تأیید مالک و سیاست سازمان آن را از مسیر رسمی اصلاح کنید.
قبل از ساخت دوباره صندوقی که قبلاً وجود داشته، درباره داده قدیمی، نام کاربری و وضعیت بکاپ تصمیم بگیرید؛ ساخت حساب تازه لزوماً نامههای قبلی را بازنمیگرداند. اگر نشانی در واقع alias یا فوروارد است، مقصد نهایی آن را نیز بررسی کنید. یک آدرس اولیه معتبر ممکن است به مقصدی قدیمی فوروارد شود و خطای پیدانشدن از آن مقصد برگردد.
اگر سرویس از Microsoft 365 یا سامانه ترکیبی استفاده میکند، بررسی صندوق، alias و مسیر انتقال باید در همان سرویس و با مدیر مربوط انجام شود. راهنمای Microsoft برای خطاهای 5.1.x به آدرس اشتباه، پیشنهاد خودکار و فوروارد نامعتبر بهعنوان علتهای ممکن اشاره میکند.
اگر مشکل بعد از انتقال ایمیل شروع شده است
ابتدا مشخص کنید صندوق واقعی اکنون روی کدام سرویس قرار دارد و رکوردهای MX دامنه به کجا اشاره میکنند. در ویندوز میتوانید با جایگزینی دامنه واقعی بهجای مثال، پاسخ دستگاه خود را ببینید:
کد / دستورnslookup -type=mx example.com
این پاسخ، رکوردهای MX دیدهشده توسط حلکننده همان دستگاه را نشان میدهد. با تنظیم DNS فعال و اطلاعات سرویس ایمیل مقصد مقایسه کنید. نتیجه ممکن است در کش باشد و اگر چند رکورد با اولویت متفاوت دارید، حذف یکی از آنها بدون شناخت طراحی ممکن است تحویل را مختل کند. راهنمای انتقال ایمیل دامنه بدون ازدسترفتن پیام برنامه مهاجرت را توضیح میدهد.
اگر ارسال از یک سایت روی همان هاست به صندوق دامنهای که ایمیل آن جای دیگری میزبانی میشود خطا میدهد، تنظیم Email Routing همان دامنه در سیپنل را نیز با محل واقعی صندوق مقایسه کنید. تشخیص اشتباه Local و Remote ممکن است سرور را به مسیر نادرست بفرستد. راهنمای تنظیم Local و Remote ایمیل مراحل این حالت را دارد. تغییر بیهدف MX و routing برای همه دامنهها مناسب نیست.
اگر فقط یک فرستنده یا برنامه خطا میگیرد
با اجازه طرفین، همان آدرس تأییدشده را از یک حساب مجاز دیگر و با پیام ساده آزمایش کنید. اگر فرستنده دوم موفق است، گزارش و نشانی ذخیرهشده در برنامه اول، فوروارد و مسیری که آن سرویس استفاده میکند را مقایسه کنید. اگر همه فرستندگان پیام مشابه دارند، بررسی صندوق و مسیر مقصد اولویت پیدا میکند. این آزمایش به تنهایی جای گزارش سرور و تأیید صاحب صندوق را نمیگیرد.
در سیپنل، مدیر فرستنده میتواند Track Delivery را برای زمان همان تلاش باز کند و نتیجه را با پیام برگشتی تطبیق دهد. فهرست رخدادها ممکن است تاریخچه محدود داشته باشد. راهنمای خواندن گزارش تحویل تفاوت ارسال و دریافت واقعی را توضیح میدهد. نام صندوق، آدرس خصوصی و محتوای نامه را فقط در مسیر مجاز به پشتیبانی بدهید.
بعد از اصلاح چه چیزی را تأیید کنیم؟
یک نامه کوتاه و غیرحساس به آدرس تأییدشده بفرستید و از گیرنده بخواهید دریافت آن را در صندوق مقصد بررسی کند. اگر فوروارد وجود دارد، مسیر نهایی را نیز با مسئول آن تأیید کنید. دیدهشدن نامه در پوشه ارسالشده بهتنهایی ثابت نمیکند تحویل کامل شده است.
برای مشخصات میزبانی میتوانید صفحه هاست وردپرس نتآرام را ببینید. وضعیت صندوق و مسیر ایمیل هر دامنه باید از تنظیمات و گزارش واقعی همان سرویس تعیین شود.
برچسبها:
اشتراکگذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاهها (۰)
دیدگاههای تاییدشده و پاسخهای تیم نتآرام
