چرا ایمیل به پوشه اسپم میرود؟
عیبیابی هویت فرستنده تا رفتار ارسال
ورود به spam یک علت واحد و یک رکورد جادویی ندارد. گیرنده هویت دامنه و IP، نتیجه احراز هویت، همراستایی From، سابقه شکایت و bounce، الگوی حجم، محتوا و انتخاب کاربر را کنار هم ارزیابی میکند. باید ابتدا بفهمید پیام reject شده، defer شده یا تحویل و سپس spam شده است.
اول بین reject، defer و spam فرق بگذارید
در reject، سرور گیرنده پیام را با کد دائمی 5xx نمیپذیرد؛ در defer با کد 4xx از فرستنده میخواهد بعداً تلاش کند؛ در spam پیام پذیرفته شده اما فیلتر یا کاربر آن را در پوشه دیگری قرار داده است. متن دقیق SMTP و log صف ارسال، نقطه شروع است. تکرار سریع یک خطای موقت میتواند وضعیت را بدتر کند.
از یک پیام رسیده، headerهایی مانند Authentication-Results، مسیر Received، دامنه From، envelope-from و امضای DKIM را بخوانید. «SPF pass» برای یک دامنه دیگر لزوماً DMARC pass نیست. آزمون را برای هر مسیر ارسال—وبسایت، CRM، خبرنامه و صندوق کارکنان—جدا انجام دهید.
SPF باید همه فرستندهها را در یک سیاست معتبر پوشش دهد
SPF با یک TXT record مشخص میکند چه سامانههایی مجازند برای envelope domain ایمیل ارسال کنند. ابتدا inventory واقعی فرستندهها را بسازید: mail server، سرویس خبرنامه، فرم سایت، CRM و relay. سپس سیاست را مطابق مستندات providerها ترکیب کنید. چند SPF record مستقل با v=spf1 برای یک نام، نتیجه معتبر نمیسازد.
SPF محدودیت lookup دارد و includeهای زنجیرهای میتوانند آن را بشکنند. رکوردهای منسوخ را حذف و نتیجه را از بیرون بررسی کنید. همچنین forwarding میتواند SPF را به دلیل تغییر مسیر شکست دهد؛ به همین دلیل DKIM و alignment DMARC نیز اهمیت دارند.
DKIM امضا را به دامنه شما متصل میکند
در DKIM، فرستنده بخشهایی از پیام را با کلید خصوصی امضا میکند و گیرنده کلید عمومی selector را از DNS میخواند. فعالکردن فقط TXT record کافی نیست؛ mail system باید واقعاً پیام خروجی را امضا کند و header امضا باید دامنه و selector مورد انتظار را نشان دهد.
نتیجه DKIM را در Authentication-Results ببینید. خطا میتواند از selector اشتباه، کلید منتشرنشده، شکستن پیام توسط واسط یا تنظیمنبودن signer باشد. کلید خصوصی باید محافظت و دورهای چرخانده شود؛ هنگام چرخش، رکورد قدیمی را تا عبور پیامهای در صف فوراً حذف نکنید.
DMARC فقط pass نیست؛ alignment با From مهم است
DMARC میخواهد حداقل یکی از SPF یا DKIM علاوه بر pass، با دامنه قابلمشاهده در header From همراستا باشد. این تفاوت توضیح میدهد چرا داشبورد provider ممکن است SPF pass نشان دهد اما DMARC fail باشد. دامنه bounce یا DKIM signing باید طبق حالت alignment با From مرتبط باشد.
سیاست را ناگهانی روی reject نگذارید. ابتدا گزارشهای aggregate را با p=none جمعآوری کنید، فرستندههای مشروع و ناشناخته را تفکیک و alignment را اصلاح کنید؛ سپس enforcement را مرحلهای افزایش دهید. آدرس دریافت گزارش نیز باید امن و قابل پردازش باشد. DMARC جدید در RFC 9989 تعریف شده و جایگزین RFC 7489 شده است.
PTR، نام میزبان، TLS و IP ارسال را بررسی کنید
IP عمومی mail server باید PTR معنادار داشته باشد و آن hostname نیز با A یا AAAA به همان IP برگردد. PTR معمولاً توسط مالک IP یا میزبان زیرساخت تنظیم میشود، نه در zone معمولی دامنه. HELO/EHLO باید نام معتبر و سازگار ارائه کند و ارسال به مقصدهای مدرن با TLS انجام شود.
IP تازه، اشتراکی یا دارای سابقه نامطلوب میتواند حتی با DNS درست اعتماد کمی داشته باشد. وضعیت blocklist فقط یک سیگنال است و خروج از یک فهرست inbox را تضمین نمیکند. منبع ارسال ناخواسته را پیدا کنید: حساب لورفته، فرم بدون محدودیت، malware یا queue قدیمی باید پیش از درخواست بازبینی متوقف شود.
رضایت گیرنده و الگوی ارسال از رکورد DNS مهمترند
فقط به افرادی پیام تبلیغاتی بفرستید که روشن و قابلاثبات رضایت دادهاند، لغو عضویت را ساده و سریع اجرا کنید و آدرسهای hard bounce یا شکایتکننده را دوباره هدف نگیرید. فهرست خریداریشده، افزایش ناگهانی حجم و ارسال نامرتبط، reputation دامنه و IP را تخریب میکند.
برای جریان تراکنشی و بازاریابی دامنه یا stream عملیاتی جدا در نظر بگیرید تا مشکل یک جریان دیگری را زمینگیر نکند. نرخ ارسال را با سابقه و پاسخهای گیرنده تنظیم و Postmaster ابزار provider مقصد را در صورت واجدشرایطبودن پایش کنید. موضوع فریبنده، لینکهای مبهم و نسخه فقط تصویری نیز تجربه کاربر را بد میکنند.
یک روال تشخیص قابل تکرار بسازید
برای هر رخداد، timestamp، message ID، IP خروجی، دامنه From، envelope-from، selector DKIM، گیرنده آزمایشی و پاسخ کامل SMTP را ثبت کنید. سپس DNS عمومی، Authentication-Results و log فرستنده را کنار هم بگذارید. تغییر همزمان SPF، DKIM، محتوا و IP فهم اثر هر اصلاح را ناممکن میکند.
پس از اصلاح، با حجم کم و گیرندگان واقعیِ رضایتداده آزمایش کنید و نرخ bounce، شکایت و placement را در طول زمان ببینید. هیچ ارائهدهندهای نمیتواند قرارگرفتن همه پیامها در inbox همه گیرندگان را تضمین کند؛ هدف، انطباق فنی، رفتار سالم و مشاهدهپذیری مستمر است.
پرسشهای پرتکرار
اگر SPF و DKIM هر دو pass باشند چرا ایمیل هنوز spam میشود؟
احراز هویت فقط بخشی از تصمیم است. alignment DMARC، reputation دامنه و IP، شکایت کاربران، bounce، حجم ناگهانی، محتوا و سابقه تعامل نیز اثر دارند.
آیا میتوانم دو رکورد SPF جدا داشته باشم؟
برای یک نام، چند رکورد مستقل v=spf1 باعث خطای ارزیابی میشود. همه منابع مجاز باید با رعایت syntax و محدودیت lookup در یک سیاست معتبر ترکیب شوند.
PTR را کجا تنظیم کنم؟
PTR در reverse DNS فضای IP تنظیم میشود و معمولاً باید از مالک IP یا شرکت میزبان بخواهید آن را به hostname موردنظر تغییر دهد. سپس forward DNS همان hostname نیز باید به IP برگردد.
DMARC را از p=reject شروع کنم؟
برای دامنه فعال معمولاً ابتدا گزارشگیری و inventory با p=none، سپس اصلاح alignment و افزایش مرحلهای enforcement کمریسکتر است. سیاست سخت ناگهانی میتواند فرستنده مشروع فراموششده را مسدود کند.
آیا تغییر متن ایمیل مشکل را حل میکند؟
اگر علت authentication، reputation یا فهرست نامعتبر باشد، تغییر چند واژه مشکل اصلی را حل نمیکند. ابتدا پاسخ SMTP و header را تحلیل کنید و بعد تجربه محتوا را بهبود دهید.
چطور بفهمم کدام سرویس از دامنه من ایمیل میفرستد؟
inventory داخلی را با گزارشهای DMARC، log سامانهها و header پیامهای واقعی تطبیق دهید. IP، envelope-from و DKIM selector معمولاً جریانهای مختلف را از هم جدا میکنند.
منابع رسمی و مطالعه بیشتر
پیش از انتخاب سرویس ایمیل، نیازت را دقیق کن
تعداد حسابها، حجم ارسال، DNS و مسئولیت نگهداری را مشخص و سپس گزینههای فعال را بررسی کن.