اگر میل سرور خودتان را اجرا میکنید، دیر یا زود یکی از کاربرها برگشتیای از Outlook.com برایتان فوروارد میکند که آخرش نوشته 550 5.7.515 Access denied, sending domain [yourdomain] does not meet the required authentication level. بعد یک نفر پیشنهاد میدهد رکورد SPF عوض شود، یکی دیگر میگوید یک relay اضافه کنیم، و یک ساعت بعد سه نفر دارند DNS دامنهای را ویرایش میکنند که همهٔ صندوقهای سازمان به آن وابستهاند.
اول صبر کنید. این نوشته همان چیزهایی است که ما قبل از دست زدن به حتی یک رکورد، به همین ترتیب چک میکنیم. از اجرای ایمیل خروجی خودمان برای fanpino.com و یک استقرار ۱۰ هزار صندوقی دانشگاهی آمده، و از یک مورد که تشخیص اولیهاش اشتباه از آب درآمد.
مایکروسافت دقیقاً چه میخواهد
مایکروسافت قواعدش برای Outlook.com و Hotmail و Live و MSN را در آوریل ۲۰۲۵ در وبلاگ Defender for Office 365 منتشر کرد. دامنههایی که روزانه بیش از ۵ هزار پیام به این آدرسها میفرستند باید SPF و DKIM معتبر داشته باشند و یک رکورد DMARC دستکم با p=none که از طریق یکی از SPF یا DKIM همراستا (aligned) پاس شود. از ۵ مه ۲۰۲۵ ایمیلهای ناموفق به Junk میرفتند. رد قطعی با کد 5.7.515 بعد از آن آمد و همان برگشتی است که الان میبینید.
دو نکته معمولاً کسانی را که سرور خودشان را دارند غافلگیر میکند. سقف ۵ هزار تا برای هر دامنهٔ From حساب میشود، و خیلی از ادمینها در Microsoft Q&A با روزی چند ده ایمیل هم همین خطا را گرفتهاند؛ پس کوچک بودن را دلیل معافیت فرض نکنید. «همراستایی» هم یعنی دامنهای که SPF یا DKIM برایش پاس شده باید با دامنهٔ هدر From که کاربر میبیند یکی باشد. SPF معتبر برای bounces.some-relay.net هیچ کمکی به ایمیلی نمیکند که آدرس From آن روی yourdomain.com است.
قدم ۱: هدر واقعی را بخوانید، نه متن برگشتی را
برگشتی فقط میگوید Outlook راضی نبوده، نمیگوید کدام بررسی شکست خورده. پس قبل از هر کاری، از همان سرور یک پیام به صندوقی که خودتان در Gmail یا Outlook.com دارید بفرستید، سورس اصلی پیام را باز کنید («Show original» در Gmail) و خط Authentication-Results را پیدا کنید. باید هر سه را ببینید:
spf=pass smtp.mailfrom=yourdomain.com
dkim=pass header.d=yourdomain.com
dmarc=pass (p=REJECT) header.from=yourdomain.comهمین یک تست برای ما یک بحث واقعی را تمام کرد. گزارش شده بود پاسخی که از دامنهٔ ما رفته بود توسط گیرندهای روی Microsoft 365 رد شده، و تشخیص اول با اطمینان کامل میگفت SPF یک include برای relay کم دارد و DKIM راهاندازی نشده. قبل از هر تغییری یک پیام آزمایشی به Gmail فرستادیم و هدر را خواندیم: spf=pass، dkim=pass و dmarc=pass با سیاست p=reject خودمان. دنبال خود برگشتی هم گشتیم و هیچجا پیدایش نکردیم، نه در صندوق و نه در لاگ تحویل میل سرور. چیزی خراب نبود. اگر SPF را با اضافه کردن relayای که اصلاً استفاده نمیکنیم «درست» کرده بودیم، به یک طرف سوم اجازهٔ ارسال به اسم خودمان داده بودیم و هیچ مشکلی هم حل نمیشد.
قدم ۲: SPF را با IP واقعی ارسال مقایسه کنید
اگر SPF شکست خورده، رکورد را ببینید (dig +short TXT yourdomain.com) و با IP عمومیای مقایسه کنید که سرور واقعاً برای اتصال خروجی استفاده میکند. این IP را از خود سرور بگیرید، مثلاً با curl -4 ifconfig.me، نه از رکورد MX یا داشبورد. روی سروری با چند آدرس یا پشت NAT این دو میتوانند فرق داشته باشند.
رکورد ما تقریباً کوتاهترین SPF ممکن است: v=spf1 mx -all. میزبان MX همان میزبان ارسال است، پس mx پوشش میدهد و -all بقیه را رد میکند. اگر با ابزار خبرنامه یا CRM هم ایمیل میفرستید، هر کدام include خودش را لازم دارد و باید زیر سقف ۱۰ کوئری DNS بمانید. از آن بگذرید، SPF نتیجهٔ permerror میدهد و Outlook آن را شکست حساب میکند.
قدم ۳: DKIM، همانی که بیصدا خراب میشود
سرورهای جدید مثل Stalwart کلید DKIM را خودشان میسازند و بعضیشان آن را دورهای عوض میکنند؛ که خوب است تا وقتی DNS عقب نیفتد. نام selector در هدر DKIM-Signature هر پیامی که میفرستید هست (s=...). آدرس <selector>._domainkey.yourdomain.com را کوئری کنید و مطمئن شوید کلید عمومی آنجا همان کلیدی است که سرور همین حالا با آن امضا میکند. کلید کهنه بعد از چرخش کلید یعنی dkim=fail (bad signature) روی همهٔ پیامها، و اگر SPF سالم باشد شاید تا وقتی Outlook شروع به برگرداندن نکرده متوجه نشوید.
این را هم چک کنید که d= در امضا دامنهٔ خودتان باشد، نه نام میزبان سرور یا دامنهٔ یک سرویسدهنده. امضای معتبر از دامنهٔ اشتباه DKIM را پاس میکند ولی در همراستایی DMARC رد میشود.
قدم ۴: DMARC، و اینکه چرا p=none هدف نیست
حداقل مایکروسافت p=none است و همین برای رفع خطای 5.7.515 کافی است. ولی برای جلوگیری از اینکه کس دیگری به اسم دامنهٔ شما ایمیل بفرستد کافی نیست. ما v=DMARC1; p=reject; rua=mailto:postmaster@... منتشر کردهایم. اگر از صفر شروع میکنید، با p=none و یک آدرس rua فعال شروع کنید، دو سه هفته گزارشهای تجمیعی را بخوانید تا فرستندههایی را که یادتان رفته پیدا کنید (سیستم فاکتور، فرم قدیمی سایت، اسکنری که PDF ایمیل میکند)، بعد بروید سراغ quarantine و بعدتر reject.
وقتی هر سه پاس شده و Outlook باز هم رد میکند
آنوقت مشکل احراز هویت نیست و تغییر DNS کمکی نمیکند. کد را دقیق بخوانید. 5.7.515 دربارهٔ احراز هویت است. مسدود شدن بهخاطر اعتبار IP شکل دیگری دارد، با کد S3150 خود Outlook یا عبارت «banned sender»، و Gmail هم نسخهٔ خودش را دارد (550 5.7.28 ... unusual rate of unsolicited mail، که ما خردادماه روی IP میل سرورمان از Gmail گرفتیم، در حالی که رکوردهایمان از خیلی قبل درست بود). مشکل اعتبار از طریق Microsoft SNDS و فرم پشتیبانی فرستنده، یا Google Postmaster Tools، و با کم کردن ایمیل ناخواسته حل میشود، نه با ویرایش SPF.
چکلیست کوتاه
- قبل از هر تغییری هدر
Authentication-Resultsیک پیام آزمایشی تازه را بخوانید. - SPF: IP خروجی واقعی را پوشش بدهد، با
-allیا~allتمام شود، زیر ۱۰ کوئری باشد. - DKIM: selector در DNS با کلیدی که سرور امروز با آن امضا میکند یکی باشد و
d=دامنهٔ خودتان باشد. - DMARC: دستکم
p=noneبا گزارش، و حرکت به سمتreject. - همه پاس است و باز برمیگردد: مشکل اعتبار یا محتواست؛ SNDS و Postmaster Tools را ببینید.
اگر هنوز در حال انتخاب میل سرور هستید، سه گزینهٔ self-hosted را در مقیاس واقعی در مقایسهٔ Mailcow، Stalwart و Mailu کنار هم گذاشتهایم. اینکه اصلاً ایمیل را خودتان میزبانی کنید یا نه در چرا بعضی سازمانها در ۲۰۲۶ هنوز ایمیل را خودشان میزبانی میکنند آمده، و اگر دارید از یک سرور قدیمی Exchange مهاجرت میکنید، نوشتهٔ پایان پشتیبانی Exchange 2019 بخش مهاجرت را پوشش میدهد.