# Cấu hình PTR cho mail server: reverse DNS là gì và cách đặt

> Cấu hình PTR cho mail: reverse DNS là gì, vì sao Gmail, Yahoo, Outlook kiểm tra, cách đặt PTR trên từng nhà cung cấp cloud và cách kiểm tra.

Source: https://zopanel.net/vi/blog/reverse-dns-ptr-mail-server  
Updated: 2026-10-21

## Ý chính

- Bản ghi PTR ánh xạ IP server về một hostname, và server nhận thư mong hostname đó trỏ ngược lại đúng IP ấy.
- Gmail, Yahoo và Outlook.com đều yêu cầu reverse DNS hợp lệ cho IP gửi thư; Gmail trả lỗi 4.7.23 hoặc 5.7.25 khi thiếu.
- PTR do bên sở hữu IP đặt, tức là nhà cung cấp VPS, không phải nơi bạn mua tên miền hay quản lý DNS.
- Một IP chỉ có một PTR, nên hãy đặt theo tên mail server, không theo từng tên miền khách hàng.

Cấu hình PTR cho mail nghĩa là IP của server có một bản ghi PTR trỏ về một hostname thật, ví dụ `mail.example.com`, và hostname đó lại trỏ ngược về đúng IP ấy. Gmail, Yahoo và Outlook.com đều kiểm tra điều này với mọi IP gửi thư, và Gmail giới hạn tốc độ hoặc từ chối thư từ IP không có PTR. Bạn đặt PTR ở nhà cung cấp VPS hoặc cloud, vì họ sở hữu dải IP, chứ không phải ở nơi đăng ký tên miền.

Bài này đi sâu hơn phần PTR trong bài [email bị vào spam](/vi/blog/email-going-to-spam): reverse DNS hoạt động thế nào, các nhà cung cấp hộp thư lớn yêu cầu chính xác điều gì, đặt PTR ở đâu trên từng nhà cung cấp cloud, cách kiểm tra và những lỗi vẫn hay gặp.

## Bản ghi PTR là gì?

DNS thông thường ("xuôi") chuyển tên thành IP: `mail.example.com` có bản ghi A là `203.0.113.10`. Reverse DNS làm ngược lại. IP được viết đảo dưới một tên miền đặc biệt, `10.113.0.203.in-addr.arpa`, và tên này có bản ghi PTR với giá trị là một hostname.

Điểm quan trọng: vùng `in-addr.arpa` của một IP do bên được cấp khối IP đó quản lý. Với VPS, đó là nhà cung cấp. Bạn tạo bao nhiêu bản ghi A trong zone DNS của mình cũng được, nhưng chỉ nhà cung cấp mới đổi được PTR của IP họ cấp, thường qua một ô trong trang quản trị hoặc qua ticket hỗ trợ.

