Defaults.Exposed › 보고서

DMARC vs SPF: 차이점은 무엇이고, 무엇이 필요한가? (2026)

게시일 2026-07-25 · 업데이트됨2026-07-30

2026-08-16 기준 수치 · 방법론 v8. 276백만 개의 등급이 매겨진 도메인에 걸친 집계 인구조사 데이터입니다. “시행 중”은 quarantine 또는 reject DMARC 정책을 의미합니다. 등급을 매기는 방법을 참조하세요.

DMARC 필러의 일부 — 전체 인구조사에 걸쳐 측정한 DMARC 도입률, 성숙도, 리그 테이블입니다.

둘 다 필요합니다 — SPF 먼저, 그다음 DMARC — 두 표준이 서로 다른 질문에 답하기 때문입니다. SPF는 목록입니다: 어떤 서버가 내 도메인을 대신해 이메일을 보낼 수 있는가? DMARC는 정책입니다: 인증에 실패한 메시지를 수신자가 어떻게 처리해야 하는가 — 그리고 그런 일이 있었다는 사실을 나는 어떻게 알 수 있는가? 어느 쪽도 다른 쪽을 대체하지 못합니다. DMARC 없는 SPF는 눈에 보이는 “From” 주소를 위조 가능한 상태로 남겨두고, SPF(또는 DKIM) 없는 DMARC는 시행할 대상이 없습니다. 인구조사 데이터는 이 둘이 얼마나 자주 혼동되는지를 보여줍니다: 2026-08-16 기준, 등급이 매겨진 276백만 개 도메인 중 **51.24%**가 SPF를 게시하지만, DMARC를 시행하는 곳은 **11.83%**뿐입니다 — 1단계를 마치고 다 끝났다고 믿는 수천만 개 비즈니스의 격차입니다.

SPF가 실제로 하는 일

SPF(Sender Policy Framework)는 도메인을 대신해 메일을 보낼 수 있는 서버 — 메일박스 제공업체, 뉴스레터 도구, CRM — 를 나열하는 단 하나의 DNS TXT 레코드입니다. 메일 서버가 당신에게서 왔다고 주장하는 메시지를 받으면, 그 메시지를 전달한 서버가 목록에 있는지 확인합니다.

여기서 두 가지 세부 사항이 중요한데, SPF의 한계를 규정하기 때문입니다:

• SPF는 기술적 발신자를 확인하지, 눈에 보이는 발신자를 확인하지 않습니다. SPF가 검증하는 주소는 봉투(envelope) 발신자(“Return-Path” — 반송 메일이 가는 주소)입니다. 사람이 받은편지함에서 읽는 “From” 줄은 전혀 보지 않습니다. 이 두 주소는 완전히 다를 수 있고, 대부분의 사기에서 실제로 다릅니다.
• SPF는 실패 시 어떻게 할지 말해주지 않습니다. 레코드는 목록에 없는 발신자를 수신자가 어떻게 처리할지 제안하는 한정자(-all 또는 ~all)로 끝나지만, 구속력 있는 지시도, 당신에게 오는 피드백도 없습니다. SPF가 있는 도메인 중 엄격한 -all을 쓰는 곳은 39.2%에 불과하고, 55.9%는 대부분의 수신자가 그냥 배달해 버리는 ~all을 씁니다.

SPF는 필수적인 배관입니다. 하지만 그 자체로는 보호가 아닙니다 — 데이터가 이 점을 노골적으로 보여줍니다: 전체 도메인의 30.9%가 SPF를 게시하지만 DMARC가 전혀 없습니다 (잘못된 안전감의 격차, 실측).

DMARC가 실제로 하는 일

DMARC(Domain-based Message Authentication, Reporting and Conformance)는 SPF와 DKIM 위에 얹혀, 이 둘에게 없는 세 가지를 더합니다:

1. 사람들이 보는 주소를 보호합니다. DMARC는 *정렬(alignment)*을 요구합니다: SPF 또는 DKIM을 통과한 도메인이 눈에 보이는 “From” 헤더의 도메인과 일치해야 합니다. 이것이 SPF가 열어둔 틈을 닫습니다 — 공격자가 자기 인프라에서 SPF를 통과시키면서 당신의 이름을 표시하는 일이 더는 불가능해집니다.
2. 실패 시 수신자에게 무엇을 할지 알려줍니다. DMARC 레코드는 정책을 게시합니다: p=none(일단 배달하고 보고만), p=quarantine(스팸 폴더), 또는 p=reject(거부). 이것이 SPF에는 없던 시행 계층입니다.
3. 당신에게 보고합니다. 수신자는 누가 당신의 도메인 이름으로 메일을 보내고 있는지 — 정당하든 아니든 — 보여주는 집계 보고서를 보냅니다. 이 표준들 가운데 피드백 루프가 있는 것은 DMARC뿐이며, 나머지를 안전하게 조일 수 있는 방법이기도 합니다.

