SPF, DKIM, DMARC의 차이점은 무엇입니까?

SPF는 무슨 역할을 합니까?

SPF는 하나의 질문에 답합니다. 이 메시지를 전달한 서버가 이 도메인을 대신해 발송할 수 있는가? 도메인 소유자는 v=spf1로 시작하고 허용된 출처를 나열하는 TXT 레코드를 게시합니다. 예를 들어 Proton Mail은 include:_spf.protonmail.ch입니다. 수신자는 접속한 IP 주소를 목록과 비교하여 끝의 한정자(-all, ~all, ?all)에 따라 통과, 실패, 소프트페일, 중립이라는 결과를 얻습니다.

SPF는 엔벨로프 발신자(MAIL FROM)와 HELO 이름을 검사하며, 독자가 보는 From 주소는 검사하지 않습니다. 이 틈이 DMARC가 존재하는 이유입니다. SPF에는 엄격한 제한도 있습니다. 도메인에는 SPF 레코드가 하나만 있어야 하고, DNS를 조회하는 항목(include, a, mx, ptr, exists, redirect) 10개 이후에 평가가 영구 오류로 중단됩니다. 전체 방법은 SPF 레코드 만들기 가이드에 있습니다.

DKIM은 무슨 역할을 합니까?

DKIM은 다른 질문에 답합니다. 이 메시지는 주장하는 도메인이 서명했는가, 그리고 변경 없이 도착했는가? 발신 서버가 선택한 헤더와 본문을 개인 키로 서명합니다. 수신자는 DKIM-Signature 헤더에서 서명 도메인(d=)과 셀렉터(s=)를 읽고, DNS의 selector._domainkey.domain에서 공개 키를 가져와 서명을 검증합니다.

서명이 메시지와 함께 이동하므로, DKIM은 메시지를 그대로 두는 전달에서도 유지되지만 SPF는 그렇지 않습니다. 전달 서비스가 자신의 IP 주소로 발송하기 때문입니다. RFC 6376은 서명자가 오래 쓰는 키에는 최소 1024비트의 RSA 키를 사용해야 한다고 설명하며, 키가 바뀔 때는 새 셀렉터를 권장합니다. 제공업체가 키를 대신 게시합니다. Proton Mail과 Fastmail은 CNAME 레코드 3개, Mailbox.org는 4개입니다. 자세한 내용은 DKIM 설정 가이드에 있습니다.

DMARC는 무슨 역할을 합니까?

DMARC는 SPF와 DKIM을 보이는 From 도메인에 묶고, 어느 검사도 일치하지 않을 때 수신자가 어떻게 할지 알려 줍니다. SPF 또는 DKIM이 통과하고 인증된 도메인이 From 도메인과 일치하면 메시지는 DMARC를 통과합니다. 정렬은 기본적으로 완화(같은 조직 도메인)이며, aspf=s 또는 adkim=s로 설정하면 엄격해집니다.

레코드는 _dmarc.yourdomain에 있고 정책을 담습니다. p=none(모니터링만), p=quarantine(의심스러운 것으로 처리), p=reject(거부). rua 주소는 집계 보고서를 받으며, 보고서는 내 이름으로 메일을 보내는 주체를 보여 줍니다. 2026년 5월에 발행된 RFC 9989가 현재 명세이며, RFC 7489를 대체하고 pct 태그를 제거하고 t 테스트 플래그를 추가합니다. 모니터링에서 거부까지의 도입 순서는 DMARC 설정 가이드에 있습니다.

세 가지가 모두 필요합니까?

예. 메일을 보내는 사용자 지정 도메인은 SPF, DKIM, DMARC를 게시해야 합니다. 주요 수신자가 이를 요구하기 때문입니다. Google의 발신자 지침은 Gmail 계정으로 하루 5,000통을 넘게 보내는 발신자에게 SPF, DKIM, DMARC 레코드(정책 none으로 충분)를 요구합니다. Microsoft는 2025년 5월 5일부터 하루 5,000통을 넘는 Outlook.com 발신자에게 같은 세 가지를 요구하고, Yahoo도 대량 발신자에게 SPF, DKIM, DMARC를 요구합니다.

개인 메일함은 보내는 메시지가 훨씬 적으므로 기준이 적용되지 않습니다. 그래도 레코드는 메일이 받은편지함에 도착하는지를 좌우하며, 다른 사람이 내 주소를 위조하는 것을 막아 줍니다. 2026-11-12 Postelva의 제공업체 도움말 페이지 집계에 따르면 전체 Proton Mail 설정에는 DNS 레코드 8개, 전체 Mailbox.org 설정에는 11개가 필요하며, 그중 각각 3개와 4개가 DKIM 키입니다. MX 레코드는 MX 레코드란 무엇인가에서 다룹니다.

세 레코드를 망가뜨리는 실수는 무엇입니까?

대부분의 실패는 세 가지 실수에서 비롯됩니다. 두 번째 SPF 레코드, 10번을 넘는 조회, 너무 일찍 너무 엄격하게 설정한 DMARC 정책입니다. SPF 레코드가 둘인 도메인은 영구 오류를 반환하므로, 기존 레코드에 새 제공업체의 include를 추가하십시오. 메일 호스트, 뉴스레터 도구, 헬프데스크를 쌓으면 조회 횟수가 10번을 넘을 수 있으며, 그러면 레코드는 모든 발신자에게 실패합니다. Mailbox.org와 Proton 모두 DMARC를 p=none에서 시작하라고 권하며, Mailbox.org는 너무 일찍 적용한 엄격한 정책이 정상 메일을 반송시킬 수 있다고 경고합니다.

네 번째 실수는 이전 제공업체의 DKIM과 SPF 항목을 몇 달 동안 그대로 두는 것입니다. 배달에는 해가 없지만 나를 대신해 말할 수 있는 서버의 목록이 넓어집니다. 이전이 확인되면 제거하십시오.

세 가지는 하나의 메시지에서 어떻게 함께 작동합니까?

수신자가 SPF와 DKIM을 실행하고 DMARC가 그 결과를 결합합니다. Proton Mail을 통해 보낸 [email protected]의 메시지를 예로 들겠습니다. 접속한 서버가 _spf.protonmail.ch 목록에 있으면 SPF가 통과합니다. yourname.com의 키로 만든 서명이 검증되면 DKIM이 통과합니다. 그러면 DMARC는 둘 중 적어도 하나가 yourname.com을 정렬된 식별자로 하여 통과했는지 묻습니다. 그렇다면 메시지는 통과하고, 그렇지 않다면 수신자가 내 정책을 적용하고 결과를 다음 집계 보고서에 기록합니다.

RFC 9989는 p=reject인 도메인이 SPF에만 의존해서는 안 되며 DKIM으로 서명해야 한다고 설명합니다. SPF는 전달 시 깨지기 때문입니다. 실험적 표준인 ARC(RFC 8617)는 전달 서비스가 원래의 결과를 기록하게 해 주지만, 내 설정의 일부는 아닙니다. 레코드를 게시한 후에는 어떤 정책이든 강화하기 전에 dig로 확인하십시오.

인용 가능한 정의: SPF는 서버를 승인하고, DKIM은 메시지를 인증하며, DMARC는 From 도메인과의 일치를 강제하고 결과를 보고합니다.