SPF, DKIM, DMARC란? 쉽게 정리한 설명

SPF, DKIM, DMARC는 이메일에 대해 각각 다른 질문에 답하는 세 가지 DNS 레코드입니다. SPF(Sender Policy Framework)는 도메인의 메일을 보낼 수 있는 서버를 나열합니다. DKIM(DomainKeys Identified Mail)은 각 메시지에 서명을 붙여, 수신 측이 발송 후 아무것도 변경되지 않았는지 확인할 수 있게 합니다. DMARC(Domain-based Message Authentication, Reporting and Conformance)는 이 둘 중 적어도 하나가 From 주소의 도메인과 일치하는지 확인하고, 둘 다 일치하지 않을 때 수신 측이 어떻게 처리할지 알려 줍니다. 2024년부터 이 레코드는 선택 사항이 아니게 되었습니다. Gmail과 Outlook.com은 이제 이 검사에 실패한 메일 중 상당수를 스팸함에 넣는 데 그치지 않고 거부합니다.

이제 생략할 수 없는 이유

Google은 2024년 2월 1일부터 개인 Gmail 계정으로 이메일을 보내는 모든 발신자에게 필수 발신자 규칙을 도입했습니다. 이 기본 요구 사항에 따라 모든 발신자는 SPF 또는 DKIM을 설정해야 합니다. 또한 발송 IP에 대해 PTR 레코드가 일치하는 유효한 정방향 및 역방향 DNS를 설정하고, 전송 시 TLS 암호화를 사용하고, RFC 5322 규격을 따라야 합니다. Google Postmaster Tools의 스팸률은 0.3% 미만을 유지해야 하며, Google은 0.1% 미만을 권장합니다. 인증되지 않은 메일을 보내면 메시지가 스팸함에 들어가거나 오류 코드 5.7.26으로 거부될 수 있다고 Google은 경고합니다.

개인 Gmail 주소로 하루 5,000건 이상을 보내면 Google은 대량 발신자로 분류하며, 규칙이 더 엄격해집니다. 대량 발신자는 SPF와 DKIM 중 하나를 고를 수 없고, 둘 다 설정해야 합니다. 또한 DMARC 레코드를 게시하고, 보이는 From 헤더와 SPF 또는 DKIM 사이의 도메인 정렬(alignment)을 유지하고, 마케팅 메일에는 작동하는 원클릭 구독 취소 기능을 넣어야 합니다. Google은 이 5,000건 기준을 기본 도메인과 모든 하위 도메인을 합쳐 24시간 단위로 계산합니다. 도메인이 한 번 이 기준에 도달하면 Google은 대량 발신자 상태를 영구적인 것으로 봅니다. 2025년 11월부터 Gmail은 규칙을 지키지 않는 트래픽에 대한 조치를 강화하기 시작했으며, 일시적인 전송 지연과 영구적인 거부로 대응하고 있습니다. 이 가이드라인은 개인 Gmail 계정에 적용되며, Google Workspace 비즈니스 메일함에는 적용되지 않습니다.

Microsoft는 2025년 5월 5일, 일반 소비자용 Outlook.com, Hotmail, Live 계정으로 하루 5,000건 이상을 보내는 발신자에게 자체 인증 규칙을 적용하기 시작했습니다. 이 기준에 해당하는 발신자는 SPF 검사를 통과하고, DKIM 서명을 통과하고, SPF 또는 DKIM과 정렬되는 p=none 또는 그보다 엄격한 DMARC 레코드를 게시해야 합니다. 이 요구 사항을 충족하지 못하면 Microsoft는 반송 코드 550 5.7.515 Access denied, sending domain does not meet the required authentication level로 메시지를 차단합니다. Yahoo도 2024년에 대량 발신자를 대상으로 비슷한 규칙을 도입했습니다.

Google은 일시적인 발송 속도 제한에는 4.x 코드를, 영구적인 전송 차단에는 5.x 코드를 사용합니다. 캠페인이 반송될 때 마케팅 대시보드만 보고 원인을 짐작하지 마십시오. 반송 메시지 읽는 방법 가이드에서 설명하듯, 서버가 보낸 원래의 거부 헤더를 확인하십시오.

