도메인 DNS 관리 화면에서 PTR 레코드를 추가하면 안 되나요?

안 됩니다. 역방향 DNS는 도메인을 호스팅하는 곳이 아니라 IP 주소를 가진 쪽의 것입니다. 내 IP의 in-addr.arpa 존은 클라우드·호스팅 업체나 ISP에 위임되어 있으므로 PTR도 그쪽에서 설정해야 합니다.

PTR 레코드에는 어떤 값을 넣어야 하나요?

mail.example.com처럼 내가 관리하는 호스트명이고, 그 이름의 A(또는 AAAA) 레코드가 같은 IP를 가리켜야 합니다. 메일 서버가 HELO/EHLO에서 밝히는 이름과 같게 맞추세요.

FCrDNS가 무엇인가요?

정방향 확인 역방향 DNS(Forward-confirmed reverse DNS)입니다. IP의 PTR이 가리키는 이름을 다시 조회했을 때 A나 AAAA 레코드에 원래 IP가 들어 있어야 합니다. Gmail은 발신자에게 이를 요구하고, 다른 수신 서버도 많이 확인합니다.

Google Workspace나 Microsoft 365를 쓰는데 역방향 DNS를 설정해야 하나요?

아닙니다. 메일은 제공자의 서버에서 나가고, 그 서버의 역방향 DNS는 제공자가 관리합니다. PTR은 내가 직접 메일을 보내는 IP에만 설정합니다.

역방향 DNS(PTR) 설정: 누가 관리하고 어디서 설정하나

역방향 DNS란

일반 DNS는 이름을 주소로 바꿉니다. mail.example.com → 203.0.113.10. 역방향 DNS는 반대 방향으로, DNS 트리의 특별한 영역에 있는 PTR 레코드를 씁니다. IPv4는 주소를 거꾸로 써서 in-addr.arpa 아래에, IPv6는 16진수 한 자리씩 거꾸로 써서 ip6.arpa 아래에 둡니다.

$ dig +short -x 203.0.113.10
mail.example.com.

# 같은 조회를 풀어 쓰면
$ dig +short PTR 10.113.0.203.in-addr.arpa
mail.example.com.

웹 트래픽은 역방향 DNS를 신경 쓰지 않습니다. 메일은 다릅니다. 수신 서버는 접속한 모든 IP의 PTR을 조회하고, 이를 발신자에 대한 가장 먼저 보는, 가장 값싼 신호로 씁니다. Gmail의 발신자 가이드라인은 발송 IP에 PTR 레코드가 있고 그 이름이 다시 같은 IP로 조회될 것을 요구하며, 이를 통과하지 못한 메일은 5.7.25 오류로 거부합니다. 다른 메일 서비스는 이만큼 명시하지 않지만, PTR이 없거나 일반적인 기본값이면 거의 어디서든 불리하게 작용합니다.

내가 해야 하는 일인가

내가 책임지는 IP에서 메일이 나갈 때만입니다. Postfix나 Exim을 돌리는 VPS·클라우드 인스턴스, 사내 Exchange 서버, 메일 장비, 호스팅 업체의 전용 IP 같은 경우입니다.

Google Workspace, Microsoft 365, 또는 Amazon SES·SendGrid·Mailgun 같은 발송 서비스로 보낸다면 메일은 그들의 IP에서 나가고 역방향 DNS도 그들이 관리합니다. 웹사이트 IP에 PTR을 넣어도 달라지는 것은 없습니다. 그런 메일이 스팸함으로 간다면 원인은 다른 곳, 대개 SPF·DKIM·DMARC에 있습니다.

메일이 실제로 어느 IP에서 나가는지 보려면 Gmail 주소로 메일을 보내고 “원본 보기”에서 Google이 붙인 첫 Received: 줄을 읽으세요. from mail.example.com (mail.example.com. [203.0.113.10]) 형태입니다. 대괄호 안의 주소가 PTR이 필요한 주소입니다. 괄호 안에서 주소 앞의 이름이 Google이 찾은 PTR이고, from 바로 뒤의 이름은 내 서버가 HELO에서 밝힌 이름입니다.

도메인 DNS 업체에서 설정할 수 없는 이유

