Email Authentication چیست؟
احراز هویت ایمیل (Email Authentication) مجموعهای از رکوردهای DNS است که به سرور گیرنده ثابت میکند پیامی که ادعا میکند از دامنه شما آمده، واقعاً از طرف شما ارسال شده است. سه استاندارد این کار را انجام میدهند: SPF مشخص میکند چه سرورهایی حق ارسال از دامنه شما را دارند، DKIM پیام را با امضای رمزنگاریشده مهر میکند و DMARC این دو را به آدرس فرستندهای که کاربر میبیند گره میزند و تعیین میکند با پیام مشکوک چه رفتاری شود.
چرا ایمیل بدون احراز هویت به اسپم میرود
پروتکل SMTP در طراحی اولیه هیچ سازوکاری برای تأیید هویت فرستنده نداشت. هر سروری در اینترنت میتواند به یک سرور دیگر وصل شود و در فیلد From هر آدرسی را که بخواهد بنویسد؛ دقیقاً مثل پاکت نامهای که فرستندهاش را خودتان روی آن مینویسید. به همین دلیل جعل آدرس فرستنده (spoofing) پایه بیشتر حملات فیشینگ است.
اگر دامنه شما هیچکدام از این سه رکورد را منتشر نکرده باشد، گیرنده راه فنی برای تفکیک ایمیل واقعی شما از ایمیل جعلی ندارد و محتاطانهترین تصمیم را میگیرد: انتقال به پوشه اسپم. از سال ۲۰۲۴ گوگل و یاهو این موضوع را از توصیه به الزام تبدیل کردند و برای فرستندگان انبوه، وجود هر سه رکورد را شرط تحویل پیام قرار دادند.
SPF: چه سرورهایی اجازه ارسال دارند
SPF یک رکورد TXT روی خود دامنه است که فهرست فرستندگان مجاز را اعلام میکند؛ چیزی شبیه v=spf1 mx include:_spf.example.com -all. سرور گیرنده IP سرور ارسالکننده را با این فهرست مقایسه میکند. علامت انتهایی مهم است: -all یعنی هر منبع دیگری را رد کن و ~all یعنی مشکوک تلقی کن ولی رد نکن.
سه نکته فنی که معمولاً نادیده گرفته میشود: SPF دامنهی Return-Path (همان MAIL FROM در گفتوگوی SMTP) را بررسی میکند، نه آدرسی که در نرمافزار ایمیل به کاربر نشان داده میشود؛ پس به تنهایی جلوی جعل فیلد From را نمیگیرد. استاندارد SPF (RFC 7208) سقف ۱۰ عملیات جستوجوی DNS دارد و هر include به آن شمارش میشود؛ از این سقف که رد شوید کل رکورد با خطای permerror بیاثر میشود. و در فوروارد، IP فرستنده عوض میشود و SPF شکست میخورد. چون همه اینها رکورد DNS هستند، نگهداریشان روی یک سرویس DNS پایدار بسیار سادهتر است.
DKIM: امضای رمزنگاریشده روی خود پیام
DKIM (RFC 6376) رویکرد متفاوتی دارد. سرور ارسالکننده با یک کلید خصوصی، بخشی از هدرها و هش بدنه پیام را امضا میکند و نتیجه را در هدری به نام DKIM-Signature میگذارد. کلید عمومی متناظر به شکل یک رکورد TXT روی آدرسی مثل selector._domainkey.example.com منتشر میشود. گیرنده کلید عمومی را از DNS میخواند و امضا را راستیآزمایی میکند.
در این هدر، d= دامنه امضاکننده و s= نام سلکتور است. چون امضا به خود پیام چسبیده و نه به مسیر عبور آن، DKIM برخلاف SPF از فوروارد جان سالم به در میبرد. در عوض هر تغییری در محتوای امضاشده امضا را میشکند؛ نمونه رایجش لیستهای پستی هستند که به موضوع پیام پیشوند یا به انتهای متن پاورقی اضافه میکنند.
DMARC: سیاست، همراستایی و گزارش
DMARC (RFC 7489) به تنهایی چیزی را تأیید نمیکند؛ نتیجه SPF و DKIM را میگیرد و سه کار انجام میدهد. یک رکورد TXT روی _dmarc.example.com منتشر میشود، مثل v=DMARC1; p=none; rua=mailto:dmarc@example.com.
- همراستایی (Alignment): این مهمترین بخش است. DMARC میخواهد دامنهای که SPF یا DKIM تأیید کرده با دامنهای که کاربر در فیلد From میبیند یکی باشد. حالت پیشفرض relaxed است و تطابق در سطح دامنه سازمانی کافی است؛ با
aspf=sیاadkim=sتطابق باید دقیق باشد. - سیاست: پارامتر
pتعیین میکند گیرنده با پیام مردود چه کند:noneفقط پایش،quarantineانتقال به اسپم وrejectرد کامل در سطح SMTP. - گزارش: با
ruaگیرندهها گزارشهای جمعی روزانه میفرستند و نشان میدهند چه IPهایی با نام دامنه شما ایمیل میفرستند و کدامشان تأیید شدهاند.
پیام وقتی DMARC را پاس میکند که دستکم یکی از SPF یا DKIM هم موفق باشد و هم همراستا. به همین دلیل ممکن است سرویسی مثل یک پنل خبرنامه، SPF را پاس کند اما به دلیل تفاوت دامنه Return-Path، DMARC شما را رد کند.
این سه چطور همدیگر را کامل میکنند
SPF به مسیر نگاه میکند، DKIM به محتوا، و DMARC هر دو را به هویتی که کاربر میبیند وصل میکند. هیچکدام جایگزین دیگری نیست: SPF با فوروارد میشکند و DKIM با ویرایش پیام؛ داشتن هر دو یعنی احتمال پاس شدن دستکم یکی بسیار بالاتر میرود.
این سه رکورد پشت سر هم کار میکنند: SPF فرستنده مجاز را میگوید، DKIM اصالت خود پیام را ثابت میکند و DMARC تعیین میکند اگر یکی از آنها رد شد چه اتفاقی بیفتد.
ترتیب درست پیادهسازی
ابتدا فهرست کنید چه سیستمهایی از طرف دامنه شما ایمیل میفرستند: سرور میزبانی، فرم تماس سایت، سرویس خبرنامه، سیستم تیکت و ایمیل سازمانی. سپس یک رکورد SPF واحد بسازید که همه آنها را پوشش دهد، برای هر فرستنده DKIM را فعال کنید و در گام آخر DMARC را با p=none و آدرس گزارش منتشر کنید. چند هفته گزارشها را بخوانید، منابع جامانده را اصلاح کنید و تنها بعد از آن به quarantine و سپس reject برسید. پرش مستقیم به p=reject رایجترین راه از دست دادن ایمیلهای واقعی است.
در cPanel چه چیزی در اختیار شماست
در cPanel بخش Email Deliverability (در نسخههای قدیمیتر Email Authentication) وضعیت SPF و DKIM هر دامنه را نشان میدهد، کلید DKIM را میسازد و رکوردهای لازم را برای کپی کردن در اختیار میگذارد. اگر DNS دامنه روی سرور دیگری مدیریت میشود، فعال کردن گزینه در cPanel کافی نیست و باید رکوردها را در همان جایی که نیمسرورها به آن اشاره میکنند وارد کنید. توجه کنید که DMARC در این بخش ساخته نمیشود و باید آن را دستی به عنوان رکورد TXT اضافه کنید.
اگر سرور ایمیل را خودتان و مثلاً با نصب iRedMail روی اوبونتو روی سرور مجازی یا اختصاصی بالا آوردهاید، یک مورد دیگر هم به همان اندازه مهم است: رکورد PTR یا reverse DNS آیپی باید با نام میزبان سرور بخواند و آن نام رکورد A متناظر داشته باشد. نبود PTR درست به تنهایی میتواند باعث رد شدن پیام شود، حتی وقتی هر سه رکورد احراز هویت سالماند.
خطاهای رایج
- انتشار دو رکورد SPF جدا روی یک دامنه؛ استاندارد فقط یک رکورد را مجاز میداند و وجود دو تا نتیجه را به خطا میبرد. باید همه را در یک رکورد ادغام کرد.
- زنجیرهای شدن includeها و عبور از سقف ۱۰ جستوجوی DNS.
- کپی کردن رکورد DKIM همراه با شکست خط یا فاصله اضافه، یا اشتباه نوشتن نام سلکتور.
- فراموش کردن زیردامنهها؛ اگر رفتار متفاوتی برای زیردامنهها لازم دارید از پارامتر
spاستفاده کنید. - رها کردن دامنههای پارکشده بدون سیاست؛ دامنهای که هرگز ایمیل نمیفرستد بهتر است SPF با
-allو DMARC باp=rejectداشته باشد.
راهاندازی این سه رکورد یکبار انجام میشود اما نگهداری دارد؛ هر سرویس جدیدی که از طرف دامنه شما ایمیل میفرستد باید به SPF و DKIM اضافه شود. اگر در تفسیر گزارشهای DMARC یا اصلاح رکوردها به کمک نیاز داشتید، تیم پشتیبانی میتواند وضعیت فعلی دامنه را بررسی کند. مستندات رسمی این استانداردها هم در دسترس است: RFC 7208، RFC 6376 و RFC 7489.