도메인 이메일 호스팅 이전: DNS 전환 점검

도메인 이메일 호스팅을 이전할 때 대상에 계정과 별칭을 다시 구성하면 주소를 유지할 수 있습니다. 하지만 DNS 수정이 잘못되면 메일 흐름이 끊기거나 두 서버로 나뉠 수 있습니다. 메시지 복사와 DNS 전환은 구분해서 계획해야 합니다.

전체 이전 계획은 비즈니스 이메일 안내서를 먼저 참고하세요. 여기서는 소유하고 관리하는 도메인의 호스팅 변경을 다룹니다. 등록기관 이전이나 개인 제공업체 주소의 이전이 아닙니다. 원본을 사용하는 동안 MX, SPF, DKIM과 DMARC를 검증합니다.

대상 계정을 준비하고 데이터를 사전 복사하며 TTL을 미리 낮추고 새 인증 기록을 게시한 뒤 수신을 전환하세요. 단계별 검증으로 위험을 줄일 수 있지만 중단 없는 이전을 보장하지는 않습니다.

도메인 이메일 이전이란 무엇인가요?

같은 도메인과 허가된 주소를 새 호스트에 구성하고 수신 경로와 발신 인증을 변경하는 작업입니다. DNS 시간차, 기존 의존성과 실제 발신자에 맞지 않는 인증도 데이터 복사와 함께 점검해야 합니다.

보통 세 가지 작업을 포함합니다.

1. 이미 생성한 대상 계정에 기존 데이터를 복사합니다. 다음 항목의 대상 준비는 실제로 복사 전에 수행해야 합니다.
2. 같은 계정, 별칭과 전달을 대상에 구성하고 검증합니다.
3. 관리하는 도메인의 새 수신 호스트로 DNS를 전환합니다.

대상과 사전 복사를 검증한 후 MX를 변경하세요. 준비 없이 전환하면 수신이 실패하거나 잘못된 곳에 저장될 수 있습니다. SPF나 DKIM을 빠뜨리면 인증에 영향을 주지만 실제 거부와 분류는 수신자가 결정합니다.

준비, 전환과 안정화로 나누세요. TrekMail은 Starter 이상에서 Gmail, Outlook, Yahoo, iCloud와 기타 IMAP 원본 가져오기를 소개합니다. IMAP은 지원되는 메시지와 상태를 복사하지 연락처, 캘린더나 계정 규칙까지 복사하지는 않습니다. 현재 지원과 허용된 인증을 확인해야 합니다. 설명된 직접 가져오기는 대화형 OAuth가 아니며 앱 비밀번호는 인증과 제공업체 정책에 따르므로 다른 지원 도구가 필요할 수 있습니다. 상세 복사 절차는 imapsync를 참고하세요.

단계 1: 전환 24-48시간 전에 준비

먼저 대상 계정을 만들고 새 인증을 게시하며 TTL을 낮추고 원본을 유지한 채 복사합니다. 이 준비 시간은 계획 예시일 뿐 모든 캐시가 갱신된다는 보장은 아닙니다.

1. 기존 메일 기록의 TTL 낮추기

DNS 서비스가 허용한다면 300초 같은 TTL을 선택할 수 있습니다. 전환 전 24-48시간은 예시이며 실제로는 기존 TTL과 캐시를 고려해야 합니다. 오 분 전에 낮춘다고 기존 응답이 사라지지는 않습니다.

dig example.com MX

dig example.com TXT

dig example.com TXT _dmarc.example.com

기존 TTL이 3600이나 86400이면 저장된 응답은 이전 만료 시점까지 남을 수 있습니다. 금요일 4:55 PM에 시작하지 말고 미리 준비하세요. 마지막 명령은 독립적인 DMARC 조회로 신뢰할 수 없으며 루트 TXT 조회도 DKIM 선택자 전체를 확인하지 않습니다. 정확한 이름을 권한 DNS 서버와 관련 리졸버에서 따로 확인합니다.

2. MX 변경 전에 메시지 복사

원본 서비스가 살아 있는 동안 IMAP 가져오기를 수행하세요. 설명된 TrekMail 기능은 이미 생성한 대상 계정에 백그라운드로 복사합니다. 로그인, 저장 한도와 시험 복사를 검증한 뒤 확장하세요.

도메인을 추가하되 수신을 일찍 전환하지 말고 대상 계정을 만든 후 대시보드에서 가져오기 시작 절차를 따르세요. TrekMail은 IMAP 서비스로 소개되며 POP3는 지원하지 않는다고 설명됩니다. POP 자체가 연속성을 깨뜨리는 것은 아니지만 서버에 없는 로컬 메일이 있을 수 있으므로 따로 백업합니다.

3. 모든 대상 주소와 기능 준비

