Defaults.Exposed

Defaults.Exposed › 보고서

이메일 인증: 완전 가이드 (SPF, DKIM, DMARC, BIMI)

게시일 · 업데이트됨

2026-08-16 기준 수치 · 방법론 v8. 276백만 개의 등급이 매겨진 도메인에 걸친 집계 인구조사 데이터입니다. 이 글은 이메일 인증 스택의 총괄 가이드이며, 각 프로토콜의 심층 분석은 본문 곳곳에 링크되어 있습니다. 등급을 매기는 방법을 참조하세요.

이메일 인증은 하나의 시스템으로 작동하는 세 개의 DNS 기반 프로토콜입니다: SPF는 어떤 서버가 당신의 도메인을 대신해 보낼 수 있는지 말하고, DKIM은 각 메시지에 서명해 변조가 드러나게 하며, DMARC는 이 둘을 사람이 실제로 보는 주소에 연결한 다음 — 검사가 실패했을 때 전 세계의 메일박스가 무엇을 해야 하는지 알려줍니다. 네 번째인 BIMI는 그 끝에 있는 눈에 보이는 보상입니다: 받은편지함 속 당신의 로고. 함께 배포되고 시행되면, 이들은 당신의 도메인에서 위조된 이메일이 도착하는 대신 반송되게 만듭니다. 부분적으로만 배포되면 — 인터넷 대부분이 그렇게 해왔습니다 — 거의 아무것도 바뀌지 않습니다. 등급이 매겨진 276백만 개 도메인 중 **51.24%**가 SPF를 게시하고, **25.80%**가 어떤 형태로든 DMARC 레코드를 게시하지만, 이를 시행하는 곳은 **11.83%**뿐이고, 완전히 시행된 스택을 운영하는 곳은 단 **2.79%**입니다. 이 가이드는 각 프로토콜의 기여, 서로 맞물리는 방식, 배포 순서, 그리고 “완료”가 실제로 무엇을 의미하는지 다룹니다.

각 프로토콜이 기여하는 것

이 네 가지 표준은 흔히 서로의 대안처럼 소개됩니다. 그렇지 않습니다 — 각각은 나머지가 남겨둔 빈틈을 메웁니다.

SPF는 발신 경로를 인증합니다. 하나의 DNS TXT 레코드가 당신의 도메인을 대신해 메일을 보낼 수 있는 서버를 나열하고, 수신자는 연결한 서버를 그 목록과 대조합니다. 넷 중 가장 오래되고 가장 쉬운 표준이라, 도입률 51.24%로 선두입니다. 약점: 사람이 읽는 “From” 줄이 아니라 기술적 주소(봉투 발신자)를 검사하며 — 메일이 포워딩되면 깨집니다. 자세한 내용은 SPF란 무엇이고 어떻게 고치나요?를 참조하세요.

DKIM은 메시지 자체를 인증합니다. 메일 서버가 개인 키로 각 발신 메시지에 서명하고, 대응하는 공개 키는 셀렉터 아래 DNS에 위치합니다. 수신자는 서명을 검증하여, 메시지가 당신의 키 보유자에게서 왔고 전송 중 변조되지 않았음을 증명합니다. 서명이 메시지 안에 실려 이동하기 때문에, DKIM은 SPF가 실패하는 포워딩에서도 살아남습니다. 인구조사에서 등급이 매겨진 도메인의 **-117.33%**에서 DKIM 셀렉터가 관찰됩니다.

DMARC는 나머지 둘에 의미를 부여하는 정책 계층입니다. SPF와 DKIM은 그 자체로는 수신자가 조용히 참고만 할 수 있는 통과/실패 결과를 낼 뿐입니다. DMARC는 세 가지를 더합니다: 정렬(검사가 눈에 보이는 From 도메인과 연관되어야 함 — 아래에서 자세히), 실패 시 수신자가 무엇을 할지 알려주는 정책(none, quarantine, reject), 그리고 누가 당신의 도메인 이름으로 보내고 있는지 볼 수 있게 하는 보고. 정책 수준의 자세한 내용은 DMARC란?을 참조하세요.

BIMI는 그 위의 신뢰 신호입니다. DMARC가 시행되고 나면, Gmail, Apple Mail, Yahoo가 당신의 메시지 옆에 표시할 로고를 게시할 수 있습니다. 그 자체로는 방어 기능이 전혀 없습니다 — 방어 작업이 끝났다는 눈에 보이는 증명서입니다. BIMI란?에서 자격 요건과 설정을 다룹니다.