단, 함정이 있습니다: DMARC는 quarantine 또는 reject에서만 보호합니다. p=none에 주차된 레코드는 모니터링만 할 뿐 아무것도 하지 않습니다 — p=none은 보호가 아닙니다. 2026-08-16 기준, 도메인의 74.20%는 DMARC 레코드가 없고, 13.96%는 모니터링 전용에 머물러 있으며, 시행하는 곳은 단 11.83%입니다.

SPF vs DMARC 나란히 비교

한 줄 요약: SPF는 경로를 인증하고, DMARC는 정체성을 보호합니다. 수신자는 SPF를 여러 신호 중 하나로 참고합니다. 시행 상태의 DMARC는 결정입니다.

SPF만으로 부족한 이유

구현 버그가 아니라 구조적인 세 가지 이유입니다:

From 헤더 공백. SPF는 “From” 줄을 절대 검사하지 않습니다. 사기꾼이 scammer-domain.com 인프라에서 눈에 보이는 From 필드에 당신 회사를 넣어 발송하면: SPF는 그들의 봉투 도메인을 그들의 SPF 레코드에 대조해 깔끔하게 통과시키고, 위조 메일은 진짜처럼 보이는 채로 도착합니다. 이를 잡는 것은 DMARC의 정렬 요구뿐입니다 — 그래서 이메일 스푸핑이 SPF 전용 도메인을 상대로 여전히 일상적으로 일어나고, 등급이 매겨진 도메인의 88.17%가 여전히 사칭될 수 있는 이유입니다.

전달(포워딩). 누군가 당신의 메일을 자동 전달하면(옛 주소에서 새 주소로, 배포용 별칭 등), 전달 서버가 메일을 배달합니다 — 그런데 그 서버는 당신의 SPF 레코드에 없으므로, 완전히 정당한 메일에서 SPF가 실패합니다. 이것은 설정 오류가 아니라 전달이 작동하는 방식 자체입니다. DKIM 서명은 전달을 견디기 때문에, (정렬된 SPF 또는 정렬된 DKIM 중 하나로 통과하는) DMARC는 이를 처리하고 순수 SPF는 처리하지 못합니다. 자세한 내용: 전달은 SPF를 깨뜨립니다.

결과도, 피드백도 없음. -all이 달린 완벽한 SPF 레코드조차 각 수신자가 조치를 선택하는 데 의존하며, 당신 이름으로 무엇이 발송되는지 아무것도 알려주지 않습니다. DMARC는 이를 명시적 지시와 보고서로 바꿉니다.

어떤 순서로 배포할 것인가

DMARC는 SPF와 DKIM이 만들어내는 결과를 소비하므로 순서가 중요합니다. 위에서부터 차례로:

1. SPF 먼저. 모든 정당한 발신자를 나열한 TXT 레코드 하나를 게시하고, 검증하는 동안은 ~all, 완료되면 -all로 끝맺습니다. SPF 수정하기.
2. DKIM 두 번째. 메일 제공업체에서 서명을 켭니다 — 전달을 거쳐도 인증을 온전하게 유지해 주는 것이 바로 이것입니다. DKIM 수정하기.
3. p=none의 DMARC, 보고 포함. v=DMARC1; p=none; rua=mailto:...를 게시하고 보고서를 실제로 읽으세요 — 놀랄 만큼 많은 도메인이 보고 주소 없이 눈을 감은 채 DMARC를 게시합니다. 제공업체별 단계: Google Workspace · Microsoft 365.
4. 보고서에서 정당한 메일이 통과하는 것이 확인되면 quarantine으로, 그다음 reject로 조입니다. 이 단계가 곧 보호이고, 그 전의 모든 것은 준비입니다. 안전한 진행 경로.

순서를 건너뛰면 양방향으로 문제가 생깁니다. SPF/DKIM 이전의 DMARC는 당신 자신의 정당한 메일을 격리시킵니다. SPF만 하고 멈추기 — 가장 흔한 최종 상태로, 전체 도메인의 30.9% — 는 눈에 보이는 From 주소를 열어둡니다. 모든 단계를 완료하는 도메인은 단 **2.79%**입니다.

