홈 › 가이드

SPF, DKIM, DMARC 설정 방법: 레코드 예시, 주의점, 확인 방법

게시일 2026-11-03 ／ 업데이트 2026-11-03 ／ 작성 Yuki Nakazawa

자체 도메인으로 메일을 보낸다면 SPF, DKIM, DMARC 설정은 더 이상 선택 사항이 아닙니다. 다음 순서로 진행하시기 바랍니다. SPF 레코드를 하나 게시하고, 2048비트 키로 DKIM 서명을 켠 다음, 보고서 수신을 활성화한 p=none으로 시작하는 DMARC 레코드를 게시합니다. 이와 함께 메일을 보내는 IP 주소에 일치하는 역방향 DNS(PTR)가 설정되어 있는지도 확인합니다.

이 가이드는 공유 호스팅, 자체 VPS, Google Workspace, Microsoft 365, 대량 메일 발송 서비스 중 어디에서 보내든 적용할 수 있습니다. 상황에 맞게 고쳐 쓸 수 있는 레코드, 인증을 깨뜨리는 가장 흔한 실수, 실제 메일 헤더로 모든 것이 제대로 작동하는지 확인하는 방법을 소개합니다.

아래 내용은 2026년 11월 기준 RFC와 Google, Yahoo, Microsoft 공식 페이지와 대조해 확인했습니다. 메일 서비스의 요구사항은 바뀔 수 있으므로 최종 기준은 각 공식 페이지로 삼으시기 바랍니다.

SPF, DKIM, DMARC가 각각 증명하는 것과 설정 순서

SPF(Sender Policy Framework)는 도메인이 자기 메일을 보낼 수 있는 서버를 DNS에 나열해 두는 방식입니다. 수신 서버는 봉투 발신자(SMTP의 MAIL FROM 주소로, 나중에 Return-Path로 표시됨)를 보고 그 도메인의 SPF 레코드를 가져와 접속한 IP 주소가 목록에 있는지 확인합니다. SPF만으로는 읽는 사람에게 보이는 From 주소에 대해 아무것도 보증하지 않습니다.

DKIM(DomainKeys Identified Mail)은 각 메일에 암호화 서명을 추가합니다. 발송 시스템은 개인 키로 서명하고, 수신 측은 DNS에 게시된 공개 키로 서명을 검증합니다. 유효한 서명은 서명한 도메인(d= 값)이 메일에 대한 책임을 지며, 서명된 헤더와 본문이 도중에 변경되지 않았음을 증명합니다.

DMARC(Domain-based Message Authentication, Reporting and Conformance)는 이 두 가지를 눈에 보이는 From 도메인과 연결합니다. 메일은 SPF 또는 DKIM이 통과하고 동시에 인증된 도메인이 From 도메인과 정렬(alignment)될 때만 DMARC를 통과합니다. DMARC 레코드는 실패한 메일을 어떻게 처리하기를 원하는지(조치 없음, 격리, 거부)와 집계 보고서를 어디로 보낼지도 수신 측에 알려 줍니다. 이 보고서를 통해 잊고 있던 발송 경로를 찾을 수 있습니다.

설정 순서

1. 내 도메인 이름으로 메일을 보내는 모든 시스템을 나열합니다. 자체 서버, Google Workspace 또는 Microsoft 365, 뉴스레터 및 트랜잭션 메일 서비스, 웹 양식, 청구서 발행 및 헬프데스크 도구 등입니다.
2. 이들을 모두 포함하는 SPF 레코드를 하나만 게시합니다.
3. 각 발송 시스템에서 DKIM을 활성화하고 공개 키를 게시합니다.
4. p=none과 rua 보고서 수신 주소로 DMARC를 게시합니다. Google은 SPF와 DKIM을 설정한 뒤 48시간을 기다렸다가 DMARC를 추가하도록 권장합니다.
5. 보고서를 읽고 실패하는 발송 경로를 고친 다음 p=quarantine으로, 마지막으로 p=reject로 전환합니다.

SPF 설정: 레코드는 하나, 조회는 10회까지

