تیم محصول چگونه باید DKIM را با خیال راحت راه‌اندازی کند؟

پیش از تولید کلید، همه مسیرهای واقعی ارسال خروجی را فهرست کنید

با فهرست موجودی شروع کنید، نه با یک رکورد DNS. هر سیستمی را فهرست کنید که می‌تواند با استفاده از دامنه‌های قابل‌مشاهده From سازمان ایمیل صادر کند: workerهای اپلیکیشن، ارائه‌دهندگان تراکنشی، پلتفرم‌های بازاریابی، ابزارهای پشتیبانی، سامانه‌های هویت، نرم‌افزار ticketing، relayها و مسیرهای اضطراری. برای هرکدام مالک، دسته‌های پیام، فرستنده envelope، دامنه قابل‌مشاهده From، دامنه کنونی DKIM d=، selector، مؤلفه امضاکننده و اینکه relay دیگری بعداً پیام را تغییر می‌دهد یا نه ثبت کنید. کلید DKIM منتشرشده برای یک ارائه‌دهنده، برای مسیری متفاوت که هرگز از کلید خصوصی آن استفاده نمی‌کند کاری انجام نمی‌دهد. به همین ترتیب، داشبورد عمومی یک ارائه‌دهنده که یک دامنه تأییدشده را نشان می‌دهد، اثبات نمی‌کند هر tenant، region، stream، قالب یا fallback امضا شده است. از هر مسیر نمونه‌های کنترل‌شده بگیرید و هدرهای اصلی‌شان را نگه دارید. پیش از فعال‌سازی امضا تصمیم بگیرید کدام مسیرها مجازند؛ DKIM مسئولیت دامنه برای یک امضا را احراز هویت می‌کند، نه رضایت گیرنده یا درستی محتوای پیام را.

دامنه امضایی انتخاب کنید که از هم‌راستایی DMARC پشتیبانی کند

تگ d= در DKIM دامنه امضاکننده را مشخص می‌کند. دامنه‌ای را انتخاب کنید که سازمان آن را کنترل می‌کند و می‌تواند در تمام عمر جریان ایمیل آن را اداره کند. وقتی DMARC به DKIM متکی است، دامنه d= باید طبق قاعده هم‌راستایی relaxed یا strict مربوط، با دامنه فیلد From قابل‌مشاهده طبق RFC 5322 هم‌راستا باشد. دامنه امضای متعلق به ارائه‌دهنده ممکن است نتیجه DKIM معتبری تولید کند اما با دامنه From سازمان هم‌راستا نباشد. تصمیم بگیرید که دامنه اصلی (apex) یا یک زیردامنه اختصاصی هر جریان را امضا کند و در این تصمیم مالکیت، جداسازی اعتبار، DNS تفویض‌شده و ایزوله کردن رخدادها را در نظر بگیرید. صرفاً برای فرار از مشکل اعتبار یا سیاست، دامنه‌های اضافی نسازید. رابطه دامنه سازمانی و حالت DMARC موردنظر را ثبت کنید. هم‌راستایی را از روی هدرهای نهایی دریافت‌شده آزمایش کنید؛ هرگز آن را فقط از lookup مربوط به selector استنتاج نکنید، چون ممکن است پیام از مقدار d= دیگری استفاده کند.

selectorها را هویت‌های عملیاتی در نظر بگیرید

selector به یک دامنه اجازه می‌دهد چند کلید منتشر کند و بدون جایگزینی یک رکورد سراسری آن‌ها را تغییر دهد. یک سیاست selector قطعی بسازید که یک ارائه‌دهنده یا امضاکننده و یک نسل چرخش را بدون افشای secret شناسایی کند. برای نمونه، product-a-2026q3 می‌تواند از default روشن‌تر باشد، اما نام‌ها را در چارچوب قراردادهای DNS و محدودیت‌های ابزار خود نگه دارید. هرگز تنها برای کاهش رکوردهای DNS، یک کلید خصوصی را میان ارائه‌دهندگان، محیط‌ها یا tenantهای نامرتبط استفاده مجدد نکنید. registryای با selector، دامنه d=، هدف، سرویس امضا، مالک، زمان ایجاد، الگوریتم، fingerprint کلید عمومی، وضعیت استقرار، مهلت چرخش و شواهد بازنشستگی نگه دارید. پیش از انتشار نام دقیق selector را بررسی کنید: lookup برابر `selector._domainkey.signing-domain` است. رکوردی تصادفی در دامنه قابل‌مشاهده From، دامنه return-path یا zone نادرست DNS امضای موردنظر را تأیید نمی‌کند. تا زمانی که ایمیل تأخیری و تلاش‌های مجدد امضاشده با selector قدیمی منقضی نشده‌اند، آن را حذف نکنید.