전환 전에 계정, 별칭, 전달과 캐치올을 구성하세요. 예외 주소도 소유자의 허가, 서비스 정책과 실제 라우팅을 검증해야 합니다.

예를 들어 billing@, support@, careers@, noreply@, 캐치올 계정과 창업자 Gmail로 가는 기존 전달 하나가 있습니다. 하나를 놓치면 해당 주소로 메일이 올 때까지 문제가 드러나지 않을 수 있습니다.

많은 브랜드와 고객 도메인을 관리한다면 중앙 운영이 도움이 될 수 있습니다. 실제 한도와 조건은 확인하세요. 규모가 문제라면 여러 도메인 이메일 호스팅 안내서를 참고합니다.

4. 이전 전에 SPF 병합

기존 시스템이 잠시 정상적인 답장이나 자동 메시지를 보낼 수 있습니다. 실제 평가되는 주소의 사용 중인 발송 서비스에 권한을 유지하세요. RFC 7208의 한도 10은 중첩 평가를 포함해 실행되는 DNS 관련 메커니즘과 수정자에 적용되며 모든 패킷이나 캐시 조회 수를 뜻하지 않습니다.

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

이 예는 실제 제공업체에 맞게 검증해야 하며 사용하지 않는 Google에 권한을 주면 안 됩니다. Free는 외부 SMTP, 유료 요금제는 관리 SMTP를 소개하지만 현재 경로와 조건을 확인하세요. 이름마다 SPF 정책 하나를 게시하고 SPF와 무관한 TXT는 함께 둘 수 있습니다.

5. DKIM 사전 게시와 DMARC 검토

새 선택자를 사용하고 새 시스템의 서명 전에 공개 키를 게시하세요. 기존 시스템이 서명하는 동안 기존 선택자를 덮어쓰면 안 됩니다. 일시적인 p=none 변경은 소유자가 승인한 위험 판단일 때만 선택합니다. 인증과 정렬이 맞으면 기존 정책을 유지할 수 있으며 모니터링 정책도 수신이나 무위험을 보장하지 않습니다.

아직 없는 DKIM 선택자 조회 결과도 RFC 2308의 SOA 관련 규칙에 따라 부정 캐시에 저장될 수 있습니다. 미리 게시하고 응답을 확인하세요. 다른 기록의 TTL을 낮춰도 이 캐시가 지워지지는 않습니다.

단계 2: 도메인 수신 전환

권한 DNS 서버에서 준비된 기록을 검증하고 대상 및 복사가 준비된 후 MX를 변경하세요. 외부 리졸버와 실제 계정의 수신·발신을 시험합니다. 필요한 시간은 환경에 따라 다릅니다.

이 작업에서는 필요한 전환만 수행하세요. 관련 없는 DNS 정리를 동시에 하면 원인 조사와 복구가 어려워질 수 있습니다.

1. 새 서비스 준비 상태 확인

MX를 일찍 바꾸지 않고 게시할 수 있는 인증과 도메인 상태를 먼저 확인합니다. Active와 녹색 표시는 실제 메일 시험이 아니며 전환 전 모든 항목을 충족할 수 없는 경우도 있습니다. TrekMail에 도메인 추가를 참고하세요. 원문은 2026년 삼월의 예로 다음 기록을 제시하며 현재 계정 값과 정책을 확인해야 합니다.

MX   @              mail.trekmail.net.   priority 10
TXT  @              v=spf1 include:spf.trekmail.net -all
TXT  dkim._domainkey  [unique value from dashboard]
TXT  _dmarc         v=DMARC1; p=quarantine;

기존 Google Workspace, Microsoft 365, Zoho, cPanel이나 등록기관 MX는 계획된 전환 시 교체합니다. 혼합 MX는 우선순위와 대체 경로로 동작하지 고정된 균등 분배가 아닙니다. 두 호스트가 모두 수락하면 서로 다른 시스템에 메일이 도착할 수 있습니다.

2. MX 교체 후 낮은 TTL 유지

관리하는 도메인의 기존 MX 집합을 새 것으로 교체합니다. 300 같은 값을 잠시 유지할 수 있지만 기존 캐시와 SMTP 재시도는 계속 고려해야 합니다. 원본 수신과 반복 변경분 동기화를 유지하세요.

dig @8.8.8.8 example.com MX

dig @1.1.1.1 example.com MX

공용 리졸버 두 곳 이상과 권한 서버를 확인하고 외부 계정에서 도메인으로, 새 계정에서 밖으로 시험합니다. 몇 번의 정상 조회로 전체 전환을 입증할 수는 없습니다.

3. IMAP 앱 설정 점검

최신 설정에서 IMAP imap.trekmail.net의 포트 993는 TLS, SMTP smtp.trekmail.net의 465는 암시적 TLS, 587는 STARTTLS를 사용합니다. 인증서 체인과 호스트 이름, 전체 메일 주소와 계정 비밀번호를 확인하세요. 대시보드 비밀번호가 아닙니다. IMAP·SMTP 앱 설정을 참고하세요.