솔직한 예외 사례들

• 메일링 리스트는 둘 다 깨뜨릴 수 있습니다. 제목을 고쳐 쓰거나 푸터를 덧붙이는 리스트는 DKIM 서명을 무효화하고 동시에 SPF도 실패시킵니다(리스트 서버가 발송하므로). 현대적인 리스트는 이를 보완하려고 From 헤더를 다시 씁니다. 커뮤니티가 메일링 리스트 위에서 살아간다면 reject에서 어느 정도의 진통을 예상하세요 — 관리 가능한 수준이지, none에 머무를 이유는 아닙니다.
• SPF는 통과하는데 DMARC는 실패할 수 있습니다. 많은 발송 플랫폼이 자기 도메인을 봉투 발신자로 쓰기 때문에 SPF는 통과하지만 — 당신의 From 도메인과는 비정렬 상태입니다. 그런 메일이 DMARC를 통과하려면 정렬된 DKIM(좋은 플랫폼이라면 지원하는 커스텀 서명 도메인)이 필요합니다. SPF와 DKIM은 통과하는데 DMARC가 실패한다면, 거의 언제나 정렬이 원인입니다.
• SPF에는 10회 조회 제한이 있습니다. include: 항목을 너무 많이 연결하면 레코드가 영구 오류를 반환하며 통째로 무시됩니다. DMARC를 조이기 전에 통합하세요. 그러지 않으면 깨진 SPF 위에 시행을 얹게 됩니다.
• 이메일을 전혀 보내지 않는 도메인에도 둘 다 필요합니다 — 그것도 가장 엄격한 버전(v=spf1 -all과 p=reject)으로 — 그렇지 않으면 주차된 도메인과 미사용 도메인이 위조하기 가장 쉬운 도메인이 됩니다.
• DMARC가 끝이 아닙니다. DMARC는 정확히 같은 도메인의 사칭을 막습니다. 유사 도메인, 표시 이름 속임수, 탈취된 진짜 메일박스는 별개의 문제입니다 — 실재하지만, DNS 레코드 세 개로 차단할 수 있는 유일한 공격 유형을 건너뛸 이유는 아닙니다.

자주 묻는 질문

DMARC와 SPF는 같은 것인가요? 아닙니다. SPF는 승인된 발송 서버의 목록으로, 독자가 결코 보지 못하는 주소에 대해 확인됩니다. DMARC는 인증된 주체가 눈에 보이는 “From” 주소와 일치하는지 확인하고, 실패 시 당신이 선택한 정책을 적용하며, 당신에게 보고합니다.

이미 SPF가 있는데 DMARC도 필요한가요? 예. SPF만으로는 눈에 보이는 From 주소를 보호하지 못합니다 — 도메인의 30.9%가 SPF는 있고 DMARC가 없으며, 여전히 위조 가능한 상태입니다. SPF는 DMARC의 전제 조건이지 대체물이 아닙니다.

SPF 없이 DMARC를 쓸 수 있나요? DKIM이 마련되어 있다면 기술적으로는 가능합니다 — DMARC는 정렬된 메커니즘 둘 중 하나만 통과해도 됩니다. 실제로는 둘 다 밑에 두는 것이 좋습니다: SPF는 DKIM이 놓치는 것을 잡고 그 반대도 마찬가지입니다(전달이 DKIM만 살아남는 고전적인 사례입니다).

무엇을 먼저 설정해야 하나요? SPF, 그다음 DKIM, 그다음 보고를 켠 p=none의 DMARC, 그다음 시행입니다. DMARC를 안전하게 조이려면 앞의 둘이 먼저 작동해야 합니다.

둘 중 비용이 드는 것이 있나요? 아니요 — SPF, DKIM, DMARC는 모두 무료 DNS 레코드입니다. 투자되는 것은 예산이 아니라 주의와 순서입니다. (DMARC 보고서 읽기는 무료 또는 유료 보고서 뷰어가 있으면 더 쉽지만, 보호 자체에는 비용이 들지 않습니다.)

내 도메인의 현재 위치 확인하기

대부분의 도메인은 목록만 있고 잠금장치가 없습니다. 무료로, 비공개로 확인하세요 — SPF, DKIM, DMARC 상태를 한눈에 보고, 다음 단계가 무엇인지 알 수 있습니다.

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