맞물리는 방식: 정렬이 게임의 전부입니다

여기가 대부분의 반쯤 끝난 배포가 놓치는 부분입니다. 모든 이메일은 두 개의 발신자 신원을 지닙니다: 봉투 발신자(라우팅과 반송에 사용, 독자에게는 보이지 않음)와 헤더 From(사람이 보는 것). SPF는 첫 번째를 검사합니다. DKIM은 메시지에 서명한 도메인이 무엇이든 그것을 검사합니다. 어느 쪽도 단독으로는 From 줄에 대해 아무 말도 하지 않습니다 — 그런데 그것이 바로 사칭꾼이 위조하는 필드입니다.

DMARC는 그 빈틈을 **정렬(alignment)**로 닫습니다: DMARC를 통과하려면, 메시지는 눈에 보이는 From 도메인과 일치하는 도메인에 대해 SPF 또는 DKIM을 통과해야 합니다. 피싱범은 SPF를 아주 쉽게 통과할 수 있습니다 — 자기 서버에서, 자기 봉투 도메인으로 보내면서, From 줄에 당신의 도메인을 넣으면 됩니다. 정렬된 DMARC가 바로 그 속임수를 실패하게 만드는 것입니다.

두 가지 실무적 결과:

배포 순서, 각 단계의 검증 게이트와 함께

이 스택에는 자연스러운 순서가 있습니다 — 각 계층은 그다음 계층을 조일 때의 안전망입니다. 순서를 서두르면 정상 메일이 반송되고, 끝을 내지 않으면 인터넷이 지금처럼 — DMARC를 게시한 도메인의 88.17%가 모니터링에 갇힌 상태로 — 끝납니다. (새 도메인을 처음부터 설정하나요? 그것을 위한 압축 체크리스트가 있습니다.)

  1. 모든 정상 발신자의 목록을 만드세요. 메일박스 제공업체, 뉴스레터 플랫폼, CRM, 헬프데스크, 청구 도구 — 당신의 도메인 이름으로 보내는 모든 것. 이 목록이 곧 당신의 SPF 레코드이자 DKIM 할 일 목록입니다; 여기서의 누락은 나중에 잃어버린 메일로 드러납니다. 검증: 각 도구의 설정 페이지에서 문서화된 SPF include와 DKIM 설정을 확인하세요.
  2. SPF를 게시하세요 — 레코드 하나, ~all로 끝나게. 각 발신자의 include:가 담긴 단일 TXT 레코드. 안전 마진으로 softfail로 시작하세요. 검증: 레코드가 정확히 하나만 존재하는지(SPF 레코드 두 개는 자동 실패), 10회 DNS 조회 한도 안에 있는지, 모든 발신자의 실제 메일이 통과하는지 확인하세요. 그다음 -all로 조이세요.
  3. 모든 발신자에서 DKIM을 켜세요. 각 플랫폼에서 서명을 켜고 그들이 주는 공개 키를 게시하세요. 발신자별로 하세요 — 양대 메일박스 제공업체는 Google Workspace와 Microsoft 365 안내를 참조하세요. 검증: Gmail 계정으로 테스트 메일을 보내고 “원본 보기”를 사용하세요 — 메시지별 SPF, DKIM, DMARC 결과와 각 검사가 어느 도메인에 대해 통과했는지(그것이 정렬 뷰입니다)를 표시합니다.
  4. 보고 기능과 함께 p=none으로 DMARC를 게시하세요. _dmarc.yourdomain에 rua= 주소가 담긴 TXT 레코드 하나. 아직 배달에는 아무 변화가 없습니다 — 계기판을 켜는 것입니다. 몇 주간 보고서가 쌓이게 두세요. 검증: 집계 보고서가 도착하고 알려진 발신자들이 정렬과 함께 통과하는 것으로 나타나는지 확인하세요. 실패하는 정상 메일이 있다면 2단계나 3단계의 빈틈입니다 — 정책이 아직 none일 때 지금 고치세요.
  5. p=quarantine으로, 그다음 p=reject로 조이세요. 이것이 실제로 사칭을 막는 단계이자, 대부분의 도메인이 결코 밟지 않는 단계입니다: DMARC를 게시한 도메인 중 시행에 도달한 곳은 **45.9%**뿐입니다. 보고서가 깨끗한 통과를 보여줄 때 이동하세요; 볼륨이 크면 pct=로 점진적 램프를 쓰세요. p=none에서 reject까지 가이드가 램프를 안전하게 안내합니다. 검증: 보고서가 계속 흐르고 정상 메일이 계속 도착하는지; 위조된 메일은 이제 반송되거나 스팸함에 들어갑니다.
  6. 선택: BIMI를 게시하세요. 시행이 갖춰지면 자격이 됩니다. SVG 로고, DNS 레코드 하나, 그리고 (Gmail의 경우) Verified Mark Certificate. 검증: Gmail 계정으로 보내고 로고를 찾아보세요.

