새 이메일 공급자로 사서함 옮기기: DNS 전환 가이드
공급자 사이에서 사서함 데이터를 옮길 때 매끄러운 전환과 48시간 장애의 차이는 DNS 전략에서 갈립니다. TTL 하나를 잘못 설정하거나 SPF include를 빠뜨리면 영구 반송과 사업 손실이 생길 수 있습니다.
창의성이 필요한 일이 아니라 정확한 기술 작업을 순서대로 수행하는 일입니다. 이 가이드는 전파 시간 관리, SPF/DKIM/DMARC 인증 병합, 새 공급자로의 라우팅을 통해 메시지 누락 위험을 줄이며 사서함 콘텐츠를 옮기는 방법을 설명합니다.
이메일 자체를 옮기는 데이터 이전 과정은 IMAP 동기화 가이드에서 확인하십시오.
사서함을 옮길 때 DNS가 즉시 전파되지 않는 이유
DNS는 분산 캐시 시스템입니다. 레코드를 바꾸면 인터넷 사업자 DNS, Google의 8.8.8.8, 로컬 라우터 같은 재귀 확인자가 Time-To-Live(TTL)를 어떻게 적용하는지에 영향을 받습니다.
TTL이 일반적인 86,400초(24시간)라면 전환 중 하루 동안 라우팅이 나뉠 수 있습니다. 일부 메일은 새 받은편지함에, 일부는 기존 받은편지함에 도착합니다.
롱테일과 네거티브 캐싱
사서함 계정을 옮길 때 다음 두 가지 숨은 요인이 전환을 자주 방해합니다.
- 롱테일: TTL이 낮아도 전 세계 확인자의 약 1-5%는 60분 미만 값을 무시합니다. 전환 후 약 한 시간 동안 이전 공급자로 잔여 트래픽이 갈 수 있다고 예상하십시오.
- 네거티브 캐싱(SOA): 새 DKIM 선택자처럼 아직 없는 레코드를 너무 일찍 조회하면 NXDOMAIN 응답이 SOA 레코드의 최소 TTL, 흔히 1시간 동안 캐시됩니다. 이후 레코드를 게시해도 한동안 보이지 않을 수 있습니다.
1단계: 48시간 전 준비
아직 MX 레코드를 건드리지 마십시오. 먼저 변경을 받아들일 환경을 준비합니다.
1단계: TTL 낮추기(T-minus 48시간)
MX, SPF(TXT), DMARC 레코드를 찾아 TTL을 300초(5분)로 낮춥니다.
최대 24시간인 전파 예상 시간을 줄이는 조치지만, 모든 확인자가 5분 안에 갱신된다는 보장은 없습니다.
dig yourdomain.com MX
# Look for 300 in the TTL column
2단계: SPF 병합(T-minus 24시간)
SPF(RFC 7208)는 도메인을 대신해 발송할 IP를 승인합니다. 전환 기간에는 두 공급자를 동시에 승인해야 합니다.
주의점: SPF는 DNS 조회를 10회로 제한합니다. Google Workspace와 TrekMail처럼 두 공급자를 합치면 이 한도를 넘을 수 있습니다.
해결책: 지원되고 지속적으로 갱신되는 방식이 있을 때만 중첩된 include:를 직접 ip4: 메커니즘으로 바꿔 평면화합니다. 그렇지 않으면 변경된 IP가 반영되지 않을 수 있습니다.
전환용 레코드 예시:
v=spf1 include:_spf.google.com include:spf.trekmail.net -all
TrekMail의 BYO SMTP로 Amazon SES나 SendGrid를 사용한다면 해당 서비스의 SPF 레코드를 포함합니다.
3단계: DKIM 사전 게시
DKIM은 google._domainkey 같은 선택자를 사용합니다. 새 공급자에서는 고유한 선택자, 예를 들어 tm1._domainkey로 키를 만드십시오. 선택자 이름을 재사용하지 마십시오. 새 선택자는 이전 공급자와 충돌하지 않으므로 며칠 전에 게시할 수 있습니다.
4단계: DMARC 완화
DMARC 정책이 p=reject 또는 p=quarantine이라면 전환 최소 24시간 전에 p=none으로 바꿉니다. 전환 초기에는 인증 실패 가능성이 있습니다. p=none은 RUA 보고서에 실패를 기록하면서 DMARC 정책에 따른 거부를 막지만 다른 필터까지 통과를 보장하지는 않습니다. 설정 방법은 Google DMARC 설정 가이드를 참고하십시오.
2단계: 전환 실행
TTL을 낮추고 인증 정보를 병합했다면 새 호스트로 사서함 라우팅을 옮길 차례입니다.
1단계: 권한 DNS와 재귀 DNS 확인
외부 확인 전에 권한 네임서버에 새 레코드가 보이는지 검사합니다.
# Check authoritative nameserver
dig @ns1.provider.com yourdomain.com MX
# Check public recursive resolver
dig @8.8.8.8 yourdomain.com MX
2단계: MX 레코드 업데이트
가능하면 새 MX를 먼저 추가하고 확인한 뒤 기존 MX를 제거하거나 한 번의 변경으로 교체합니다. TrekMail 사용자는 다음 값을 씁니다.
10 mx1.trekmail.net
20 mx2.trekmail.net
TTL은 300초로 유지하고 아직 높이지 마십시오.
3단계: 캐시 비우기와 확인
Windows에서는 ipconfig /flushdns, macOS에서는 sudo dscacheutil -flushcache로 로컬 DNS 캐시를 비웁니다. dig를 다시 실행하십시오. 이 작업은 로컬 캐시만 지우며 외부 확인자의 갱신을 앞당기지는 않습니다.
3단계: 전환 후 안정화
테넌트 귀속 오류 확인(550 5.7.64)
Microsoft 365나 비슷한 제품으로 옮길 때 흔한 문제입니다. 대상의 내부 디렉터리에 도메인이 완전히 구성되지 않으면 Relay Access Denied로 메일을 거부할 수 있습니다. MX를 바꾸기 전에 새 공급자 화면에서 도메인 상태가 Verified 또는 Healthy인지 확인합니다.
DMARC 보고서 모니터링(72시간)
사흘 동안 RUA 보고서를 확인합니다.
- 성공: 새 공급자 IP의 트래픽이 SPF와 DKIM을 통과합니다.
- 실패: 결제 시스템이나 마케팅 플랫폼의 정상 트래픽이 인증에 실패합니다. SPF/DKIM을 즉시 고칩니다.
정리(T-plus 72시간)
트래픽이 안정된 뒤 다음을 수행합니다.
- 이전 공급자가 더 이상 발송하지 않는지 확인한 후 SPF의
include:를 제거합니다. - 이전에 서명된 메시지를 검증할 안전 기간이 지난 뒤 기존 DKIM CNAME/TXT 레코드를 제거합니다.
- TTL을 3,600s(1시간) 또는 86,400s(24시간)로 높입니다.
- DMARC를
p=quarantine또는p=reject로 다시 적용합니다.
사서함 이전 체크리스트 요약
| 시점 | 작업 | 레코드 유형 |
|---|---|---|
| T-48h | TTL을 300s로 낮추기 | MX, SPF, DMARC |
| T-24h | SPF 병합, 두 공급자 승인 | TXT |
| T-24h | 새 DKIM 선택자 사전 게시 | CNAME/TXT |
| T-24h | DMARC를 p=none으로 완화 | TXT |
| T-0 | MX 레코드로 사서함 라우팅 전환 | MX |
| T-0 | 이전 공급자의 발송이 끝날 때까지 SPF 병행 유지 | TXT |
| T+72h | 안전 기간 후 기존 DNS 정리 및 DMARC 적용 | 전체 |
TrekMail로 사서함 이전을 더 간단하게
DNS 수동 관리는 실수하기 쉽습니다. TXT 레코드의 구문 오류 하나로 SPF 정책 전체가 무효가 될 수 있습니다.
소규모 기업
TrekMail은 실시간 DNS 상태 검사를 제공합니다. 대시보드가 권한 네임서버를 조회하고 MX, SPF, DKIM 레코드를 필수 기준과 대조합니다. 구문 오류를 반송 발생 전에 표시할 수 있지만 전 세계 DNS 전파 완료까지 보장하는 것은 아닙니다.
자체 도메인 이메일 설정 방법을 자세히 알아보십시오.
에이전시
50+개 도메인을 관리하려면 표준화가 필요합니다. TrekMail에서는 모든 고객 환경에 일관된 DNS 템플릿을 적용할 수 있습니다. Starter와 Agency의 관리형 SMTP는 IP 평판과 전송 헤더를 처리하므로 해당 경로에서는 복잡한 SPF 평면화나 자체 IP 워밍업 일정이 필요하지 않습니다.
에이전시를 위한 다중 도메인 이메일 호스팅을 살펴보십시오.
| 요금제 | 가격 | DNS 상태 검사 | 관리형 SMTP |
|---|---|---|---|
| Free | $0 (no card) | 예 | 직접 연결만 가능 |
| Starter | $3.50/mo | 예 | 포함 |
| Pro | $10/mo | 예 | 포함 |
| Agency | $23.25/mo | 예 | 포함 + IP 평판 관리 |
모든 유료 요금제에는 14일 무료 체험이 제공되며 카드가 필요합니다. Nano 요금제에는 카드가 필요하지 않습니다.
마무리
새 공급자로 사서함 데이터를 옮길 때 문제는 주로 DNS 전환에서 생깁니다. TTL을 일찍 낮추고 인증 레코드를 병합하며 유지보수 시간에 MX를 바꾸고 72시간 동안 DMARC 보고서를 확인하십시오. 이것이 핵심 절차입니다.
DNS를 직접 조정하는 수고를 덜고 싶다면 TrekMail을 무료로 사용해 보고 대시보드에서 설정을 검증하십시오.