SPF는 도메인 자체에 설정하는 TXT 레코드입니다. 다음은 자체 서버에서 IPv4와 IPv6로 보내면서 Google Workspace도 사용하는 도메인의 예입니다.

example.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:_spf.google.com ~all"

대부분의 DNS 관리 화면에서는 호스트 필드를 비워 두거나 @를 입력하고, 유형으로 TXT를 선택한 뒤 v=spf1로 시작하는 값을 붙여 넣습니다. 자주 쓰는 구성 요소는 다음과 같습니다.

SPF의 주의점

• 이름 하나에 SPF 레코드는 하나. RFC 7208은 같은 도메인에 여러 SPF 레코드를 두는 것을 금지합니다. 그러면 수신 측은 permerror를 반환하고 모든 메일의 SPF가 실패합니다. 서비스를 추가할 때는 두 번째 v=spf1 레코드를 만들지 말고 기존 레코드를 수정해 include:를 덧붙입니다.
• 10회 조회 제한. include, a, mx, ptr, exists 메커니즘과 redirect 수정자는 각각 DNS 조회를 일으키며, 중첩된 include 내부의 조회를 포함해 전체 평가에서 그 합계가 10을 넘으면 안 됩니다. 초과하면 permerror가 됩니다. ip4:, ip6:, all은 조회를 일으키지 않습니다. RFC 7208은 응답이 없는 조회가 두 번 발생하면 수신 측이 평가를 중단해야 한다고도 규정하므로, 더 이상 사용하지 않는 서비스의 include는 삭제하시기 바랍니다.
• ~all과 -all. -all은 목록에 없는 발송 경로가 허가되지 않았다는 뜻(fail)이고, ~all은 아마도 허가되지 않았다는 뜻(softfail)입니다. Google은 Workspace 도메인에 ~all을 권장하고, Microsoft는 DKIM과 DMARC도 사용하는 Microsoft 365 도메인에 -all을 권장합니다. 모든 발송 경로를 찾았는지 아직 확신할 수 없다면 ~all로 시작하고 차단은 DMARC에 맡기시기 바랍니다.
• 하위 도메인에는 별도의 레코드가 필요합니다. example.com의 SPF 레코드는 news.example.com에 적용되지 않습니다. 대량 메일 발송 서비스를 별도의 하위 도메인에 두면 조회 10회 한도도 따로 확보되고, 그 평판을 직원 업무 메일과 분리할 수 있습니다.
• 문법 실수. Microsoft는 흔한 실수로 include: 대신 include=를 쓰는 것, 콜론 뒤의 공백, include한 도메인 끝에 붙은 점을 들고 있습니다.

메일을 전혀 보내지 않는 도메인에는 v=spf1 -all을 게시해 사칭을 어렵게 만드시기 바랍니다.

DKIM 설정: 2048비트 키와 셀렉터

DKIM은 두 부분으로 이루어집니다. 발송 시스템이 개인 키로 서명하고, DNS에는 그에 대응하는 공개 키를 게시합니다. Google Workspace, Microsoft 365, 대부분의 호스팅 제어판과 메일 발송 서비스에서는 관리 콘솔에서 키를 생성하고 표시되는 DNS 값을 복사합니다.

키 길이와 셀렉터

2048비트 RSA 키를 사용하시기 바랍니다. RFC 8301은 1024비트를 최소로 정하고 서명자는 2048비트 이상을 사용해야 한다고 규정하며, rsa-sha1은 금지합니다. Google의 안내도 같습니다. DNS 호스트가 지원하면 2048비트를 선택하고, 지원하지 않을 때만 1024비트를 사용합니다.

셀렉터는 어떤 키로 메일에 서명했는지 식별하는 라벨로, 이 덕분에 하나의 도메인이 발송 서비스별 또는 교체 주기별로 여러 키를 동시에 가질 수 있습니다. 공개 키는 selector._domainkey.yourdomain에 게시됩니다. Google Workspace는 기본 셀렉터로 google을 사용합니다. Microsoft 365는 Microsoft가 호스팅하는 키를 가리키는 selector1._domainkey와 selector2._domainkey, 두 개의 CNAME 레코드를 사용합니다. 형식이 테넌트마다 다르므로 정확한 대상 값은 Defender 포털이나 Get-DkimSigningConfig에서 확인하시기 바랍니다.

