이메일 헤더에서 SPF, DKIM 및 DMARC 결과를 읽는 방법
Once Email 편집팀검토 Once Email 한국어 편집 검토
글 안내
이 글을 읽을 가치
- 독창적 분석
- 우리는 인증 신원, 정렬 및 메시지 안전성을 구별한 다음 모든 패스를 신뢰로 취급하지 않고 결합된 SPF, DKIM 및 DMARC 증거를 해석합니다.
- 동향 설명
- 최신 DMARC 작업을 포함하여 이메일 인증 표준 및 배포 지침은 계속 발전하고 있으며 눈에 보이는 발신자 신원을 해석하는 데 있어 정렬은 여전히 핵심입니다.
- 실용적 가치
- 독자는 공통 결과 필드를 읽고 메커니즘이 불일치하는 이유를 이해하며 헤더 증거가 컨텍스트 및 독립적 검증과 결합되어야 하는 시기를 알 수 있습니다.
이 페이지의 내용
이메일 헤더에는 SPF, DKIM 및 DMARC 결과가 포함되는 경우가 많습니다. 이러한 메커니즘은 전달과 관련된 도메인 및 시스템에 대한 증거를 제공합니다. 그들은 모든 종류의 속임수를 검사하지 않으며 메시지, 보낸 사람 또는 링크가 안전하다는 것을 증명하지 않습니다.
이 가이드에서는 Once Email 이메일 헤더 분석기 . 분석기는 브라우저에 로컬로 붙여넣은 텍스트를 읽습니다. DNS, 평판, 맬웨어 또는 실시간 정책 조회를 수행하지 않습니다.
SPF: 이 시스템은 봉투 도메인에 대해 승인되었습니까?
보낸 사람 정책 프레임워크를 사용하면 도메인에서 SPF ID를 사용하여 보낼 수 있는 권한이 있는 시스템을 게시할 수 있습니다. 수신 시스템은 연결된 발신자를 게시된 정책과 비교하고 pass, fail, softfail, neutral 또는 none와 같은 결과를 기록합니다.
SPF는 단순히 사람이 보이는 보낸 사람 필드에 보이는 주소를 확인하는 것이 아닙니다. DMARC는 SMTP MAIL FROM ID에 대한 SPF 결과를 사용한 다음 해당 도메인이 표시되는 작성자 도메인과 일치하는지 평가합니다.
전달 서버가 최종 수신기에 연결되는 시스템이 되므로 전달은 SPF를 복잡하게 만들 수 있습니다. 따라서 실패한 SPF 결과에는 컨텍스트가 필요합니다. 그 자체로는 메시지에 대한 완전한 평결이 아닙니다.
DKIM: 메시지의 서명된 부분이 검증되었나요?
DomainKeys Identified Mail은 서명 도메인과 연결된 암호화 서명을 추가합니다. 수신자는 DNS에서 공개 키를 검색하고 서명된 헤더 필드와 본문이 여전히 유효한지 확인합니다.
DKIM 패스는 서명된 자료가 서명 도메인에 대해 검증되었다는 증거입니다. 표시 이름이 정직하다는 것, 눈에 보이는 모든 요소에 서명이 있었다는 것, 링크된 웹사이트가 안전하다는 것은 입증되지 않습니다. 메일링 시스템은 서명을 깨는 방식으로 메시지를 합법적으로 수정할 수도 있습니다.
DMARC: 인증된 신원이 표시되는 작성자 도메인과 일치합니까?
DMARC는 SPF 및 DKIM을 기반으로 합니다. 인증된 SPF 또는 DKIM 도메인을 표시되는 보낸 사람 주소의 도메인과 비교하고 도메인 소유자의 게시된 정책 및 수신자 정책을 적용합니다.
현재 IETF 사양인 RFC 9989에서는 DMARC가 도메인 수준 식별자를 인증하고 표시 이름 공격을 해결하거나 메시지 내용을 분석하지 않는다고 설명합니다. 이는 2026년 5월에 이전 RFC 7489를 대체했습니다.
2026 DMARC 개정판에서 변경된 사항
RFC 9989는 모든 메시지 시스템이 2026년에 갑자기 동작을 변경했다는 증거는 아닙니다. 이는 현재 프로토콜 정의를 통합하고 RFC 7489 및 RFC 9091을 명시적으로 폐기하며 집계 및 오류 보고서 형식을 동반 사양으로 분리합니다. 실제 읽기 규칙은 안정적으로 유지됩니다. DMARC 통과는 표시되는 작성자 도메인의 사용이 허가된 정렬된 SPF 또는 DKIM ID를 의미합니다. 이는 평판 점수, 메시지 작성자에 대한 신원 확인, 링크 및 첨부 파일 스캔이 아닙니다.
이러한 구별은 제품 발표에서 "새로운 DMARC 요구 사항"을 해석할 때 중요합니다. 공급자는 기본 프로토콜과 관계없이 배달 정책이나 대량 발송인 요구 사항을 변경할 수 있습니다. 예를 들어 Gmail의 발신자 가이드라인은 전송량에 따라 다양한 인증 요구 사항을 적용합니다. 공급자 정책, 프로토콜 유효성 검사 및 메시지 안전을 세 개의 별도 계층으로 처리합니다.
DMARC 패스는 필수 정렬과 함께 전달된 하나 이상의 지원되는 인증 경로를 의미합니다. 작성자가 개인적으로 확인되었거나 계정이 손상되지 않았거나 메시지가 무해하다는 의미는 아닙니다.
인증 결과 읽기
단순화된 헤더는 다음과 같습니다.
Authentication-Results: mx.example;
spf=pass smtp.mailfrom=mailer.example;
dkim=pass header.d=mailer.example;
dmarc=pass header.from=mailer.example
다음 값을 함께 검토하세요.
Authentication-Results필드를 작성한 서버는 무엇입니까?- SPF를 통과한 도메인은 무엇입니까?
- DKIM으로 서명된 도메인은 무엇입니까?
- 표시되는 보낸 사람 주소에는 어떤 도메인이 표시됩니까?
- DMARC는 정렬, 실패 또는 정책 없음을 보고합니까?
- 예상한 발송인에게 배송 경로가 적합합니까?
여러 시스템이 메시지를 처리했기 때문에 헤더에는 여러 결과 필드가 포함될 수 있습니다. 가장 최근에 신뢰할 수 있는 수신자의 결과가 가장 관련성이 높은 경우가 많지만 어느 중개자를 신뢰할 수 있는지 결정하려면 사서함 공급자와 배달 경로에 대한 지식이 필요합니다.
통행증이 안전 보장이 아닌 이유
공격자는 자신이 제어하는 도메인을 인증할 수 있습니다. 합법적인 발신자의 계정이 손상될 수 있습니다. 올바르게 인증된 메시지에도 오해의 소지가 있는 요청, 악성 첨부 파일 또는 위험한 링크가 포함될 수 있습니다.
Gmail 발신자 가이드라인에서는 전송량에 따라 서로 다른 인증 제어를 요구하며 인증을 전달 가능성 및 악용 방지 조치로 설명합니다. 인증을 일반적인 콘텐츠 안전 판정으로 바꾸지는 않습니다.
메시지에서 자격 증명, 금전, 긴급 조치 또는 민감한 파일을 요구하는 경우 알려진 연락 채널을 통해 요청을 확인하세요. 발신자 이름이나 녹색 인증 결과에만 의존하지 마십시오.
분석기를 보수적으로 사용하세요
메시지 본문이나 첨부 파일이 아닌 헤더 필드만 붙여넣으세요. 분석기의 요약을 메시지가 도착한 컨텍스트와 비교합니다. 누락, 기형 또는 상충되는 증거를 사기에 대한 자동 증거가 아닌 추가 확인 사유로 간주합니다.
사고 대응, 도메인 구성 또는 영향력이 큰 결정의 경우 사서함 공급자의 원본 메시지 보기를 사용하고 자격을 갖춘 전자 메일 관리자 또는 보안 전문가에게 문의하세요.