카드 결제를 받는 모든 기업이 따라야 하는 보안 표준인 PCI DSS는 DMARC를 필수 통제 항목으로 명시하지 않습니다. 하지만 2025년 3월 31일부터 이 표준의 4.0.1 버전은 자동화된 피싱 방지 조치를 요구하고 있으며, PCI Security Standards Council은 그 가이드에서 피싱 방지 요건을 충족하는 승인된 방법으로 DMARC, SPF, DKIM을 거론합니다. 카드 결제를 처리한다면, DMARC는 이제 선택 사항이 아니라 갖추고 있을 것으로 기대되는 항목입니다.
업체 블로그 글에서는 PCI DSS가 "DMARC를 요구한다"고 흔히 주장합니다. 이 주장은 정확하지 않으며, 그 차이는 PCI 심사 과정에서 중요하게 작용합니다. 이 글에서는 요구사항 5.4.1이 무엇을 규정하는지, DMARC가 그 안에서 어디에 해당하는지, 그리고 DNS와 컴플라이언스를 관리하는 사람이 무엇을 해야 하는지 설명합니다. 웹사이트를 통해 카드 결제를 받는다면, 이 작업은 IT 또는 보안 팀, 혹은 도메인을 관리하는 대행사의 몫입니다.
특정 섹션으로 바로 이동하려면 링크를 클릭하세요.
이름으로 명시해 요구하지는 않습니다. 표준의 현재 버전인 PCI DSS 4.0.1은 조직이 자동화된 피싱 방지 메커니즘을 갖출 것을 의무화합니다. 다만 요건 자체에서 특정 기술을 지목하지는 않습니다. 기술이 거론되는 곳은 가이드이며, 여기서 PCI Security Standards Council은 DMARC, SPF, DKIM 같은 스푸핑 방지 통제가 "피싱 공격자가 해당 기관의 도메인을 위조해 직원을 사칭하는 것을 막는 데 도움이 될 수 있다"고 기술합니다.
즉 PCI 가이드는 DMARC를 권장할 뿐, 필수 통제 항목으로 열거하지는 않습니다. 실무에서는 "권장"과 "필수"의 차이가 여기서 크지 않습니다. SPF, DKIM, DMARC는 도메인 스푸핑을 막는 표준적이고 문서화된 방법이므로, 자동화된 피싱 방지 메커니즘을 확인하는 심사관은 이들을 보게 될 것으로 기대합니다. 실무적인 조언은 단순합니다. DMARC를 갖추세요. 심사관이 그것을 확인할 것이기 때문입니다. 표준이 DMARC를 이름으로 명시해 요구한다고 주장하지는 마세요. 실제로는 그렇지 않으며, 심사관은 그 차이를 알고 있을 것입니다.
관련 규정은 요구사항 5.4.1입니다. 피싱 공격을 탐지하고 직원을 보호하기 위한 프로세스와 자동화된 메커니즘을 갖추어야 한다는 내용입니다. 여기서 핵심 단어는 "자동화된"입니다. 보안 인식 교육만으로는 이 요건을 충족하지 못합니다. 표준이 요구하는 것은 경고를 받은 직원만이 아니라 실제로 작동하는 기술적 통제이기 때문입니다.
5.4.1은 미래 시행일이 지정된 요구사항으로 공개되었고, 이는 조직이 준비하는 동안에는 선택 사항이었음을 의미합니다. 그 유예 기간은 2025년 3월 31일에 종료되었습니다. 그 이후로 이 피싱 방지 요건은 의무가 되었습니다. 심사관은 PCI DSS 심사 과정에서 이를 확인하며, 더는 모범 사례로 미룰 수 없습니다.
가이드는 또한 카드 데이터를 저장하거나 처리하는 시스템뿐 아니라 조직 전체에 피싱 방지 통제를 적용할 것을 권장합니다. DMARC는 기본적으로 이를 수행합니다. 하나의 DMARC 정책이 도메인의 모든 주소에 적용되므로, 시스템마다 따로 확장할 필요가 없습니다.
표준이 DMARC를 이름으로 지목하지 않으니 당연히 나올 질문입니다. 요구사항 5.4.1은 직원을 피싱으로부터 보호하는 것이 목적이므로, 다른 도구로 그 일부를 충족할 수 있습니다. 보안 이메일 게이트웨이, 피싱 방지 필터, 링크 및 첨부파일 스캔, 또는 자동화된 보안 인식 교육 등이 그것입니다. 카드 결제를 받는 대부분의 기업은 이미 이 가운데 일부를 운영하고 있으며, 계속 유지하는 것이 맞습니다.
하지만 이런 도구는 자기 회사의 받은편지함에 도착하는 메일만 검사합니다. 공격자가 From 주소에 당신의 도메인을 위조해 당신의 고객, 파트너, 직원을 상대로 피싱하는 것은 전혀 막지 못합니다. 그런 종류의 도메인 스푸핑을 막는 유일하고 현실적인 방법은 이메일 인증, 즉 SPF, DKIM, DMARC를 함께 운영하는 것입니다. 사실상 대체재가 없습니다. PCI 가이드가 이 셋을 모두 거론하는 이유, 그리고 요건이 그것들을 명시적으로 적어 두지 않는데도 심사관이 이들을 보게 될 것으로 기대하는 이유가 여기에 있습니다.
DMARC 레코드를 게시하는 것과 그것을 강제 적용하는 것은 같지 않습니다. 그리고 바로 이 지점에서 많은 기업이 이 요건이 의도하는 수준에 미치지 못합니다.
p=none 상태의 DMARC 레코드는 모니터 전용 모드로 동작합니다. 수신 서버에 인증에 실패한 메일을 보고하도록 지시하되, 그 메일을 그대로 배달하게 합니다. 가시성은 얻을 수 있고 이는 유용하지만, 당신의 도메인에서 온 것처럼 위장한 위조 메시지는 여전히 받은편지함에 도달합니다. 아무것도 차단되지 않습니다. 피싱 방지 통제로서 p=none 레코드는 단 한 건의 공격도 막지 못합니다.
위조 메일을 차단하려면 DMARC를 강제 적용 모드로 두어야 합니다. p=quarantine은 실패한 메시지를 스팸함으로 보내고, p=reject는 아예 거부합니다. 누군가 당신의 도메인을 위조해 고객이나 직원을 상대로 피싱하는 것을 막는 것이 바로 이 강제 적용입니다. PCI는 필수 정책 수준을 명시하지 않으므로, 이는 표준의 한 줄이 아니라 우리의 해석입니다. 그러나 아무것도 차단하지 않는 DMARC 레코드를 피싱 방지 통제라고 심사관에게 설명하기는 어렵습니다.
대부분의 도메인이 노출되어 있는 지점이 바로 여기입니다. DMARCeye의 2026년 1분기 산업 보고서에 따르면, DMARC를 게시한 도메인 가운데 36.7%가 p=none, 36.8%가 p=quarantine, 26.5%가 p=reject 상태입니다. 3분의 1이 넘는 도메인이 모니터 전용으로 설정되어 있어 아무것도 차단하지 못하는 DMARC 레코드를 게시하고 있습니다. 강제 적용 격차에 대한 전체 분석에 얼마나 많은 도메인이 모니터링 단계를 끝내 벗어나지 못하는지에 대한 전체 수치가 담겨 있습니다.
현재 도메인의 DMARC 정책이 무엇이며 강제 적용으로 설정되어 있는지 확인하려면 아래에 도메인을 입력하세요.
먼저 이 작업을 누가 맡는지 파악하세요. DMARC 레코드를 게시하고 정책을 강화하는 일은 마케팅이 아니라 DNS와 이메일 인증에 관한 작업입니다. 규모가 큰 회사에서는 IT나 보안 부서가 담당합니다. 소규모 사업에서는 대개 도메인을 관리하는 사람, 즉 IT 외주 업체, 웹 호스팅 업체, 또는 이메일과 DNS를 운영하는 대행사에게 돌아갑니다. PCI 컴플라이언스에 책임이 있지만 DNS를 직접 관리하지는 않는다면, 당신이 할 일은 적임자에게 작업을 맡기고 심사 전에 완료되었는지 확인하는 것입니다.
기술적 단계는 순서대로 다음과 같습니다.
SPF와 DKIM을 게시하세요. DMARC는 이 둘에 의존합니다.p=none 상태로 DMARC 레코드를 게시해, 배달에 영향을 주지 않으면서 보고서 수집을 시작하세요.p=quarantine으로, 이어서 p=reject로 옮기세요. 이것이 피싱 방지 취지를 충족하는 설정입니다.피해야 할 함정은 발신자 목록을 파악하기 전에 p=reject로 건너뛰는 것입니다. 강제 적용을 너무 일찍 켜면, 고객이 기다리고 있는 결제 영수증을 포함한 정당한 메일이 차단되기 시작합니다. DMARC 구현 완전 가이드는 강제 적용으로 넘어가는 과정을 단계별로 안내합니다.
기업을 DMARC 강제 적용으로 밀어붙이는 힘은 PCI DSS만이 아닙니다. 2024년부터 Google과 Yahoo는 대량 발신자에게 DMARC 게시를 요구해 왔고, Microsoft도 이후 Outlook과 Hotmail로 보내는 대량 발신자에게 동일한 기준을 적용했습니다. 주요 메일박스 제공자와 결제 표준은 이제 같은 것을 요구합니다. 메일을 인증하고, 다른 사람이 당신의 도메인을 위조하지 못하게 하라는 것입니다.
카드 결제를 받으면서 마케팅 또는 트랜잭션 이메일도 발송하는 기업이라면, 하나의 프로젝트로 두 의무를 모두 충족할 수 있습니다. PCI를 위해 갖춘 DMARC 강제 적용은 받은편지함 제공자가 기대하는 것과 동일한 통제입니다. Google 및 Yahoo 발신자 요건 가이드가 그쪽 측면을 자세히 다룹니다.
PCI DSS v4.0.1은 DMARC를 필수 통제 항목 목록에 추가하지 않았으며, 추가했다고 말하는 사람은 경계해야 합니다. 그것이 한 일은 피싱 방지 보호를 의무화하고, 그 보호를 제공하는 방법으로 DMARC, SPF, DKIM을 지목한 것입니다. 가장 중요한 것은 강제 적용입니다. p=none 상태의 DMARC 레코드는 문제를 기록하는 데 그치지만, p=quarantine이나 p=reject는 문제를 해결합니다.
DMARCeye는 당신의 도메인이 수신하는 DMARC 보고서를 읽어, 어떤 발신자가 정당한지, 그리고 언제 강제 적용으로 안전하게 옮길 수 있는지를 평이한 언어로 보여 줍니다. 그래서 모니터링에서 컴플라이언스로 넘어가는 단계가 고객이 의존하는 메일을 망가뜨리지 않게 합니다.