가이드 · cloudflare dmarc

제품 팀은 Cloudflare DMARC를 어떻게 안전하게 구현해야 하나요?

Cloudflare에서 DMARC를 설정하려면 먼저 보이는 From 도메인으로 발송하는 모든 서비스를 목록으로 만들고, 통제된 메시지에서 SPF 또는 DKIM 정렬을 확인한 다음, 정확한 _dmarc 이름에 TXT 정책 하나를 추가하세요. 보고 모드로 시작하고, 이전 DNS 상태를 보존하고, 권한 있는 응답과 재귀 응답을 검증하고, quarantine이나 reject를 요청하기 전에 집계 보고서를 검토하세요. Cloudflare는 DNS 정책을 호스팅하거나 분석할 뿐이며, 발신자를 정렬 상태로 만들어 주거나 전달을 증명하지는 않습니다.

Cloudflare DNS와 발신자 설정을 분리하기

Cloudflare가 권한 있는 DNS를 운영하는 동안 다른 제공업체가 애플리케이션 이메일을 제출하고 서명할 수 있습니다. 무언가를 수정하기 전에 이 경계를 기록하세요. 영역(zone)은 DMARC TXT 정책을 게시하고, 각 이메일 제공업체는 반송 경로, DKIM 서명 도메인과 셀렉터, 검증, 때로는 보고까지 제어하며, 애플리케이션은 테넌트, 메시지 유형, 수신자, 템플릿, 보이는 From 주소, 제공업체 경로를 제어합니다. 유효한 DNS 레코드가 있어도 승인되지 않은 발신자, 누락된 DKIM 서명, 정렬되지 않은 반송 경로, 테넌트 간 From 값 문제는 고칠 수 없습니다. 프로덕션, 스테이징, 지원, 결제, ID, 모니터링, CRM, 마케팅, 사람이 보내는 메일 시스템을 보이는 From 도메인별로 정리하세요. 각 시스템에 담당자와 롤백 연락처를 지정하고, 적용 강도를 높이기 전에 알 수 없는 보고서 출처를 분류하세요.

수신 측이 평가하는 정책 이름을 조회하기

alerts@notify.example.test에서 온 메일이라면 _dmarc.notify.example.test의 TXT부터 확인하세요. 웹사이트 호스트, 메일 교환기, DKIM 셀렉터, 반송 경로 이름에 실수로 정책을 게시하지 마세요. 현재의 DMARC 검색은 작성자 도메인에 유효한 레코드가 없을 때 해당하는 조직 도메인이나 퍼블릭 서픽스의 정책을 선택할 수 있으므로, 조회한 이름과 선택된 정책 도메인을 모두 기록하세요. Cloudflare를 열기 전에 기존의 권한 있는 응답과 재귀 응답을 조회하세요. 같은 이름에 정책 레코드가 여러 개 있거나, 태그 문법이 잘못되었거나, CNAME이 충돌하면 결과를 사용할 수 없게 될 수 있습니다. 이전 내용, TTL, 리졸버 출력, 담당자, 변경 후 기대값을 확보해 두면 장애 중에 재구성하지 않고도 정확하게 롤백할 수 있습니다.

Cloudflare에서 검토를 마친 TXT 레코드 하나 만들기

올바른 Cloudflare 계정과 영역을 열고 DNS Records로 이동해 Add record를 선택한 다음 TXT를 고르세요. 루트 도메인 정책에는 상대 이름으로 _dmarc를 사용하고, 대상 서브도메인에는 정확한 _dmarc 레이블을 사용하세요. 따옴표가 일관되지 않은 값이 없도록 검토를 마친 값 하나를 입력하세요. Cloudflare 문서에 따르면 따옴표 없이 저장한 새 TXT 내용에는 Cloudflare가 감싸는 따옴표를 추가합니다. 롤아웃과 복구에 맞는 TTL을 고르고, 필요하면 개인정보가 없는 변경 참조를 추가하고, 영역, 이름, 이전 값, 새 값을 확인한 뒤에만 저장하세요. TXT 정책은 DNS 데이터이며 프록시되는 웹 경로가 아닙니다. 호스팅 파트너나 다른 권한 있는 제공업체가 영역을 관리한다면, Cloudflare 대시보드가 권한 있는 곳이라고 가정하지 말고 그쪽에서 변경하세요.

명시적인 결정으로 DMARC 값 구성하기

관찰 단계의 레코드는 v=DMARC1; p=none과 승인된 집계 보고 URI로 시작할 수 있지만, 이는 예시일 뿐 모든 경우에 맞는 값은 아닙니다. 버전을 맨 앞에 두고, 요청할 정책을 의도적으로 정하고, 모든 보고 수신처를 승인하세요. 하위 도메인 정책, 정렬 모드, 비율, 보고 태그는 문서화된 요구 사항과 현재 표준 해석이 있을 때만 검토하세요. 다른 사람의 rua 메일함이 들어 있는 공급업체 샘플을 복사하거나, 문법이 유효하다는 이유로 p=reject로 건너뛰지 마세요. 유효한 레코드는 수신 측에 요청하는 처리 방식을 나타낼 뿐입니다. SPF나 DKIM이 인증에 성공한다는 것, 인증된 식별자가 From 도메인과 정렬된다는 것, 모든 정상 발송 경로를 파악했다는 것, 메시지가 받은편지함에 도착했다는 것을 증명하지 않습니다.

