Tự host email năm 2026 có còn đáng không?

Câu trả lời ngắn gọn

Tự host email vẫn đáng làm trong năm 2026, miễn là bạn tách công việc này thành 2 phần. Nhận email của chính bạn trên VPS của chính bạn có rủi ro thấp và vẫn hoạt động, vì bạn là bên nhận và không ai phải tin tưởng bạn. Gửi email để các nhà cung cấp mailbox lớn chấp nhận là một công việc khác. Công việc này phụ thuộc vào reputation của địa chỉ IP mà bạn kế thừa, thay vì tự xây dựng.

Cấu hình mà các operator có kinh nghiệm thực sự sử dụng là mô hình hybrid. Server của họ lưu mailbox và archive, còn email gửi đi được chuyển qua một relay đã xác thực trên port 587. Tự host hoàn toàn theo cả 2 chiều vẫn phù hợp trong một số trường hợp cụ thể. Các trường hợp đó nằm gần cuối bài viết này.

Phần khó của việc tự host email là khả năng gửi thư đến inbox

Cài mail server thường mất một cuối tuần. Một stack hiện đại cung cấp SMTP (simple mail transfer protocol) để chuyển thư, IMAP (internet message access protocol) để đọc thư, bộ lọc spam và giao diện webmail chỉ từ một file compose. Bài Cài mail server Mailcow trên VPS đã trình bày phần này. Không có gì khó trong quá trình cài đặt.

Khó khăn bắt đầu khi server của bạn mở kết nối đến một máy do một công ty không biết bạn là ai vận hành, rồi yêu cầu máy đó đưa thư vào inbox của ai đó. Receiver không có lý do để chấp nhận. Nó quyết định dựa trên nhiều tín hiệu: reputation của IP kết nối, reputation của domain, thư có được xác thực hay không và người dùng của nó đã phản hồi với thư từ bạn như thế nào trước đây. Sender mới hoàn toàn không có lịch sử, và việc không có lịch sử không được xem là trung lập. Nó được đánh giá là rủi ro. Vì vậy, những thư đầu tiên sẽ vào spam hoặc bị defer cho đến khi hình thành được một pattern.

Bạn sẽ thấy thông báo từ chối. Gmail gửi một rejection vĩnh viễn có dạng sau:

550-5.7.1 [203.0.113.5      19] Our system has detected that this message is
550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,
550-5.7.1 this message has been blocked.

Microsoft gửi một thông báo khác, kết thúc bằng một block-list code thay đổi tùy trường hợp:

550 5.7.1 Unfortunately, messages from [203.0.113.5] weren't sent. Please
contact your Internet service provider since part of their network is on
our block list (S3150).

Trước hết, hãy đọc chữ số đầu tiên. Code bắt đầu bằng 4 là tạm thời, nên server của bạn giữ thư lại và retry. Code bắt đầu bằng 5 là vĩnh viễn, nên thư bị bounce về sender ngay lập tức. Một lần defer 4xx không bao giờ được gỡ bỏ thường là do rate limit hoặc reputation limit, và có thể tự được giải quyết. Mã 5xx là một quyết định và sẽ không tự được giải quyết.

Vì sao email từ server mới lại vào thư mục spam?

Vì địa chỉ IP đó không thực sự mới. Bạn không nhận được một địa chỉ hoàn toàn mới. Nhà cung cấp cấp cho bạn một địa chỉ được tái sử dụng từ pool của họ, và lịch sử của địa chỉ đó đi kèm theo. Nếu tenant trước đó từng gửi spam, message đầu tiên của bạn có thể bị từ chối trước khi bạn gửi message thứ hai.

Hãy kiểm tra địa chỉ trước khi triển khai bất kỳ thứ gì trên đó. Các public blocklist trả lời qua DNS, với 4 octet của địa chỉ được đảo ngược:

sudo apt update && sudo apt install -y bind9-dnsutils netcat-openbsd swaks
dig +short 10.0.0.10.zen.spamhaus.org

Câu trả lời rỗng nghĩa là địa chỉ không nằm trong danh sách. Câu trả lời nằm trong 127.0.0.0/8 nghĩa là địa chỉ có trong danh sách, và octet cuối cho biết list nào đã khớp. Có một điểm dễ nhầm trong phép kiểm tra này: Spamhaus từ chối các query đi qua những public resolver lớn, nên cùng lookup đó khi thực hiện qua 8.8.8.8 sẽ trả về 127.255.255.254 bất kể trạng thái thực tế là gì. Mã đó nghĩa là query bị từ chối, không phải địa chỉ đã bị đưa vào danh sách. Hãy chạy query qua resolver của chính server, hoặc dùng web lookup.

