MX를 바꾸면 기존 메일함의 과거 메일도 같이 옮겨지나요?

옮겨지지 않습니다. MX는 앞으로 들어올 메일의 경로만 바꿉니다. 과거 메일은 IMAP 동기화나 서비스가 제공하는 이관 도구로 따로 복사해야 하며, MX를 바꾸기 전에 먼저 시작하는 편이 좋습니다.

전환 중에 메일이 유실될 수 있나요?

순서를 지키면 유실은 거의 없습니다. MX를 바꾸기 전에 새 서비스에 모든 계정과 별칭을 만들어 두고, 바꾼 뒤에도 기존 서비스를 며칠 살려 두면 양쪽 중 어디로 들어와도 받게 됩니다. 유실이 생기는 전형적인 경우는 새 쪽에 없는 주소로 메일이 들어와 바로 반송되거나, 기존 계정을 너무 빨리 해지한 경우입니다.

IMAP 동기화는 얼마나 걸리나요?

메일 수와 첨부 용량, 양쪽 서비스의 속도 제한에 달려 있습니다. 계정당 메일함이 큰 경우 며칠이 걸릴 수 있으므로 전환일 1~2주 전에 1차 동기화를 시작하고, 전환 직후에 변경분만 다시 동기화하는 방식이 안전합니다.

전환 뒤 기존 서비스는 언제 해지하면 되나요?

MX 전환 뒤 최소 1~2주, 여유가 있으면 한 달 정도 유지하는 것을 권합니다. 캐시가 긴 발신 서버가 한동안 옛 MX로 보낼 수 있고, 동기화에서 빠진 폴더나 공유 사서함이 나중에 발견되는 경우가 있습니다. 해지 전에 전체 메일을 내려받아 보관해 두면 더 안전합니다.

전환을 되돌릴 수 있나요?

MX를 옛 값으로 되돌리면 수신 경로는 돌아옵니다. 다만 전환 뒤 새 서비스로 들어온 메일은 옛 메일함에 없으므로 따로 옮겨야 하고, 기존 계정을 이미 해지했다면 되돌릴 수 없습니다. 그래서 기존 서비스를 살려 두는 기간이 사실상 되돌릴 수 있는 기간입니다.

메일 서비스 옮기기

메일 서비스를 옮기면서 메일을 잃지 않는 핵심은 순서입니다. 새 서비스에 계정과 별칭을 모두 만들고 과거 메일을 먼저 복사한 다음, 마지막에 MX를 바꾸고, 바꾼 뒤에도 기존 서비스를 며칠 살려 둡니다. MX를 먼저 바꾸면 새 쪽에 없는 주소로 온 메일이 바로 반송되므로 이 순서를 뒤집지 않는 것이 중요합니다.

전체 작업은 보통 2주 정도의 일정으로 잡습니다. 메일함 용량이 크면 동기화에 걸리는 시간 때문에 더 길어집니다.

옮기기 전에 파악할 것

계정 목록: 실제 메일함이 있는 주소 전부 (퇴사자 계정과 비활성 계정 포함)
별칭과 그룹 목록: info, sales 같은 공용 주소와 각각을 누가 받는지
계정별 메일함 용량과 메일 수, 그중 실제로 옮길 범위
공유 사서함, 캘린더, 연락처, 자동 전달 규칙, 부재 중 자동 응답 설정
도메인 목록: 메일을 받는 도메인과 서브도메인이 둘 이상인지
이 도메인 이름으로 메일을 보내는 외부 시스템 (알림 메일, 청구서 발송, 마케팅 도구)

마지막 항목을 빼먹으면 전환 뒤 그 시스템의 메일만 인증에 실패합니다. 현재 SPF 레코드에 들어 있는 include 목록을 그대로 적어 두면 빠진 경로를 찾기 쉽습니다.

이관 절차