“보낼 수 있지만 받을 수 없다”는 증상만으로 DNS라고 단정하지 마세요. 계정, 별칭, 저장 한도, 필터, 폴더 매핑, 캐시, 앱과 네트워크를 실제 시험과 로그로 함께 조사합니다.

단계 3: 이전 후 첫 72시간 관찰

첫 72시간은 관측 예이지 완료 기한이 아닙니다. 수신과 발신 인증, 기존 경로를 확인하고 늦게 온 오래된 날짜의 메일, 이동과 지원되는 플래그를 반복 반영하세요. 검증된 종료 전까지 기존 SMTP, 관리용 동기화와 복구를 유지합니다.

십 분 뒤 완료처럼 보여도 드문 문제는 며칠 뒤 드러날 수 있습니다. 자주 실행하지 않는 업무도 점검하세요.

1. 기존 제공업체를 쓰는 경로 확인

CRM, 스캐너, WordPress 양식, 청구 도구와 지원 시스템이 기존 경로로 발송할 수 있습니다. 헤더와 로그를 조사하고 권한이나 정책을 줄이기 전에 해당 연동을 수정하세요.

2. 수신뿐 아니라 인증과 정렬 확인

서버가 수락했다고 인증 성공이나 받은편지함 배치가 증명되는 것은 아닙니다. 신뢰할 수 있는 수신 결과를 확인하세요. 전달로 SPF가 실패해도 표시 From과 정렬된 유효한 DKIM 서명 또는 통과하고 정렬된 SPF가 있으면 DMARC가 통과할 수 있습니다.

외부 전달을 유지한다면 도메인 이메일을 Gmail로 전달에서 영향과 실제 경로를 확인하세요.

3. 검증 후 겹치는 권한 정리

기존 서비스가 정상 발송에 쓰이지 않을 때 SPF 권한을 제거합니다. 기존 DKIM 기록은 대기열과 검증할 전달 서명이 필요로 하는 동안 유지하세요. 안정화 후 TTL을 3600으로 높이는 예를 검토할 수 있습니다. 일시적 p=none을 선택했다면 조사, 시험과 복구 계획에 따라 정책을 다시 검토합니다.

정리도 이전의 일부지만 고정 시간이 지났다고 이전 인증을 안전하게 없앨 수 있는 것은 아닙니다.

기존 방식과 통제된 방식 비교

호스팅 변경은 등록기관 이전이 아닙니다. 대상을 준비해 복사하고 수신을 계획적으로 전환하며 인증을 검증하세요. 도구는 오류 발견에 도움이 될 수 있지만 직접 시험을 대체하지 않습니다.

TrekMail은 자체 도메인, IMAP, 캐치올, Nano의 외부 SMTP 또는 유료 요금제의 포함 SMTP, 전달, 이전과 API를 소개합니다. 원문 가격은 Starter 월 $3.50부터이며 Free, Starter, Pro, Agency와 Enterprise가 있습니다. 현재 기능과 한도, 조건은 TrekMail 가격에서 확인하세요. 요금제 모델이 무제한 추가를 뜻하지는 않습니다.

최종 도메인 이전 체크리스트

대상을 만들고 TTL을 미리 낮춘 뒤 데이터를 복사하고 SPF를 병합하며 DKIM을 게시하세요. DMARC를 판단하고 필요한 MX 전환 및 실제 시험을 수행합니다. 반복 변경분과 검증 후 기존 구성을 정리하세요.

1. 24-48시간을 계획 예로 삼되 기존 캐시 만료를 고려.
2. 이미 생성하고 시험한 대상 계정에 IMAP 데이터 복사.
3. 계정, 별칭, 전달과 캐치올을 전환 전에 구성 및 검증.
4. 사용 중인 발송 서비스를 이름별 SPF 정책 하나로 병합.
5. 새 DKIM 선택자 게시와 실제 서명 시험.
6. 위험에 맞고 허가된 경우에만 일시적 p=none 선택, 자동 완화는 불필요.
7. 도메인 상태와 실제 수신·발신 확인.
8. 관리하는 도메인의 활성 MX를 계획된 시점에 교체.
9. 실제 수신·발신 시험과 변경분 반복.
10. 72시간 뒤 진행 상황을 검토하되 검증된 경우에만 기존 인증 정리 및 정책 강화.

설정 하나를 바꾸는 작업이 아니라 통제된 인프라 변경으로 접근하세요. 위험을 줄여도 연속성을 보장하지는 않습니다. 이후 운영에는 TrekMail의 소개된 여러 도메인 요금제, 공유 저장 공간과 IMAP 이전을 현재 조건 안에서 검토할 수 있습니다.