- 회사 도메인 만료를 막는 등록·갱신 점검표
- 1단계: 실제 등록기관과 등록 계정 찾기
- 2단계: 연락 이메일이 도메인 자체에만 의존하지 않는지 확인하기
조회 1 · 전체 글
대표 이미지: Grigent Guide가 이 글의 주제에 맞춰 AI로 제작한 편집 일러스트입니다. 실제 상품·행사·기관의 촬영 사진은 아닙니다.
회사 도메인 만료를 막는 등록·갱신 점검표
회사 도메인이 만료되면 웹사이트만 멈추는 것이 아닙니다. 같은 도메인을 쓰는 이메일, 비밀번호 재설정, 고객 문의, API 콜백, 인증서 발급도 영향을 받을 수 있습니다. 담당자가 퇴사한 개인 계정으로 등록되어 있거나, 자동갱신이 켜져 있어도 결제카드가 만료되면 알림을 놓치기 쉽습니다.
ICANN은 도메인 등록인이 등록기관과 계약을 맺고 등록·관리·이전·갱신에 관한 권리와 책임을 가진다고 설명합니다. 만료 회복 정책은 등록기관이 만료 전후 알림을 보내는 최소 기준을 두지만, 실제 연락처와 결제수단을 최신 상태로 유지하고 기한 전에 갱신하는 책임까지 대신해 주지는 않습니다.
1단계: 실제 등록기관과 등록 계정 찾기
호스팅 회사와 도메인 등록기관은 같지 않을 수 있습니다. 웹사이트를 운영하는 곳, DNS를 관리하는 곳, 도메인을 등록한 곳을 구분합니다.
ICANN Lookup 같은 공식 조회 도구에서 등록기관과 만료 관련 정보를 확인하고, 내부 결제 영수증과 대조합니다. 계정에 로그인할 수 있는지도 직접 시험합니다.
기록할 항목은 다음과 같습니다.
- 도메인 이름
- 등록기관과 리셀러
- 등록 계정 아이디
- 등록인 조직명
- 등록인·관리·기술 연락 이메일
- 등록 만료일
- 자동갱신 여부
- 결제수단의 끝 네 자리와 만료일
- 계정의 2단계 인증 수단
- DNS 운영사와 네임서버
비밀번호를 평문 표에 적지 않습니다. 비밀번호 관리자에서 담당자별 권한을 부여하고, 비상 접근 방법만 운영 문서에 적습니다.
2단계: 연락 이메일이 도메인 자체에만 의존하지 않는지 확인하기
갱신 알림을 admin@회사도메인으로만 받으면 도메인이 만료되어 메일이 중단된 뒤 복구 안내도 받지 못할 수 있습니다. 조직이 통제하는 별도 비상 이메일을 추가하고, 두 명 이상이 알림을 받을 수 있게 합니다.
퇴사자의 개인 메일이나 한 사람의 휴대전화가 유일한 복구 수단으로 남아 있지 않은지 봅니다. 연락처를 변경할 때 이전·잠금 정책에 영향을 줄 수 있으므로 등록기관의 안내를 확인합니다.
ICANN의 만료 회복 안내는 갱신 알림이 공식 등록정보의 이메일로 전달된다고 설명합니다. 따라서 알림이 오지 않았다는 사실만으로 보호받을 수 있다고 가정하지 말고 등록정보를 정기적으로 검토해야 합니다.
3단계: 자동갱신의 네 가지 실패 지점 점검하기
자동갱신을 켰다고 끝이 아닙니다.
- 결제수단 만료: 카드 유효기간, 한도, 해외결제 차단을 확인합니다.
- 잔액·승인 실패: 법인카드 교체나 비용센터 변경이 있었는지 봅니다.
- 자동갱신 대상 오류: 여러 도메인 중 핵심 도메인이 실제로 켜져 있는지 확인합니다.
- 계정 잠금: 2단계 인증 기기 분실 시 복구할 수 있는지 점검합니다.
갱신 예정일을 만료일과 같게 생각하지 않습니다. 등록기관에 따라 자동갱신 시점과 실패 재시도 방식이 다릅니다. 만료 90일, 60일, 30일, 14일, 7일 전에 달력 알림을 두고, 사람이 실제 상태를 확인하도록 합니다.
4단계: 핵심 도메인은 여러 해 선갱신 검토하기
서비스의 대표 도메인처럼 바꿀 수 없는 자산은 예산과 정책이 허용하는 범위에서 여러 해 미리 갱신할 수 있습니다. 다만 총 등록 가능 기간과 환불·이전 조건은 등록기관 계약을 확인합니다.
유사 철자, 국가도메인, 캠페인용 도메인을 모두 같은 중요도로 관리할 필요는 없습니다. 다음처럼 등급을 나눕니다.
- A등급: 대표 웹·메일·로그인에 사용
- B등급: 리디렉션, 브랜드 보호, API에 사용
- C등급: 종료 가능한 캠페인·실험용
A등급은 다중 담당자, 선갱신, 변경 승인과 비상 연락망을 적용합니다. C등급은 종료일 전에 서비스를 내리고 링크를 정리하는 계획을 둡니다.
5단계: DNS와 이메일 레코드 사본 남기기
도메인을 복구하거나 등록기관을 옮겨도 DNS 설정이 자동으로 따라오지 않을 수 있습니다. 변경 전에 다음 레코드를 내보내거나 문서화합니다.
- A, AAAA, CNAME
- MX
- TXT와 소유권 검증
- SPF, DKIM, DMARC
- API와 서비스별 서브도메인
- 인증서 관련 CAA
- 네임서버와 TTL
기록에는 값뿐 아니라 용도와 담당 서비스를 함께 적습니다. 알 수 없는 TXT 레코드를 임의로 삭제하면 이메일 인증이나 외부 서비스 연결이 깨질 수 있습니다.
DNS 변경 전에는 TTL을 고려하고, 변경 뒤 웹·메일·API를 확인할 테스트 목록을 준비합니다. 복구용 사본에 비밀키를 넣지 않습니다.
6단계: 만료 알림을 받았을 때 피싱부터 구분하기
도메인 만료를 사칭한 결제 메일도 많습니다. 메일의 결제 링크를 바로 누르지 말고 비밀번호 관리자에 저장된 공식 주소나 직접 입력한 등록기관 주소로 로그인합니다.
다음을 확인합니다.
- 메일에 적힌 도메인이 실제 보유 도메인인가?
- 발신자가 실제 등록기관 또는 리셀러인가?
- 계정 화면의 만료일과 메일이 일치하는가?
- 결제 금액과 복구 수수료가 계약에 표시되어 있는가?
- 결제 페이지의 주소와 인증서가 공식 도메인인가?
등록기관이 기억나지 않으면 ICANN Lookup에서 확인합니다. 만료를 이유로 인증 코드나 계정 비밀번호 전체를 요구하는 연락을 신뢰하지 않습니다.
7단계: 이미 만료되었을 때 순서
웹사이트와 이메일이 갑자기 멈췄다면 먼저 DNS 장애와 도메인 만료를 구분합니다. 등록기관 계정과 ICANN 조회에서 상태를 확인합니다.
- 등록기관 공식 지원에 즉시 연락합니다.
- 현재 상태와 갱신·복구 가능 여부, 비용을 확인합니다.
- 결제와 본인확인 절차를 공식 계정에서 진행합니다.
- DNS가 중단되었는지 확인합니다.
- 웹·메일·인증·API 서비스의 복구 순서를 정합니다.
- 고객과 내부 팀에 장애 범위와 우회 연락처를 알립니다.
- 정상화 뒤 만료 원인과 재발 방지 조치를 기록합니다.
ICANN 정책에는 만료 후 갱신 또는 복구와 관련된 최소 절차가 있지만, 실제 제공 기간과 수수료는 등록기관과 계약에 따라 달라질 수 있습니다. 만료된 도메인이 항상 되돌아온다고 가정하면 안 됩니다.
담당자 변경과 퇴사 체크리스트
- 등록 계정이 회사 소유 이메일인지 확인합니다.
- 개인 휴대전화에만 묶인 2단계 인증을 이전합니다.
- 복구 코드와 비상 연락 수단을 재발급합니다.
- 결제 담당자와 기술 담당자를 각각 지정합니다.
- 변경 이력을 남기고 최소 두 명이 접근을 시험합니다.
- 과도한 권한이 있는 이전 담당자의 접근을 회수합니다.
분기별 점검표
- [ ] 등록기관과 등록 계정에 로그인했다.
- [ ] 등록인 연락처와 비상 이메일이 최신이다.
- [ ] 만료일과 자동갱신 예정일을 확인했다.
- [ ] 결제수단과 한도에 문제가 없다.
- [ ] A등급 도메인의 선갱신 기간이 충분하다.
- [ ] DNS·메일 레코드 사본을 갱신했다.
- [ ] 두 명 이상의 담당자가 복구 절차를 안다.
- [ ] 최근 변경과 테스트 결과를 기록했다.
공식 참고 자료
- Information for Domain Name Registrants — ICANN
- Expired Registration Recovery Policy 안내 — ICANN
- ICANN Registration Data Lookup
도메인 종류와 등록기관에 따라 갱신·복구·이전 조건이 다릅니다. 실제 조치는 등록기관의 최신 계약과 공식 계정에 표시된 상태를 기준으로 진행하세요.
확인한 공식 자료
본문은 아래 공개 자료를 바탕으로 정리했습니다. 적용 전 최신 원문과 날짜를 다시 확인하세요.