Deliverability email năm 2026 — chuẩn xác thực, lịch warmup, và feedback loop.

§1 · Định nghĩa

Deliverability email thực sự là gì.

Deliverability là tỷ lệ message bạn gửi đến được primary inbox của recipient — khác với delivery (message đã được mail server của recipient nhận) và khác với send (bạn đã đẩy nó vào sending pipeline). Một message có thể được send thành công, delivered tới mail server của recipient, rồi rớt vào spam folder — đó là delivery success và deliverability failure. Các con số mọi người quan tâm — open rate, click rate, conversion — phụ thuộc vào deliverability, không phải delivery.

Mailbox provider — Gmail, Outlook, Yahoo, Apple iCloud Mail, Proton, các provider regional lớn — mỗi nơi chạy một pipeline chấm điểm nhiều stage trên từng message đi vào. Các stage gần giống nhau giữa các provider, chỉ khác trọng số:

1. Kiểm tra ở connection-time. Reverse DNS, HELO/EHLO sanity, hỗ trợ TLS, IP có nằm trên RBL (Spamhaus, SpamCop, …) hay không.
2. Kiểm tra xác thực. SPF pass/fail (RFC 7208), validate chữ ký DKIM (RFC 6376), DMARC alignment (RFC 7489). Cả ba phải pass sạch sẽ để được hưởng scoring downstream nhẹ tay nhất.
3. Chấm điểm nội dung. Mật độ keyword spam, reputation của link, tỷ lệ image-to-text, From-name có khớp với From-address không.
4. Tra cứu reputation. Bản ghi nội bộ của provider về IP gửi và From-domain của bạn — bounce rate lịch sử, complaint rate, engagement trên các send trước đó.
5. Tín hiệu engagement. Recipient (hoặc cohort của họ) đã từng open hoặc click các message tương tự từ bạn chưa? Engagement gần đây là tín hiệu tích cực mạnh nhất xét riêng lẻ.
6. Disposition. Inbox, tab Promotions (Gmail), spam folder, hay reject. Disposition lại quay vòng làm input cho reputation.

Năm section bên dưới xử lý stage 2 (authentication) và stage 4 (reputation). Stage 1 chủ yếu là việc của sending relay; stage 3 và 5 là quyết định nội dung + audience nằm ngoài phạm vi của một guide deliverability. Stage 6 là output. Với một sender thương mại điển hình, làm đúng stage 2 và 4 đưa bạn từ 60–80% inbox lên 95%+.

Guide này viết cho operator self-hosted vì chính bạn là người xoay các núm. Trên SaaS, nền tảng abstract phần lớn việc này; trên self-hosted bạn sở hữu record SPF, keypair DKIM, policy DMARC, lịch IP warmup. Tin tốt: các chuẩn là public và ổn định. Tin xấu: không có lối tắt.

§2 · SPF

SPF — Sender Policy Framework.

SPF (RFC 7208) là một danh sách công khai các địa chỉ IP được uỷ quyền gửi mail thay mặt domain của bạn. Bạn publish nó như một TXT record duy nhất trên sending domain. Khi mailbox provider nhận một message tự xưng đến từ @yourcompany.com, nó tra record SPF tại yourcompany.com và hỏi: message này có đến từ một trong các IP được liệt kê không? Có thì SPF pass. Không thì SPF fail.

Cú pháp

v=spf1 include:amazonses.com ~all

Đọc là: "SPF version 1, authorize bất cứ gì Amazon SES authorize, soft-fail mọi thứ còn lại." ~all ở cuối là mệnh đề catch-all. ~all = soft-fail (đánh dấu khả nghi nhưng vẫn nhận), -all = hard-fail (reject), ?all = neutral (không có ý kiến). Dùng ~all cho tới khi DMARC khoẻ mạnh, rồi siết lại -all.

Nhiều sender (vd. Google Workspace cho outbound + SES cho marketing + Mailgun cho transactional) được chain qua nhiều cơ chế include::

v=spf1 include:_spf.google.com include:amazonses.com include:mailgun.org ~all

Giới hạn 10 DNS lookup. RFC 7208 §4.6.4 giới hạn quá trình resolve SPF ở 10 DNS lookup tổng cộng. Mỗi include: tính một. Failure thường gặp: chain 5+ vendor và vượt limit, sau đó SPF resolve về permerror và bị xử lý như fail. Audit bằng dig TXT yourcompany.com + một SPF flattener nếu bạn đang gần limit.

SPF trong AcelleMail