**Forward-confirmed reverse DNS (FCrDNS)** là bước kiểm tra mà server nhận thư thực sự làm. Họ tra PTR của IP đang kết nối, sau đó tra bản ghi A (hoặc AAAA) của tên nhận được, và mong thấy lại IP ban đầu. [Tài liệu rDNS của Hetzner](https://docs.hetzner.com/dns-console/dns/general/reverse-dns/) mô tả đúng như vậy. Ý tưởng này đã có từ lâu: [RFC 1912](https://www.rfc-editor.org/rfc/rfc1912.html) từ năm 1996 đã viết "Make sure your PTR and A records match" và cảnh báo nhiều dịch vụ sẽ không làm việc với máy chủ không được đăng ký DNS đúng cách.

## Vì sao nhà cung cấp hộp thư kiểm tra reverse DNS?

Spam từ lâu đến từ máy tính gia đình bị chiếm quyền và server dùng một lần, với reverse DNS chung chung hoặc không có. Một PTR khớp là tín hiệu rẻ cho thấy có người vận hành IP đó như mail server thật. Các nhà cung cấp lớn nay đã ghi rõ điều này vào quy định:

| Nhà cung cấp | Yêu cầu | Nguồn |
| --- | --- | --- |
| Gmail | Mọi người gửi: IP gửi phải có DNS xuôi và ngược hợp lệ. PTR phải trỏ về hostname có bản ghi A hoặc AAAA trỏ ngược đúng IP gửi | [Email sender guidelines](https://support.google.com/a/answer/81126) |
| Lỗi của Gmail | `4.7.23` (không có PTR hoặc PTR không trỏ ngược đúng: bị giới hạn tốc độ) và `5.7.25` (bị chặn: "Gmail requires that sending IP addresses have a PTR record") | [Sender guidelines FAQ](https://support.google.com/a/answer/14229414) |
| Yahoo | Mọi người gửi: DNS xuôi và ngược hợp lệ; PTR nên có ý nghĩa, không chung chung và phản ánh tên miền của bạn | [Sender best practices](https://senders.yahooinc.com/best-practices/) |
| Outlook.com | "Email servers must have valid reverse DNS records"; thư từ dải IP động có thể bị từ chối | [Postmaster policies](https://substrate.office.com/ip-domain-management-snds/Postmaster/Policies) |

Yêu cầu của Gmail áp dụng cho mọi người gửi từ 1/2/2024, và FAQ của Google cho biết từ tháng 11/2025 Gmail "ramping up its enforcement on non-compliant traffic", tức siết chặt việc xử lý thư không tuân thủ. Nói cách khác, thiếu PTR không còn chỉ là bị trừ điểm spam; thư có thể không được nhận.

Lưu ý PTR gắn với **IP**, còn SPF, DKIM và DMARC gắn với **tên miền**. Bạn cần cả hai. DMARC hoàn hảo không cứu được một IP thiếu reverse DNS, và PTR hoàn hảo cũng không xác thực tên miền của bạn.

## Chọn hostname phù hợp

Trước khi đặt, hãy chọn một hostname làm danh tính mail của server, ví dụ `mail.congtyban.vn`. Sau đó làm cho ba thứ khớp nhau:

1. **Bản ghi A** `mail.congtyban.vn → 203.0.113.10` trong zone DNS của bạn (thêm AAAA nếu gửi qua IPv6).
2. **Bản ghi PTR** `203.0.113.10 → mail.congtyban.vn` ở nhà cung cấp.
3. **Lời chào SMTP (HELO/EHLO)** mà mail server gửi đi. Với Postfix, `smtp_helo_name` mặc định là `$myhostname`, nên hãy đặt `myhostname = mail.congtyban.vn`.

Những câu hỏi hay gặp về tên:

- **PTR có phải khớp với tên miền của khách hàng không?** Không. Mỗi IP chỉ có một PTR, nên trên server gửi thư cho 50 tên miền, PTR đặt theo tên server chứ không theo từng tên miền. Điều quan trọng là FCrDNS và một cái tên không trông chung chung. Lời khuyên "phản ánh tên miền của bạn" của Yahoo được đáp ứng bằng tên miền công ty bạn.
- **PTR trỏ về CNAME được không?** Nên tránh. RFC 1912 yêu cầu PTR trỏ về tên có bản ghi A, không phải bí danh.
- **PTR mặc định của nhà cung cấp có dùng được không?** Thường là không. Tên mặc định kiểu `203-0-113-10.ip.example-cloud.net` trông đúng kiểu tên chung chung mà Yahoo cảnh báo, và hiếm khi trỏ ngược về IP của bạn.

## Cách đặt PTR trên từng nhà cung cấp cloud

Ở hầu hết nhà cung cấp, bản ghi A phải có trước, vì họ kiểm tra nó trước khi chấp nhận PTR tùy chỉnh.

| Nhà cung cấp | Nơi đặt reverse DNS | Ghi chú |
| --- | --- | --- |
| DigitalOcean | Đặt tên Droplet bằng hostname đầy đủ (`mail.example.com`); PTR được tạo từ tên | Không tạo tay được; đổi tên Droplet sẽ cập nhật PTR. Reserved IP không hỗ trợ PTR ([manage DNS records](https://docs.digitalocean.com/products/networking/dns/how-to/manage-records/)) |
| Vultr | Cài đặt instance, mục **IPv4**: thay giá trị reverse DNS mặc định | Theo từng IP ([IPv4 networking](https://docs.vultr.com/products/compute/cloud-compute/networking/ipv4)) |
| Linode (Akamai) | Tab **Network**, menu cạnh IP, **Edit RDNS** | Cần bản ghi A trước; có thể mất tới 48 giờ ([configure rDNS](https://techdocs.akamai.com/cloud-computing/docs/configure-rdns-reverse-dns-on-a-compute-instance)) |
| Hetzner Cloud | Server, **Networking**, sửa mục rDNS cạnh từng IP | Áp dụng cho primary IP và floating IP ([cloud server rDNS](https://docs.hetzner.com/cloud/servers/cloud-server-rdns/)) |
| AWS EC2 | **Elastic IPs**, **Actions**, **Update reverse DNS** | Bản ghi A phải trỏ về Elastic IP; IP sau đó bị khóa vào tài khoản ([reverse DNS for email](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Elastic_Addressing_Reverse_DNS.html)) |
| Google Cloud | **Public DNS PTR record** trên card mạng chính của VM | Cần xác minh sở hữu tên miền trước; chỉ card mạng chính ([create a PTR record](https://docs.cloud.google.com/compute/docs/instances/create-ptr-record)) |
| Microsoft Azure | Thuộc tính `ReverseFqdn` của public IP, qua Azure CLI hoặc PowerShell | Không có trong portal; chỉ IPv4; tên phải trỏ về IP trước ([reverse DNS for Azure services](https://learn.microsoft.com/en-us/azure/dns/dns-reverse-dns-for-azure-services)) |

Hai lưu ý đi kèm bảng. Trên AWS và Google Cloud, hãy dùng IP tĩnh (Elastic hoặc reserved), nếu không, một lần stop rồi start có thể khiến server nhận IP mới không có PTR. Và nhớ rằng chỉ có PTR thì chưa gửi được thư: phần lớn các nhà cung cấp này còn chặn cổng 25 gửi ra theo mặc định. Xem bài [VPS bị chặn port 25](/vi/blog/port-25-blocked-vps) để biết chính sách từng hãng.

Với các nhà cung cấp VPS Việt Nam và nhà cung cấp nhỏ khác, PTR thường được đặt qua ticket. Hãy hỏi trước khi mua: họ có đặt PTR cho IP của bạn không, và mất bao lâu.

## Cách kiểm tra reverse DNS

Trên bất kỳ máy nào có `dig`:

```bash
dig -x 203.0.113.10 +short          # mong đợi: mail.congtyban.vn.
dig +short mail.congtyban.vn A      # mong đợi: 203.0.113.10
```

Hai kết quả phải trỏ về nhau. Nếu lệnh đầu vẫn trả về tên mặc định của nhà cung cấp, thay đổi chưa được lưu hoặc chưa cập nhật. Sau đó kiểm tra lời chào mà server gửi đi:

```bash
postconf myhostname smtp_helo_name
```

Bài kiểm tra cuối cùng là gửi thư thật. Gửi một thư tới địa chỉ Gmail, mở thư, chọn **Hiển thị thư gốc** (Show original) và xem header `Received` từ server của bạn: nó cho biết IP và tên ngược mà Google nhìn thấy.

### Đừng quên IPv6

Nếu server có địa chỉ IPv6, Postfix có thể gửi thư qua IPv6 tới các nhà cung cấp hỗ trợ, trong đó có Gmail. Khi đó hướng dẫn của Gmail yêu cầu cả IPv6 cũng phải có PTR, và có ghi rõ lỗi "Message does not meet IPv6 sending guidelines regarding PTR records and authentication". Hãy đặt PTR (và bản ghi AAAA) cho địa chỉ IPv6, hoặc cho Postfix chỉ gửi qua IPv4 bằng `inet_protocols = ipv4`. Một số nhà cung cấp không hỗ trợ được: ví dụ Azure không hỗ trợ PTR cho public IPv6.

## Những lỗi reverse DNS hay gặp

| Lỗi | Biểu hiện | Cách sửa |
| --- | --- | --- |
| Đặt PTR trong zone DNS của chính bạn | `dig -x` vẫn ra tên mặc định của nhà cung cấp | Đặt trong trang quản trị của nhà cung cấp hoặc qua ticket |
| Thiếu bản ghi A hoặc A trỏ nơi khác | FCrDNS thất bại; Gmail báo `4.7.23` | Thêm `mail.example.com A <IP server>` |
| Tên HELO là `localhost` hoặc hostname mặc định | Bộ lọc spam trừ điểm vì không khớp | Đặt `myhostname` trùng tên PTR |
| Chuyển server sang IP mới | PTR cũ nằm ở IP cũ, IP mới chưa có gì | Đặt PTR cho IP mới trước khi đổi MX |
| Gửi qua IPv6 mà không có PTR | Gmail báo lỗi IPv6 | Thêm PTR cho IPv6 hoặc chỉ gửi qua IPv4 |

Khi chuyển sang server mới, đặt PTR cho IP mới là một trong những bước đầu tiên, trước khi chuyển mail. Bài [chuyển cả server hosting](/vi/blog/move-whole-hosting-server) có bước này trong danh sách kiểm tra.

## Reverse DNS với ZoPanel

ZoPanel không đặt bản ghi PTR, vì ngoài bên sở hữu IP thì không ai đặt được. Việc ZoPanel làm là giúp bạn không bỏ sót. Khi cài mail server, bạn nhập **Mail hostname** phải trỏ về server, và trang Email nhắc bạn yêu cầu nhà cung cấp đặt PTR về tên đó. ZoPanel dùng hostname này cho mail server, và chứng chỉ của panel bao gồm cả tên này, nên phần mềm email kết nối tới `mail.example.com` không bị cảnh báo.

Sau khi đặt xong, bấm **Run check** trong **Mail delivery check**. Công cụ kiểm tra reverse DNS (PTR) và cổng 25 gửi ra, so DNS công khai với các bản ghi MX, SPF, DKIM, DMARC cần có, và tra IP server trên Spamhaus, SpamCop, Barracuda, kèm gợi ý cho từng lỗi. Ghi chú theo từng nhà cung cấp có trong [cài đặt trên nhà cung cấp cloud](/vi/docs/install-cloud-providers), còn mail server được mô tả trong [tài liệu email](/vi/docs/email).

## Kết luận

Reverse DNS là việc mất năm phút, nhưng rất nhiều lỗi email bắt nguồn từ nó. Chọn một hostname mail, tạo bản ghi A, nhờ nhà cung cấp trỏ PTR của IP về tên đó, cho mail server chào bằng đúng tên ấy, rồi kiểm tra cả hai chiều bằng `dig`. Sau đó mới chuyển sang SPF, DKIM và DMARC.

Nếu bạn muốn một panel kiểm tra những điều này giúp mình, [gói Free của ZoPanel](/vi/pricing) có sẵn mail server và Mail delivery check, cho 3 tài khoản hosting, 10 website, không giới hạn thời gian.

## Câu hỏi thường gặp

### Đặt bản ghi PTR cho server ở đâu?

Ở nhà cung cấp sở hữu IP: nhà cung cấp VPS, cloud hoặc server riêng. Phần lớn có ô reverse DNS cho từng IP trong trang quản trị; một số cần gửi ticket. Tạo bản ghi PTR trong zone DNS tên miền của bạn không có tác dụng.

### Gửi qua relay như SendGrid hay Amazon SES thì có cần reverse DNS không?

IP của relay mới là bên chuyển thư, và relay tự quản lý reverse DNS của họ. PTR của server bạn quan trọng với thư mà server gửi trực tiếp. Dù vậy vẫn nên đặt, để không có gì hỏng nếu sau này bạn ngừng dùng relay hoặc có thư đi vòng qua relay.

### Một IP có nhiều bản ghi PTR được không?

Về kỹ thuật DNS cho phép, nhưng hầu hết nhà cung cấp chỉ hỗ trợ một PTR cho mỗi IP, và server nhận thư mong một cái tên rõ ràng. Hãy đặt PTR theo tên server (ví dụ `mail.congtyban.vn`) và để SPF, DKIM, DMARC lo cho từng tên miền khách hàng.

### Đổi PTR mất bao lâu?

Thường vài phút, nhưng tùy nhà cung cấp và bộ nhớ đệm DNS. Linode cho biết cập nhật reverse DNS có thể mất tới 48 giờ. Hãy kiểm tra bằng `dig -x` qua một DNS resolver công khai trước khi thử gửi thư.

### Reverse DNS có ảnh hưởng tới website không?

Trên thực tế là không. Trình duyệt và khách truy cập không kiểm tra PTR. Nó quan trọng với mail server và một số dịch vụ khác có ghi log hoặc kiểm tra tên của IP đang kết nối.