실제 메시지에서 SPF와 DKIM 정렬 검증하기

원본 헤더를 직접 확인할 수 있는 수신자에게, 모든 애플리케이션 경로에서 통제된 예시 메시지를 보내세요. 보이는 From, SMTP MAIL FROM, 발송 IP, DKIM d= 도메인과 셀렉터, Authentication-Results, 제공업체 식별자, 메시지 유형, 환경, 시각을 기록하세요. DMARC는 정렬된 인증 SPF 또는 정렬된 검증 DKIM 서명을 통해 통과할 수 있습니다. SPF는 SMTP 식별자를 평가하며 전달(forwarding) 시 바뀔 수 있고, DKIM은 선택된 내용에 대한 서명을 검증합니다. 둘 다 애플리케이션 승인을 대신하지 못합니다. 하위 도메인과 장애 조치 경로를 포함해 relaxed 또는 strict 정렬을 의도적으로 테스트하세요. 제공업체 API의 접수, 대상 서버의 수락, DMARC 통과, 메일함 도달, 반응은 서로 다른 관찰입니다. 이 상태들을 분리해 두어야 API 호출 성공이나 초록색 정책 표시를 더 강한 전달 증거로 착각하지 않습니다.

대시보드 밖에서 DNS와 보고서 검증하기

저장한 뒤에는 Cloudflare의 권한 있는 네임서버와 서로 독립적인 여러 재귀 리졸버에서 정확한 _dmarc 이름의 TXT를 조회하세요. 원본 응답, 선택된 정책 도메인, TTL, 리졸버, 타임스탬프, 파서 결과를 저장하세요. 사용 가능한 레코드가 정확히 하나인지, v=DMARC1이 맨 앞인지, 필수 값이 유효한지, 보고 URI가 승인되었는지 확인하세요. 예상되는 캐시 기간이 지난 뒤에 반복하세요. 통제된 메시지를 다시 보내고 수신 측 헤더를 확인하세요. Cloudflare 문서는 DMARC Management를 발송 출처와 집계된 SPF, DKIM, DMARC 결과를 볼 수 있는 수단으로 설명하지만, 보고서는 수신 측이 제공하는 지연된 관찰이지 완전한 실시간 전수 조사가 아닙니다. 제공업체 증거와 대조하세요. 리졸버 간 응답이 다르거나, 빈도가 낮은 트래픽이 보이지 않거나, 알 수 없는 정상 출처가 있거나, 통제된 메시지가 정렬되지 않거나, 보고서 볼륨이 예기치 않게 바뀌면 진행을 멈추세요.

Cloudflare DMARC Management도 DNS 변경으로 취급하기

Cloudflare는 DMARC Management를 활성화하면 레코드가 없을 때 만들 것을 제안하거나 기존 rua 태그에 Cloudflare 집계 보고 주소를 추가할 수 있다고 설명합니다. 이 제안된 변경을 프로덕션 인프라처럼 검토하세요. 이전 값을 내보내고, 기존 수신처가 여전히 의도한 것인지 확인하고, 도메인 범위를 검증하고, 롤백 수단을 보존하세요. 활성화 문서에는 현재의 루트 도메인 범위와 외부 SPF 레코드에 대한 주의 사항도 나와 있습니다. 이 기능이 다른 곳에서 호스팅되는 SPF 경로를 안전하게 다시 쓸 수 있다고 추정하지 마세요. 목록에 나온 출처나 IP가 어떤 애플리케이션, 테넌트, 사람이 승인했는지를 증명하지는 않으며, 행이 없다고 해서 트래픽이 없다는 뜻도 아닙니다. 이 화면은 증거 수집에 활용하되, 권한 있는 DNS, 원본 메시지, 제공업체 로그, 애플리케이션 감사 증거는 계속 보존하세요.

증거를 바탕으로 단계적으로 적용 강도 높이기

모든 정상 발신자, 메시지 유형, 요일별 패턴, 배치 작업, 장애 조치 경로, 빈도가 낮은 워크플로를 포괄할 만큼 충분히 오래 관찰하세요. 출처를 자사 소유, 승인된 공급업체, 전달됨(forwarded), 알 수 없음, 악용으로 분류하세요. 더 강한 처리를 요청하기 전에 정상 트래픽의 정렬 문제를 고치세요. 진행 여부 판단 기준에는 유효한 DNS, 통제된 메시지 통과, 충분한 정렬 커버리지, 알 수 없는 정상 출처 없음, 사고 담당자, 지원 준비, 검증된 롤백이 포함되어야 합니다. 정책은 상한이 있고 승인된 변경으로만 강화하고, 인증 실패와 비즈니스 실패를 함께 모니터링하세요. 정상 메시지 거부, 보고서 손실, 예기치 않은 출처, 리졸버 불일치, 제공업체 마이그레이션, 하위 도메인 상속으로 인한 뜻밖의 동작이 생기면 롤백하거나 일시 중지하세요. 회귀 원인을 분명히 파악할 수 있도록 가능하면 SPF, DKIM, DMARC를 따로따로 변경하세요.