Model SendingDomain của AcelleMail expose getSpf() tại app/Model/SendingDomain.php:154, đọc setting toàn cục spf_record và render ra value của TXT record. Method verifySpf(string $ipOrHostname) tại line 363 wrap thư viện Mika56\SPFCheck — query DNS live ở runtime và assert RESULT_PASS. Bề mặt verification trong admin UI hiện xanh khi record đã có và authorize sending IP, đỏ khi không.

Mẹo thực tế: SPF chỉ authenticate envelope sender (mức SMTP MAIL FROM), không phải From-header hiển thị. Đó là phần khoảng cách mà DMARC alignment vá lại — xem §4.

§3 · DKIM

DKIM — DomainKeys Identified Mail.

DKIM (RFC 6376) gắn một chữ ký mật mã vào từng message đi ra. Server nhận fetch public key của bạn từ một TXT record trong DNS, verify chữ ký với một số header cụ thể và body của message, và chấp nhận message là authentic nếu phép toán khớp. SPF nói "IP này được phép gửi cho chúng tôi"; DKIM nói "đúng body và From-header này chưa bị sửa kể từ lúc chúng tôi ký."

Cơ chế

1. Bạn generate một keypair RSA (tối thiểu 1024-bit, khuyến nghị 2048-bit cho setup mới).
2. Public key đi vào DNS như một TXT record tại {selector}._domainkey.{yourdomain}. Selector là một chuỗi tuỳ ý (vd. k1, mail, 20251208) bạn chọn để xoay key mà không phá vỡ các message đang inflight.
3. Private key ở lại trên sending server của bạn. MTA (hoặc sending relay) ký từng message đi ra bằng nó, thêm một header DKIM-Signature.
4. Mail server của recipient đọc các value d= (domain) và s= (selector) từ header chữ ký, tra {s}._domainkey.{d}, fetch public key, và verify.

DKIM trong AcelleMail

SendingDomain::generateDkimKeys() tại app/Model/SendingDomain.php:221 generate một keypair RSA 1024-bit qua OpenSSL binding của PHP, lưu private half vào dkim_private, và lưu public half vào dkim_public. Selector được đọc từ dkim_selector trên model, fallback về setting toàn cục dkim_selector. Value DNS record render qua $this->getDomain()->getDkimDnsRecord() (line 270) và được hiện cho operator với nút copy cạnh "the value to publish."

Pattern generate key (từ generateDkimKeys()):

$config = [
    'digest_alg' => 'sha256',
    'private_key_bits' => 1024,
    'private_key_type' => OPENSSL_KEYTYPE_RSA,
];
$res = openssl_pkey_new($config);
openssl_pkey_export($res, $privKey);
$pubKey = openssl_pkey_get_details($res)['key'];

Verification: $this->getDomain()->verifyDkim() query DNS tại {selector}._domainkey.{domain} và so public key đã publish với value lưu local. Method verify() đầy đủ trên model điều phối các check identity + DKIM + SPF + DMARC trong một call (line 300).

DKIM vendor-managed

Nếu bạn gửi qua Amazon SES, SendGrid, Mailgun, hoặc bất kỳ vendor nào ký phía họ, bạn publish selector + public key của vendor thay vì tự generate. Capability SignsDkimOnServer ở mức driver của AcelleMail (xem app/SendingServers/Capabilities/SignsDkimOnServer.php) đánh dấu các driver xử lý DKIM remote; UI khi đó hiện các CNAME của vendor để publish thay vì generate keypair local. SES dùng ba CNAME uỷ quyền _domainkey về amazonses.com — set một lần và SES xoay underlying key giúp bạn.

§4 · DMARC

DMARC — alignment, policy, và reporting.

DMARC (RFC 7489) nằm trên SPF và DKIM. Nó làm ba việc mà SPF và DKIM riêng lẻ không làm:

1. Alignment. Yêu cầu envelope domain đã được SPF validate hoặc domain ký DKIM phải khớp với domain From-header hiển thị. Không có alignment, SPF và DKIM có thể pass cho một domain khác với cái recipient thấy — đúng khe hở mà phishing khai thác.
2. Policy. Báo cho server nhận biết phải làm gì khi alignment fail: none (không làm gì, chỉ report), quarantine (đẩy vào spam), reject (từ chối message ở mức SMTP).
3. Reporting. Aggregate report (RUA — XML report hàng ngày của mọi send từ domain bạn) và forensic report (RUF — per-failure individual report) gửi đến địa chỉ bạn chỉ định. Report cho bạn visibility về ai đang gửi mail tự xưng là bạn.

Cú pháp

_dmarc.yourcompany.com.    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com; pct=100; aspf=s; adkim=s"