Kết quả sạch là điều kiện cần, nhưng chưa đủ. Không nằm trong danh sách chỉ có nghĩa là gần đây chưa có ai khiếu nại về địa chỉ đó. Nó không có positive reputation, trong khi positive reputation mới là yếu tố thực sự giúp mail vào inbox. Reputation được xây dựng bằng cách gửi lượng mail nhỏ, đúng đối tượng trong nhiều tuần.

Các địa chỉ lân cận cũng có ảnh hưởng, vì một số receiver đánh giá reputation trên toàn bộ network block thay vì chỉ một địa chỉ. Khi một customer khác trong cùng dải /24 bắt đầu gửi spam, mail của bạn có thể bị chậm hoặc bị đánh giá xấu theo. Cách đánh giá ở cấp block cũng giải thích vì sao khiếu nại abuse đến inbox VPS về traffic mà account holder không hề gửi: khiếu nại đi theo dải địa chỉ.

Cần xác nhận gì trước khi bắt đầu: port 25 và bản ghi PTR

TCP port 25 gửi đi là port bị lạm dụng nhiều nhất trên Internet, nên nhiều nhà cung cấp hosting mặc định chặn port này trên account mới. Một số nhà cung cấp sẽ mở port khi bạn yêu cầu. Một số chỉ mở sau khi account đã có thời gian hoạt động và lịch sử thanh toán. Một số không bao giờ mở. Chính sách khác nhau giữa các nhà cung cấp và có thể thay đổi theo thời gian, vì vậy đừng xem bài viết này, một thread cũ trên forum hoặc trang marketing của bất kỳ nhà cung cấp nào là thông tin hiện tại. Hãy hỏi và yêu cầu câu trả lời bằng văn bản trước khi thanh toán.

Kiểm tra đường đi ngay từ server:

nc -vz gmail-smtp-in.l.google.com 25

Đường đi đang mở sẽ in succeeded! trong vòng một giây. Đường đi bị chặn sẽ treo rồi timeout mà không có thông báo nêu rõ nguyên nhân chặn, vì packet bị drop im lặng trông giống hệt một lỗi network thông thường.

Yêu cầu thứ hai là bản ghi PTR, còn gọi là reverse DNS. Receiver lấy địa chỉ IP đã kết nối đến nó, tra bản ghi PTR để lấy hostname, rồi tra hostname đó để lấy lại một địa chỉ. Khi hai địa chỉ khớp nhau, cơ chế này được gọi là forward-confirmed reverse DNS. Đây là một kiểm tra đơn giản để xác nhận host đang kết nối thuộc về đúng đơn vị mà nó tự nhận.

dig -x 203.0.113.5 +short
dig +short mail.example.com

Lệnh thứ nhất phải trả về mail hostname của bạn. Lệnh thứ hai phải trả về đúng địa chỉ bạn đã dùng lúc đầu. Chỉ owner của một địa chỉ IP mới có thể publish bản ghi PTR cho địa chỉ đó, nên host sẽ phải thiết lập giúp bạn hoặc cung cấp tùy chọn này trong control panel. Không có bản ghi PTR, hoặc dùng một tên generic như 203-0-113-5.static.example-isp.net, là tín hiệu tiêu cực rõ ràng, vì mail server thật hầu như luôn có hostname tương ứng còn các nguồn spam gửi hàng loạt thường không có.

Nếu host cũng cấp IPv6 và server ưu tiên IPv6, mọi yêu cầu trên cũng áp dụng cho địa chỉ IPv6, đồng thời Gmail kiểm tra IPv6 chặt hơn. Gửi mail qua IPv6 từ địa chỉ không có bản ghi PTR sẽ bị từ chối với thông báo rằng message không đáp ứng hướng dẫn gửi mail qua IPv6 liên quan đến bản ghi PTR và authentication. Nếu bạn không thể thiết lập bản ghi PTR cho IPv6, chỉ gửi qua IPv4. Trong Postfix, dùng smtp_address_preference = ipv4 để ưu tiên IPv4 hoặc inet_protocols = ipv4 để tắt hoàn toàn IPv6.

Ba câu hỏi cần hỏi mọi host

