چرا ایمیل سازمانی به اسپم می رود؟ بررسی SPF، DKIM و DMARC

پیش فاکتور برای مشتری فرستاده اید و برنامه ایمیل هم خطایی نشان نداده است. چند ساعت بعد مشتری می گوید چیزی نرسیده؛ پیام در پوشه Spam بوده است. وقتی ایمیل سازمانی به اسپم می رود، تغییر رمز صندوق یا نصب دوباره نرم افزار ایمیل معمولا نقطه شروع مناسبی نیست. باید ببینید مقصد چه پیامی دریافت کرده، فرستنده را چگونه شناخته و درباره آن چه تصمیمی گرفته است.

برای بررسی اسپم شدن ایمیل سازمانی، یک پیام واقعی را از هدر کامل آن دنبال کنید: نتیجه SPF، امضای DKIM، هم راستایی DMARC و مسیر ارسال را بخوانید؛ سپس اعتبار فرستنده و محتوای همان پیام را بررسی کنید. وجود چند رکورد سبز در یک ابزار DNS، تضمین ورود به Inbox نیست. این راهنما روی پیامی تمرکز دارد که ارسال شده اما در مقصد اسپم می شود؛ مشکل وصل نشدن برنامه به SMTP مسیر جداگانه ای دارد.

اول معلوم کنید «نرسیدن» دقیقا یعنی چه

از گیرنده بخواهید پوشه Spam و قرنطینه سازمان را هم بررسی کند. اگر گزارش برگشت دریافت کرده اید، کد خطا و متن کامل آن را نگه دارید. پیام رد شده با پیامی که پذیرفته شده و به Junk رفته یکسان نیست. عبارت Sent در برنامه شما هم تنها نشان می دهد ارسال از آن برنامه انجام شده است؛ محل نهایی پیام در صندوق مقصد را ثابت نمی کند.

برای آزمون، یک پیام کوتاه با موضوع مشخص به دو صندوق تحت کنترل خودتان در دو ارائه دهنده متفاوت بفرستید. زمان، آدرس From و Message-ID را ثبت کنید. بعد از هر اصلاح، پیام تازه ای با شناسه تازه بسازید؛ پیام دیروز با درست شدن DNS امروز دوباره ارزیابی نمی شود. از ارسال پشت سر هم ده ها نسخه یکسان خودداری کنید؛ قرار است یک مسیر را دنبال کنید، نه اینکه صندوق آزمایش را پر کنید.

هدر پیام چه چیزی را روشن می کند؟

در نسخه وب Gmail، پیام را باز کنید و از منوی کنار Reply گزینه Show original را بزنید. در سرویس های دیگر نام هایی مانند View source یا View raw message وجود دارد. راهنمای نمایش هدر کامل در Google مسیر چند سرویس را توضیح می دهد. برای پشتیبانی، اصل پیام یا هدر کامل مفیدتر از تصویری است که فقط موضوع و گیرنده را نشان می دهد؛ اطلاعات خصوصی نامرتبط را پیش از اشتراک عمومی حذف کنید.

در هدر، Authentication-Results ثبت شده توسط سامانه دریافت کننده معتبر را پیدا کنید. ممکن است چند بخش مشابه وجود داشته باشد؛ هر عبارتی که فرستنده در هدر گذاشته، گزارش قابل اعتماد مقصد نیست. RFC 8601 قالب این گزارش و اهمیت مرز اعتماد را تعریف می کند. سه نتیجه را همراه دامنه مربوط به هر کدام بخوانید، نه فقط کلمه pass را.

spf=pass smtp.mailfrom=bounce.example.com
dkim=pass header.d=example.com
dmarc=pass header.from=example.com

این خطوط نمونه آموزشی هستند، نه نتیجه آزمایش روی دامنه ای واقعی. در یک هدر واقعی، دامنه MAIL FROM، مقدار d= در DKIM-Signature و دامنه From ممکن است فرق داشته باشند. همین تفاوت گاهی توضیح می دهد چرا SPF پاس شده ولی DMARC شکست خورده است.