긴 공개 키 게시하기

2048비트 공개 키는 DNS 문자열 하나에 허용되는 255자보다 길기 때문에, 존 파일 형식에서는 하나의 TXT 레코드 안에 따옴표로 묶은 여러 문자열로 적습니다.

selector1._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA(first part of your key)"
    "(rest of your key)IDAQAB" )

괄호 안의 부분(first part of your key, rest of your key)을 실제 키로 바꾸시기 바랍니다. 수신 측은 문자열 사이에 공백 없이 이어 붙이므로 키 안의 어느 위치에서 나누어도 됩니다. 많은 관리 화면이 긴 값을 자동으로 나누므로, 먼저 전체 값을 붙여 넣어 보고 관리 화면이 거부할 때만 직접 나누시기 바랍니다. 복사하는 과정에서 빠진 부분이 없는지 확인합니다. p=가 비어 있으면 키가 폐기되었다는 뜻이 됩니다.

Postfix 등의 MTA를 운영하는 자체 VPS에서는 OpenDKIM 같은 서명용 milter로 키 쌍을 만들 수 있습니다. 예를 들면 opendkim-genkey -b 2048 -s selector1 -d example.com입니다. 생성된 공개 키 파일의 내용을 위와 같이 게시합니다.

메일이 실제로 서명되는지 확인하기

보낸 메일을 열어 DKIM-Signature: 헤더를 찾습니다. d= 태그는 내 도메인, s=는 게시한 셀렉터여야 합니다. 많은 메일 발송 서비스는 기본적으로 자사 도메인으로 서명합니다. 이 경우 DKIM은 통과하지만 내 From 도메인과 정렬되지 않으므로 DMARC에는 도움이 되지 않습니다. 서비스의 사용자 지정 도메인 인증을 켜서 d=가 내 도메인이 되도록 하시기 바랍니다.

DMARC 설정: p=none으로 시작해 단계적으로 강화하기

DMARC는 도메인 아래 _dmarc에 두는 TXT 레코드입니다. 수신 측에 메일 처리 방식을 바꾸지 말도록 요청하는 모니터링 모드로 시작하고, 집계 보고서를 요청합니다.

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

집계 보고서는 어떤 IP 주소가 내 도메인 이름으로 메일을 보냈고 통과했는지를 기계가 읽을 수 있는 형식으로 요약한 것입니다. Google은 보고서를 받을 전용 메일함이나 그룹을 두도록 권장합니다. 정상적인 발송 경로가 모두 정렬된 상태로 통과한다는 것이 보고서로 확인되면, 두 번째 레코드를 추가하지 말고 같은 레코드를 수정해 정책을 강화합니다.

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

정렬을 쉽게 설명하면

DMARC를 통과하려면 SPF와 DKIM 중 적어도 하나가 From 도메인과 일치하는 도메인으로 통과해야 합니다. 완화 모드에서는 조직 도메인만 일치하면 되므로 d=example.com인 DKIM 서명은 alerts@news.example.com에서 보낸 메일과 정렬됩니다. 엄격 모드에서는 정확히 일치해야 합니다. 메일 발송 서비스는 Return-Path에 자사 도메인을 쓰는 경우가 많아 SPF가 통과해도 정렬되지 않습니다. 이런 메일이 DMARC를 통과하게 하는 현실적인 방법은 정렬된 DKIM입니다.

하위 도메인에 다른 정책을 적용하려면 sp=를 추가합니다. 예를 들어 p=reject; sp=quarantine은 기본 도메인에서 실패한 메일은 거부하고, 하위 도메인에서 실패한 메일은 격리만 합니다.

개정된 표준에 대해