1. TCP port 25 gửi đi có được mở trên account mới không? Nếu không, quy trình và thời gian cụ thể để mở port là gì?
2. Tôi có thể thiết lập bản ghi PTR cho địa chỉ IPv4 và địa chỉ IPv6 của mình không? Tôi thực hiện việc đó ở đâu?
3. Nếu địa chỉ của tôi nằm trong blocklist do khách hàng trước đó, host có chuyển tôi sang một địa chỉ khác không?

Hãy hỏi cả ba câu trước khi thanh toán, không phải sau đó. Một host trả lời rõ ràng hai câu đầu và trả lời không cho câu thứ ba vẫn có thể dùng được, vì bạn có thể kiểm tra địa chỉ ngay ngày đầu tiên rồi hủy dịch vụ. Một host không chịu trả lời bất kỳ câu nào bằng văn bản đã cho bạn biết việc chạy mail trên đó sẽ như thế nào.

SPF, DKIM và DMARC thực sự chứng minh điều gì

Ba bản ghi DNS chứng minh rằng email tự nhận là được gửi từ domain của bạn thực sự đã được gửi như vậy. Mỗi bản ghi trả lời một câu hỏi khác nhau. Bản ghi thứ ba chỉ hoạt động khi bạn đã hiểu hai bản ghi đầu tiên.

SPF (sender policy framework) là một bản ghi TXT liệt kê những server được phép gửi email cho domain của bạn. Server nhận kiểm tra bản ghi này với envelope sender, tức địa chỉ được truyền trong lệnh SMTP MAIL FROM. Địa chỉ này không phải là header From: mà người đọc nhìn thấy.

DKIM (domainkeys identified mail) thêm chữ ký cryptographic vào các header của message. Chữ ký này bao phủ body và một danh sách header được chọn. Public key tương ứng nằm trong DNS dưới selector do bạn chọn. Khi đó, bất kỳ ai cũng có thể xác minh message được gửi bởi người nắm private key của bạn và không bị sửa đổi trên đường truyền.

DMARC (domain-based message authentication, reporting and conformance) liên kết hai cơ chế trên với domain trong header From: hiển thị, đồng thời cho receiver biết phải xử lý thế nào khi liên kết này không hợp lệ.

example.com.                  TXT  "v=spf1 mx -all"
mail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.example.com.           TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Từ khóa quan trọng là alignment. DMARC không pass chỉ vì SPF đã pass. DMARC pass khi SPF hoặc DKIM pass, đồng thời domain đã pass phải trùng với domain trong header From:. Đây là lý do email được relay có thể fail mà không dễ nhận ra: relay rewrite envelope sender thành domain của chính nó nên SPF vẫn pass, nhưng domain đã pass là domain của relay. Vì vậy SPF không được align và DMARC fail, trừ khi chữ ký DKIM của bạn tồn tại và hợp lệ. Hãy ký bằng key được publish dưới domain của bạn để giải quyết vấn đề này.

Alignment cũng giải thích vấn đề forwarding. Khi mailing list hoặc địa chỉ đại học cũ forward message của bạn, forwarding server trở thành địa chỉ IP kết nối. Địa chỉ này không nằm trong SPF record của bạn, nên SPF fail tại đích cuối. DKIM vẫn hoạt động sau forwarding, miễn là các header đã ký không bị sửa đổi. DKIM là cơ chế phải hoạt động trong trường hợp này.

Trước tiên, hãy publish p=none với địa chỉ reporting rua=, rồi đọc aggregate report trong hai tuần trước khi siết policy. Các report này là nơi duy nhất cho bạn thấy những email được gửi dưới danh nghĩa của bạn nhưng không phải do bạn gửi. Đây cũng là cách duy nhất để tìm forwarder mà bạn đã bỏ sót. Chuyển thẳng sang p=reject sẽ bỏ qua bước này và làm hỏng email hợp lệ mà không để lại thông tin cho biết nguyên nhân.

Sau đó, hãy kiểm thử toàn bộ chuỗi từ đầu đến cuối. Gửi một message đến account do bạn sở hữu tại một nhà cung cấp lớn, rồi mở raw source của message:

swaks --to you@gmail.com --from postmaster@example.com --server 127.0.0.1
sudo journalctl -t postfix/smtp -f