Cloudflare DMARC의 흔한 실패 유형 피하기

자주 발생하는 실패로는 잘못된 영역 수정, 잘못된 _dmarc 이름에 게시, 정책 레코드 두 개 방치, 깨진 따옴표 추가, 승인된 rua 목록 덮어쓰기, 루트 도메인과 하위 도메인의 정책이 같다고 가정하기, 드물게 발송하는 발신자가 나타나기 전에 p=reject 사용하기가 있습니다. 대시보드의 저장 상태나 감지 상태를 메시지 수준의 증거로 취급하는 것도 흔한 실수입니다. 정확한 diff, 통제된 수신자, 독립적인 조회, 원본 헤더, 수신자 범위의 사고 로그를 사용하세요. 고객 주소, 메시지 본문, API 키, 제한 없는 보고서 데이터는 티켓과 분석 도구에 넣지 마세요. 권한 있는 응답과 캐시된 응답이 계획한 기간을 넘어서도 불일치하거나, 예상한 발신자가 없거나, 실제 메시지가 정렬에 실패하면 중단하고 위임, 캐시, 레코드 문법, 발신자 목록, SPF, DKIM을 각각 따로 진단하세요.

SendHQ의 활용 방식

안전한 경계는 제공업체 중립적입니다. 애플리케이션이 메시지를 승인하고, 발송 제공업체가 인증하며, Cloudflare가 DNS 상태를 게시하거나 분석하고, 수신자가 메시지를 평가합니다. Cloudflare의 최신 공식 문서, 최신 DMARC 표준, 관찰된 DNS 응답, 제어된 수신 메시지 증거에 의존하세요.

자주 묻는 질문

루트 도메인 DMARC 정책은 Cloudflare의 어떤 이름에 두나요?

영역에 _dmarc TXT를 만들면 _dmarc.example.com으로 조회됩니다. 하위 도메인이 From ID라면 해당 작성자 도메인과 현재의 검색 규칙을 기준으로 평가하세요.

TXT 값에 따옴표를 직접 넣어야 하나요?

Cloudflare는 따옴표 없이 저장한 새 TXT 내용을 자동으로 따옴표로 감싼다고 설명합니다. 일관되지 않은 수동 따옴표는 피하고, 권한 있는 원본 응답과 파서 결과를 확인하세요.

Cloudflare가 DMARC TXT 레코드를 프록시하나요?

아니요. 이 TXT 정책에는 HTTP 프록시 결정이 관여하지 않습니다. 권한 있는 DNS에 게시하고 외부에서 검증하세요. 웹 프록시 동작은 별개의 기능입니다.

DMARC Management가 레코드를 바꿀 수 있나요?

Cloudflare의 활성화 문서에 따르면 레코드 추가나 Cloudflare rua 수신처 추가를 제안할 수 있습니다. 그 변경을 명시적으로 검토하고, 보존하고, 검증하고, 롤백하세요.

p=none이면 실패한 메일을 거부하나요?

아니요. 관찰을 위한 요청 정책입니다. 더 강한 수신 측 요청을 고려하기 전에 보고서와 통제된 메시지로 정상 발신자를 파악하고 개선하세요.

DMARC 통과는 받은편지함 도달을 증명하나요?

아니요. 해당하는 정렬 인증 평가를 통과했음을 증명할 뿐입니다. 제공업체의 접수, 수신 측의 수락, 폴더 도달, 반응에는 각각 별도의 범위별 증거가 필요합니다.

SPF는 통과하는데 DMARC는 실패할 수 있는 이유는 무엇인가요?

인증된 SMTP 식별자가 보이는 From 도메인과 정렬되지 않았거나 다른 평가 오류가 있을 수 있습니다. 정확한 식별자와 수신 측의 원본 결과를 확인하세요.

DMARC 레코드가 이메일 제공업체 연동을 증명하나요?

아니요. DMARC 레코드만으로는 이메일 제공업체 연동을 증명하지 않습니다.

출처

더 알아보기

애플리케이션 이메일용 DMARC 확인 방법DNS 조회를 전달로 착각하지 않으면서 DMARC 레코드 검색, 문법, SPF와 DKIM 정렬, 정책, 보고서, 실제 애플리케이션 메시지를 확인합니다.애플리케이션 이메일을 위한 SPF 레코드 문법 설명SPF v=spf1 문법, 메커니즘, 한정자, 수정자, DNS 조회 제한, include와 redirect 동작, 검증, DMARC 정렬을 이해합니다.애플리케이션 이메일의 DKIM 확인 방법실제 서명을 살펴보고, 셀렉터와 도메인을 조회하고, 메시지를 검증하고, 수신 측 결과를 읽고, 정렬을 테스트해 DKIM을 확인합니다.이메일 전달성 서비스 평가 방법범위, 증거, 인증, 피드백 루프, 발송 제외, 개인정보 보호, 이식성, 운영 적합성을 기준으로 이메일 전달성 서비스를 평가합니다.