وقتی ایمیل تأیید دیر می‌رسد، دکمه ارسال مجدد به‌نظر می‌رسد پاسخ واضحی باشد. اغلب این کار وضعیت را بدتر می‌کند: چند پیام همزمان می‌رسند، فقط جدیدترین کد معتبر می‌ماند و هیچ‌کس نمی‌داند کدام درخواست کدام پیام را تولید کرده است.
تحویل را به‌عنوان یک دنباله از نقاط بررسی در نظر بگیرید. آخرین نقطه بررسی که قطعا موفق بوده را پیدا کنید، سپس نقطه بعدی را بررسی کنید.
ابتدا، شواهد را ثابت کنید
قبل از درخواست پیام دیگر، موارد زیر را ثبت کنید:
- آدرس دقیق گیرنده؛
- زمانی که دکمه ارسال را فشار دادید؛
- نام فرستنده یا سرویس؛
- آیا صفحه موفقیت را گزارش کرده است؛
- آیا این اولین درخواست است یا ارسال مجدد؛
- زمان انقضای مورد انتظار، در صورت نمایش.
صفحه فرستنده را باز نگه دارید. یک اشتباه تایپی که دو دقیقه بعد کشف می‌شود، وقتی فرم اصلی هنوز مقدار ارسال‌شده را دارد، راحت‌تر اصلاح می‌شود.
آدرس را بررسی کنید، نه حافظه‌تان
آدرس ارسال‌شده را با آدرسی که GPTMail نمایش می‌دهد مقایسه کنید. بخش محلی، هر نقطه یا رقم، و پسوند دامنه را بررسی کنید. هنگام باز بودن چندین تب صندوق‌ورودی یا تغییر اخیر دامنه انتخابی، به‌خصوص دقت کنید.
سپس تأیید کنید که دامنه در صفحه دامنه فعال است. یک آدرس می‌تواند از نظر نحوی معتبر باشد در حالی که دامنه‌اش غیرفعال یا دیگر به GPTMail مسیردهی نمی‌شود.
اگر وب‌سایت قبل از ارسال آدرس را رد کند، هنوز مشکلی در تحویل وجود ندارد. یک آدرس پشتیبانی‌شده دیگر تولید کنید و دوباره ارسال کنید.
تأیید کنید که فرستنده واقعاً تحویل را آغاز کرده است
پیام موفقیت در یک وب‌سایت گاهی فقط به این معنی است که یک کار پس‌زمینه ایجاد شده است. ممکن است فرستنده هنوز در صف باشد، محدودیت سرعت داشته باشد یا ایمیل را مجددا تلاش کند.
چند دقیقه صبر کنید قبل از ارسال مجدد. اگر سرویس یک لاگ فعالیت ارائه می‌دهد، بررسی کنید که آیا درخواست تأیید را ثبت کرده است یا نه. برای محصولی که مدیریت می‌کنید، صف برنامه و رویداد ارائه‌دهنده ایمیل را بررسی کنید نه اینکه فقط به صندوق ورودی دریافت‌کننده خیره شوید.
یک بار تازه‌سازی کنید، سپس پیام صحیح را جستجو کنید
از تازه‌سازی دستی استفاده کنید و بر اساس زمان دریافت مرتب کنید. به‌دنبال فرستنده و موضوع مورد انتظار بگردید، نه فقط نام سرویس در پیش‌نمایش قابل مشاهده. ایمیل‌های خودکار و بازاریابی می‌توانند از زیر دامنه‌های مختلف بیایند.
اگر چند کد دریافت شد، از جدیدترین درخواست استفاده کنید. بسیاری از سیستم‌ها کدهای قبلی را به‌محض صدور جایگزین، نامعتبر می‌سازند.
مشکل فرستنده را از مشکل دامنه جدا کنید
یک پیام تست کوتاه متنی ساده به همان آدرس از یک ارائه‌دهنده نامرتبط ارسال کنید.
- اگر تست برسد، دامنه دریافت‌کننده کار می‌کند و فرستنده اصلی با تاخیر، فیلتر کردن آدرس یا شکست قبل از تحویل مواجه است.
- اگر هیچ‌یک از پیام‌ها نرسد، وضعیت دامنه و پیکربندی MX را بررسی کنید.
- اگر پیام‌های یک ارائه‌دهنده می‌رسند اما دیگری به‌طور مداوم نمی‌رسد، قبل از گزارش، فرستنده، زمان‌ها و جزئیات بازگشت (bounce) را جمع‌آوری کنید.
برای دامنه سفارشی، راهنمای راه‌اندازی MX دامنه سفارشی بدون حدس را دنبال کنید. در طول یک تست زنده DNS را به‌صورت تصادفی تغییر ندهید؛ هر تغییر یک پنجره انتشار جدید ایجاد می‌کند.
درک شکست‌های رایج DNS
یک جستجوی MX ممکن است به‌صورت موقت به‌دلیل زمان‌سری (timeout) حل‌کننده، عدم توافق سرورهای نام‌گذاری معتبر، شکست اعتبارسنجی DNSSEC یا عدم انتشار رکورد، شکست بخورد. «رکوردی یافت نشد» نتیجه یک جستجوی خاص در زمان خاصی است، نه اثبات اینکه رکورد هرگز وجود نداشته است.
پاسخ DNS معتبر را پرس‌وجو کنید و هدف واقعی را با هدف نمایش داده‌شده توسط GPTMail مقایسه کنید. اگر مطابقت داشتند، صبر کنید و دوباره تلاش کنید. اگر مطابقت نداشتند، رکورد معتبر را اصلاح کنید.
وقتی پیام می‌رسد اما کد ناموفق است
تحویل و تأیید سیستم‌های جداگانه‌ای هستند. یک کد می‌تواند به دلایل زیر ناموفق باشد:
- یک کد جدیدتر آن را جایگزین کرده؛
- کد در مسیر منقضی شده؛
- به جلسه مرورگر یا حساب کاربری دیگری تعلق دارد؛
- فضای خالی همراه کد کپی شده؛
- صفحه مقصد از محیط متفاوتی استفاده می‌کند؛
- ساعت یا وضعیت فرستنده نادرست است.
یک کد جدید درخواست کنید، منتظر پیام خاص آن بمانید و یک‌بار استفاده کنید. اگر ناموفق شد، زمان درخواست و زمان پیام را همراه هم گزارش کنید.
گزارش پشتیبانی مختصر
گزارش‌های مفید شامل آدرس گیرنده، آدرس فرستنده، موضوع، زمان‌های UTC، اینکه آیا فرستنده دوم به صندوق ورودی رسیده است یا نه، و خطای دقیق نمایش داده‌شده توسط فرستنده می‌شود. قبل از به‌اشتراک‌گذاری عمومی لاگ‌ها، کدهای تأیید و لینک‌های خصوصی را حذف کنید.
«بدون ایمیل» بررسی سختی است. «پیام در ساعت ۱۴:۰۳ UTC درخواست شد؛ ارائه‌دهنده دوم در ساعت ۱۴:۰۵ رسید؛ فرستنده مورد انتظار تا ساعت ۱۴:۱۵ هیچ پیام یا بازگشتی نساخت» طرف مشکل‌دار را شناسایی می‌کند.
بدانید چه زمانی صبر را متوقف کنید
اگر حساب مهم است و سرویس روش تأیید دیگری ارائه می‌دهد، از آن استفاده کنید. اگر ثبت‌نام ریسک کمی دارد، یک آدرس پشتیبانی‌شده جدید تولید کنید و دوباره شروع کنید. صندوق ایمیل موقت را به‌عنوان تنها مسیر بازیابی برای حسابی که قصد نگهداری آن را دارید، استفاده نکنید.
راهنمای تصمیم‌گیری کلی در ایمیل موقت، استفاده بهینه موجود است.