DMARC 마이그레이션 가이드

DMARC 플랫폼을 마이그레이션할 때는 현재 DMARC 플랫폼에서 적용된 구성을 이해하는 것이 중요합니다. 잘 계획된 마이그레이션은 인증과 보고를 강화하면서 이메일이 원활하게 계속 전달되도록 보장합니다. 이 가이드는 DMARC 제공업체(및 관련 DNS 수준 구성) 전환의 각 단계를 안내합니다.

개요

이 가이드는 다음 내용을 다룹니다:

• 계획 및 인벤토리
• 평가 및 준비
• 병렬 설정
• DNS 업데이트 순서
• 테스트 및 모니터링
• 전환 실행
• 마이그레이션 후 검토

이 프로세스를 따르면 모범 사례와의 정렬을 보장하고 자동화 팁을 활용하여 다운타임 제로, 전달성 유지, 보고 및 시행 최대화를 보장할 수 있습니다.

1. 계획 및 인벤토리

이 첫 번째 단계는 현재 설정의 관련된 각 영역을 완전히 이해하고 있음을 보장합니다.

도메인 및 레코드 인벤토리

관련된 모든 도메인을 카탈로그화합니다. 각 도메인에 대해 다음과 같은 현재 DNS 레코드를 수집합니다:

DNS 레코드	예상 레코드 유형	식별 방법
DMARC	TXT 또는 CNAME	호스트 이름에 _dmarc 포함
SPF	TXT	값 섹션이 v=spf1로 시작
DKIM	TXT 또는 CNAME	호스트 이름에 _domainkey 포함
BIMI	TXT	값 섹션이 v=BIMI1로 시작
MTA-STS	TXT	호스트 이름에 _mta-sts 포함
TLS-RPT	TXT	호스트 이름에 _tls-rpt 포함

기존 DMARC 시행(p=none/quarantine/reject)과 보고 주소(rua/ruf)를 문서화합니다. 처음부터 완전한 인벤토리가 중요합니다 – 변경하기 전에 "먼저 기존 보호 서비스의 설정 인벤토리를 만드십시오".

대규모 환경의 경우 스크립트나 DNS 내보내기 도구를 사용하여 이 데이터 수집을 자동화합니다.

발신 소스 식별

• 모든 메일 발신자(온프레미스 서버, 클라우드 서비스, 마케팅 플랫폼 등)와 각 도메인에 대한 현재 SPF include 또는 DKIM 키를 나열
• 모든 하위 도메인 또는 제3자 위임 확인
• 기존 DMARC 보고서 또는 발신 이메일 로그를 사용하여 인벤토리 검증

현재 보고 흐름 검토

• DMARC 집계/실패 보고서 및 TLS-RPT 보고서가 전송되는 위치(이메일 주소) 기록
• 새로운 DMARC Manager 플랫폼으로 전환하여 가시성 유지 계획
• DMARC 레코드는 여러 보고 URI(쉼표로 구분)를 나열하여 이전 및 새 시스템에 동시에 데이터 전송 가능

기준 성능 설정

변경 전에 현재 이메일 메트릭(반송률, 스팸 불만, 전달성) 및 DMARC 준수 수준을 기록합니다. 이를 통해 마이그레이션 후 개선 사항을 확인하고 후퇴가 없음을 보장할 수 있습니다.

2. 평가 및 준비

평가 및 준비 단계는 필요한 경우 롤백할 준비가 되어 있음을 보장합니다. 소규모 환경의 경우 아래 모든 사항이 필요하지 않을 수 있으므로 판단하여 사용하십시오.

기존 DNS 레코드 백업

• 영역 파일 내보내기 또는 저장
• DMARC, SPF, DKIM 선택자, MTA-STS, TLS-RPT 등의 모든 현재 레코드 사본 보관

새 대상 DNS 항목 카탈로그화

DMARC Manager를 열고 각 도메인에 대한 새로운 대상 설정을 캡처합니다. 각 도메인에 대해 DMARC manager에서 필요한 새 레코드가 있는지 확인합니다(레거시 플랫폼에서 다루는 경우):