swaks in ra cuộc trao đổi SMTP trong lúc diễn ra. Log line của Postfix cho lần delivery kết thúc bằng status=sent (250 2.0.0 OK ...) khi receiving server đã accept message. Nếu không, log sẽ ghi nguyên văn nội dung từ chối. Hãy tìm kiếm đúng chuỗi đó. Trong message đã được delivery, raw source chứa một header Authentication-Results: liệt kê từng lần kiểm tra cùng trạng thái pass hoặc fail và domain đã được xác thực. Cả ba phải có trạng thái pass và domain phải là domain của bạn.

Làm thế nào để phát hiện vấn đề về reputation?

Feedback loop là cơ chế trong đó một nhà cung cấp mailbox gửi cho bạn bản sao của một message mỗi khi một người dùng của họ bấm nút báo spam. Nếu không có feedback loop, dấu hiệu đầu tiên của sự cố là việc gửi đã thất bại từ trước, và bạn chỉ biết sau nhiều tuần.

Các chương trình này khác nhau, và không phải chương trình nào cũng phù hợp với một VPS có một địa chỉ duy nhất. Tính đến tháng 8 năm 2026, Microsoft vận hành dịch vụ dữ liệu và khiếu nại theo từng địa chỉ để chủ sở hữu địa chỉ đăng ký; Yahoo cung cấp complaint feedback loop dựa trên DKIM signing domain; còn Google công bố dữ liệu reputation tổng hợp thay vì từng khiếu nại riêng lẻ, trong một dashboard vẫn trống cho đến khi bạn gửi một volume hằng ngày đủ đáng kể đến người dùng của họ. Hãy đọc điều khoản hiện tại của từng dịch vụ trước khi phụ thuộc vào chúng, vì các chương trình này có thể thay đổi và không chương trình nào có nghĩa vụ cấp quyền truy cập cho bạn.

Các yêu cầu bulk sender do Google công bố, có hiệu lực từ tháng 2 năm 2024, là tuyên bố công khai rõ ràng nhất về những gì một hệ thống nhận thư lớn hiện yêu cầu. Sender gửi hơn 5,000 message mỗi ngày đến tài khoản Gmail cá nhân phải xác thực bằng SPF và DKIM, công bố chính sách DMARC, cung cấp one-click unsubscribe cho bulk mail và duy trì tỷ lệ khiếu nại spam dưới 0.3 phần trăm. Mail cá nhân từ một server nhỏ thấp hơn nhiều so với ngưỡng này, nhưng các tín hiệu tương tự vẫn được xem xét ở mọi volume, còn tỷ lệ khiếu nại là chỉ số bạn không thể thấy nếu không có feedback loop.

Mô hình phân tách hiệu quả: tự host nhận mail, dùng relay cho mail gửi đi

Nhận mail là phần gần như không có nhược điểm. Không ai phải tin bạn để chấp nhận mail được gửi đến bạn. MX record, tức DNS record chỉ ra mail exchanger của domain, trỏ đến server của bạn. Người gửi kết nối đến bạn, còn mọi quyết định sau đó đều do bạn kiểm soát: giữ mail nào, giữ trong bao lâu, lập index như thế nào và cho phép ai tìm kiếm. Storage rẻ, và archive do bạn sở hữu không thể bị đóng bởi một quyết định tự động nào đó từ policy ở nơi khác. Công việc là có thật, nhưng phạm vi rõ ràng: cập nhật spam filter, duy trì việc gia hạn chứng chỉ TLS (transport layer security), duy trì backup và không để disk đầy.

Mail gửi đi là phần bạn có thể trả phí để tránh bài toán khó. Cấu hình server chuyển mọi message gửi đi đến một relay đã xác thực trên port 587, thay vì kết nối trực tiếp với Internet trên port 25. Trong Postfix, sửa main.cf:

relayhost = [smtp.relay.example]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

Dùng editor ghi credentials vào /etc/postfix/sasl_passwd để password không bao giờ xuất hiện trong shell history. Đây là một dòng duy nhất, và hostname ở bên trái phải được ghi chính xác như trong relayhost:

[smtp.relay.example]:587 username:password

sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd.db
sudo systemctl reload postfix

Message gửi sau khi reload sẽ ghi log relay=smtp.relay.example[...]:587 và status=sent. Dòng log có nội dung SASL authentication failed nghĩa là credentials không được chấp nhận. Nguyên nhân thường gặp là hostname trong sasl_passwd được ghi khác với hostname trong relayhost, vì việc lookup so khớp chuỗi chính xác.