Đọc là: "DMARC version 1, quarantine các message fail alignment, gửi aggregate report đến dmarc@yourcompany.com, apply policy lên 100% các message fail, yêu cầu strict alignment cho cả SPF và DKIM."

Quy trình rollout chuẩn

1. Day 0: publish p=none với rua= trỏ về một mailbox có theo dõi. Nhận report trong 7–14 ngày. Đây là observe-only — không message nào bị reject.
2. Day 14: review report. Nhận diện các sender hợp lệ (SES của chính bạn, IP gửi của CRM, các provider transactional) và đưa hết về SPF + DKIM alignment.
3. Day 30: siết về p=quarantine; pct=10. Mail không aligned đi vào spam ở 10% recipient. Theo dõi report trong hai tuần.
4. Day 45: nâng lên pct=50, rồi pct=100 trong 2–4 tuần.
5. Day 60–90: siết về p=reject. Lúc này mail không aligned bị bounce ngay ở SMTP — phisher dùng domain bạn ăn hard reject.

Đừng bỏ qua rollout. Nhảy thẳng từ không có DMARC sang p=reject là nguyên nhân tự gây ra thảm hoạ deliverability phổ biến nhất: một sender transactional bị quên (CRM, tool support, hệ thống billing) bắt đầu hard-bounce ngay khoảnh khắc p=reject lan ra.

Yêu cầu từ mailbox provider

Từ tháng 2/2024, Gmail và Yahoo yêu cầu DMARC cho bất kỳ sender nào gửi > 5.000 message mỗi ngày tới domain của họ, kèm SPF hoặc DKIM aligned, kèm one-click List-Unsubscribe (RFC 8058). Microsoft 365 tại thời điểm viết bài cũng đã align về cùng chuẩn. Ngưỡng "commercial sending" đã dịch chuyển vĩnh viễn — DMARC không còn là optional cho bất kỳ list nào trên ~1.000 contact. Set nó sớm, kể cả khi list bạn còn nhỏ.

§5 · BIMI

BIMI — bonus logo thương hiệu.

BIMI (Brand Indicators for Message Identification) hiển thị logo thương hiệu của bạn bên cạnh message trong inbox của recipient. Gmail, Yahoo, Apple Mail, và Fastmail hỗ trợ nó tính đến 2025. Đây là tính năng deliverability-adjacent — bản thân không phải authentication — nhưng yêu cầu DMARC ở mức p=quarantine hoặc p=reject như tiền đề, vì vậy nó nằm trong guide này.

Các bước setup (sau khi DMARC ở mức quarantine hoặc nghiêm hơn):

1. Tạo phiên bản SVG của logo theo spec BIMI SVG Tiny PS — vuông, không có chữ ngoài mark, path đơn giản.
2. Host SVG ở một URL HTTPS công khai truy cập được.
3. Tuỳ chọn lấy một Verified Mark Certificate (VMC) từ CA — Gmail yêu cầu để hiện badge với dấu tick xanh, ~$1,500/năm. Common Mark Certificate (CMC) là lựa chọn rẻ hơn cho thương hiệu chưa đăng ký.
4. Publish BIMI record: default._bimi.yourcompany.com TXT "v=BIMI1; l=https://yourcdn/logo.svg; a=https://yourcdn/vmc.pem"

Tác động deliverability của BIMI là gián tiếp nhưng đo được: logo thương hiệu trong inbox đẩy open rate lên 5–20% trong các case study được publish (data pilot của Yahoo Mail, BIMI report của Mailchimp). Nó cũng là forcing function mạnh — bạn không thể enable BIMI nếu chưa cứng hoá DMARC, nên các team dùng nó như cà rốt cho một đợt dọn dẹp authentication.

§6 · Reputation

Reputation — mailbox provider thực sự chấm điểm cái gì.

Authentication là nhị phân — một record hoặc resolve và align hoặc không. Reputation là liên tục: một điểm từ 0 đến 100 do mỗi mailbox provider duy trì, riêng biệt cho sending IP và From-domain của bạn. Hai điểm số kết hợp lại thành quyết định routing (inbox vs Promotions vs spam vs reject).

Các tín hiệu

Xem điểm reputation của bạn ở đâu

• Google Postmaster Tools (postmaster.google.com) — reputation IP và domain theo góc nhìn Gmail, kèm tuân thủ authentication, tỷ lệ encryption, tỷ lệ spam. Miễn phí.
• Microsoft SNDS (postmaster.live.com/snds/) — data ở mức IP của Outlook.com, phân loại sender reputation. Miễn phí, cần đăng ký.
• Yahoo Sender Hub — mới hơn, đăng ký qua trang Yahoo Postmaster. Aggregate stats theo domain.
• Dashboard của provider — Reputation Dashboard của Amazon SES hiện bounce + complaint rate kèm ngưỡng. SparkPost, Mailgun, SendGrid đều có tương tự.

