550 5.7.25: Gmail 역방향 DNS(PTR) 거부 해결

문제

Gmail로 보낸 메일이 550-5.7.25와 함께 반송되고, 다음 문구가 그대로 붙어 있습니다: “The IP address sending this message does not have a PTR record setup, or the corresponding forward DNS entry does not point to the sending IP address.” 받은편지함에는 아무것도 도착하지 않았고, SPF·DKIM·DMARC를 아무리 손봐도 소용이 없습니다 — Gmail이 당신의 도메인을 보기도 전에 연결을 거부했기 때문입니다. 이건 도메인 문제가 아니라 IP 문제입니다.

증상

• 반송 메시지에 550-5.7.25와 PTR 레코드 부재 또는 정방향 DNS가 발신 IP와 일치하지 않는다는 문구가 있습니다.
• 2024년 초 이후 시작되거나 악화됐습니다. 구글이 발신자 요건 강제를 강화하면서, 예전엔 그냥 넘어가던 걸 이제 거부하기 시작했습니다.
• SPF·DKIM·DMARC는 다 통과하는데도 Gmail(그리고 종종 Yahoo, Outlook)이 여전히 거부합니다.
• 주력 플랫폼에서 보낸 메일은 도착하는데, 새 VPS·cron 스크립트·갓 띄운 클라우드 인스턴스에서 보낸 메일이 반송됩니다.
• dig -x <발신IP>가 NXDOMAIN, 제공자 기본 호스트명, 또는 전혀 다른 곳으로 해석되는 이름을 돌려줍니다.

550 5.7.25가 실제로 뜻하는 것

코드를 두 개의 사실로 읽으세요. 550은 SMTP 응답(RFC 5321)으로 영구 실패입니다 — 같은 IP에서 동일한 연결을 재시도해도 소용없습니다. 5.7.25는 확장 상태 코드이고, RFC 7372가 이를 정확히 **“Reverse DNS validation failed”(역방향 DNS 검증 실패)**로 정의합니다: 발신 클라이언트의 IP 주소가 수신 측 정책이 요구하는 역방향 DNS 검사를 통과하지 못했다는 뜻입니다.

Gmail이 요구하는 건 단순히 PTR 레코드가 있는가가 아닙니다. FCrDNS — 정방향 확인 역방향 DNS입니다. 두 조회가 서로를 확인해 줘야 합니다:

1. 발신 IP의 역방향 조회(dig -x <ip>)가 호스트명을 담은 PTR 레코드를 돌려준다.
2. 그 호스트명의 정방향 조회(dig A <호스트명>)가 처음의 그 IP로 다시 해석된다.

둘 중 하나라도 없거나, 둘이 서로 다른 주소를 가리키면 왕복이 닫히지 않고, Gmail은 이를 미인증 발신자로 읽습니다. 대형 수신 업체가 이걸 고집하는 이유는 오래되고 단순합니다: 제대로 운영되는 메일 서버는 소유자가 역방향 DNS를 맞춰 설정해 둔 IP 위에 있습니다. 탈취당한 가정용 IP 위의 봇넷 호스트는 거의 그렇지 않습니다. FCrDNS는 이 둘을 갈라내는, 수십 년 된 값싼 신호이고 — 5.7.25는 당신이 그 신호의 잘못된 쪽에 떨어졌을 때 나옵니다.

주요 원인 3가지

1. 발신 IP에 PTR이 아예 없다. 새 VPS나 클라우드 인스턴스는 역방향 DNS가 없거나 제공자 기본값(ec2-…, vps-…, static-…)으로 시작합니다. 어느 쪽도 당신의 메일 호스트를 가리키지 않으니 정방향으로 확인할 대상 자체가 없습니다. 판별: dig -x <ip>가 NXDOMAIN이나 당신이 설정하지 않은 주소를 돌려준다.
2. PTR은 있지만 정방향이 확인해 주지 못한다. 역방향 DNS가 mail.example.com을 가리키는데, mail.example.com은 다른 IP — 이전한 옛 서버, 프록시, CDN 엣지, 실제 발신기 앞의 로드밸런서 — 로 해석됩니다. 역방향은 설정됐지만 정방향이 모순됩니다. 판별: dig -x는 깔끔한 이름을 주는데 dig A <그 이름>이 발신 IP를 돌려주지 않는다.
3. 내가 통제할 수 없는 IP를 쓴다. 공유 호스팅, 공유 SMTP 발신, 또는 컨테이너 플랫폼이 PTR이 제공자 소유라 바꿀 수 없는 IP를 배정합니다. 판별: PTR이 호스트의 일반 이름이고, 지원 티켓은 진전이 없으며, 해결책은 레코드가 아니라 다른 발신 경로다.

DechoNet으로 진단하기

• 역방향 DNS 조회는 발신 IP를 넣으면 그 IP가 해석되는 PTR 레코드를 보여줍니다 — 제공자와 씨름하기 전에 역방향 DNS가 존재하는지, 어떤 호스트명을 주장하는지 가장 빨리 확인하는 길입니다.
• 이메일 진단은 도메인의 SPF·DKIM·DMARC를 한 번에 끌어옵니다. IP 쪽이 깨끗해진 뒤, 도메인 쪽에 두 번째 반송 사유가 숨어 있지 않은지 확인하세요.

해결 체크리스트

• 실제 발신 IP를 찾으세요 — 메일 서버가 밖으로 연결할 때 쓰는 IP로, 반송 메시지의 Received 체인에서 확인합니다. 웹사이트의 A 레코드가 아닙니다. 둘은 대개 다릅니다.
• 역방향 DNS 조회(또는 dig -x <ip>)로 PTR이 존재하고 제공자 기본값이 아니라 당신의 메일 호스트명을 가리키는지 확인하세요.
• dig A <그 호스트명>으로 그것이 정확히 같은 발신 IP로 되돌아오는지 확인하세요. FCrDNS 통과에는 양방향이 일치해야 합니다.
• PTR은 도메인 등록기관이 아니라 IP 소유자 — 클라우드/VPS 콘솔이나 ISP 지원 — 에서 설정하거나 고치세요.
• 메일 서버의 HELO/EHLO 호스트명을 PTR 이름과 일치시키세요. 여기서 어긋나면 같은 평판 검사에 걸립니다.
• 다시 테스트하고, 역방향 존 변경이 전파되도록 24~48시간을 기다린 뒤 여전히 깨졌는지 판단하세요.

에스컬레이션 시점

• PTR을 설정할 수 없는 공유·제공자 잠금 IP라면 레코드와 씨름하지 마세요. 역방향 DNS를 통제할 수 있는 전용 IP를 주는 호스트로 옮기거나, 이미 FCrDNS를 통과하는 IP를 가진 인증된 릴레이로 보내세요.
• PTR과 정방향 확인이 둘 다 맞는데도 Gmail이 여전히 5.7.25를 돌려주면, 전체 반송 메시지를 확보하고 주요 블록리스트에 IP가 올라 있는지 확인하세요 — 이 시점엔 역방향 DNS는 정상이고 문제가 IP 평판으로 옮겨간 것이며, 그건 다른 해결책이 필요합니다.