SPF/DKIM/DMARC 레코드 검사기

도메인을 입력하면 SPF·DMARC·DKIM 레코드를 실시간으로 조회하여 스푸핑 방지 이메일 인증 설정 상태를 진단합니다.

마지막 업데이트: 2026-09-20

사칭을 막는 DNS 설정을 진단하기

도메인을 넣기만 하면 이 도구가 그 도메인의 SPF·DKIM·DMARC 레코드를 그 자리에서 조회하여, 사칭 메일에 대한 대비가 어디까지 갖춰졌는지를 보고합니다. 내 도메인이 남에게 사칭당하기 쉬운지, 또 내가 보내는 메일이 받는 쪽의 믿음을 얻을지를 확인할 수 있습니다.

**이 셋은 맡은 몫이 달라, 어느 하나만으로는 모자랍니다.** SPF는 그 도메인의 이름으로 보내도 되는 서버를 밝히고, DKIM은 본문이 고쳐지지 않았음을 서명으로 담보합니다. **그리고 DMARC는 그 두 검사를 통과하지 못한 메일을 어떻게 다룰지를 받는 쪽에 일러 주는** 몫을 맡습니다. 요긴한 대목이 여기입니다. **SPF와 DKIM을 두었더라도 DMARC가 없으면, 검사를 통과하지 못한 사칭 메일을 어찌할지가 온전히 받는 쪽의 재량에 맡겨집니다.** DMARC를 `p=none`인 채로 둔 도메인도 많은데, 이는 「보고만 받고 아무것도 막지 않는다」는 뜻이어서 대비가 아직 길 위에 있는 상태입니다.

사용하는 방법

살펴볼 도메인을 넣습니다 `example.com`처럼 도메인만 넣으면 됩니다.
SPF의 내용을 확인합니다 **허용한 발신처의 목록과, 끝의 한정자가 `~all`인지 `-all`인지를 보십시오.**
DMARC의 정책을 읽습니다 **`p=none`이라면 아직 아무것도 막고 있지 않습니다.**
모자란 레코드를 더합니다 진단의 결과가 DNS에 무엇을 더할지 정하는 바탕이 됩니다.

더 잘 활용하기 위한 팁

SPF, DKIM, DMARC 순서로 설정하는 것이 정석입니다. 먼저 SPF와 DKIM을 정비하고 마지막에 DMARC로 수신자에게 처리 지침을 명확히 하세요.
DMARC는 처음부터 p=reject로 설정하지 말고, 먼저 p=none으로 리포트를 수집해 모든 정상 발신 경로를 파악한 뒤 단계적으로 강화하면 사고를 예방할 수 있습니다.
include가 많은 도메인은 "DNS 조회 10회/255자" 제한에 걸려 조회가 실패할 수 있으므로, 불필요한 include는 정기적으로 정리하세요.
이 도구는 대표적인 DKIM 셀렉터만 시도하므로, "찾을 수 없음"으로 표시되어도 실제로는 다른 셀렉터가 사용되고 있을 뿐일 수 있습니다.
Gmail, Outlook 등 주요 수신 서버는 2024년부터 대량 발신자에게 SPF·DKIM·DMARC 정비를 의무화했으므로, 뉴스레터를 발송하는 도메인은 이 설정을 우선 확인해야 합니다.

이럴 때 쓸 수 있습니다

우리 도메인의 대비를 확인할 때

**사칭의 피해는 아무 대비도 없는 도메인부터 노립니다.**

내 메일이 스팸으로 다뤄지는 까닭을 찾을 때

메일이 닿지 않을 때 먼저 의심할 곳이 SPF나 DKIM의 미비입니다.

발송 서비스를 더한 뒤 확인할 때

**새 발송 서비스를 쓰기 시작했다면 SPF에 더하는 것을 잊지 않았는지 살핍니다.**

거래처의 도메인을 살필 때

받은 메일이 참인지를 가늠할 재료가 됩니다.

메일 인증 용어