SPF: 도메인의 메일을 보낼 수 있는 서버

RFC 7208로 표준화된 Sender Policy Framework는 수신 메시지의 봉투 발신자(envelope sender)를 검증합니다. 봉투 발신자는 메일 서버가 반송 메일을 돌려보낼 때 쓰는 Return-Path 또는 MAIL FROM 주소입니다. SPF는 처음 HELO 또는 EHLO 인사 단계에서 밝힌 서버 이름도 검사할 수 있습니다. SPF는 봉투 발신자만 확인하고 받은편지함에 보이는 From 주소는 확인하지 않습니다. 그래서 SPF만으로는 공격자가 브랜드 이름을 사칭하는 것을 막을 수 없습니다.

SPF 레코드는 DNS에 하나의 TXT 레코드로 존재합니다. 수신 서버에 어떤 IP 주소, MX 서버, 외부 플랫폼이 도메인의 메일을 보낼 수 있는지 알려 줍니다. 일반적인 레코드는 다음과 같습니다.

v=spf1 include:_spf.google.com include:spf.your-esp.example ~all

모든 레코드는 v=spf1으로 시작합니다. include:_spf.google.com 구문은 수신 서버에 Google의 SPF 레코드를 조회해 그 안에 나열된 IP 주소를 허용하라고 지시합니다. 두 번째 include는 마케팅 플랫폼이나 트랜잭션 이메일 서비스가 운영하는 서버에 발송 권한을 줍니다.

끝의 지시어는 목록에 없는 발신자를 어떻게 처리할지 수신 측에 알려 줍니다. ~all로 쓰는 softfail 한정자는 목록에 없는 서버가 아마 허용되지 않은 서버라는 뜻이지만, 수신 측이 메시지를 받은 뒤 스팸 필터링을 적용하도록 권합니다. -all로 쓰는 fail 한정자는 목록에 없는 서버를 하드 실패로 표시하며, 일부 수신 측은 그런 메일을 바로 거부합니다. 복잡한 설정을 점검하는 발신자는 정상적인 업무 메일이 실수로 버려지지 않도록 ~all로 시작하는 경우가 많습니다.

RFC 7208은 어길 수 없는 엄격한 제한 두 가지를 정합니다. 첫째, 도메인은 SPF 레코드를 하나만 게시할 수 있습니다. 레코드를 두 개 게시하면 permerror가 발생해, 발송하는 모든 메일의 SPF가 무효가 됩니다. 둘째, SPF는 include, a, mx, ptr, exists, redirect를 합쳐 DNS 조회를 최대 10회까지만 허용합니다. 레코드를 해석하는 데 11번째 조회가 필요하면 수신 서버는 permerror를 반환합니다. 전달(포워딩)도 SPF를 깨뜨립니다. 수신자가 메시지를 전달하면 전달하는 서버의 IP가 레코드와 일치하지 않아 SPF가 실패합니다.

DKIM: 메시지가 변경되지 않았음을 증명하는 서명

RFC 6376에 정의된 DKIM은 서버가 아니라 메시지 자체를 대상으로 작동합니다. 서버는 메시지를 보낼 준비를 할 때 선택한 헤더와 본문의 암호화 해시를 만들고, 그 해시에 개인 키로 서명한 뒤, 결과를 DKIM-Signature 헤더에 씁니다. 이 헤더에는 두 가지 주요 값이 있습니다. d= 태그의 서명 도메인과 s= 태그의 셀렉터 문자열입니다. DKIM은 서명이 유효한지만 알려 줍니다. 실패했을 때 어떻게 할지 정하는 것은 DMARC의 역할입니다.

메시지가 도착하면 수신 측은 헤더에서 셀렉터와 도메인을 읽고, DNS에서 s._domainkey.d에 있는 공개 키를 조회해 서명을 확인합니다. DKIM은 헤더와 내용에 서명할 뿐, 이메일 자체를 암호화하지는 않습니다. 본문은 읽을 수 있는 텍스트로 전송되지만, 서명은 전송 중에 아무도 제목, 발신자 정보, 본문을 바꾸지 않았음을 증명합니다.