کلید خصوصی را تولید و از آن محافظت کنید

اگر ارائه‌دهنده پشتیبانی می‌کند، جفت‌کلید را درون یک سرویس مدیریت‌شده کلید یا یک سیستم امضای کاملاً کنترل‌شده تولید کنید. کلید خصوصی هرگز نباید وارد DNS عمومی، کنترل نسخه، کد مرورگر، خروجی CI، analytics، لاگ‌های معمولی، تیکت‌ها، اسناد، promptها یا چت مشترک شود. دسترسی امضا را فقط به جزئی از سیستم ایمیل بدهید که به کلید نیاز دارد، محیط عملیاتی را از محیط‌های پایین‌تر جدا کنید و دسترسی‌های مدیریتی را ثبت کنید. RFC 8301 الزامات رمزنگاری DKIM را به‌روز می‌کند و می‌گوید امضاکنندگان باید از کلیدهای RSA با دست‌کم 1024 بیت استفاده کنند و بهتر است دست‌کم 2048 بیت به کار ببرند؛ همچنین به محدودیت‌های عملیاتی DNS برای کلیدهای بزرگ‌تر اشاره می‌کند. به‌جای کپی کردن یک مثال منسوخ، از قابلیت‌ها و توصیه‌های فعلی امضاکننده انتخاب‌شده و جمعیت گیرندگان پیروی کنید. اگر Ed25519 را در نظر دارید، RFC 8463 کاربرد آن در DKIM را تعریف می‌کند، اما سازگاری باید آزمایش شود و در صورت نیاز یک راهبرد امضای سازگار حفظ شود. چرخش کلید باید بدون خروج کلید خصوصی از سیستم ممکن باشد.

کلید عمومی را دقیق منتشر کنید

یک رکورد TXT را در نام مالک دقیق `selector._domainkey.signing-domain` منتشر کنید. رکورد کلید DKIM تگ‌هایی مانند v=DKIM1، نوع کلید در صورت نیاز و p= حاوی محتوای کلید عمومی بدون wrapper کلید خصوصی دارد. قالب دقیق رکورد امضاکننده و رفتار نقل‌قول‌گذاری ارائه‌دهنده DNS خود را دنبال کنید. پیش از ذخیره بررسی کنید رابط DNS به‌طور خودکار zone را اضافه می‌کند، رشته‌های بلند را می‌شکند یا کاراکترها را escape می‌کند یا نه. پس از انتشار مستقیماً name serverهای authoritative و سپس resolverهای بازگشتی مستقل را query کنید و مقدار کامل TXT را بازسازی کنید. چند رشته کاراکتری در یک رکورد TXT به‌وسیله کلاینت‌های DNS به هم متصل می‌شوند، در حالی که چند رکورد منبع رقیب می‌توانند ابهام ایجاد کنند. پاسخ و TTL قبلی را برای بازگشت (rollback) نگه دارید. تنها برای ساکت‌کردن یک بررسی‌کننده، با انتشار کلیدی گسترده‌تر یا باقی‌گذاشتن test flag در محیط عملیاتی، امنیت را کاهش ندهید. یک رکورد قابل‌مشاهده انتشار DNS را اثبات می‌کند، نه اینکه فرستنده از کلید خصوصی منطبق استفاده می‌کند.

امضاکننده نهایی و فیلدهای امضاشده را پیکربندی کنید

