도메인 DNS 이전과 메일 유지: MX·SPF·DKIM·DMARC 대조표

AI Editter

웹사이트는 새 서버에서 잘 열리는데 메일이 오지 않거나 스팸으로 분류된다면 DNS 이전에서 웹 레코드만 복사했을 수 있습니다. A·AAAA·CNAME 외에 메일 수신과 발신 인증에 필요한 레코드를 대조해야 합니다.

네임서버 변경은 웹 호스팅 이전과 별개입니다. 도메인의 권한 DNS를 바꾼다면 기존 영역 전체를 확인하고, 메일 사업자가 요구한 정확한 값이 새 DNS에도 존재하는지 검증합니다.

역할이 다른 네 가지 레코드

레코드	확인할 역할	흔한 누락
MX	수신 메일 서버와 우선순위	대상·우선순위
SPF TXT	허용한 발신 서버	다른 발신 서비스 include
DKIM	발신 서명의 공개키	selector별 TXT 또는 CNAME
DMARC TXT	인증 정렬·처리 정책·보고	_dmarc 레코드

SPF나 DKIM이 존재한다는 사실과 DMARC가 통과한다는 것은 다릅니다. DMARC는 표시 From 도메인과 인증 도메인의 정렬을 포함해 평가합니다. 개념과 레코드는 Cloudflare 메일 인증 안내와 사용하는 메일 사업자의 공식 설정을 함께 확인합니다.

이전 전 레코드 원본을 보관

기존 DNS 영역을 내보내고 관리자 화면과 사업자 설정을 대조합니다. 자동 스캔이 모든 레코드를 찾았다고 가정하지 않습니다. DKIM selector처럼 이름을 알아야 조회할 수 있는 값이 있습니다.

메일 외에 자동 검색, 인증용 TXT, 발신 서비스 검증 CNAME, MTA-STS·TLS 보고 등 사용하는 항목도 포함합니다. TTL과 프록시 여부, MX 대상의 주소 해석도 기록합니다.

SPF는 같은 이름에 여러 정책 레코드를 추가해 병합하는 방식으로 처리하지 않습니다. 실제 발신 서비스 목록을 하나의 유효한 정책으로 관리하고 조회 제한과 문법을 확인합니다. 이전 작업 중 승인되지 않은 발신 범위를 추가하지 않습니다.

새 권한 DNS를 직접 조회한 뒤 전환

다음은 조회 형식 예시입니다. 도메인, 새 권한 서버, DKIM selector는 실제 값으로 바꿉니다.

dig @ns-new.example.net example.com MX +noall +answer
dig @ns-new.example.net example.com TXT +noall +answer
dig @ns-new.example.net selector1._domainkey.example.com TXT +noall +answer
dig @ns-new.example.net selector1._domainkey.example.com CNAME +noall +answer
dig @ns-new.example.net _dmarc.example.com TXT +noall +answer

DKIM은 제공자에 따라 TXT 또는 CNAME을 사용합니다. 값이 길어 여러 문자열로 표시되는 TXT는 단순 화면 줄바꿈과 실제 값 손상을 구분합니다. 기존 권한 서버에도 같은 질의를 보내 값과 우선순위를 비교합니다.

메일 서버 호스트가 HTTP용 프록시 대상으로 잘못 설정되지 않았는지 확인합니다. Cloudflare를 쓴다면 메일 관련 호스트의 DNS 전용 여부와 지원 서비스를 공식 DNS 레코드 안내에 맞춰 검토합니다.

TTL을 낮추면 즉시 바뀌는 것은 아니다

기존에 캐시된 응답은 이전 TTL 동안 남을 수 있습니다. 변경 직전에 TTL을 낮췄다고 모든 리졸버가 즉시 새 값을 읽지는 않습니다. 사전 준비 시간을 두고, 네임서버 위임과 레코드 TTL을 구분해 계획합니다.

DNSSEC가 활성화돼 있다면 DS와 새 제공자의 서명키 관계도 별도로 확인합니다. 메일 레코드가 정확해도 DNSSEC 검증 실패로 도메인 전체 조회가 실패할 수 있습니다.

실제 메일로 수신과 발신을 각각 시험

시험	확인
외부 사업자 → 회사 메일	수신 여부·지연·반송
회사 메일 → 외부 사업자	도착·스팸 분류·헤더
업무 시스템 발송	승인된 발신 서비스 인증
별칭·그룹·자동 전달	기존 업무 경로 유지
첨부 메일	내용과 첨부 정상

수신 메일의 원본 헤더에서 신뢰할 수 있는 수신 서버의 Authentication-Results를 확인합니다. SPF, DKIM, DMARC 결과와 정렬 도메인을 보고, 단순히 TXT 조회가 성공했다는 이유로 발신 인증이 정상이라고 판단하지 않습니다.

실패하면 반송 코드와 시각, 발신 경로를 기록합니다. 모든 발신 서비스가 같은 인증 구성을 쓰지 않을 수 있으므로 웹사이트 폼, CRM, 뉴스레터 등도 각각 시험합니다.

되돌릴 때도 캐시와 발신 데이터를 고려

문제가 생기면 잘못된 레코드를 정확히 수정하는 것이 네임서버 전체를 왕복하는 것보다 빠를 수 있습니다. 원인을 확인한 뒤 복구 범위를 선택합니다. 변경을 반복하면 서로 다른 캐시가 남아 진단이 더 어려워질 수 있습니다.

최종 이전 기록에는 기존·새 레코드, 위임 변경 시각, 권한 DNS와 공개 리졸버 조회, 실제 메일 결과를 보관합니다. 웹사이트 접속 성공과 메일 이전 성공을 각각 확인해야 전체 DNS 이전을 완료했다고 볼 수 있습니다.