SPF/DKIM/DMARC 레코드 검사기
도메인을 입력하면 SPF·DMARC·DKIM 레코드를 실시간으로 조회하여 스푸핑 방지 이메일 인증 설정 상태를 진단합니다.
팁
- SPF, DKIM, DMARC 순서로 설정하는 것이 정석입니다. 먼저 SPF와 DKIM을 정비하고 마지막에 DMARC로 수신자에게 처리 지침을 명확히 하세요.
- DMARC는 처음부터 p=reject로 설정하지 말고, 먼저 p=none으로 리포트를 수집해 모든 정상 발신 경로를 파악한 뒤 단계적으로 강화하면 사고를 예방할 수 있습니다.
- include가 많은 도메인은 "DNS 조회 10회/255자" 제한에 걸려 조회가 실패할 수 있으므로, 불필요한 include는 정기적으로 정리하세요.
- 이 도구는 대표적인 DKIM 셀렉터만 시도하므로, "찾을 수 없음"으로 표시되어도 실제로는 다른 셀렉터가 사용되고 있을 뿐일 수 있습니다.
- Gmail, Outlook 등 주요 수신 서버는 2024년부터 대량 발신자에게 SPF·DKIM·DMARC 정비를 의무화했으므로, 뉴스레터를 발송하는 도메인은 이 설정을 우선 확인해야 합니다.
자주 묻는 질문
여담이지만 ― 스푸핑 방지 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대 축은 일부 대기업만의 지식이 아니라 뉴스레터나 시스템 알림 메일을 보내는 모든 사업자가 알아야 할 기본 상식이 되었습니다.