- چرا گرمسازی (warm‑up) IP و دامنه برای سرور ایمیل ضروری است؟
- چه زمانی باید Warm‑up انجام داد؟
- اصول فنی Warm‑up و فاکتورهای مورد توجه ISPها
- نمونه برنامه Warm‑up پیشنهادی (قابل خودکارسازی)
- پیادهسازی فنی روی Postfix — نمونه کانفیگ
- خودکارسازی روند warm‑up (اسکریپت / cron / systemd)
- احراز هویت و رکوردهای DNS — SPF, DKIM, DMARC, PTR
- مدیریت Bounce و Complaints
- مانیتورینگ و ابزارها
- Sicherheit und bewährte Verfahren
- تأثیر لوکیشنها و انتخاب دیتاسنتر
- نکات ارسال هدفمند برای تریدرها، گیمها و توسعهدهندگان
- چکلیست نهایی قبل از شروع warm‑up
- نتیجهگیری و پیشنهادات کاربردی
چرا گرمسازی (warm‑up) IP و دامنه برای سرور ایمیل ضروری است؟
گرمسازی IP و دامنه یکی از مراحل حیاتی برای حفظ deliverability و افزایش ریپوتیشن هنگام راهاندازی سرور ایمیل جدید یا اضافهکردن IP اختصاصی است.
هدف warm‑up افزایش تدریجی حجم ایمیلهای ارسالی و نشان دادن رفتار طبیعی و نرخ تعامل بالا به ISPها است تا از قرار گرفتن در اسپم یا بلوک شدن جلوگیری شود.
چه زمانی باید Warm‑up انجام داد؟
مواردی که نیاز به warm‑up دارند شامل موارد زیر هستند:
انتخاب IP جدید اختصاصی یا افزودن دامنه ارسال جدید.
انتقال از Shared IP Zu Dedicated IP که نیاز به اعتبارسازی از صفر دارد.
تغییر دیتاسنتر یا لوکیشن (مثلاً جابجایی reverse‑DNS).
اصول فنی Warm‑up و فاکتورهای مورد توجه ISPها
فاکتورهای مهم که ISPها بررسی میکنند
حجم ارسال روزانه و نرخ رشد (sudden spikes باعث مشکوک شدن میشود).
نرخ برگشتی (bounce rate) و نوع bounce (hard vs soft).
نرخ گزارش بهعنوان spam (complaint rate).
تعامل کاربران (open/click) و نرخ حذف/لغو عضویت.
وجود رکوردهای هویتی: Lichtschutzfaktor, DKIM, DMARC، PTR (reverse DNS)، TLS.
تاریخچه IP و دامنه (previous blacklists).
استراتژی کلی Warm‑up
شروع با حجم کم و افزایش تدریجی (مثلاً روز اول 50 ایمیل، روز دوم 150، روز سوم 400 و…).
تقسیم ارسالها به دستههای کوچک (batches) بر اساس engagement یا seed lists.
ارسال به کاربران فعال و پرتعامل در مراحل اولیه.
حذف یا فیلتر کردن آدرسهای پرریسک (old lists، purchased lists).
نظارت مداوم و تنظیم برنامه بر اساس بازخورد (bounces, complaints, inbox placement).
نمونه برنامه Warm‑up پیشنهادی (قابل خودکارسازی)
نمونهای از برنامه آغازین برای Warm‑up:
روز 1: 50 ایمیل
روز 2: 150 ایمیل
روز 3: 400 ایمیل
روز 4: 800 ایمیل
روز 7: 2,000 ایمیل
روز 14: نزدیک به حجم هدف نهایی (مثلاً 10k/day)
این جدول یک نمونه اولیه است؛ برای مقیاسهای بزرگتر از IP pool و subdomain استفاده کنید.
پیادهسازی فنی روی Postfix — نمونه کانفیگ
برای مدیریت ارسال بین چند IP و افزایش تدریجی حجم میتوانید از master.cf Und sender_dependent_default_transport_maps Verwenden.
نمونه master.cf:
smtp-ip1 unix - - n - - smtp
-o smtp_bind_address=203.0.113.45
-o syslog_name=postfix-ip1
smtp-ip2 unix - - n - - smtp
-o smtp_bind_address=203.0.113.46
-o syslog_name=postfix-ip2فعالسازی mapping در main.cf:
sudo postconf -e 'sender_dependent_default_transport_maps = hash:/etc/postfix/sender_transport'نمونه /etc/postfix/sender_transport:
[email protected] smtp-ip1:
[email protected] smtp-ip2:
*@example.com smtp-ip1:sudo postmap /etc/postfix/sender_transport
sudo systemctl reload postfixبا اسکریپت یا scheduler میتوانید فایل /etc/postfix/sender_transport را هر روز بروزرسانی کرده و مقصد هر دسته از ارسالها را تغییر دهید.
خودکارسازی روند warm‑up (اسکریپت / cron / systemd)
رویکرد ساده: اسکریپتی بنویسید که هر روز تعداد batch را بر اساس جدول warm‑up افزایش دهد، فایل mapping را ویرایش کند، سپس postmap و reload اجرا نماید.
نمونه خلاصه Python برای ارسال دستهای (illustrative):
from smtplib import SMTP
import time, csv
def send_batch(recipients):
with SMTP('localhost') as s:
for r in recipients:
s.sendmail('[email protected]', r, 'Subject: Test\\n\\nBody')
time.sleep(1) # rate control; adjust per day algorithmتوصیه میشود از MTAهای تخصصی یا پلتفرمهایی مثل Postal, Haraka Oder Mautic برای مدیریت بهتر rate‑limit و صفبندی استفاده کنید.
احراز هویت و رکوردهای DNS — SPF, DKIM, DMARC, PTR
پیش از شروع warm‑up باید رکوردهای هویتی بهدرستی تنظیم شوند تا ISPها بتوانند اعتبار ارسال را تایید کنند.
مثال SPF (TXT):
example.com. IN TXT "v=spf1 ip4:203.0.113.45 ip4:203.0.113.46 -all"DKIM (opendkim) — نمونه دستورات:
sudo apt install opendkim opendkim-tools
sudo opendkim-genkey -s default -d example.com
sudo mkdir -p /etc/opendkim/keys/example.com
sudo mv default.* /etc/opendkim/keys/example.com/سپس تنظیمات opendkim را به Postfix متصل کنید:
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = inet:127.0.0.1:8891مثال DMARC:
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100; aspf=r; adkim=r"PTR / Reverse DNS: باید توسط ارائهدهنده IP تنظیم شود. در صورتی که پنل ارائهدهنده امکان ست کردن reverse DNS را دارد، حتماً PTR را برای هر IP تنظیم کنید.
مدیریت Bounce و Complaints
Hard bounces: بلافاصله از لیست حذف شوند.
Soft bounces: مجدداً 2–3 بار تلاش شوند و سپس طبق الگوریتم حذف شوند.
شکایات (feedback loop): ثبتنام در FBLهای ISPها (مثلاً Microsoft SNDS, Yahoo FBL) و حذف سریع موارد شکایت.
Durchführung suppression lists و API برای حذف آدرس در لحظه ضروری است.
مانیتورینگ و ابزارها
ابزارها و روشهای پیشنهادی برای بررسی وضعیت deliverability:
لاگهای سرور:
tail -f /var/log/mail.logOder/var/log/maillog.تست رکوردها:
dig TXT example.com,dig +short PTR 203.0.113.45.ابزارهای آنلاین: mxtoolbox, Gmail Postmaster Tools, Microsoft SNDS.
استفاده از seed lists برای ارسال آزمایشی و بررسی inbox placement در mailboxهای مختلف.
Sicherheit und bewährte Verfahren
استفاده از TLS (STARTTLS) برای ارسال: پورت 587 با AUTH یا 465.
محدودیت دسترسی به پنل ارسال و API با احراز هویت دو مرحلهای.
پیادهسازی anti‑DDoS و شبکه BGP برای پایداری سرویس.
جداکردن سرویسهای transactional از promotional با IP/Domain مجزا.
تأثیر لوکیشنها و انتخاب دیتاسنتر
انتخاب دیتاسنتر نزدیک به کاربران میتواند تأثیر در Latenz داشته باشد اما در deliverability عمومی، مواردی مانند reverse DNS، کیفیت بلوک IP و تاریخچه آن اهمیت بیشتری دارند.
شرکت ارائهدهنده با ۸۵+ لوکیشن جهانی امکان انتخاب IP از بلوکهای پاک، تنظیم PTR و پیکربندی شبکه (BGP, Anycast) را فراهم میکند تا بهترین ترکیب performance و deliverability بدست آید.
نکات ارسال هدفمند برای تریدرها، گیمها و توسعهدهندگان
تریدرها/پلتفرمهای مالی: ایمیلهای حساس و اعلانها را روی IPهای اختصاصی نگهدارید؛ deliverability برای alertها حیاتی است.
Gaming: نوتیفها و transactional را از promotional جدا کنید؛ از زیرساخت مجزا برای assets و ایمیل استفاده شود.
DevOps: از ابزارهای CI برای تست ایمیل و از MTA staging برای شبیهسازی warm‑up استفاده کنید.
چکلیست نهایی قبل از شروع warm‑up
SPF, DKIM, DMARC تنظیم شده و معتبر.
PTR برای هر IP ست شده توسط ارائهدهنده.
Feed‑back loopها و Google Postmaster ثبت شدهاند.
لیست مخاطبین پاکسازی شده و تنها کاربران فعال در مراحل اولیه هدف باشند.
برنامه رشد روزانه مشخص و خودکار شده باشد.
مانیتورینگ برای bounces/complaints راهاندازی شده باشد.
استفاده از IP pool و transport maps برای توزیع بار.
سیاست حذف بلافاصله hard bounces اجرا شود.
نتیجهگیری و پیشنهادات کاربردی
اجرای خودکار روند warm‑up برای ایمیلسرور نیازمند برنامهریزی، تست و پایش مداوم است. ترکیب تنظیمات Postfix/Exim/Haraka با رکوردهای صحیح DNS و مدیریت bounce/complaint پایههای موفقیت در deliverability هستند.
در محیطهای تولیدی از IP pool، تقسیم بار و ابزارهای مانیتورینگ برای کاهش ریسک استفاده کنید.