일반적인 이메일 전달은 헤더와 본문 내용을 그대로 유지하므로, 유효한 DKIM 서명은 보통 전달 후에도 유지됩니다. 그래서 전달된 메일에서는 DKIM이 SPF보다 더 믿을 수 있습니다. 다만 바닥글을 추가하거나 제목에 태그를 붙이는 메일링 리스트는 여전히 서명을 깨뜨릴 수 있습니다. Gmail은 1024비트 이상의 키를 요구하며 2048비트를 권장합니다.

DNS에 게시하는 DKIM 공개 키 레코드는 다음과 같은 형식입니다.

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

v=DKIM1 태그는 프로토콜 버전을, k=rsa는 키 알고리즘을 나타내며, p=에는 base64로 인코딩한 공개 키가 들어갑니다. 자체 메일 서버를 운영한다면 DKIM 생성기로 키 쌍을 만들 수 있습니다.

흔한 함정은 플랫폼의 기본 서명에 의존하는 경우입니다. 많은 이메일 플랫폼은 기본적으로 자체 공유 도메인(d=shared-esp.example)으로 발송 메일에 서명합니다. 서명은 통과하지만 서명 도메인이 보이는 From 도메인과 일치하지 않아 DMARC 정렬이 실패합니다. 플랫폼 설정에서 사용자 지정 DKIM을 설정해, 서명의 d= 태그에 자사 도메인이 들어가게 해야 합니다.

DMARC: 두 검사를 From 주소에 연결하는 검사

Domain-based Message Authentication, Reporting, and Conformance는 봉투 검사와 암호화 서명을 사람이 읽는 From 주소에 연결합니다. 정렬이란 SPF 또는 DKIM을 통과한 도메인이 From 줄의 도메인과 같다는 뜻입니다. DMARC는 SPF 또는 DKIM 중 하나가 인증을 통과하고, 동시에 From 헤더 도메인과 정렬될 때 통과합니다. 메시지가 두 가지 모두 정렬될 필요는 없습니다. 다만 Google은 둘 다 정렬하도록 권장하며, 앞으로 둘 다 요구할 수도 있다고 밝히고 있습니다.

회사가 주간 뉴스레터를 보낸다고 가정해 보겠습니다. 메시지에는 From: news@example.com이 표시됩니다. 이메일 서비스는 반송을 처리하기 위해 자체 봉투 주소를 사용해 Return-Path를 bounce-123@bounces.esp-mail.example로 설정합니다. 이 서비스는 d=example.com을 사용하는 사용자 지정 DKIM으로 메시지에도 서명합니다.

수신 서버가 이 메시지를 처리할 때는 다음과 같습니다.

1. SPF는 봉투 도메인 bounces.esp-mail.example를 확인해 통과합니다. 하지만 esp-mail.example가 example.com과 일치하지 않으므로, SPF는 DMARC 정렬에 실패합니다.
2. DKIM은 example.com의 서명을 확인하고, 암호화 해시를 검증하고, From 헤더 도메인 example.com과 일치함을 확인합니다. 따라서 DKIM은 통과하고 DMARC 정렬도 충족합니다.
3. DKIM이 통과하고 정렬되었으므로, 메시지는 DMARC를 통과합니다.

DMARC는 SPF와 DKIM 각각에 두 가지 정렬 모드를 제공합니다. 완화(relaxed) 정렬은 기본 설정이며, 조직 도메인의 하위 도메인이 루트 도메인과 정렬되는 것을 허용합니다. 예를 들어 news.example.com에서 보낸 메일은 SPF 또는 DKIM 도메인 example.com과 정렬됩니다. aspf=s 또는 adkim=s로 설정하는 엄격(strict) 정렬은 도메인이 정확히 일치해야 하며, 하위 도메인의 차이를 허용하지 않습니다.

DMARC 레코드에는 세 가지 정책 중 하나를 게시합니다.

• p=none: DMARC를 모니터링 모드로 둡니다. 수신 측은 인증 보고서를 수집하면서 메일을 평소처럼 전달합니다.
• p=quarantine: DMARC에 실패한 메일을 스팸함 또는 정크 폴더로 보내도록 수신 측에 요청합니다.
• p=reject: DMARC에 실패한 메일을 거부하도록 수신 측에 요청합니다.

