홈페이지 호스팅을 옮겨도 이메일은 기존 업체에 그대로 둘 수 있습니다. 주의할 시점은 DNS 서비스나 네임서버를 바꿀 때입니다. 메일 기록을 빠뜨리지 않도록 새 사이트가 열리는지, 기존 주소로 수신과 답장이 되는지를 각각 확인하세요.
변경 전후 DNS 대조표 만들기
현재 DNS 영역을 저장하고 MX와 메일 관련 TXT, CNAME의 이름·유형·값을 적어 새 영역과 비교하세요. 문의 양식과 주문 알림이 쓰는 발신 서비스도 홈페이지 담당자에게 확인합니다. 메일 이전을 계획하지 않았다면 메일 설정은 유지하세요. 변경 뒤에는 외부 문의, 답장, 사이트 알림을 시험합니다. 네임서버를 바꾼다고 과거 메일이 복사되지는 않습니다. 두 업체의 MX를 함께 넣어도 직원별로 수신 서비스를 나누지는 못합니다.
업체별 역할부터 구분하세요
도메인 운영에는 등록 업체, DNS 업체, 웹호스팅, 이메일 서비스라는 네 역할이 있습니다. 한 관리 화면에서 모두 구매했더라도 역할은 서로 다릅니다.
등록 업체는 도메인 이름을 갱신하고 DNS 업체는 설정을 보관합니다. 웹호스팅은 사이트를 운영하며 이메일 서비스는 메일을 받고 저장합니다. 따라서 “도메인이 이 업체에 있다”는 말만으로 메일 레코드를 어디에서 바꿔야 하는지는 알 수 없습니다.
작업 전에 실제로 적용되는 DNS 영역의 관리 화면을 찾고 현재 값을 저장하세요. 사이트를 외주 업체가 관리한다면 쇼핑몰, 고객 지원, 결제 알림 등 각 서비스에 쓰이는 기록을 확인합니다.
유지해야 할 기록 알아보기
일반적인 웹사이트는 A, AAAA, CNAME을 사용하고 메일 수신은 MX가 담당합니다. 이메일을 따로 운영할 때는 보통 현재 DNS 영역에서 필요한 기록만 바꾸면 됩니다. 메일 하나를 연결하려고 DNS 전체를 옮겨야 하는 경우는 많지 않습니다.
TXT 레코드에도 도메인 소유 확인이나 발신 설정이 들어갑니다. SPF는 발신 허용 출처, DKIM은 서명 확인, DMARC는 발신 주소의 도메인 확인 방침에 쓰입니다.
값은 사용 중인 서비스에 따라 달라집니다. 직원 메일은 TrekMail을 사용하더라도 쇼핑몰 영수증은 별도 플랫폼에서 보낼 수 있습니다. 두 출처를 모두 고려하세요. 이름이 낯설다는 이유로 레코드를 지우지 말고 메일 DNS 안내에서 용도를 확인합니다.
점검에서 문제가 발견되면
원인을 찾는 동안 기존 호스팅과 메일 접근은 유지하세요. 문의 양식만 실패하면 수신 MX를 바꾸기 전에 앱 발신 설정을 확인합니다. 메일이 어디에도 도착하지 않는다면 현재 기록을 저장한 DNS 영역과 비교하고 담당 업체에 경로 점검을 요청하세요. 이메일 업체가 그대로라면 직원 앱 설정도 보통 유지합니다. 점검과 별도로 계획한 과거 메일 이전이 끝난 뒤 기존 서비스를 해지하세요.
설정 이어가기
함께 읽기
- 웹 호스팅 이메일이 도달률에 만드는 숨은 비용
- 내 도메인에 이메일 설정하기: 로그인은 되지만 메일이 작동하지 않을 때
- 홈페이지가 완성되기 전에 업무용 메일부터 시작하려면
- 회사 이름이 바뀌어도 예전 이메일 주소를 유지하려면?
- 포털 알림은 도착하는데 고객 답장은 안 보여요. 무엇을 확인하나요?