2026년 5월 DMARC는 RFC 7489를 대체하는 RFC 9989로 다시 발행되었습니다. 기존 레코드는 계속 작동하며 여전히 v=DMARC1로 시작합니다. 새 표준에서는 0 또는 100 이외의 값에서 정확하게 적용되는 경우가 드물었던 pct 태그가 없어지고, t=y(테스트 모드)와 np(존재하지 않는 하위 도메인에 대한 정책) 같은 태그가 추가되었습니다. 일부 제공업체의 도움말에는 아직 pct가 나오므로, 가장 오해의 여지가 적은 강화 방법은 p= 값을 단계적으로 바꾸는 것입니다.

발송 IP의 역방향 DNS(PTR)

역방향 DNS는 IP 주소를 호스트 이름으로 되돌려 대응시킵니다. Google은 개인 Gmail 계정으로 보내는 모든 발신자에게 PTR 레코드를 요구하며, 그 호스트 이름은 같은 발송 IP로 다시 해석되어야 합니다. Yahoo는 발송 IP에 유효한 정방향 및 역방향 DNS를 요구하고, 일반적인 형태가 아닌 의미 있는 PTR 레코드를 권장합니다.

203.0.113.10       PTR  mail.example.com.
mail.example.com.  A    203.0.113.10

PTR 레코드는 내 도메인의 존에 있지 않습니다. IP 주소의 소유자가 관리하므로, VPS라면 제공업체의 제어판(흔히 역방향 DNS 또는 rDNS라고 부름)에서 설정한 뒤 내 DNS에 일치하는 A 레코드(IPv6라면 AAAA)를 만듭니다. IPv6로 보낸다면 IPv6 주소에도 같은 설정이 필요합니다. Google Workspace, Microsoft 365, 메일 발송 서비스, 대부분의 공유 호스팅에서는 제공업체가 발송 IP와 그 역방향 DNS를 관리합니다.

설정을 확인하는 방법

Authentication-Results 읽기

외부 메일함으로 테스트 메일을 보내고 전체 헤더를 확인합니다. Gmail에서는 메일을 열고 원본 보기를 선택합니다. Google의 DKIM 도움말은 자신에게 보내지 말고 다른 사용자에게 보내라고 안내합니다. 다음과 같은 헤더를 찾습니다.

Authentication-Results: mx.example.net;
       dkim=pass header.i=@example.com header.s=selector1;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass header.from=example.com

정확한 형식은 수신 측마다 다릅니다. 중요한 것은 spf=pass, dkim=pass, dmarc=pass이고, header.i 또는 header.d와 header.from에 내 도메인이 있는지입니다. 서비스의 도메인으로 SPF가 통과하지만 DKIM에 다른 도메인이 표시된다면 DMARC는 실패합니다. 먼저 DKIM 정렬을 고치시기 바랍니다.

DNS를 직접 조회하기

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10

Windows에서는 nslookup -type=TXT _dmarc.example.com으로 같은 확인을 할 수 있습니다. DNS 변경 사항이 퍼지는 데는 시간이 걸릴 수 있으며, Google은 SPF와 DKIM이 각각 작동하기 시작하기까지 최대 48시간이 걸릴 수 있다고 안내합니다. 무료 온라인 검사 도구로도 레코드를 분석하고 SPF 조회 횟수를 셀 수 있습니다.

인증이 통과하는데도 메일이 반송되거나 스팸함으로 간다면 블랙리스트 조회 도구로 발송 IP나 도메인이 DNSBL에 등재되어 있는지 확인하고, 다음 단계는 블랙리스트 때문에 메일이 전달되지 않을 때를 참고하시기 바랍니다.

Gmail, Yahoo, Outlook.com의 발신자 요구사항

주요 메일 서비스는 이제 인증을 의무화하고 있습니다. 2026년 11월 기준 각 공식 페이지의 내용은 다음과 같습니다.

