DMARC란? 회사 도메인을 도용한 메일을 막는 원리

SPF와 DKIM이 있는데 DMARC도 필요한 이유

가온상사는 직원용 메일 외에도 뉴스레터 서비스를 사용합니다. 직원은 업무 메일 서비스에서, 마케팅팀은 뉴스레터 서비스에서 메일을 보내지만, 받는 사람에게는 둘 다 회사 주소가 보입니다. 이처럼 화면에 보이는 주소와 실제 발송에 사용하는 도메인은 서로 다를 수 있습니다.

먼저 메일 한 통에 등장하는 세 가지 이름을 구분해 보겠습니다. From은 사람이 읽는 보낸 사람 주소입니다. MAIL FROM은 서버가 메일을 전달할 때 사용하는 주소로, 배달 실패 안내를 돌려받는 데 쓰입니다. DKIM의 d=는 메일에 전자서명을 붙인 도메인입니다.

이 뉴스레터가 SPF를 통과했다면 “지금 접속한 서버는 mailer.example.net이 허용한 서버”라는 뜻입니다. DKIM까지 통과해도 확인한 것은 “mailer.example.net의 서명이 유효하다”는 사실입니다. 두 결과만으로 가온상사의 example.com을 사용해도 되는지까지 확인한 것은 아닙니다. SPF의 MAIL FROM 검사 ↗ DKIM 서명 도메인 ↗

공격자도 자신이 관리하는 도메인에서는 SPF와 DKIM을 정상 설정할 수 있습니다. 그런 인증을 통과한 메일에 가온상사의 From 주소를 붙였다고 해서 가온상사 메일이 되지는 않습니다. 여기서 DMARC가 한 가지를 더 묻습니다. “통과한 인증이 화면에 보이는 회사 도메인과 연결되어 있는가?”

회사가 정하고, 받는 서버가 확인합니다

DMARC의 정식 이름은 Domain-based Message Authentication, Reporting, and Conformance입니다. 이름보다 역할을 기억하는 편이 쉽습니다. 회사는 DNS, 즉 도메인의 정보를 공개하는 곳에 인증 정보와 방침을 올립니다. 메일을 받는 서버는 그 정보를 조회해 확인하고, 보고 기능을 제공한다면 관찰 결과를 회사에 돌려줍니다.

따라서 회사 DNS에 DMARC를 설정하는 일은 주로 회사 주소를 믿고 메일을 받는 고객과 거래처를 보호하는 일입니다. 직원의 받은편지함으로 들어오는 모든 사기 메일을 걸러 주는 기능과는 역할이 다릅니다. 수신 메일 보호에는 받는 메일 서비스의 인증 검사와 사칭 탐지, 콘텐츠 검사가 함께 필요합니다.

PASS 옆에 어느 도메인이 적혀 있는지 보세요

DMARC는 From의 @ 뒤 도메인을 기준으로 삼습니다. 앞부분이 billing인지 news인지는 통과 조건이 아닙니다. 인증을 통과한 도메인이 From 도메인과 맞는 관계를 도메인 정렬(alignment)이라고 부릅니다.

SPF가 통과하고 DKIM의 도메인이 같다는 식으로 서로 다른 경로의 조건을 섞을 수는 없습니다. SPF는 SPF 안에서, DKIM은 DKIM 안에서 두 조건을 모두 만족해야 합니다. 도메인 이름만 같은 실패한 서명은 근거로 사용할 수 없습니다. DMARC 표준의 정렬 조건 ↗

정상 뉴스레터와 주소 도용 메일이 둘 다 실패했다는 점을 눈여겨보세요. DMARC는 발송자의 의도를 읽지 않습니다. 가온상사가 실제로 이용하는 서비스라도, 회사 도메인으로 발송하도록 인증 설정을 마치지 않으면 연결을 확인할 수 없습니다. 실패는 조사할 이유이며, 그 자체로 도용의 확정 증거는 아닙니다.

뉴스레터는 무엇을 바꾸면 통과할까요?

가온상사가 뉴스레터 서비스의 도메인 인증 절차를 진행했다고 해 보겠습니다. 서비스가 발급한 DNS 값을 등록하고 회사 도메인으로 DKIM 서명을 켭니다. 이후 새로 보낸 메일에서 d=example.com의 서명이 실제로 통과하면, SPF가 여전히 서비스 도메인으로 통과하더라도 DMARC는 통과합니다.

From: news@example.com — 두 경우 모두 동일

설정 전
SPF  PASS  mailer.example.net
DKIM PASS  mailer.example.net
DMARC FAIL — example.com과 연결된 인증 없음

회사 도메인 DKIM 설정 후
SPF  PASS  mailer.example.net
DKIM PASS  example.com
DMARC PASS — DKIM 경로가 통과하고 정렬됨

