메일도메인 설정하고 이전하는 방법

얼마 전 웹사이트를 다른 서버로 옮긴 뒤 메일이 끊겼다는 연락을 받았다. 웹페이지는 정상인데 문의 메일만 들어오지 않았다. 새 호스팅에 사이트 파일은 옮겼지만, DNS를 바꾸면서 기존 메일 수신 설정을 빠뜨린 경우였다. 메일도메인을 운영할 때는 웹서버 이전과 메일 이전을 별도 작업으로 봐야 한다.

메일을 어디서 받을지 먼저 정한다

메일도메인은 회사나 사이트 이름으로 된 주소를 쓰기 위한 기반이다. 도메인만 등록한다고 사서함이 생기지는 않는다. 메일을 저장하고 읽을 서비스가 필요하고, DNS의 MX 레코드가 그 서비스로 수신 메일을 안내한다. 웹호스팅의 메일 기능, 별도 메일 서비스, 직접 운영하는 서버 중에서 고르면 된다.

직원 5명이 각자 2GB씩 보관한다면 기본 사서함 용량은 10GB다. 첨부파일과 퇴사자 메일 보관분을 감안해 30%를 더 잡으면 약 13GB부터 검토할 수 있다. 다만 용량만 보지 말고 계정 수, 한 통당 첨부파일 제한, 발송량 제한, 백업과 복원 방법을 같이 확인해야 한다. 문의 메일 몇 통을 받는 작은 사이트라면 비싼 서버가 필요하지 않을 때가 많다.

메일 때문에 VPS를 새로 두는 선택은 신중해야 한다. 직접 운영하면 저장 공간 외에도 보안 업데이트, 스팸 차단, 발송 IP 평판, 역방향 DNS, 장애 대응을 맡아야 한다. 특히 서버 업체가 발송 포트를 제한하거나 역방향 DNS 변경을 지원하지 않으면 설치를 마쳐도 외부 발송이 막힐 수 있다. 운영할 사람이 따로 없다면 계정 수에 맞는 메일 서비스를 쓰는 편이 대체로 수월하다.

DNS에서는 수신과 발송 설정을 구분한다

MX는 들어오는 메일의 목적지를 정한다. SPF는 어떤 서버가 해당 도메인 이름으로 메일을 보낼 수 있는지 선언한다. DKIM은 발송 메일에 서명을 붙여 수신 측이 변조 여부를 확인하게 한다. DMARC는 발신자 주소의 도메인과 SPF 또는 DKIM 인증 결과가 맞는지 검사하고, 실패한 메일의 처리 방침을 알린다. 네 설정은 역할이 다르다.

처음 설정할 때 흔한 실수는 MX만 넣고 발송 인증을 빼는 것이다. 이 경우 받기는 되는데 보낸 메일이 스팸함에 들어가거나 거부될 수 있다. 구글의 발신자 안내도 발송 규모에 따라 SPF, DKIM, DMARC 설정을 요구한다. 서비스 관리 화면에서 제공하는 레코드 값을 그대로 확인하고, 실제 발송에 쓰는 서비스가 여러 개라면 모두 목록에 올려야 한다. 쇼핑몰 알림, 문의 폼, 뉴스레터가 각각 다른 곳에서 발송되는 경우가 많다.

SPF 레코드는 같은 이름에 여러 개를 따로 만들지 않는다. 허용할 발송처를 한 레코드에 모아야 하고, 외부 서비스를 계속 추가하면 SPF 조회 한도를 넘을 수도 있다. DKIM은 발송 서비스가 안내하는 선택자와 키를 사용한다. DMARC는 처음부터 강한 차단 정책을 걸기보다 인증 결과를 관찰하는 정책으로 시작해 정상 발송 경로를 확인한 뒤 강화하는 편이 안전하다. 문의 폼 하나를 빠뜨린 채 차단하면 고객에게 보내는 답장까지 실패할 수 있다.

이전할 때는 사서함과 DNS를 함께 옮긴다

메일 이전 전에는 현재 MX, SPF, DKIM, DMARC 레코드를 기록하고 계정·별칭·자동 전달 목록을 뽑아둔다. 사서함의 메일뿐 아니라 연락처와 일정도 사용하는지 확인한다. 새 서비스에 계정을 먼저 만들고 기존 메일을 복사한 다음, 샘플 계정에서 오래된 메일과 첨부파일이 열리는지 검사한다. 복사가 끝났다는 표시만으로 복원이 가능한 상태라고 판단하면 위험하다.

DNS 변경 하루나 이틀 전에는 MX의 TTL을 300초 정도로 낮출 수 있다. 다만 이미 저장된 이전 TTL이 남아 있을 수 있어 변경 직후 모든 발신 서버가 새 MX를 보는 것은 아니다. 그래서 기존 메일 서비스를 바로 해지하지 않고 며칠 더 유지한다. 변경 당일에는 기존 사서함과 새 사서함을 모두 확인하고, 늦게 들어온 메일은 한 번 더 복사한다.

도메인의 네임서버까지 바꾸는 이전이라면 특히 주의해야 한다. 새 DNS에 웹사이트 주소만 등록하고 메일 레코드를 누락하면 웹은 열려도 메일은 끊긴다. 실제로 사이트 이전 사고에서 자주 보는 모습이다. 변경 전후의 DNS 레코드를 항목별로 대조하고, 외부 계정에서 보내기·받기를 각각 시험한다. 같은 도메인 계정끼리만 주고받는 테스트로는 외부 수신 장애를 놓칠 수 있다.

장애가 나면 메일이 멈춘 지점부터 찾는다

메일이 안 온다면 먼저 외부에서 보낸 시험 메일의 반송 메시지가 있는지 확인한다. 이어 MX가 의도한 서비스를 가리키는지, 새 사서함이 존재하는지, 저장 용량이 찼는지 본다. DNS가 맞는데도 한 사람에게만 안 들어오면 계정·별칭·필터 설정을 확인할 차례다. 전체 수신 장애와 특정 계정 장애를 구분하면 확인 범위가 빨리 좁혀진다.

보내기만 실패한다면 발송 서비스의 오류 기록과 수신 측 반송 사유를 먼저 읽는다. SPF·DKIM 인증 결과, DMARC 일치 여부, 발송량 제한을 순서대로 확인한다. 직접 운영하는 서버라면 발송 포트, 서버의 역방향 DNS, IP 평판도 살펴야 한다. 오류 문구 없이 설정을 반복해서 바꾸면 원래 정상인 경로까지 깨뜨리기 쉽다.

백업은 메일 서비스가 제공한다는 말만 듣고 끝내지 않는다. 계정 삭제나 잘못된 동기화까지 되돌릴 수 있는지, 보관 기간은 얼마인지, 필요한 사서함 하나만 복원할 수 있는지를 확인해야 한다. 중요한 계정은 주기적으로 별도 보관하고 실제로 한 통을 복원해 보는 편이 낫다. 메일도메인 운영에서 비용을 아낄 곳은 서버 사양일 수 있지만, 확인 절차와 복원 수단까지 줄이면 작은 장애도 오래 간다.