새 서비스에 계정과 별칭을 모두 만듭니다
도메인 소유 확인을 마치고, 위에서 적은 계정과 별칭을 전부 생성합니다. 이 시점에는 MX를 건드리지 않으므로 메일은 계속 기존 서비스로 들어옵니다. 공용 주소는 계정이 아니라 별칭으로 만들 수 있는지 확인하고, 퇴사자 주소도 전달용 별칭으로 남겨 둡니다.
MX 레코드의 TTL을 낮춥니다
현재 MX의 TTL을 300초로 내립니다. 원래 값이 86400초였다면 하루가 지나야 기존 캐시가 모두 만료되므로, 전환일보다 최소 하루, 여유를 두면 이틀 앞서 해 둡니다. 이 작업은 수신 경로를 바꾸지 않아 위험이 없습니다.
과거 메일을 IMAP으로 1차 동기화합니다
대부분의 메일 서비스는 기존 서버에서 메일을 끌어오는 이관 도구를 제공합니다. 계정별로 기존 서비스의 IMAP 접속 정보(서버 주소, 포트 993, 계정과 비밀번호 또는 앱 비밀번호)를 넣고 동기화를 시작합니다. 기존 서비스에서 2단계 인증을 쓰고 있으면 앱 비밀번호를 먼저 발급해야 합니다.
계정 수가 많으면 관리자 권한으로 일괄 이관하는 기능을 쓰고, 없으면 메일 클라이언트에 양쪽 계정을 IMAP으로 등록해 폴더를 복사하는 방법도 됩니다. 받은 편지함 외에 보낸 메일, 아카이브, 사용자 폴더가 모두 넘어갔는지 확인합니다.
전환 시점을 정하고 구성원에게 알립니다
금요일 저녁이나 연휴 전날처럼 메일이 적은 시간을 고릅니다. 다만 문제가 생겼을 때 대응할 사람이 있는 시간이어야 하므로, 아무도 없는 시점은 피합니다. 구성원에게는 전환 시각, 새 서비스 접속 주소, 첫 로그인 방법, 휴대전화 메일 앱 재설정 방법을 미리 안내합니다.
MX를 새 서비스 값으로 교체합니다
기존 MX 레코드를 지우고 새 서비스가 안내한 값을 넣습니다. 두 서비스의 MX를 동시에 두면 수신이 갈라지므로 한쪽만 남깁니다. 우선순위와 값 형식은 MX 레코드 이해하기를 참고하세요.
```
dig +short MX example.com    # 새 서비스 호스트만 보이면 교체 완료
```
SPF와 DKIM, DMARC를 새 서비스 기준으로 다시 겁니다
SPF의 include를 새 서비스 값으로 바꾸고, 기존 서비스 include는 기존 발송을 멈춘 뒤에 지웁니다. DKIM은 새 서비스에서 키를 새로 만들고 그 선택자로 공개키를 게시한 다음 관리 화면에서 서명을 켭니다. 선택자가 다르므로 기존 DKIM 레코드를 지우지 않아도 충돌하지 않습니다. DMARC 레코드는 그대로 두되, 정책이 p=reject 라면 전환 기간에는 일시적으로 p=quarantine 으로 낮춰 두는 편이 안전합니다. 각 레코드의 값과 검증 방법은 SPF, DKIM, DMARC 설정에 있습니다.
2차 동기화로 변경분을 맞춥니다
1차 동기화 이후 기존 메일함에 들어온 메일을 한 번 더 동기화합니다. 이관 도구는 보통 중복을 건너뛰므로 같은 설정으로 다시 실행하면 됩니다. 이 단계를 빼면 1차 동기화 이후부터 MX 전환까지의 메일이 새 메일함에 없습니다.
송수신과 인증을 확인합니다
외부 메일 계정과 양방향으로 테스트하고, 받은 메일 원본의 Authentication-Results 헤더에서 spf=pass, dkim=pass, dmarc=pass 를 확인합니다. 공용 주소와 그룹 주소도 각각 한 번씩 보내 봅니다. 자동 전달 규칙과 부재 중 응답은 새 서비스에서 다시 설정해야 하는 경우가 많습니다.
MX TTL을 되돌립니다
며칠 안정적으로 동작하면 TTL을 3600초 정도로 올립니다.

기존 서비스를 며칠 더 살려두는 이유

MX를 바꿨어도 전환 직후 모든 메일이 새 서비스로 오지는 않습니다. 세 가지 이유 때문입니다.

캐시가 긴 발신 서버. TTL을 무시하거나 자체 기준으로 오래 캐시하는 구현이 있습니다. 하루 이틀은 옛 MX로 보내는 서버가 남습니다.
큐에 쌓여 있던 메일. 전환 전에 옛 서버로 들어갔다가 아직 배달되지 않은 메일이 있습니다.
동기화 누락. 공유 사서함, 잘 쓰지 않는 사용자 폴더, 용량 제한으로 건너뛴 큰 첨부가 나중에 발견됩니다.

그래서 기존 서비스의 계정은 MX 전환 뒤 최소 1~2주 유지하고, 그 기간에는 담당자가 양쪽 메일함을 함께 확인합니다. 해지 전에 계정별 메일 전체를 내려받아 보관해 두면 나중에 누락을 발견해도 복구할 수 있습니다.

되돌릴 수 있는 지점

전환 작업은 단계마다 되돌릴 수 있는 정도가 다릅니다. 어디까지 안전한지 미리 알고 진행하면 판단이 빨라집니다.

단계	되돌리기	방법과 주의점
새 쪽 계정 생성, TTL 인하	완전히 가능	수신 경로를 바꾸지 않습니다. 언제든 중단해도 영향이 없습니다.
IMAP 1차 동기화	가능	복사일 뿐 기존 메일함은 그대로입니다. 새 쪽 메일함을 비우면 됩니다.
MX 교체	가능하지만 시간이 듦	옛 MX 값으로 되돌리면 수신은 돌아옵니다. 그 사이 새 쪽으로 들어온 메일은 따로 옮겨야 합니다.
SPF, DKIM 재설정	가능	레코드 값을 옛 값으로 되돌립니다. 전파에 TTL만큼 걸립니다.
기존 서비스 해지	불가능	메일함 데이터가 삭제됩니다. 해지 전에 전체 내려받기를 먼저 합니다.

사실상 마지막 되돌리기 지점은 기존 서비스 해지 직전입니다. 그 전까지는 MX 값 하나로 양쪽을 오갈 수 있습니다.

전환 뒤 보낸 메일이 스팸함으로 분류되면 평판이 새 발송 경로에서 다시 쌓이는 중일 수 있습니다. 점검 순서는 보낸 메일이 스팸함에 들어갈 때에 정리했습니다. 서비스 선택 자체를 다시 검토하려면 회사 도메인으로 메일 쓰기를 보시고, 도메인 자체를 다른 등록기관으로 옮기는 작업과 겹친다면 무중단 이전 준비를 함께 확인하세요.