서비스가 지원한다면 MAIL FROM을 회사의 도메인이나 하위 도메인으로 바꾸고 SPF를 맞추는 방법도 있습니다. 다만 example.com의 SPF에 서비스 이름을 추가하는 것만으로 위 예시의 SPF 정렬이 해결되지는 않습니다. 실제 검사 대상이 계속 mailer.example.net이면 From과의 관계가 그대로이기 때문입니다. 서비스가 지원하는 회사 도메인 DKIM이나 사용자 지정 MAIL FROM 설정을 확인해야 합니다. Microsoft의 정렬 실패 진단 ↗

같아야 한다는 말은 어디까지일까요?

기본값인 완화 모드(r)는 같은 조직 도메인에 속하는지를 봅니다. 아래의 일반적인 구성에서는 mail.example.com도 example.com과 정렬됩니다. 엄격 모드(s)는 전체 도메인이 정확히 같아야 합니다.

마지막 주소는 중간에 회사 이름이 들어가 있어도 example.net 아래에 있습니다. 글자가 비슷하거나 일부가 포함됐다는 뜻의 “완화”가 아닙니다. aspf는 SPF의, adkim은 DKIM의 정렬 모드를 정하며, 처음에는 기본값 r로 발신 구조를 확인하는 편이 일반적입니다. s는 도메인을 정확히 분리해 운영할 이유가 있고 정상 발신도 그 조건을 만족할 때 검토합니다.

인증 결과, 처리 방침, 리포트는 구분해서 봅니다

DMARC가 실패했다고 확인한 다음에는 어떻게 할까요? 회사는 DNS 레코드의 p=에 원하는 처리 방침을 적습니다. 가온상사가 새로 DMARC를 시작한다면, 아직 설정하지 않은 뉴스레터가 있으므로 우선 관찰하면서 정상 발신을 정리할 필요가 있습니다.

여기서 p=none은 실패를 통과로 바꾸지 않습니다. p=reject도 SPF나 DKIM 검사를 더 엄격하게 만드는 값은 아닙니다. 검사 결과가 같아도, 실패했을 때 회사가 요청하는 처리가 달라지는 것입니다.

수신 서버는 그 요청에 자체 보안 정책을 더해 최종 처리합니다. 그러므로 none인 메일도 스팸 검사 때문에 거부될 수 있고, DMARC가 통과해도 받은편지함에 들어간다는 보장은 없습니다. 전달 메일에 대한 수신 측 판단이나 예외 설정에 따라 요청과 실제 처리가 달라질 수도 있습니다. 수신 측 정책 적용에 관한 표준 ↗

처음 등록할 때 이해해야 할 값

DNS 이름: _dmarc.example.com
유형: TXT
값: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

v=DMARC1은 DMARC 레코드라는 표시이고, p=none은 관찰을 시작할 때의 방침입니다. rua=에는 집계 보고서를 받을 주소를 적습니다. 마지막의 adkim=r, aspf=r은 앞서 본 기본 정렬 모드이며, 생략해도 기본값은 같습니다.

이 예시는 기존 레코드가 없는 도메인의 시작점을 설명합니다. 이미 quarantine이나 reject를 운영 중이라면 예시를 그대로 덮어쓰지 마세요. 같은 이름에 DMARC 레코드를 두 개 추가해서도 안 됩니다. 보고 주소는 실제로 수신 가능한 전용 주소를 마련하고, 외부 분석 서비스 주소라면 그 서비스의 보고 수신 동의 설정도 확인합니다. Google의 DMARC 설정 안내 ↗

RUA로 놓친 정상 발신처를 찾습니다

RUA는 DMARC 집계 리포트의 수신 주소를 지정하는 항목입니다. 보고하는 수신 서버는 자신이 관찰한 메일을 발신 IP와 인증 결과 등으로 묶어 보냅니다. XML이라는 구조화된 파일 형식으로 오므로, 일반적인 청구서처럼 읽기보다는 분석 도구나 변환 결과로 확인하는 경우가 많습니다.

이 자료를 “주소 도용 메일 258통”이라고 읽으면 정상 뉴스레터 240통까지 공격으로 분류하게 됩니다. 반대로 뉴스레터 설정을 고친 뒤 통과율이 높아졌다고 미확인 18통을 무시해서도 안 됩니다. 리포트의 숫자를 회사의 서비스 목록과 연결해야 다음 행동이 정해집니다.

RUA는 보고에 참여한 수신자가 본 범위의 집계입니다. 전체 발송 로그나 메일 원문이 아니며, 실시간 경보 또는 최종 받은편지함 도착 확인서도 아닙니다. 보고가 없다고 주소 도용 시도가 없었다고 결론 내릴 수는 없습니다. 집계 리포트의 내용과 구조 ↗