جزئی را پیکربندی کنید که پیام نهایی را به لایه انتقال خروجی تحویل می‌دهد، یا مطمئن شوید هیچ جزء بعدی محتوای امضاشده را تغییر نمی‌دهد. امضای DKIM یک هش بدنه و فیلدهای هدری را که در h= نام برده شده‌اند پوشش می‌دهد. RFC 6376 امضای فیلد هدر From را برای یک امضای معتبر الزامی می‌کند. هدرهای حیاتی از نظر هویت را که متناسب با محصول‌اند وارد کنید، بدانید هدرهای تکراری چگونه انتخاب می‌شوند و از امضای فیلدهایی که یک سیستم پایین‌دستی ضروری باید بازنویسی کند پرهیز کنید، مگر اینکه آن تبدیل کنترل‌شده باشد. canonicalization را آگاهانه انتخاب کنید. canonicalization از نوع relaxed تغییرات تعریف‌شده در فاصله‌ها و قالب‌بندی هدر را تحمل می‌کند، اما اجازه ویرایش دلبخواهی بدنه را نمی‌دهد. canonicalization از نوع simple شکننده‌تر است. افزودن footer، بازنویسی لینک، تغییر boundary در MIME، تبدیل transfer-encoding، تگ‌های موضوع و نرمال‌سازی پایان خطوط پس از امضا می‌تواند تأیید را خراب کند. پیام کاملاً رندرشده را پس از تبدیل‌های تأییدشده امضا کنید و نگذارید کاربران غیرقابل‌اعتماد d=، s=، فهرست هدرها یا کلیدها را انتخاب کنند.

پیام‌های اصلی دریافت‌شده را سرتاسری تأیید کنید

پیام‌های کنترل‌شده را از هر مسیر واقعی و مشابه محیط عملیاتی به صندوق‌های آزمایشی خارجی که تیم اداره می‌کند بفرستید. پیام اصلی خام را نگه دارید، نه یک بدنه کپی‌شده یا پیوست تیکتی که دوباره serialize شده است. مقادیر d= و s= در DKIM-Signature، فهرست هدرهای امضاشده، هش بدنه، الگوریتم، canonicalization، مهر زمانی و هر تاریخ انقضا را بررسی کنید. کلید عمومی را از یک شبکه مستقل کوئری کنید و یک تأییدکننده منطبق با استانداردها را روی بایت‌های اصلی اجرا کنید. هدر Authentication-Results گیرنده مورد اعتماد را با تأییدکننده خود مقایسه کنید و مرزهای اعتماد RFC 8601 را رعایت کنید. متن ساده، multipart alternative، پیوست‌های موردانتظار، موضوع‌های Unicode، هدرهای طولانی، قالب‌ها، تبدیل‌های ردیابی، تلاش‌های مجدد و مسیرهای relay را آزمایش کنید. آزمون‌های منفی باید شامل یک هدر امضاشده عمداً تغییرداده‌شده در یک fixture، یک selector ناموجود، یک selector منقضی یا بازنشسته و مسیری باشد که امضا را دور می‌زند. هرگز برای ساختن آزمون، ایمیل واقعی مشتری را دستکاری نکنید.

DKIM، DMARC و تحویل را نتایجی جداگانه ارزیابی کنید

عبور DKIM یعنی verifier برای دامنه امضاکننده شناسایی‌شده، امضایی معتبر روی فیلدها و بدنه امضاشده یافت. این امر هر هدر امضانشده را احراز هویت نمی‌کند، نویسنده انسانی را تأیید نمی‌کند، رضایت گیرنده را اثبات نمی‌کند، انطباق قانونی را برقرار نمی‌کند یا پذیرش و رسیدن به صندوق ورودی را تضمین نمی‌کند. DMARC جداگانه ارزیابی می‌کند که آیا یک دامنه DKIM یا SPF گذرانده با دامنه قابل‌مشاهده From هم‌راستا است و سیاست مالک دامنه را اعمال می‌کند. برای آزمون‌های کنترل‌شده دست‌کم نتیجه و دلیل DKIM، دامنه d=، selector، دامنه قابل‌مشاهده From، نتیجه هم‌راستایی، نتیجه SPF، نتیجه DMARC، گیرنده و timestamp را ثبت کنید. نشانی کامل گیرندگان و محتوا را از metricهای معمول خارج نگه دارید. پذیرش ارائه‌دهنده SMTP، پذیرش سرور گیرنده، برگشت بعدی، جای‌گذاری در پوشه صندوق ایمیل و تعامل، وضعیت‌های بعدی‌اند. اگر DKIM عبور می‌کند اما ایمیل رد یا فیلتر می‌شود، به‌جای چرخش مکرر کلیدها، هم‌راستایی DMARC، SPF، اعتبار IP و دامنه، نرخ گزارش اسپم، سیاست پیام، نرخ و راهنمایی گیرنده را بررسی کنید.