نتیجه قابل مشاهده	از کجا شروع کنید؟	چه چیزی را تغییر ندهید؟
spf=fail بعد از افزودن سرویس تازه	مجوز مسیر ارسال تازه در SPF	رکورد SPF دوم نسازید
spf=permerror	رکورد تکراری، ساختار و تعداد lookup	با افزودن includeهای بیشتر حدس نزنید
dkim=none	فعال بودن امضا روی سرویس ارسال	صرفا رکورد DNS را نشانه امضا ندانید
dkim=fail	selector، کلید عمومی و تغییر پیام در مسیر	کلید تصادفی جایگزین نکنید
SPF یا DKIM پاس، DMARC شکست خورده	هم راستایی دامنه با From	سیاست را برای پنهان کردن خطا سخت تر نکنید
همه پاس، پیام در Spam	اعتبار، محتوای پیام و سیاست گیرنده	DNS سالم را بی دلیل بازنویسی نکنید

SPF باید تمام مسیرهای مجاز را پوشش دهد

فهرستی از ارسال کننده های دامنه بسازید: صندوق کارمندان، سامانه حسابداری، سایت، CRM و سرویس خبرنامه. ممکن است پیام های کارمندان درست باشند اما فاکتورهای حسابداری از IP دیگری بروند. SPF برای هویت های SMTP از جمله MAIL FROM مجوز مسیر ارسال را مشخص می کند؛ صرف اینکه آدرس From در ظاهر سازمانی است، آن مسیر را مجاز نمی کند.

برای یک نام، چند رکورد مستقل که با v=spf1 شروع می شوند نسازید. باید منابع مجاز در یک سیاست معتبر جمع شوند. RFC 7208 وجود چند رکورد SPF را مجاز نمی داند و برای سازوکارهای نیازمند پرسش DNS نیز سقف تعیین می کند؛ includeهای تو در تو هم در این بررسی اهمیت دارند. از ارائه دهنده ارسال، مقدار لازم را بگیرید و قبل از حذف منابع قبلی مشخص کنید هنوز استفاده می شوند یا نه.

dig example.com TXT +short
dig _dmarc.example.com TXT +short

example.com را با دامنه واقعی عوض کنید. این فرمان ها تنظیم عمومی DNS را می خوانند؛ نتیجه احراز هویت یک پیام خاص نیستند. یک رکورد SPF صحیح برای دامنه اصلی هم لزوما مشکل MAIL FROM در زیردامنه دیگری را حل نمی کند. نامی را بررسی کنید که در گزارش واقعی پیام آمده است.

در DKIM، هم رکورد لازم است و هم امضا

DKIM پیام را با کلید خصوصی سرویس ارسال امضا می کند و گیرنده با کلید عمومی منتشر شده در DNS آن را بررسی می کند. در هدر DKIM-Signature، مقدار s= همان selector و d= دامنه امضاست. نام رکورد معمولا از ترکیب selector و _domainkey ساخته می شود. selector را از هدر یا پنل سرویس بگیرید؛ عبارت selector در مثال زیر جایگزین است، نه مقداری ثابت برای تمام سرویس ها.

dig selector._domainkey.example.com TXT +short
dig selector._domainkey.example.com CNAME +short

بعضی سرویس ها TXT می دهند و بعضی CNAME. نوع و مقصد دقیق رکورد را از پنل همان حساب بردارید؛ کپی مقدار مربوط به دامنه دیگر درست نیست. مستندات DKIM مایکروسافت تاکید می کند مقدارهای لازم را از پنل یا ابزار مدیریت حساب بگیرید. بعد از انتشار رکورد، فعال بودن امضای خروجی را نیز کنترل کنید. معیار موفقیت، dkim=pass در پیام تازه است. اگر متن پیام پس از امضا در یک واسطه تغییر کند، بررسی DKIM هم ممکن است شکست بخورد.

DMARC فقط جمع دو چراغ سبز نیست