rua 태그는 수신 측에 집계 보고서를 보낼 곳을 알려 줍니다. 집계 보고서는 보통 매일 오는 XML 파일로, 어떤 IP 주소가 도메인을 사용해 메일을 보냈는지 보여 줍니다. _dmarc.example.com에 게시하는 일반적인 시작용 레코드는 다음과 같습니다.

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

2026년 5월, Internet Engineering Task Force는 RFC 9989를 Standards Track으로 발표했습니다. 함께 집계 보고에 관한 RFC 9990과 실패 보고에 관한 RFC 9991도 발표했습니다. 이 새 표준으로 RFC 7489와 RFC 9091은 공식적으로 폐기되었습니다. v=DMARC1으로 시작하는 기존 레코드는 계속 작동하지만, 개정된 규격은 여러 운영 태그를 조정합니다. 비율 태그(pct)와 보고서 형식 태그(rf)는 폐지되어 더 이상 표준에 포함되지 않으며, 보고 주기 태그(ri)는 historic(과거 규격)으로 분류됩니다. 정책 적용을 시험하는 발신자는 이제 테스트 모드를 위한 새 t 태그를 사용하고, 관리자는 np 태그로 존재하지 않는 하위 도메인에 대한 정책을 정할 수 있습니다. 현재 DNS 레코드에 비율 태그가 있다면 제거할 계획을 세우십시오. DMARC 레코드 생성기로 개정된 레코드를 만들거나 기존 태그를 정리할 수 있습니다.

수신 서버가 메시지를 확인하는 순서

수신 게이트웨이에 이메일이 도착하면, 서버는 정해진 순서로 인증 검사를 실행합니다.

1. 서버가 네트워크 연결을 수락하고, 발신자 IP 주소를 기록하고, HELO 또는 EHLO 인사를 평가합니다.
2. 서버가 봉투의 Return-Path에서 도메인을 추출하고, DNS를 조회해 발송 IP에 대한 SPF 허용 여부를 확인합니다.
3. 서버가 DKIM-Signature 헤더를 찾고, DNS에서 selector._domainkey.domain의 공개 키를 조회하고, 헤더와 본문 내용의 암호화 해시를 다시 계산합니다.
4. 서버가 보이는 From 헤더를 확인하고, DNS에서 _dmarc.domain의 DMARC 정책 레코드를 조회합니다.
5. 서버가 도메인 정렬을 평가합니다. 인증된 SPF 도메인 또는 인증된 DKIM 도메인이 보이는 From 도메인과 일치하는지 확인합니다.
6. 서버가 정렬 결과에 따라 게시된 DMARC 정책(none, quarantine, reject)을 적용합니다.
7. rua로 보고서를 요청했다면, 서버는 다음 집계 보고서에 이 결과를 추가해 보냅니다.

Gmail에서는 아무 메시지에서나 “원본 보기”를 열면 세 가지 결과를 모두 볼 수 있습니다.

SPF, DKIM, DMARC가 자주 깨지는 곳

새 이메일 서비스를 추가할 때 흔히 하는 실수는 SPF 레코드를 두 개 게시하는 것입니다. 관리자가 설정 문서를 따라 v=spf1 include:sendgrid.net ~all을 추가하면서, 기존 Google 레코드와 별도로 두 번째 TXT 레코드를 게시하는 경우가 있습니다. RFC 7208은 한 도메인에 SPF 레코드를 여러 개 두는 것을 금지합니다. 수신 서버는 레코드 두 개를 발견하면 permerror로 처리를 중단하고 SPF를 실패로 판정합니다. 해결하려면 허용하는 모든 업체를 하나의 문자열로 합쳐 v=spf1 include:_spf.google.com include:sendgrid.net ~all처럼 만드십시오.