선택 사항인 BIMI 인증서를 제외하면 전 과정이 무료입니다. 비용은 돈이 아니라 정성입니다.

흔한 실패 유형

인구조사는 같은 몇 가지 실수를 대규모로 목격합니다:

”완료”의 모습

완료는 “레코드가 존재한다”가 아닙니다. 완료는 이것입니다: 당신의 도메인에서 위조된 메일이 거부되고, 그것이 더 이상 사실이 아니게 되면 며칠 안에 알게 된다. 구체적으로 — 모든 발신자에 대해 통과하는 -all의 SPF 레코드 하나; 모든 플랫폼의 DKIM 서명; 집계 보고서를 계속 읽고 있는 quarantine 또는 reject의 DMARC; 그리고 받은편지함 로고를 원한다면 그 위에 BIMI. 이 최종 상태는 드뭅니다: 2026-08-16 기준, 등급이 매겨진 도메인의 2.79% — 완전히 보호된 소수 — 만이 완전히 시행된 스택을 운영합니다.

두 가지 힘이 이것을 서서히 이메일로 사업하는 기본 비용으로 만들고 있습니다: Google과 Yahoo의 대량 발신자 요건은 이미 볼륨 발신자에게 인증을 의무화하고, 전달성(deliverability)은 인증된 쪽에 점점 더 보상을 줍니다. 네 프로토콜을 하나의 결승선을 가진 하나의 시스템으로 취급하는 도메인 — 보호를 설치가 아니라 유지의 대상으로 보는 6단계 사고방식 — 은 시작한 지 몇 주 만에 도달합니다. 나머지는 시작하고, 멈추고, 스푸핑 가능한 채로 남습니다.

자주 묻는 질문

SPF, DKIM, DMARC가 다 필요한가요, 하나만 있으면 되나요? 셋 다입니다. SPF와 DKIM은 인증 메커니즘이고, DMARC는 이들을 눈에 보이는 From 주소에 연결하고 수신자에게 행동을 지시하는 정책입니다. 어느 하나만으로는 사칭의 문이 열려 있습니다.

어떤 순서로 설정해야 하나요? SPF 먼저, DKIM 두 번째, p=none의 DMARC 세 번째, 그다음 보고서에서 정상 메일 통과가 확인되면 DMARC를 quarantine/reject로 조이세요. 원한다면 BIMI는 마지막에. SPF와 DKIM이 깨끗해지기 전에 DMARC를 시행하는 것이 정상 메일이 반송되는 경위입니다.

전체 배포에 얼마나 걸리나요? DNS 레코드는 몇 시간이면 됩니다. DMARC 시행까지의 안전한 경로는 몇 주가 걸립니다 — 대부분은 모든 정상 발신자가 정렬과 함께 통과하는지 모니터링 보고서로 확인하는 대기 시간입니다.

이메일을 보내지 않는 도메인에도 필요한가요? 네 — 세워둔 도메인은 아무도 지켜보지 않기 때문에 사칭하기 가장 쉽습니다. 레코드 세트는 짧습니다: SPF v=spf1 -all, 빈 DKIM 정책, 그리고 DMARC p=reject. 세워둔 도메인도 스푸핑될 수 있습니다를 참조하세요.

비용이 많이 드나요? 아니요. 모든 레코드는 무료 DNS 변경이며, 유일한 선택적 비용은 BIMI의 Verified Mark Certificate입니다. 2026-08-16 기준, 완료한 2.79%와 나머지의 격차는 예산이 아니라 노력과 순서입니다.

이메일 인증을 무료로 확인하세요

한 번의 스캔으로 도메인의 SPF, DKIM, DMARC, BIMI 상태를 확인하세요 — 비공개로, 소유자만 볼 수 있게.

도메인 점검하기 → · SPF 수정하기 → · DKIM 수정하기 → · DMARC 수정하기 → · 등급을 매기는 방법 → · 집계 데이터만 사용합니다. 데이터는 EU에서 저장·처리됩니다.