Mô hình phân tách này hiệu quả vì relay sở hữu các địa chỉ đã có nhiều năm mail được chấp nhận, và duy trì reputation đó là toàn bộ hoạt động kinh doanh của họ. Bạn vẫn giữ domain, mailbox, archive và khả năng rời đi, vì đổi relay chỉ cần sửa một dòng cấu hình và một DNS record. Điều bạn phải đánh đổi là tính bảo mật của mail gửi đi trước operator của relay. Đây là chi phí thực sự của mô hình này, và nên được quyết định trước thay vì chỉ phát hiện ra sau đó.

Có thêm một điểm nên phân tách ngay trong ngày đầu tiên. Mọi mail bulk nên được gửi từ subdomain riêng với DKIM key riêng: news.example.com cho newsletter và mail.example.com cho mail cá nhân. Reputation gắn với sending domain, nên tỷ lệ complaint của newsletter Listmonk tự host sẽ không kéo reputation của mail cá nhân xuống theo.

Khi nào tự host hoàn toàn vẫn là lựa chọn phù hợp?

Sản lượng. Chi phí relay tính theo từng message vẫn hợp lý ở mức vài trăm message mỗi tháng, nhưng sẽ không còn hợp lý khi lên đến hàng triệu message. Ở quy mô đó, bạn có thể chi trả cho các địa chỉ IP riêng và lịch warmup cần thiết để chúng hoạt động ổn định.

Phạm vi pháp lý. Khi quy định hoặc hợp đồng yêu cầu mail không được lưu trên disk của bên thứ ba, chất lượng gửi mail không còn là yếu tố quyết định. Bạn đơn giản là không thể sử dụng relay.

Quyền kiểm soát không thể mua bằng gói dịch vụ. Bạn có thể đặt retention rule theo chính sách của mình thay vì theo tier của gói, dùng một địa chỉ cho mỗi service để biết service nào làm lộ địa chỉ, chạy filtering bằng code của mình và không phải chịu quyết định suspend account từ một hệ thống không có quy trình kháng nghị.

Mail không bao giờ rời khỏi network của bạn. Alert và các mail giữa máy với máy hoàn toàn không gặp vấn đề deliverability, vì cả hai đầu đều thuộc quyền quản lý của bạn. Một SMTP server cục bộ gửi mail vào các mailbox của chính bạn là đủ, và đây cũng là pattern đứng sau cấp cho assistant một mailbox tự host riêng qua MCP (model context protocol).

Nếu bạn gửi mail outbound trực tiếp, hãy warmup địa chỉ đó. Bắt đầu với volume hằng ngày thấp đến những người đang chờ mail của bạn, tăng dần trong vài tuần và không bao giờ gửi một burst từ địa chỉ còn cold. Reputation được xây dựng từ các mail được chấp nhận, có ít complaint trong thời gian dài. Vì vậy, một spike đột ngột từ địa chỉ không có history sẽ trông chính xác như một server bị breach và bị xử lý như vậy.

Chi phí vận hành mail server trong năm đầu tiên là bao nhiêu?

Tuần đầu tiên là giai đoạn dựng hệ thống: cài package, cấu hình DNS record, cấp TLS certificate, gửi các email kiểm thử đầu tiên và đặt DMARC ở p=none.

Tuần thứ hai đến tuần thứ sáu mới là phần mà không ai lên kế hoạch. Bạn đọc các DMARC aggregate report, tìm ra vấn đề alignment mà trước đó không biết là mình đang gặp, phát hiện forwarder làm hỏng SPF, rồi chuyển policy sang p=quarantine và sau đó sang p=reject. Giai đoạn này quyết định việc self-hosting có trở thành công việc thường lệ hay trở thành thứ khiến bạn thấy khó chịu.

Sau đó, công việc ổn định ở khoảng một giờ mỗi tháng: cập nhật package, xác minh certificate đã gia hạn thay vì mặc định rằng nó đã được gia hạn, kiểm tra restore từ backup, xem disk tăng trưởng thế nào và tra cứu một blocklist.

Rồi sẽ có một tuần mà bạn không thể lên lịch trước. Một địa chỉ bị đưa vào blocklist vì việc bạn không làm. Một receiver lớn thay đổi rule và mail của bạn lại vào spam. Mail đang nằm trong queue không có nghĩa là đã mất: mặc định Postfix sẽ retry một message bị deferred trong 5 ngày, theo thiết lập maximal_queue_lifetime = 5d, nên một outage kéo dài vài giờ chỉ làm tăng độ trễ và không gây hậu quả nào khác. Một outage kéo dài cả tuần thì sẽ làm mất mail.