가장 많이 헷갈리는 부분입니다. 도메인의 DNS 업체는 example.com에 대해 권한이 있습니다. 10.113.0.203.in-addr.arpa에 대해서는 권한이 없습니다. 이 존은 주소를 가진 쪽의 체인을 따라 위임됩니다. 지역 인터넷 레지스트리가 대역을 ISP나 클라우드 업체에 넘기고, 그 업체가 역방향 존을 운영합니다. PTR은 거기서 만들어야 합니다.

누가 관리하는지 직접 볼 수 있습니다.

$ dig +noall +answer +authority SOA 10.113.0.203.in-addr.arpa
113.0.203.in-addr.arpa. 3600 IN SOA ns1.hosting-provider.example. hostmaster.hosting-provider.example. 2026100701 7200 3600 1209600 3600

SOA에 나온 존 이름과 네임서버가 누구의 시스템인지 알려 줍니다. 거의 항상 클라우드나 호스팅 업체이고, 업체가 내 주소의 PTR을 설정하는 입력란이나 API를 제공합니다. 일부 DNS 관리 화면에 “PTR” 레코드 유형이 있지만, 거기 추가한 레코드는 아무도 조회하지 않습니다.

예외가 두 가지 있습니다. 조직이 레지스트리에서 IP 대역을 직접 할당받았다면, 역방향 존의 네임서버를 레지스트리에 등록하고 다른 존처럼 직접 운영합니다. ISP가 /29 같은 작은 대역을 줬다면 RFC 2317의 CNAME 방식으로 역방향 항목을 내 네임서버에 위임해 주거나, 요청하면 PTR을 대신 설정해 줍니다.

PTR에 넣을 값

메일 서버용 호스트명 하나를 정하세요. 보통 mail.example.com이나 smtp.example.com입니다. 그리고 세 가지를 일치시킵니다.

PTR: 203.0.113.10 → mail.example.com
정방향 레코드: mail.example.com → 203.0.113.10 (내가 관리하는 내 도메인 존의 A 레코드)
HELO/EHLO 이름: 서버가 접속할 때 밝히는 이름. Postfix에서는 myhostname(발신 HELO에 기본으로 쓰임), Exim에서는 primary_hostname입니다.

앞의 두 가지가 함께 정방향 확인 역방향 DNS(FCrDNS)이고, 수신 서버가 실제로 검증하는 부분입니다. 세 번째는 대부분의 수신 서버가 엄격하게 요구하지는 않지만, 자기를 localhost.localdomain이나 server1이라고 밝히면서 PTR은 다른 이름인 서버는 침해된 기계와 똑같아 보입니다. 맞추는 데 비용이 들지 않습니다.

몇 가지 원칙:

IP 하나에 PTR 하나. DNS는 여러 개를 허용하지만, 수신 서버는 그중 하나를 고르고 어느 것을 고를지는 내가 정할 수 없습니다.
내가 메일을 보내는 도메인, 적어도 내가 가진 도메인의 이름을 쓰세요. PTR이 모든 메일의 From: 도메인과 같을 필요는 없고, 여러 도메인의 메일을 호스팅한다면 같을 수도 없습니다. 다만 실제로 조회되는 진짜 이름이어야 합니다.
가정용처럼 보이는 이름은 피하세요. ec2-203-0-113-10.ap-northeast-2.compute.amazonaws.com이나 203-0-113-10.static.isp.example 같은 업체 기본값도 조회는 되지만, IP 모양의 이름을 관리되지 않는 기계나 일반 사용자 기기의 신호로 보는 수신 서버가 있습니다.

정방향 A 레코드를 먼저 만드세요. 여러 업체가 그 이름이 이미 해당 IP로 조회되지 않으면 PTR 설정을 거부합니다.

주요 업체별 설정

업체 콘솔은 자주 바뀝니다. 아래 이름은 찾아야 할 항목이지, 보장된 메뉴 경로가 아닙니다.

AWS EC2. 역방향 DNS는 자동 할당 공인 IP가 아니라 탄력적 IP(Elastic IP)에만 설정할 수 있습니다. 콘솔에서는 EC2 → 탄력적 IP → 주소 선택 → 작업 → 역방향 DNS 업데이트입니다. CLI로는:

aws ec2 modify-address-attribute --allocation-id eipalloc-0abc1234 --domain-name mail.example.com
aws ec2 describe-addresses-attribute --allocation-ids eipalloc-0abc1234 --attribute domain-name

AWS는 mail.example.com이 이미 그 탄력적 IP로 조회되는지 확인합니다. 별개로, EC2는 기본적으로 외부 25번 포트 발신을 제한합니다. 인스턴스가 메일을 직접 전달하려면 먼저 AWS에 이 제한 해제를 요청해야 합니다.