DMARC نتیجه SPF یا DKIM را به دامنه قابل مشاهده در From مرتبط می کند. برای عبور، دست کم یکی از این مسیرها باید هم احراز هویت موفق داشته باشد و هم با دامنه From هم راستا باشد. در حالت relaxed، دامنه سازمانی مشترک می تواند کافی باشد؛ در حالت strict، تطابق دقیق تر لازم است. توضیح تنظیم DMARC در Microsoft این تفاوت بین هویت SMTP، امضای DKIM و From را روشن می کند.

فرض کنید CRM از آدرس sales@example.com پیام می فرستد، اما MAIL FROM و امضای آن هر دو متعلق به دامنه خود سرویس هستند. SPF آن سرویس می تواند پاس شود و همچنان DMARC دامنه example.com شکست بخورد. راه حل، فعال کردن امضای دامنه اختصاصی یا مسیر هم راستای پشتیبانی شده توسط همان سرویس است؛ نه افزودن یک رکورد نامرتبط به DNS.

برای دامنه فعال، رفتن مستقیم به p=reject بدون شناخت همه مسیرها می تواند پیام های سالم را هم در معرض رد شدن بگذارد. ابتدا فهرست ارسال کننده ها و گزارش های DMARC را بررسی کنید و سپس سیاست را مرحله ای تقویت کنید. راهنمای اجرای تدریجی DMARC در Google همین مسیر پایش و سپس اعمال سیاست را پیشنهاد می کند. صندوق گزارش باید واقعی، قابل دسترس و تحت نظارت باشد؛ آدرس نمونه مستندات را کپی نکنید.

اگر احراز هویت سالم است، چرا هنوز اسپم می شود؟

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

الزام های ارسال انبوه را به تمام مکاتبات اداری تعمیم ندهید. Google و Yahoo برای فرستندگان عادی و انبوه بخش های جدا دارند؛ شروط احراز هویت و لغو اشتراک بازاریابی را متناسب با نوع و حجم ارسال خود بخوانید. برای IP خروجی نیز از میزبان درباره PTR و تطابق DNS مستقیم سوال کنید. hostname و سرور واقعی ارسال را از ارائه دهنده بگیرید؛ ساختن نامی مانند mail.yourdomain بدون تنظیم سرویس کافی نیست.

اگر فقط پیام های یک برنامه اسپم می شوند، هدر همان ها را با پیام سالم کارمند مقایسه کنید. اگر همه مسیرها متاثرند، بررسی تنظیمات سرور و سرویس ایمیل مناسب تر است. برای درخواست از پشتیبانی آفاق هاست، Message-ID، زمان با منطقه زمانی، مقصد، گزارش برگشت و هدر نمونه را آماده کنید. نتیجه مطلوب، احراز هویت صحیح پیام های تازه در تمام مسیرهای مجاز و تحویل قابل پیگیری است؛ یک بار رسیدن به Inbox، تضمین دائمی نمی سازد.

سه سوال درباره اسپم شدن ایمیل سازمانی

آیا تغییر MX مشکل اسپم پیام خروجی را حل می کند؟

MX مسیر دریافت ایمیل دامنه را معرفی می کند. تغییر آن بدون برنامه می تواند دریافت را مختل کند و جای اصلاح هویت و اعتبار مسیر ارسال را نمی گیرد.

آیا p=reject باعث می شود ایمیل حتما وارد Inbox شود؟

خیر. این سیاست درباره پیام های ناموفق در DMARC است. تصمیم اسپم برای پیام معتبر هم می تواند به عوامل دیگری وابسته باشد.

چرا پیام فوروارد شده SPF ناموفق دارد؟

سرور واسطه ممکن است IP مجاز فرستنده اصلی نباشد. هدر و وضعیت DKIM را هم بررسی کنید؛ در مسیرهای واسطه، تنظیم درست فوروارد و گاهی ARC مطرح است. راهنمای عیب یابی احراز هویت Microsoft این حالت را از ارسال مستقیم جدا می کند.