Backup MX record không phải câu trả lời tốt như vẻ ngoài của nó. Các sending server vốn đã tự retry trong nhiều ngày, nên một secondary server chỉ làm nhiệm vụ queue thường không mang lại nhiều lợi ích. Tệ hơn, nếu secondary server nhận mail cho domain của bạn mà không biết những địa chỉ nào tồn tại, nó sẽ nhận cả mail gửi đến các địa chỉ không tồn tại rồi bounce mail đó về các sender bị giả mạo. Khi đó backup của bạn trở thành nguồn phát tán backscatter. Hãy dành công sức cho việc monitoring và cho một quy trình restore mà bạn đã thực sự kiểm thử.

Hãy đánh giá toàn bộ hệ thống bằng câu hỏi bạn sẽ áp dụng cho mọi thứ khác trên máy chủ: việc tự sở hữu hệ thống này có mang lại cho bạn thứ mà bạn không thể mua không? Với mailbox và archive, câu trả lời thường là có. Với việc gửi mail đến người nhận bên ngoài, câu trả lời thường là không. Đây cũng là tiêu chí dùng để sắp xếp phần còn lại trong danh sách những thứ đáng self-hosting trong 2026.

FAQ

Tôi có thể tự host email nếu nhà cung cấp VPS chặn port outbound 25 không?

Có, để nhận mail và gửi mail qua relay. Mail inbound đến server của bạn qua port 25, và việc chặn outbound không ảnh hưởng đến phần này. Mail outbound sẽ đi qua một relay đã xác thực trên port 587, là port các nhà cung cấp thường không chặn. Khi port 25 bị đóng, bạn không thể gửi mail trực tiếp đến các mail server khác, vì việc gửi mail giữa các server theo quy ước diễn ra trên port 25. Kiểm tra bằng nc -vz gmail-smtp-in.l.google.com 25. Nếu lệnh treo rồi timeout, port đã bị chặn.

Tại sao mail của tôi vào spam dù SPF, DKIM và DMARC đều pass?

Cơ chế xác thực chứng minh ai đã gửi message. Nó không chứng minh message đó được mong muốn. Pass cả 3 cơ chế giúp bạn chuyển từ trạng thái chưa xác định sang đã xác định. Sau đó, mail server nhận sẽ chấm điểm dựa trên reputation của IP address và domain. Sender mới thường chưa có reputation. Hãy xây dựng reputation bằng cách gửi lượng mail nhỏ mà người nhận thực sự chờ đợi trong vài tuần. Sau đó xác nhận bản ghi PTR khớp với mail hostname theo cả 2 chiều. Kiểm tra cả nội dung mail có tự tạo thêm điểm phạt hay không, chẳng hạn dùng link shortener hoặc tracking domain lạ.

Tôi có cần một IP address riêng cho self-hosted mail server không?

Có, nếu gửi mail outbound trực tiếp. Mail server cần một address có bản ghi PTR do bạn kiểm soát và có reputation chỉ thuộc về bạn. Địa chỉ VPS vốn đã là dedicated theo nghĩa này. Tuy nhiên, bạn không kiểm soát được lịch sử của address đó hoặc các địa chỉ cùng network block. Nếu relay mail outbound, các address của relay sẽ mang reputation. Address của bạn chỉ cần chấp nhận các kết nối inbound.

Chuyển địa chỉ mail chính sang self-hosted server có an toàn không?

Hãy chuyển từng giai đoạn thay vì cut-over một lần. Giữ mailbox hiện tại hoạt động, thêm server của bạn làm đích thứ 2, rồi forward một bản sao sang đó trong vài tuần. Trong thời gian này, đọc các DMARC report và xác nhận mail đi được theo cả 2 chiều. Chỉ thay đổi bản ghi MX sau khi mail thử nghiệm đã đến đúng trong 1 tuần. Sự cố khiến nhiều người hối tiếc là cut-over làm mất mail inbound. Phần inbound không thể khôi phục lại.

Setup nhỏ nhất để vẫn kiểm soát mail của tôi là gì?

Dùng server của bạn để lưu mailbox và archive, còn mail outbound được chuyển qua một relay đã xác thực trên port 587. Bạn sở hữu data và domain, đồng thời tránh hoàn toàn vấn đề reputation. Chi phí đổi sang phương án khác vẫn thấp, vì relay chỉ cần thay đổi 1 dòng cấu hình và 1 SPF entry. Sau này thay relay thường chỉ mất một buổi chiều.