Microsoft Azure. 공인 IP 리소스에 reverse FQDN을 설정합니다.

az network public-ip update --resource-group my-rg --name my-mail-ip --reverse-fqdn mail.example.com.

Azure는 그 이름이 해당 IP(또는 공인 IP의 Azure DNS 이름)로 조회되는지 확인하고, 공인 IP에 DNS 이름 레이블이 먼저 있어야 한다고 요구할 수 있습니다. Azure도 여러 구독 유형에서 외부 25번 포트를 막습니다.

Google Cloud. PTR은 VM 외부 IP의 액세스 구성에서 설정합니다. 콘솔이나 gcloud compute instances update-access-config의 --public-ptr-domain 옵션을 씁니다. 도메인 소유 확인을 요구할 수 있습니다. 참고로 Compute Engine은 외부 주소의 25번 포트로 나가는 연결을 막으므로, GCE VM은 보통 메일을 직접 전달할 수 없고 발송 서비스를 거쳐야 합니다.

DigitalOcean은 Droplet 이름으로 PTR을 설정합니다. Droplet 이름을 mail.example.com 같은 전체 호스트명으로 바꾸면 PTR이 따라갑니다. Hetzner, Vultr, Linode/Akamai 등 대부분의 VPS 업체는 IP 주소나 네트워크 화면에 역방향 DNS 입력란이 있습니다. Linode도 AWS처럼 정방향 레코드가 먼저 있어야 합니다.

ISP 기업 회선, 코로케이션. 국내 통신사 기업 회선을 포함해 대개 셀프 서비스 화면이 없습니다. IP와 원하는 호스트명을 적어 고객센터나 담당 영업에 요청하세요. 업체가 확인할 수 있도록 A 레코드는 미리 만들어 두세요.

IPv6를 잊지 마세요

다 설정하고 나서 많은 사람이 걸리는 부분입니다. 서버에 IPv6 주소가 있고 수신 서버도 IPv6를 지원하면 MTA는 보통 IPv6를 우선합니다. IPv4 PTR은 완벽한데 IPv6 주소에는 PTR이 없고, Gmail로 가는 메일이 IPv6에서 역방향 DNS 오류로 반송됩니다.

메일을 보내는 IPv6 주소에 PTR(과 일치하는 AAAA 레코드)을 설정하거나, IPv6 발신을 끄세요. Postfix라면:

# /etc/postfix/main.cf
inet_protocols = ipv4

그다음 systemctl restart postfix. 장기적으로는 IPv6 역방향 DNS를 제대로 설정하는 것이 낫지만, 업체가 내 IPv6 대역에 PTR을 지원해야 가능합니다.

결과 확인

dig +short -x 203.0.113.10          # → mail.example.com.
dig +short A mail.example.com       # → 203.0.113.10
dig +short -x 2001:db8::25          # IPv6로 보낸다면

양방향이 일치해야 합니다. dig -x가 여전히 이전 값을 돌려준다면 이전 응답의 TTL을 보세요. 캐시는 TTL이 끝날 때까지 이전 값을 들고 있고, 변경을 게시하는 데 시간이 걸리는 업체도 있습니다. 역방향 존의 네임서버에 직접 물어보면(위 SOA에 나온 서버로 dig -x 203.0.113.10 @ns1.hosting-provider.example) 원천에서 변경이 반영됐는지 알 수 있습니다.

역방향 DNS 조회는 내 네트워크 밖에서 이 왕복을 확인합니다. IPv4·IPv6 주소의 PTR, 그 이름이 같은 주소로 다시 조회되는지, 이름으로 보아 어느 호스팅 업체인지 보여 줍니다. 호스트명을 넣으면 먼저 주소를 조회한 뒤 확인합니다. 이메일 점검에 IP를 넣으면 PTR과 그 주소의 블랙리스트 상태를 함께 보여 줍니다. 마지막으로 Gmail로 테스트 메일을 보내 첫 Received: 줄의 괄호 안, 주소 옆에 내 호스트명이 나오는지 확인하세요.

역방향 DNS가 맞는데도 메일이 거부된다면 다음은 주소의 평판(메일 서버 블랙리스트 조회와 해제)과 SPF·DKIM·DMARC(이메일 전달률 가이드)를 보세요.

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.