가비아 도메인 메일 연결하고 이전하는 방법

얼마 전 웹사이트를 새 서버로 옮긴 뒤 메일이 안 들어온다는 연락을 받았다. 서버는 정상이었고 원인은 네임서버 변경이었다. 새 DNS에 웹 접속 기록만 옮기고 메일 기록은 빠뜨린 것이다. 가비아 도메인 메일을 연결할 때도 먼저 확인할 것은 요금제보다 현재 메일이 어디로 배달되는지다.

도메인 구매와 메일 계정은 별개다

가비아에서 도메인을 샀다고 사서함이 자동으로 생기지는 않는다. 도메인은 메일 주소에 붙일 이름이고, 받은 메일을 저장하고 발송하는 기능은 별도의 메일 서비스가 맡는다. 하이웍스 같은 메일 상품을 쓸 수도 있고, 이미 사용하는 다른 업체의 메일 서비스에 가비아 도메인을 연결할 수도 있다.

선택하기 전에 계정 수부터 세어보는 편이 낫다. 실제로 로그인할 사람이 2명인데 문의용, 채용용, 운영용 주소마다 유료 계정을 만들 필요는 없을 수 있다. 메일 서비스가 별칭이나 그룹 주소를 지원한다면 여러 주소를 담당자 사서함으로 받을 수 있다. 다만 여러 사람이 같은 사서함에 로그인하는 방식은 누가 답장했는지 추적하기 어렵다. 공동 처리와 권한 관리가 필요하면 그 기능을 지원하는 상품인지 확인해야 한다.

요금표에서는 총 저장 용량보다 계정별 용량, 첨부파일 제한, 모바일 동기화 방식, 보관 기간, 퇴사자 계정 처리 방법을 먼저 본다. 하루 수십 통을 주고받는 작은 팀이라면 비싼 협업 상품의 기능을 다 쓰지 못하는 경우가 많다. 반대로 계약서와 견적서가 계속 쌓이는 팀은 저장 용량과 검색 기능이 운영 비용을 좌우한다.

DNS를 바꾸기 전에 현재 값을 남긴다

메일 연결의 중심은 MX 기록이다. 이 기록이 해당 도메인으로 들어오는 메일을 어느 서비스가 받을지 알려준다. SPF는 발송 서버를 확인하는 데 쓰이고, DKIM과 DMARC는 발신 도메인 인증과 위조 메일 처리에 관여한다. MX만 맞으면 수신은 될 수 있지만, 발송 인증이 빠지면 상대편에서 스팸으로 분류하거나 거절할 수 있다.

가비아 관리 화면에서 도메인의 네임서버와 DNS 기록을 먼저 확인한다. 여기서 자주 헷갈리는 점은 도메인을 가비아에서 샀어도 DNS를 다른 업체가 운영할 수 있다는 것이다. 이 경우 기록을 고칠 곳은 가비아 DNS 관리툴이 아니라 현재 네임서버를 운영하는 업체다. 기존 MX, SPF, DKIM, DMARC 값을 화면 캡처나 문서로 남겨두면 잘못 바꿨을 때 되돌리기 쉽다.

기존 메일을 쓰는 중이라면 새 MX를 추가하기 전에 이전 일정을 잡는다. MX 우선순위를 낮은 숫자로 설정했다고 해서 기존 사서함의 메일이 새 사서함으로 복사되지는 않는다. 이전에 필요한 과거 메일, 연락처, 일정은 별도로 내보내거나 서비스의 이전 도구로 복사해야 한다. 기존 서비스의 계정을 바로 해지하면 전환 도중 늦게 도착한 메일을 확인할 길도 사라진다.

가비아 도메인 메일 연결 순서

하이웍스를 이용한다면 서비스를 신청하고 관리자 화면에서 사용할 도메인과 계정을 만든다. 가비아 등록 도메인이 가비아 네임서버를 쓰는 경우 DNS 기록이 자동 설정될 수 있다. 기존에 다른 메일 업체의 MX가 있거나 타사 네임서버를 사용한다면 수동 설정이 필요하다. 자동 연결 여부를 예상하지 말고 실제 DNS 기록과 서비스의 연결 상태를 확인하는 게 안전하다.

• 현재 네임서버와 모든 메일 관련 DNS 기록을 저장한다.
• 새 메일 서비스에서 안내하는 MX, SPF, DKIM 값을 확인한다. 값은 서비스와 설정 상태에 따라 달라질 수 있으므로 관리자 화면의 안내를 그대로 따른다.
• 실제 DNS 운영 화면에서 기록을 입력하고 저장한다. 가비아 DNS를 사용한다면 My가비아의 서비스 관리에서 DNS 관리툴로 들어갈 수 있다.
• 기존 SPF가 있다면 TXT 기록을 무작정 하나 더 만들지 않는다. 여러 발송 서비스를 쓰는 경우 허용 대상을 검토해 하나의 SPF 정책으로 구성한다.
• 메일 계정을 만든 뒤 외부 메일 주소와 양방향으로 시험한다. 웹메일 접속 성공만으로 수신과 발송이 확인된 것은 아니다.

DNS 변경은 보는 사람의 네트워크에 따라 반영 시점이 다를 수 있다. 가비아 안내에도 네임서버 변경 후 최대 48시간 동안 연결이 불안정할 수 있다고 적혀 있다. 그래서 운영 중인 메일을 이전할 때는 기존 사서함을 일정 기간 유지하면서 양쪽을 확인한다. 전환 직전에는 TTL을 낮춰둘 수 있지만, 변경 직후에 낮춰도 이미 저장된 이전 값에는 바로 적용되지 않는다.

안 될 때는 수신과 발송을 나눠 확인한다

외부에서 보낸 메일만 안 들어오면 현재 공개된 MX가 어느 서비스로 향하는지부터 확인한다. 관리자 화면에 저장한 값과 실제 조회 결과가 다르면 네임서버 위치나 DNS 반영 시간을 살핀다. MX가 맞는데도 실패한다면 새 서비스에 해당 주소의 계정이나 별칭이 만들어졌는지, 저장 용량이 가득 차지 않았는지 확인한다.

받기는 되는데 보내기가 안 되면 발송 서버 설정과 계정 인증을 본다. 보내기는 되지만 상대편 스팸함으로 간다면 SPF, DKIM, DMARC 상태와 발송 경로를 확인한다. 웹사이트의 문의 양식이나 예약 알림이 별도 서버에서 나간다면 그 경로도 발송 정책에 포함돼야 한다. SPF를 수정할 때는 기존에 쓰던 발송 서비스를 빠뜨리지 않도록 주의한다.

장애 문의에는 ‘메일이 안 된다’보다 시간, 보낸 사람과 받는 사람, 반송 메시지, 웹메일에서도 같은지 여부를 함께 남기는 편이 빠르다. 실무에서는 이 네 가지가 있으면 DNS 문제인지, 계정 문제인지, 발송 인증 문제인지 범위를 꽤 줄일 수 있다. 도메인 메일은 처음 연결할 때보다 이전할 때 사고가 많이 난다. 계정 비용을 고르기 전에 현재 기록과 메일 보관 방법을 확인하는 일이 결국 시간을 아낀다.