Check ít nhất một dashboard hàng tuần. Các leading indicator (xu hướng spam rate, IP reputation drop) xuất hiện vài ngày trước downstream effect (open rate giảm) — đến lúc bạn phát hiện một campaign underperform, vấn đề reputation đã trễ hai tuần.

§7 · IP warmup

IP warmup — lịch 6 tuần.

Một sending IP mới khởi điểm reputation bằng 0. Mailbox provider throttle volume lớn từ IP mới một cách có chủ ý — đây là phòng tuyến chính chống snowshoe spammer dựng cloud instance và blast. Warmup là thực hành tăng dần send volume trong 4–6 tuần trong khi giữ trong giới hạn throttle per-day và per-hour, xây reputation một cách hữu cơ.

Bạn chỉ làm việc này một lần cho mỗi IP. Đa số team không bao giờ làm vì IP chia sẻ của Amazon SES, SendGrid, và Mailgun đã pre-warmed. Trường hợp warmup quan trọng: dedicated IP trên SES (thường > 1M send/tháng mới justify), self-hosted Postal MTA trên một cloud instance mới, migration từ ESP này sang ESP khác có đổi domain.

Lịch warmup

Lịch dựa trên khuyến nghị warmup published của SparkPost / Postmark / SES, gộp lại thành một bảng theo tuần. Ramp chậm hơn lịch này nếu bạn thấy complaint rate đi lên; ramp nhanh hơn chỉ khi mỗi bước đều có provider xác nhận reputation green-light.

Theo dõi warmup trong AcelleMail

Model SendingServer của AcelleMail có state warmup first-class. warmup_enabled, warmup_strategy_id, và warmup_started_at nằm trên bảng sending_servers; isWarmupEnabled() tại app/Model/SendingServer.php:333 gate quyết định lúc send. Bảng đồng hành SendingServerWarmupLog ghi lại mọi send trong window warmup kèm date, status, và một meta payload serialize — xem app/Model/SendingServerWarmupLog.php.

Pattern: gán một WarmupStrategy (một row định nghĩa đường volume per-day) cho sending server, lật warmup_enabled = true, set warmup_started_at = now(). SendingServerWarmupUsage trong send pipeline track count hôm nay và từ chối dispatch vượt trần daily của strategy. Khi trần day-N của strategy vượt full daily volume của bạn, server tốt nghiệp và warmup mode tự disable.

Các class DynamicRateTracker và InMemoryRateTracker (app/Library/) xử lý rate limiting per-minute / per-hour ở lớp SMTP — kể cả ngoài warmup, AcelleMail vẫn enforce trần rate published của relay để một surge queue không trip throttling phía provider.

§8 · Bounce + complaint

Bounce, complaint, và feedback loop.

Hard bounce vs soft bounce

Hard bounce là failure vĩnh viễn — thường là SMTP code 5xx: địa chỉ không tồn tại, domain không resolve, mailbox của recipient bị disable vĩnh viễn. Model BounceLog của AcelleMail định nghĩa hằng số HARD và SOFT tại app/Model/BounceLog.php:33; một hard bounce suppress địa chỉ ngay lập tức. Soft bounce là transient — code 4xx: mailbox đầy, server tạm thời không available, message quá lớn. Soft bounce retry theo lịch backoff; các địa chỉ soft bounce nhiều lần qua nhiều send rồi cuối cùng bị demote về hard.

Bản đồ phân loại cho bounce notification của AWS SES (nguồn mà documentation BounceLog.php:32 của AcelleMail trích): bounce type bao gồm Permanent (hard) với sub-type General / NoEmail / Suppressed / OnAccountSuppressionList; Transient (soft) với sub-type General / MailboxFull / MessageTooLarge / ContentRejected / AttachmentRejected; cộng Undetermined (xử lý như soft, retry).

Complaint

Một complaint là recipient bấm "report as spam" trong email client của họ. Complaint đến qua Feedback Loop (FBL) — một kênh notification per-provider nơi ISP forward cho bạn các message bị report là abuse. FeedbackLoopHandler của AcelleMail tại app/Model/FeedbackLoopHandler.php xử lý message FBL đi vào qua IMAP/POP và parse các header Abuse Reporting Format (ARF, RFC 5965) để trích message ID gốc và feedback type.

