Lịch warmup IP 6 tuần cho người tự host email

Một IP chưa có lịch sử gửi trông giống hệt một IP vừa bị takeover dưới góc nhìn của mailbox provider. Chưa có tín hiệu nào chứng minh tính hợp pháp — chưa hề. Gửi 50.000 message trong ngày đầu tiên từ một IP mới tinh trông không khác gì một spammer thuê một dải IP còn nguyên để bắn trước khi hệ thống reputation kịp phát hiện.

Vì thế Gmail, Outlook, Yahoo, Apple iCloud Mail và các nhà cung cấp khu vực đều làm cùng một việc khi gặp IP lạ: chấp nhận một lượng nhỏ ban đầu, quan sát phản ứng của người nhận (open / click / mark-as-spam / xoá-không-đọc), và chỉ sau vài ngày tương tác sạch họ mới mở khoá cho volume lớn hơn. "Vài ngày" đó chính là cửa sổ warmup. Bỏ qua nó bạn không bị chặn — bạn bị throttle và tống vào spam folder trong nhiều tuần sau đó, hồi phục còn khó hơn cả bị từ chối thẳng.

Có hai dạng ramp đang được dùng phổ biến:

• Tuyến tính (Linear) — cùng một mức tăng cố định mỗi ngày. 50 → 100 → 150 → 200 → 250 … Dễ đoán, chậm, thận trọng.
• Luỹ thừa (Exponential) — nhân lên. 50 → 100 → 200 → 400 → 800 … Đạt volume mục tiêu nhanh hơn nhưng quyết liệt hơn ở đoạn cuối.

Warmup engine có sẵn của AcelleMail (model: app/Model/WarmupStrategy.php) hỗ trợ cả hai thông qua các hằng số GROWTH_STRATEGY_LINEAR và GROWTH_STRATEGY_EXPONENTIAL, kèm hai preset tiện dụng: PRESET_BALANCED (tuyến tính, mức tăng vừa phải) và PRESET_CAUTIOUS (tuyến tính, mức tăng nhỏ hơn với cửa sổ ramp dài hơn). Với domain gửi hoàn toàn mới chưa có reputation lịch sử, cautious là mặc định an toàn hơn. Với một đợt migration IP mà From-domain đã có reputation trên một IP khác, balanced hoặc exponential đều chấp nhận được.

Các con số dưới đây là một ramp tuyến tính thận trọng. Chúng được đặt thấp có chủ ý; kỷ luật còn quan trọng hơn con số chính xác. Quy tắc duy nhất phá tan mọi đợt warmup: tuyệt đối không nhân đôi volume của ngày hôm qua trên IP mới khi reputation chưa hình thành. Một khi bounce rate + complaint rate hàng tuần đều sạch trong một tuần tại đỉnh, IP đã "warm" và quá trình warmup kết thúc.

Kết thúc tuần 1 bạn đã chứng minh được rằng mình gửi được và người nhận đang tương tác. Kết thúc tuần 2 bạn ở mức 10.000/ngày — nhảy một bậc magnitude so với ngày đầu. Đây là lúc ngưỡng bulk-sender ở Gmail và Yahoo bắt đầu áp dụng: trên ~5.000 message/ngày tới một mailbox provider duy nhất, các yêu cầu về DMARC alignment, one-click unsubscribe và trần complaint-rate trở thành bắt buộc thay vì khuyến nghị. Nếu bạn thiếu bất kỳ điều kiện tiên quyết nào trong số đó, tuần 2 là lúc nó lộ diện — không phải dưới dạng bị chặn mà là một cú chuyển âm thầm vào spam folder.

Cách xử lý là chốt cả ba điều kiện tiên quyết trước khi warmup bắt đầu:

• DMARC tối thiểu ở p=quarantine; pct=100, lý tưởng là p=reject, kèm RUA report đang chảy đều.
• One-click unsubscribe qua header List-Unsubscribe + List-Unsubscribe-Post (RFC 8058). AcelleMail emit sẵn các header này theo mặc định.
• Ngân sách complaint-rate — Amazon SES áp trần cứng 0,1% complaint rate. Giữ dưới 0,05% như mức biên an toàn khi vận hành.

Console command app/Console/Commands/WarmupListServers.php là điểm vào cron. Nó duyệt mọi sending server đang active có gắn strategy và áp daily cap của ngày-trong-strategy trước khi cho phép bất kỳ campaign nào tiêu thụ server đó. Cap được lưu trong SendingServerWarmupUsage; log thực thi theo từng ngày nằm ở SendingServerWarmupLog. Bản thân strategy hỗ trợ ba kiểu giới hạn qua các hằng số trên WarmupStrategy:

• LIMIT_TYPE_PER_DAY_CAP — "ngân sách gửi hôm nay là N, không hơn"
• LIMIT_TYPE_TARGET_VOLUME — "ramp đến khi N/ngày được duy trì ổn định, rồi đánh dấu hoàn tất"
• LIMIT_TYPE_STOP_AFTER_DAYS — "ramp trong N ngày rồi dừng"

Với phần lớn vận hành viên, tổ hợp hợp lý là GROWTH_STRATEGY_LINEAR + LIMIT_TYPE_TARGET_VOLUME: ramp tuyến tính cho tới khi chạm daily target, rồi gỡ warmup và chạy bình thường. Strategy có thể gắn vào bất kỳ sending server nào — SES, Mailgun, SMTP generic, custom — độc lập với driver bên dưới.

Nếu bạn đang warmup với Amazon SES (cặp đôi được khuyến nghị theo /pricing), ba con số trong panel "Reputation metrics" của SES console là quan trọng trong giai đoạn ramp:

• Bounce rate — AWS cảnh báo ở 5%, pause ở 10%. Bạn nên ở thấp hơn 2% rất nhiều.
• Complaint rate — AWS cảnh báo ở 0,1%, pause ở 0,5%. Giữ dưới 0,05% như mức biên vận hành.
• Daily sending limit — SES tự tăng giới hạn này khi lịch sử gửi của bạn tích luỹ. Nếu nó dừng tăng, ramp warmup của bạn đang đi nhanh hơn mức tự cấp.

Mỗi chỉ số là per-account, không phải per-IP, nên metric là đạo hàm của toàn bộ hoạt động gửi cộng dồn. Nếu bounce-rate có xu hướng nhích lên trong tuần 2, hãy chậm lại — đừng cố đẩy qua. Provider đã nhận ra một điều gì đó, và chi phí điều tra bây giờ nhỏ hơn rất nhiều so với chi phí hồi phục sau khi bị pause.

Bạn có thể bỏ qua warmup trong hai tình huống và chỉ hai mà thôi:

1. Bạn đang dùng SES với shared IP (mặc định — SES production account dùng chung một pool IP được quản lý). Pool đó đã được pre-warm; bạn thừa hưởng reputation của nó. Warmup không liên quan trừ khi bạn nâng cấp lên SES dedicated IP.
2. From-domain hiện hữu của bạn đã có reputation tích luỹ trên một IP khác, và bạn đang migrate sang IP mới. Bạn vẫn cần warmup, nhưng dùng preset exponential thay vì linear cautious, vì reputation của From-domain mang theo được.

Với tất cả những người còn lại — domain mới, dedicated IP, các bản cài đặt Postal MTA tự host hoàn toàn mới — warmup không phải tuỳ chọn. Phần xử lý chuyên sâu hơn với cách đọc dashboard SES theo từng ngày nằm ở /guide/email-deliverability §7.