• DMARC
• SPF
• DKIM
• MTA-STS
• TLS-RPT
• BIMI

예시: DMARC에 대한 설정 지침을 찾을 수 있는 위치의 예시입니다. 다른 설정은 관련 표준 설정 탭으로 전환하여 찾을 수 있습니다.

이해관계자 역할

책임을 할당합니다. DNS를 업데이트하는 사람, 새로운 DMARC Manager를 구성하는 사람, 보고서를 모니터링하는 사람, 문제가 발생할 경우 롤백을 처리하는 사람을 정의합니다. 예를 들어, IT 운영팀이 DNS 변경을 처리하고 보안팀이 보고서를 검토할 수 있습니다. 명확한 역할과 커뮤니케이션 채널이 핵심입니다.

위험 평가 및 일정 계획

• 위험(예: 일시적인 잘못된 구성으로 인한 반송) 식별 및 완화 계획
• 트래픽이 적은 시간대 또는 도메인 그룹별 단계적 마이그레이션 고려
• 많은 도메인의 경우 영향을 제한하기 위해 배치로 마이그레이션(예: 한 번에 100개 도메인)

새 환경 준비

• 팀이 새 플랫폼의 인터페이스/API에 익숙해지도록 함
• 필요한 모든 정보(새 공개 DKIM 키, SPF include 값, 보고 주소, MTA-STS 엔드포인트) 수집
• 새 DMARC Manager의 레코드에 대한 DNS 액세스 권한 확인
• 필요한 DNS CNAME 또는 TXT 항목 기록

DNS TTL 감소

• 변경 몇 일 전에 주요 레코드(DMARC, SPF, DKIM, MTA-STS, TLS-RPT)의 TTL을 낮은 값(예: 300–3600초)으로 감소
• 이는 전환 중 전파 지연을 최소화함
• 안정화 후 높은 TTL 복원 기억

역할 위임 및 문서화

• 계획된 각 변경 사항을 문서화하고 단계별 실행 가이드 준비
• 각 도메인(또는 도메인 템플릿)에 대해 정확한 DNS 편집 및 순서 기록
• 감사 준비된 변경 로그를 유지하여 규정 준수를 입증하고 무엇이 언제 변경되었는지 보여줄 수 있도록 함

3. 병렬 구성

이전 DMARC 플랫폼이 활성 상태인 동안 새로운 DMARC Manager를 병렬로 구성하여 두 시스템이 동시에 이메일을 수신하거나 검증하도록 합니다. 이 "이중 쓰기" 단계는 다운타임이나 사각지대를 방지하며 모든 관련 DNS 항목에 적용됩니다.

새 DMARC Manager에 도메인 추가

1. DMARC Manager에 모든 새 도메인 추가
2. 필요에 따라 DNS 소유권 확인(예: DNS TXT 또는 이메일 통해)

DMARC 구성

1. 새로 추가된 도메인의 초기 DMARC 정책을 현재 게시된 정책으로 설정
2. 이전 DMARC 플랫폼의 보고 주소를 DMARC Manager에 추가
3. 도메인 인터페이스의 '설정 편집'에서 구성:
   • 집계 보고서 섹션에 RUA 주소 추가
   • 실패 보고서 섹션에 RUF 주소 추가

SPF 구성

1. DMARC Manager에서 각 도메인의 SPF TXT 레코드를 현재 게시된 SPF 레코드로 업데이트
2. 모든 include가 DMARC Manager에 나타나는지 확인
3. 'all' 태그가 동일한 정책(일반적으로 ~all)으로 설정되어 있는지 확인
4. 레거시 DMARC 플랫폼의 이전 SPF include는 아직 제거하지 않음

DKIM 구성

1. DKIM 키를 새 DMARC Manager의 DKIM 키 관리에 추가
2. 이전 DKIM 레코드는 아직 제거하지 않음

BIMI 구성