Các ARF feedback type mà AcelleMail xử lý (theo FeedbackLoopHandler::FEEDBACK_TYPES tại line 35):

• abuse — recipient mark rõ ràng là spam. Suppress ngay.
• fraud — recipient mark là phishing. Suppress + log vào security review.
• virus — antivirus của recipient flag một payload. Suppress + audit content.
• other — complaint chung. Suppress.
• not-spam — report rõ "không phải spam" (hiếm). Loại khỏi suppression — xem EXCLUDED_FEEDBACK_TYPES.

Các mailbox provider lớn tham gia FBL: AOL, Yahoo, Microsoft (qua JMRP), Comcast, BlueTie. Gmail không chạy public FBL — họ chuyển feedback "marked as spam" qua dashboard Postmaster Tools và qua aggregate DMARC report.

Quy tắc suppression

1. Hard bounce → suppress vĩnh viễn. Không bao giờ retry; địa chỉ đã chết.
2. Complaint → suppress vĩnh viễn. Recipient đã chủ động bảo dừng. Gửi lại là illegal trong đa số jurisdiction và đốt reputation.
3. Soft bounce ×3 trong 30 ngày → demote về hard, suppress. Soft bounce dai dẳng là mailbox đầy hoặc connectivity bền vững — coi như chết.
4. Unsubscribe → suppress cho marketing, không cho transactional. Order receipt và password reset vẫn tiếp tục; campaign dừng.
5. Trúng spam trap → escalate điều tra. Kéo toàn bộ acquisition source của subscriber đó. List nhiều khả năng bị nhiễm địa chỉ mua hoặc scrape.

§9 · List hygiene

List hygiene — kỷ luật giữ reputation cao.

Authentication là setup một lần. Reputation là kỷ luật vận hành. Bảy thói quen xoay được kim:

1. Double opt-in cho mọi signup marketing. Một click confirm trước khi địa chỉ vào active list. Loại bỏ typo, role address (info@, sales@), và địa chỉ harvest. Thêm 10–20% friction cho signup; trừ 50–80% rủi ro bounce/complaint.
2. One-click unsubscribe (RFC 8058). Header List-Unsubscribe trỏ về một URL one-click. Gmail và Yahoo yêu cầu cho sender > 5K/ngày tới domain của họ từ tháng 2/2024. Làm unsub dễ hơn complaint — recipient định bấm "spam" sẽ bấm "unsubscribe" thay.
3. Re-engagement trước khi suppress. Subscriber không open trong 90 ngày nhận một campaign "chúng tôi muốn vẫn liên quan." Open → giữ. Không open → vào sunset queue. Không open sau 180 ngày → suppress.
4. Tự suppress bounce. Xử lý webhook bounce trong vài phút; xoá khỏi active sending list trước campaign tiếp theo. BounceLog::record() của AcelleMail và các handler bounce-webhook kiểu vbrandsync làm tự động.
5. Không bao giờ import list đã mua. Tuyệt đối không. List đã mua đầy spam trap. Một trap hit và domain bạn lên Spamhaus 30+ ngày. Phép toán không bao giờ ổn — list đã mua là một cái hố reputation vĩnh viễn.
6. Segment theo engagement. Gửi campaign cho 50% engaged gấp đôi tần suất, 50% lạnh nửa tần suất. Đẩy open rate tổng lên, đẩy complaint rate xuống, và cho mailbox provider tín hiệu mạnh "sender này liên quan."
7. Giới hạn cadence automation. Welcome series + abandoned-cart + post-purchase + birthday + re-engagement có thể tạo 8 message trong một tuần. Giới hạn tổng automation message ở mức một / 48 giờ / recipient, với ngoại lệ cứng cho transactional (receipt, password reset).

§10 · Tooling AcelleMail

Tooling deliverability của AcelleMail — source ship sẵn cái gì.

Trích thẳng từ source tree dưới app/Model/ và app/Library/. Mỗi entry là một model, capability interface, hoặc library class thật — không phải marketing.

§11 · Troubleshooting

Sự cố deliverability thường gặp và cách xử lý.

§12 · FAQ

FAQ deliverability email.

Cluster head

Đi tiếp đến đâu.

Domain đã authenticated. Bounce được track. Reputation cấp inbox.

AcelleMail ship sẵn verification SPF/DKIM/DMARC, xử lý ARF feedback-loop, state machine IP warmup, và rate limiting per-server trong box. Mọi tuyên bố trong guide này đều map về một class trong app/Model/ hoặc app/Library/ của AcelleMail trong source tree.