• Gmail(2024년 2월 1일부터 시행): 개인 Gmail 계정으로 보내는 모든 발신자는 SPF 또는 DKIM, 서로 일치하는 정방향 및 역방향 DNS, TLS 연결, Postmaster Tools 기준 0.3% 미만의 스팸률이 필요합니다. 하루 5,000통을 초과해 보내는 발신자는 추가로 SPF와 DKIM 모두, DMARC 레코드(p=none도 허용), SPF 또는 DKIM과 정렬된 From 도메인, 마케팅 메일의 원클릭 수신 거부가 필요합니다. DKIM 키는 1024비트 이상이어야 하며 2048비트가 권장됩니다.
• Yahoo(2024년 2월부터 적용): 모든 발신자는 SPF 또는 DKIM, 유효한 정방향 및 역방향 DNS, 0.3% 미만의 스팸률이 필요합니다. 대량 발신자는 SPF와 DKIM 모두, 통과하는 최소 p=none 이상의 DMARC 정책, From 정렬(완화 모드로 충분), 작동하는 원클릭 수신 거부, 발송 IP의 유효한 정방향 및 역방향 DNS가 필요합니다.
• Outlook.com(outlook.com, hotmail.com, live.com 뒤에 있는 개인용 서비스): 하루 5,000통을 초과해 보내는 도메인은 SPF와 DKIM을 통과하고, SPF 또는 DKIM과 정렬된 최소 p=none 이상의 DMARC를 게시해야 합니다. Microsoft는 2025년 5월 5일부터 요구사항을 충족하지 않는 메일을 550; 5.7.515 오류로 거부한다고 밝혔습니다.

전문은 Google 이메일 발신자 가이드라인, Yahoo 발신자 모범 사례, Microsoft의 Outlook.com 공지에서 확인하시기 바랍니다. 훨씬 적은 양을 보내더라도 지금 세 가지를 모두 설정해 두면 나중에 기준이 낮아져도 당황할 일이 없습니다. Gmail 고유의 문제 해결은 Gmail로 메일이 전달되지 않을 때를 참고하시기 바랍니다.

흔한 실수

• 두 번째 SPF 레코드. 서비스마다 새 v=spf1 레코드를 추가하면 도메인 전체의 SPF가 무효가 됩니다. 하나로 합치시기 바랍니다.
• include가 너무 많음. SPF에 남아 있는 오래된 서비스가 조회 10회 한도를 잡아먹습니다. 쓰지 않는 것은 삭제하고 대량 메일은 하위 도메인으로 옮깁니다.
• 키는 게시했지만 서명을 켜지 않음. Google Workspace에서는 DNS 레코드가 반영된 뒤에도 '인증 시작'을 클릭해야 합니다. 다른 플랫폼에도 비슷한 스위치가 있습니다.
• 서비스가 자사 도메인으로 서명함. SPF와 DKIM은 모두 통과하지만 DMARC는 실패합니다. 사용자 지정 도메인 서명을 켜시기 바랍니다.
• 곧바로 p=reject로 설정. 잊고 있던 웹 양식이나 청구서 발행 시스템의 메일이 하루아침에 전달되지 않게 됩니다. p=none으로 시작해 보고서를 읽으시기 바랍니다.
• 복사·붙여넣기 중 손상. 값 안에 들어간 불필요한 따옴표, 잘린 키, 관리 화면이 도메인을 자동으로 붙여 _dmarc.example.com.example.com이 되어 버린 호스트 이름 등입니다. dig로 간단히 조회하면 모두 발견할 수 있습니다.

자주 묻는 질문

참고한 공식 페이지

이 글의 사실 관계는 게시 시점에 아래 공식 페이지와 대조하여 확인했습니다. 정책과 동작은 예고 없이 바뀔 수 있으므로 중요한 판단을 내리기 전에 공식 페이지를 확인하시기 바랍니다.

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9989: DMARC (obsoletes RFC 7489)
• Google: Email sender guidelines
• Google Workspace: Set up SPF
• Google Workspace: Set up DKIM
• Google Workspace: Set up DMARC
• Yahoo Sender Hub: Sender Best Practices
• Microsoft Community Hub: Outlook's New Requirements for High-Volume Senders
• Microsoft Learn: Set up SPF for your Microsoft 365 domain
• Microsoft Learn: How to use DKIM for email in your custom domain

관련 가이드

전체 가이드 →