مهاجرت امن به Symantec Email Security.cloud
چک‌لیست DNS، Mail Flow، Sender Authentication و سیاست‌های قرنطینه برای مهاجرت بدون اختلال.
پاسخ کوتاه: مهاجرت به Symantec Email Security.cloud صرفاً تغییر MX نیست. پیش از Cutover باید Domainها، Inbound و Outbound Route، Connectorها، SPF/DKIM/DMARC، مالک Quarantine، آزمایش Mail Flow و مسیر بازگشت مشخص باشند. تغییر DNS بدون آماده‌سازی مسیر دریافت و ارسال، احتمال اختلال در تحویل پیام را بالا می‌برد.
چک‌لیست تصمیم مهاجرت
| مرحله | خروجی لازم | کنترل |
|---|---|---|
| آماده‌سازی | Inventory دامنه‌ها، سرویس‌ها و مسیرهای ایمیل | مالک هر Domain و Connector مشخص است |
| Route | Inbound/Outbound Route و مقصد نهایی | فنی‌بودن و اتصال Route تأیید شده است |
| Pilot | گروه یا Domain محدود | دریافت، ارسال و Quarantine آزمایش شده‌اند |
| Cutover | تغییر مرحله‌ای DNS/MX | گزارش‌ها و صف پیام پایش می‌شوند |
۱. پیش از تغییر MX، Route را آماده کنید
Broadcom توصیه می‌کند پیش از تغییر MX، Inbound Route به Hostname یا IP مقصد جدید تنظیم و انتشار آن کنترل شود. Routeهای جدید باید آزمون‌های فنی سرویس را بگذرانند. برای Microsoft 365 یا Google Workspace، FQDN مقصد ارائه‌شده توسط همان سرویس باید مبنای Route باشد؛ حدس‌زدن مقصد یا استفاده از آدرس داخلی مناسب نیست.
۲. MX و DNS را مرحله‌ای تغییر دهید
MX باید فقط به مسیرهای اختصاص‌یافتهٔ Email Security.cloud اشاره کند تا همهٔ پیام‌ها اسکن شوند؛ وجود Mail Server داخلی یا Relay عمومی به‌عنوان MX جایگزین می‌تواند مسیر دورزدن حفاظت بسازد. TTL را پیش از Cutover بررسی کنید و انتشار تغییر را پایش کنید. DNS تغییرپذیر است، اما Mail Flow تولیدی نباید محل آزمایش باشد.
۳. Sender Authentication را حفظ و کنترل کنید
SPF، DKIM و DMARC بخشی از طراحی تحویل هستند. قبل از اعمال سیاست‌های محدودکننده، گزارش‌ها و فرستنده‌های مجاز را تحلیل کنید. اگر قرار است Domain از ESS خارج شود، Broadcom تأکید می‌کند تا زمانی که حذف کامل انجام نشده، رکوردهای لازم مانند SPF/DKIM قدیمی را زودتر حذف نکنید.
۴. Pilot و روزهای نخست بهره‌برداری
- یک Domain یا گروه محدود را برای Pilot انتخاب کنید.
- دریافت، ارسال، Connectorها، TLS، Quarantine و اعلان‌ها را آزمون کنید.
- False Positiveها و Allow Listها را با دلیل، مالک و تاریخ بازبینی ثبت کنید.
- پس از Cutover، Alertها، گزارش‌ها، صف پیام و درخواست‌های کاربران را با دقت بیشتری پایش کنید.
مسئولیت عملیاتی
Cloud بودن سرویس نیاز به مالکیت داخلی را حذف نمی‌کند. شخص یا تیم مشخص باید مسئول مرور هشدارها، رسیدگی به گزارش فیشینگ، کنترل Quarantine و بازبینی استثناها باشد. صفحهٔ Symantec Email Security.cloud مالک موضوع محصول و استعلام است؛ این صفحه صرفاً راهنمای مهاجرت است.
پرسش‌های متداول
آیا می‌توان MX را بدون Pilot تغییر داد؟
توصیه نمی‌شود. ابتدا Routeها و Mail Flow را در محدوده کنترل‌شده آزمایش کنید.
آیا Cloud بودن، نیاز به کنترل Quarantine را حذف می‌کند؟
خیر. باید مالک، دسترسی، اعلان و فرآیند آزادسازی پیام مشخص باشد.
آیا DMARC را مستقیم روی Reject بگذاریم؟
خیر. سیاست باید با دادهٔ گزارش‌های واقعی و به‌صورت مرحله‌ای سخت‌تر شود.
منابع رسمی و تاریخ بازبینی
- MX record setup with Email Security.cloud
- Adding inbound routes for Email Security.cloud
- Configure Microsoft 365 for inbound mail
- Configure Exchange for outbound mail
تاریخ بازبینی: ۷ سپتامبر ۲۰۲۶.
مسیر مرتبط با این مقاله
حفاظت ابری از ایمیل سازمانی در برابر بدافزار، باج‌افزار، فیشینگ، URLهای مخرب و جعل هویت تجاری.