어떤 도용·사칭에 도움이 되고, 무엇이 남을까요?

가온상사가 뉴스레터를 포함한 정상 발신을 정리하고 p=reject를 적용했다고 해 보겠습니다. 공격자가 허용받지 않은 서버에서 billing@example.com을 From에 적어 보냈고, 정렬된 인증도 없다면 DMARC는 실패합니다. 이를 받는 서버는 가온상사의 거부 요청을 판단에 사용할 수 있습니다.

하지만 공격자는 이름을 비슷하게 보이게 하거나 실제 계정을 탈취하는 다른 방법을 쓸 수 있습니다. 따라서 “회사 사칭”이라는 말만으로 DMARC가 적용되는 상황인지 판단하면 안 됩니다.

특히 DMARC는 billing@example.com을 특정 재무팀 직원의 신원과 연결하지 않습니다. 회사 도메인을 사용할 수 있는 발신 환경인지 확인하는 것이므로, 정상 계정에서 온 잘못된 송장이나 악성 링크도 인증은 통과할 수 있습니다. DMARC가 다루는 사칭 범위 ↗

처음의 계좌 변경 요청으로 돌아가 보겠습니다. DMARC 통과 여부는 주소를 신뢰할 근거 하나입니다. 실제 계좌 변경을 승인할 근거까지 되지는 않습니다. 지급 정보를 바꾸기 전에는 메일에 새로 적힌 번호 대신 기존 계약서나 이미 알고 있던 거래처 연락처로 확인하는 절차가 필요합니다. FBI의 업무 이메일 사기 예방 안내 ↗

회사 주소를 쓰는 발신처부터 확인하세요

“메일을 많이 보내는 회사만 필요할까요?” 메일 수가 적어도 회사 주소로 고객과 거래한다면 확인할 이유가 있습니다. 적은 수의 청구서나 비밀번호 재설정 메일도 업무에서는 중요합니다. 반대로 직원용 메일이 잘 통과한다는 사실만으로 자동 알림과 외부 서비스까지 준비됐다고 보기는 어렵습니다.

가온상사의 담당자가 처음 할 일은 DMARC 값을 강하게 바꾸는 것이 아닙니다. 마케팅팀에는 뉴스레터, 영업팀에는 CRM, 개발팀에는 회원가입과 주문 알림을 물어 회사 주소를 사용하는 발신처를 모으는 일입니다. DNS 관리자가 회사의 모든 발송 서비스를 알고 있다고 가정하지 않는 편이 좋습니다.

1. 도메인과 발신처를 한 목록에 적습니다

   직원용 메일, 뉴스레터, CRM, 고객지원, 청구서·자동 알림의 서비스명과 담당자, 사용 중인 From 주소를 기록합니다. 하위 도메인을 쓰면 함께 표시합니다.

2. 서비스별 실제 메일을 받아 확인합니다

   DNS 등록 화면에서 끝내지 않고 새로 발송한 메일에서 인증 결과와 도메인 정렬을 봅니다. 정상 경로가 실패하면 발신 서비스의 회사 도메인 인증부터 고칩니다.

3. 리포트와 회사 기록을 맞춰 봅니다

   RUA 수신·분석 담당자를 정하고 발신처 목록과 대조합니다. 월말 청구서처럼 드물게 보내는 메일은 해당 발송 시점까지 따로 확인합니다.

4. 남은 실패 원인을 설명할 수 있을 때 정책을 바꿉니다

   정상 발신 누락과 전달 경로의 영향을 확인한 뒤 격리·거부를 검토합니다. 변경 후에는 리포트와 실제 반송·고객 문의를 함께 살피고, 새 서비스를 도입할 때 같은 확인을 반복합니다.

한 번의 검사에서 PASS를 본 것과 회사의 발신 환경을 파악한 것은 다릅니다. 매일 보내는 직원 메일은 문제없어도 월말에만 발송하는 청구 서비스가 빠져 있을 수 있습니다. “며칠 지났으니 완료”나 전체 통과율 한 숫자보다, 중요한 정상 발신처를 각각 확인했는지가 정책 전환의 근거가 됩니다.

설정을 시작할 때는 현재 표준과 이용 서비스의 공식 안내를 함께 확인하세요. 오래된 가이드의 일부 항목은 2026년 표준에서 폐기됐고, 새 항목의 지원 범위도 수신 서비스마다 다를 수 있습니다. 구체적인 설정값과 정책 전환 기준은 아래 관련 글에서 이어서 확인할 수 있습니다. 현행 DMARC 항목 등록부 ↗