10회 조회 제한을 넘는 것도 눈에 띄지 않게 전송을 망가뜨리는 원인입니다. include, a, mx, ptr, exists, redirect 태그는 모두 이 제한에 포함되며, 업체 레코드 안에 중첩된 include도 포함됩니다. 레코드에 11번째 조회가 필요하면 수신 서버는 자동으로 permerror를 반환합니다. 조회 횟수 초과는 오래된 업체 레코드를 정리하거나, 조회 점검 도구를 사용하거나, include를 명시적인 ip4 범위로 바꿔 해결합니다. 단, ip4 범위로 바꾸는 것은 직접 관리하고 바뀌지 않는 발송 IP에만 해당합니다.

새 발송 서비스를 연결하면서 DNS에 추가하지 않으면, 발송 메일이 스팸 필터에 걸리기 쉬워집니다. 영업팀이나 지원팀은 DNS 관리자에게 알리지 않고 예약 도구, 헬프데스크 플랫폼, 청구서 시스템을 연결하는 경우가 많습니다. 이런 새 서버는 SPF 레코드에 없고 자사 DKIM 키로 서명하지 않으므로, 메시지가 인증에 실패해 스팸함에 들어갑니다. 해결 방법은 간단한 규칙입니다. 새 도구를 연결하는 사람은 DNS 관리자에게 알립니다. 그리고 DMARC 보고서에서 모르는 발신자가 있는지 살펴봅니다.

플랫폼이 서명한 DKIM에 의존하면, 서명이 암호학적으로 유효하더라도 DMARC 정렬이 깨집니다. 이메일 서비스가 d=platform-mail.example로 메시지에 서명하고 From 줄에는 From: support@yourcompany.example가 표시되면, DKIM은 기술적 검사는 통과하지만 자사 도메인과의 정렬에는 실패합니다. 이 불일치를 해결하려면 플랫폼 설정을 열어 자사 도메인용 사용자 지정 DKIM 키를 만들고, DNS 콘솔에 셀렉터 레코드를 게시하십시오.

메시지 전달은 수신자가 업무 메일을 개인 받은편지함으로 전달할 때마다 SPF를 깨뜨립니다. 중간 서버는 자체 IP 주소로 메시지를 넘기는데, 이 IP는 SPF 레코드와 일치하지 않습니다. 외부의 전달 설정은 통제할 수 없지만, 메시지에 유효한 DKIM 서명이 있으면 전달 후에도 서명이 유지되어 여러 단계를 거쳐도 DMARC 요구 사항을 충족할 수 있습니다.

다른 플랫폼을 통해 무료 @gmail.com From 주소로 대량 캠페인을 보내면, 구조상 DMARC에 실패합니다. Google의 발신자 가이드라인은 외부 서버에서 Gmail 주소를 사칭하면 이메일 도달률이 나빠진다고 명시적으로 경고합니다. 외부 플랫폼은 Google 도메인에 대해 유효한 암호화 서명을 만들거나 SPF를 통과할 수 없으므로, 메일 서비스 제공업체는 그 메일을 거부하거나 격리합니다. 발신자는 항상 직접 소유한 도메인으로 메일을 보내야 합니다.

DMARC를 p=none으로 계속 두면 도메인은 사칭에 취약한 상태로 남습니다. 모니터링 정책은 Gmail과 Microsoft의 최소 요건을 충족하지만, p=none은 사칭 메일이 나타나도 수신 서버에 아무 보호 조치도 하지 말라고 알립니다. 이 설정에서는 누군가 도메인을 그대로 사칭해도 DMARC가 막지 못합니다. 몇 주 동안 매일 오는 집계 보고서를 검토하고, 정상적인 발송 경로가 모두 정렬되는지 확인한 뒤, 정책을 p=quarantine으로, 그다음 p=reject로 올려야 합니다.

SPF 레코드, DKIM 설정, DMARC 설정 체크리스트

다음 순서대로 진행하십시오.