کلید را بدون ایجاد وقفه در تأیید بچرخانید

از selectorهای همپوشان استفاده کنید. ابتدا یک کلید محافظت‌شده جدید تولید کنید و رکورد عمومی آن را زیر یک selector جدید منتشر کنید. DNS مرجع و بازگشتی را بررسی کنید، امضاکننده را برای استفاده از selector جدید پیکربندی کنید و از همه مسیرها آزمون‌های کنترل‌شده بفرستید. نسبت امضاهایی را که از selector قدیمی و جدید استفاده می‌کنند و نتایج تأیید آن‌ها را پایش کنید. کلید عمومی قدیمی را در طول حداکثر عمر پیام‌های داخل صف، بازه تلاش مجدد و دوره cache در DNS به‌علاوه یک حاشیه اطمینان صریح در دسترس نگه دارید. سپس همه امضاها با selector قدیمی را متوقف کنید، مطمئن شوید هیچ پیکربندی فعالی به آن ارجاع نمی‌دهد و رکورد آن را طبق سیاست بازنشسته کنید. ابطال اضطراری پس از افشای کلید خصوصی ممکن است به حذف سریع‌تر، توقف ترافیک، چرخش اعتبارنامه‌های ارائه‌دهنده و اطلاع‌رسانی رخداد نیاز داشته باشد؛ این مصالحه را از پیش مستند کنید. در چرخش روزمره یک selector را درجا بازنویسی نکنید، چون کلیدهای عمومی قدیمیِ cacheشده ممکن است باعث fail شدن تأیید پیام‌هایی شوند که با کلید خصوصی جدید امضا شده‌اند.

خطاها را از امضا به بیرون عیب‌یابی کنید

برای امضای ناموجود، مشخص کنید که آیا پیام از یک جریان امضانشده، دامنه From غیرمجاز، relay جایگزین یا مسیر قالب استفاده کرده است. برای key-not-found، lookup دقیق s= و d=، تفویض zone، پاسخ مرجع، خطاهای DNSSEC یا resolver و انتشار را بررسی کنید. برای عدم تطابق هش بدنه، MIME خام پیش از امضا و دریافت‌شده را مقایسه کنید تا تبدیل‌های پس از امضا را پیدا کنید. برای عدم تطابق امضا، تأیید کنید که کلید عمومی منتشرشده با کلید خصوصی فعال مطابقت دارد و canonicalization و هدرهای امضاشده را بررسی کنید. برای DKIM پاس با DMARC رد، هم‌راستایی با دامنه From قابل‌مشاهده را ارزیابی کنید. خطاهای موقت lookup در DNS را جدا از اشکالات پایدار پیکربندی دسته‌بندی کنید و فقط وقتی پاسخ SMTP موقت است از تلاش‌های مجدد محدود در لایه انتقال استفاده کنید. در صورت امضای بین‌دامنه‌ای، کلیدهای ناشناخته، خطای گسترده تأیید یا احتمال افشای کلید، جریان آسیب‌دیده را متوقف کنید. شواهد را با حداقل داده شخصی نگه دارید و در هر آزمون مجدد کنترل‌شده فقط یک متغیر را تغییر دهید.

از مستندات DKIM سامانه ارسال خود استفاده کنید

DKIM را در سامانه‌های ارسال واقعی و مرجع DNS خود راه‌اندازی کنید، پیام‌های اصلی دریافت‌شده را اعتبارسنجی کنید و به استانداردهای به‌روز IETF و مستندات ویژه ارائه‌دهنده تکیه کنید.

پرسش‌های متداول

منابع

• RFC 6376: امضاهای DomainKeys Identified Mail (DKIM) — RFC Editor
• RFC 8301: به‌روزرسانی الگوریتم رمزنگاری و استفاده از کلید در DKIM — RFC Editor
• RFC 8463: یک روش جدید امضای رمزنگاری برای DKIM — RFC Editor
• RFC 7489: احراز هویت، گزارش‌دهی و انطباق پیام مبتنی بر دامنه (DMARC) — RFC Editor
• RFC 8601: فیلد هدر پیام برای نمایش وضعیت احراز هویت پیام — RFC Editor
• RFC 5321: پروتکل ساده انتقال ایمیل (SMTP) — RFC Editor