1. 인증서 파일을 DMARC manager로 복사
2. 이미지 파일을 DMARC manager로 복사(정확한 SVG 사용)
3. 이전 BIMI 레코드는 아직 제거하지 않음

MTA-STS 구성

MTA-STS를 사용하는 경우 새 DMARC Manager의 MTA-STS 정책이 이전 정책을 반영하는지 확인합니다.

4. 레코드 업데이트 순서

적절한 DNS 변경 순서로 위험을 최소화합니다. 다음 순서를 따르십시오:

1. TTL 감소(준비에서 완료)
2. 기존 SPF를 새 SPF로 교체:
   • DMARC Manager 지침 따르기
   • 구문 및 조회 제한 확인
   • DNS 전파 대기(몇 분에서 한 시간)
3. 새 DKIM 키 관리 항목 게시:
   • 새 DKIM 관리 NS 레코드 추가
   • 롤백을 위해 이전 DKIM 레코드 활성 유지
4. 기존 DMARC 레코드 교체:
   • DMARC Manager 레코드 사용
   • 구문 확인(도메인당 하나의 DMARC TXT/CNAME)
5. 기존 BIMI 레코드 교체:
   • 이전 BIMI 레코드 제거
   • 새 BIMI NS 레코드 추가
6. MTA-STS DNS 레코드 업데이트
7. TLS-RPT DNS TXT 업데이트
8. 검증 일시 중지(24–48시간)
9. 선택적 시행 조정

검증 단계

각 단계에서 이메일 인증 확인:

• SPF: 도구 또는 테스트 이메일을 사용하여 인증 확인
• DKIM: 테스트 메시지를 보내고 헤더 검증
• DMARC: 공급자 간 분할 보고 확인

5. 테스트 및 모니터링

DMARC 보고서

• 두 서비스 모두 보고서를 수신하는지 확인
• 샘플 보고서 비교
• 정당한 이메일 소스 확인

인증 테스트

• 각 소스에서 테스트 이메일 전송
• SPF=pass 및 DKIM=pass 확인
• 모든 실패 조사

MTA-STS 검증

• 온라인 MTA-STS 검사기 사용
• 외부 도메인 이메일 테스트
• Google Workspace 관리 콘솔 확인(해당되는 경우)

TLS-RPT 검토

• 며칠 후 보고서 검토
• 모든 문제 해결
• 새 공급자가 보고서를 수신하는지 확인

전달성 모니터링

• 반송률 관찰
• 스팸 보고서 모니터링
• 사용자 불만 추적

6. 전환 실행

확인 후 최종 전환 수행:

1. 이전 DKIM 키 제거(48–72시간 후)
2. SPF include 정리
3. DMARC 레코드 최종화:

   v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100

4. MTA-STS 구성 업데이트
5. 이전 TLS-RPT URI 제거
6. 이전 공급자 해제

참고: 백업 계획이 준비된 상태에서 유지보수 기간 동안 제거 수행.

7. 마이그레이션 후 검토

검증 체크리스트

• [ ] 모든 도메인이 DMARC Manager에 보고
• [ ] DMARC Manager 레코드만 남음
• [ ] dig 또는 DNS 관리 인터페이스로 확인

성능 검토

• 이메일 거부율 모니터링
• DMARC 준수 확인
• 마이그레이션 전/후 메트릭 비교

문서화

• 감사 로그 컴파일
• DNS 변경 문서화
• 전환 날짜 기록
• 확인 메시지 저장

정책 개선

• 시행 증가 계획
• p=reject로 이동
• 정기적 SPF 검토

결론

세심한 인벤토리, 준비, 시스템 병렬 실행을 통해 전환 중 다운타임 제로를 보장합니다. 다중 수신자 보고는 전달성과 가시성을 중단 없이 유지합니다. 마지막으로, 이전 레코드 정리와 정책 강화로 마이그레이션을 완료하여 DMARC Manager 하에서 더 강력한 이메일 인증과 포괄적인 모니터링을 남깁니다.