1. 도메인을 사용해 이메일을 보내는 모든 내부 서비스, 마케팅 플랫폼, 고객 지원 도구, 트랜잭션 메일 도구를 나열합니다.
2. 허용하는 발송 서버를 모두 담은 SPF 레코드를 하나만 게시하고, 전체 조회 횟수를 10회 미만으로 유지합니다. SPF 검사 도구가 횟수를 세어 줍니다.
3. 모든 발송 플랫폼에서 자사 도메인을 사용하는 사용자 지정 DKIM 서명을 켜고, 일치하는 셀렉터 레코드를 DNS에 게시합니다.
4. 발송 IP 주소에 유효한 정방향 DNS와, 역방향 DNS에 설정된 일치하는 PTR 레코드가 있는지 확인합니다.
5. _dmarc에 p=none과 사용 중인 rua 메일함을 넣은 첫 DMARC 레코드를 게시해, XML 집계 보고서를 받기 시작합니다.
6. 발송 도메인을 Google Postmaster Tools에 등록해 도메인 평판, 전송 오류, 스팸 신고율을 모니터링합니다.
7. 몇 주 동안 DMARC 집계 보고서를 검토해, 정상적인 모든 발송 경로가 SPF 또는 DKIM 정렬을 충족하는지 확인합니다.
8. DMARC 정책을 p=none에서 p=quarantine으로 올리고, 전송이 안정적인지 평가한 다음, p=reject로 옮깁니다.
9. 개인 Gmail 계정으로 테스트 메시지를 보내고 “원본 보기”를 열어 SPF, DKIM, DMARC가 모두 PASS인지 확인합니다.

자주 묻는 질문

DMARC에는 SPF와 DKIM이 모두 필요합니까? 아니요. DMARC는 SPF 또는 DKIM 중 하나가 인증을 통과하고, 보이는 From 헤더의 도메인과 정렬되면 됩니다. 두 프로토콜을 모두 사용하면 전달로 SPF가 깨질 때에도 더 안정적이며, Google은 대량 발송에는 둘 다 설정하도록 권장합니다. 하지만 한 가지만 유효하게 정렬되어도 메시지는 DMARC를 통과합니다.

SPF와 DMARC의 차이는 무엇입니까? SPF는 Return-Path 헤더에 있는 기술적인 봉투 발신자 주소에 대해, 특정 메일 서버 IP 주소가 메일을 보낼 수 있도록 허용합니다. DMARC는 이메일 프로그램에서 사람이 보는 From 주소를 확인하고, SPF 또는 DKIM이 그 도메인과 정렬되는지 검증하며, 검증에 실패한 메시지를 수락할지, 격리할지, 거부할지 수신 서버에 알려 줍니다.

하루 5,000건 미만으로 보내도 DMARC가 필요합니까? Gmail은 대량 발신자에게만 DMARC를 요구하므로, 발송량이 적다면 DMARC가 없어도 차단되지 않습니다. 다만 SPF 또는 DKIM은 여전히 필요합니다. 그래도 rua를 넣은 p=none 레코드는 게시할 가치가 있습니다. 보고서를 보면 잊고 있던 서비스나 도메인을 사칭하는 사람을 포함해, 어떤 서비스가 자사 도메인으로 메일을 보내는지 알 수 있기 때문입니다.

SPF 레코드를 두 개 둘 수 있습니까? 아니요. RFC 7208은 한 도메인에 SPF 레코드를 두 개 이상 게시하는 것을 금지합니다. 수신 서버는 DNS에서 SPF 레코드를 여러 개 발견하면 즉시 permerror로 평가를 중단하고 SPF를 실패로 처리합니다. 허용하는 모든 IP 주소와 외부 include를 v=spf1으로 시작하는 하나의 레코드로 합쳐야 합니다.

DMARC를 가장 쉽게 설명하면? SPF는 메시지를 보내는 서버가 도메인의 메일을 보낼 수 있는 서버인지 확인합니다. DKIM은 메시지가 변경되지 않았음을 보여 주는 서명을 확인합니다. DMARC는 마지막 검사입니다. 이 둘 중 하나가 From 주소와 같은 도메인에 속하는지 확인합니다. 둘 다 아니라면, DMARC는 수신 서버에 메시지를 그래도 전달할지, 스팸함으로 보낼지, 거부할지 알려 줍니다.

이 레코드들은 발신자가 누구인지 증명하지만, 보내는 대상의 문제는 해결하지 않습니다. 더 이상 존재하지 않는 주소로 보낸 메일은 여전히 반송됩니다. 그 부분은 이메일 반송률을 낮추는 방법 가이드에서 다루며, 다음 발송 전에 리스트를 Giggal.ai(영어)로 검사할 수도 있습니다.