SPF: **그 도메인의 이름으로 보내도 되는 서버를 늘어놓는** DNS 레코드입니다. 끝의 `-all`은 늘어놓지 않은 것은 물리라는 뜻입니다.
DKIM: 보낼 때 붙이는 전자 서명입니다. **받는 쪽이 공개 키로 본문과 헤더가 도중에 고쳐지지 않았음을 확인할 수 있습니다.**
DMARC: **SPF와 DKIM 검사를 통과하지 못한 메일을 어떻게 다룰지 받는 쪽에 일러 주는** 레코드입니다.
p=none: DMARC 정책의 하나로, **보고는 받되 물리지도 격리하지도 않는** 상태입니다. 막 들이기 시작한 단계의 설정입니다.
p=quarantine과 p=reject: 각각 「스팸으로 따로 두라」와 「아예 물리라」를 이릅니다. **여기까지 나아가는 것이 이 일의 목표입니다.**
셀렉터: DKIM 공개 키를 DNS의 어디에 두었는지를 밝히는 이름입니다. `selector._domainkey.example.com` 꼴로 참조됩니다.

자주 묻는 질문

반드시 필수는 아니지만, 세 가지를 함께 갖춰야 비로소 "발신자의 정당성을 증명하고(SPF/DKIM), 실패 시 처리 방법을 수신 측에 지시할 수 있는(DMARC)" 일관된 방어가 완성됩니다. 하나만 설정하면 효과가 제한적이므로 순서대로 정비하는 것을 권장합니다.

꼭 그렇지는 않습니다. DKIM 셀렉터 이름은 발신 서비스마다 자유롭게 정할 수 있어, 이 도구가 시도하는 대표적인 이름(default·google 등)과 일치하지 않으면 "찾을 수 없음"으로 표시됩니다. 정확히 확인하려면 발신 메일 서비스의 관리자 화면이나 메일 헤더의 DKIM-Signature 항목을 확인하세요.

권장하지 않습니다. 정상적인 발신 경로(뉴스레터 발송 서비스나 업무 시스템 등)를 아직 완전히 파악하지 못한 상태에서 reject로 설정하면 정상 메일까지 거부될 위험이 있습니다. 먼저 p=none으로 몇 주간 리포트를 수집해 문제가 없음을 확인한 뒤 quarantine, reject 순으로 단계적으로 강화하는 것이 안전합니다.

최종적으로는 -all(Fail, 명확한 거부)이 권장되지만, SPF 설정에 아직 확신이 없는 전환기에는 ~all(SoftFail, 의심스러움으로 처리)을 사용해 정상 메일이 잘못 차단되지 않는지 확인한 후 -all로 전환하는 방법이 안전합니다.

아니요. 입력한 도메인에 대한 DNS 조회는 그때그때 즉시 이루어지며, 가져온 레코드 정보를 서버에 저장하지 않습니다.

여담이지만 ― 스푸핑 방지 3대 축이 만들어지기까지

SPF, DKIM, DMARC는 각각 다른 시기, 다른 배경에서 등장한 기술입니다. 가장 먼저 등장한 SPF(2003년경)는 "어떤 IP 주소에서 이 도메인 이름으로 메일을 보내도 되는지"를 선언하는 방식으로, 발신자 주소를 위조하는 스패머에 대한 대응책으로 확산되었습니다. 하지만 SPF는 메일 전달(포워딩)에 취약해, 전달되면 발신 IP가 바뀌어 인증이 깨지는 약점이 있었습니다.

이 약점을 보완한 것이 2007년경 표준화된 DKIM입니다. SPF처럼 IP 주소로 판단하는 대신 메일 본문과 헤더 일부에 전자 서명을 붙이고, 수신 측이 DNS에 공개된 공개 키로 서명을 검증하는 방식이라 전달되더라도 서명 자체만 훼손되지 않으면 인증이 유지됩니다.

다만 SPF와 DKIM은 "인증에 실패했다"는 사실만 감지할 수 있을 뿐, 실패한 메일을 어떻게 처리할지(전달·스팸 처리·거부)는 전적으로 수신 서버에 맡겨져 있었습니다. 이 "수신 측에 대한 지침"을 통일하기 위해 2012년에 제정된 것이 DMARC입니다. DMARC는 인증 결과를 발신 도메인 관리자에게 리포트(rua=)로 되돌려주는 기능도 갖추고 있어, 자사 도메인이 부정 이용되고 있지 않은지 지속적으로 모니터링할 수 있게 되었습니다.

2024년 구글과 야후가 대량 발신자(하루 5,000통 이상)에게 SPF·DKIM·DMARC 정비를 사실상 필수 요건으로 정하면서, 이 3대 축은 일부 대기업만의 지식이 아니라 뉴스레터나 시스템 알림 메일을 보내는 모든 사업자가 알아야 할 기본 상식이 되었습니다.

모든 여담 보기