쇼핑몰 SPF·DKIM·DMARC 설정: Gmail·Yahoo 발신자 요건 대응
SPF·DKIM·DMARC의 역할, Gmail·Yahoo·Outlook.com 발신자 요건, Shopify·WooCommerce 설정 방법과 p=reject까지 가는 단계를 정리합니다.
FixReports 편집팀8분 분량
Gmail과 Yahoo의 발신자 요건을 충족하려면 모든 온라인 쇼핑몰은 발신 도메인에 SPF 또는 DKIM을 설정해야 합니다. 대량 발신자는 두 가지를 모두 설정하고, p=none 이상의 DMARC 레코드를 게시하며, 수신자에게 보이는 From 도메인을 SPF 또는 DKIM 도메인과 정렬(alignment)해야 합니다. 대량 발신자는 또한 마케팅 이메일에 원클릭 수신 거부를 제공하고, 신고된 스팸 비율을 0.3% 미만으로 유지해야 합니다. Shopify에서는 관리자 화면에서 발신자 도메인을 인증하고 DMARC 레코드를 추가하면 되고, WooCommerce에서는 인증된 이메일 서비스 제공업체를 통해 메일을 보내면 됩니다. DMARC 보고서에서 정상적인 메일이 모두 통과하는 것이 확인되면 정책을 p=reject 쪽으로 강화할 수 있습니다.
핵심 요약
- 2024년 2월 1일부터 Gmail은 모든 발신자에게 SPF 또는 DKIM 설정을, 대량 발신자에게는 SPF, DKIM, DMARC 모두의 설정을 요구합니다 (Google (새 탭에서 열림)).
- 24시간 동안 개인 Gmail 계정으로 5,000건에 가까운 메시지를 보내면 Gmail은 대량 발신자로 간주하며, 이 지위는 만료되지 않습니다 (Gmail FAQ (새 탭에서 열림)).
- 2025년 11월부터 Gmail은 요건을 충족하지 않는 트래픽에 대한 시행을 강화했으며, 여기에는 일시적 거부와 영구 거부가 포함됩니다 (Gmail FAQ (새 탭에서 열림)).
- Outlook.com은 2025년 5월 5일부터 하루 5,000건이 넘는 이메일을 보내는 도메인에 SPF, DKIM, DMARC를 요구하고 있습니다 (Microsoft (새 탭에서 열림)).
- SPF는 한 번의 검사에서 DNS 조회가 필요한 항목을 최대 10개까지만 허용하며, 이를 넘으면
permerror가 반환됩니다 (RFC 7208 (새 탭에서 열림)). - DMARC는 2026년 5월에 개정되었습니다. RFC 9989 (새 탭에서 열림)가 RFC 7489를 대체하고
pct태그를t로 바꿨습니다.
SPF, DKIM, DMARC는 실제로 무슨 역할을 하나요?
SPF는 도메인을 대신해 메일을 보낼 수 있는 주체를 나열하고, DKIM은 각 메시지에 서명하며, DMARC는 이 두 가지를 고객이 보는 From 주소와 연결합니다.
| 레코드 | 증명하는 내용 | 위치 | 표준 |
|---|---|---|---|
| SPF | 발신 서버가 봉투(envelope) 발신자(MAIL FROM)에 사용된 도메인에 대해 승인된 서버임 | 도메인의 TXT 레코드 | RFC 7208 (새 탭에서 열림) |
| DKIM | 메시지가 해당 도메인에 의해 서명되었고 전송 중에 변경되지 않았음 | selector._domainkey.example.com의 TXT 레코드 | RFC 6376 (새 탭에서 열림) |
| DMARC | 화면에 보이는 From 도메인과 정렬된 도메인으로 SPF 또는 DKIM이 통과했음. 실패 시 수신 측이 취할 조치와 보고서를 보낼 곳도 알려 줌 | _dmarc.example.com의 TXT 레코드 | RFC 9989 (새 탭에서 열림) |
정렬은 놓치기 쉬운 부분입니다. 이메일 플랫폼이 자체 반송(bounce) 도메인으로 SPF를 통과하더라도 From 주소에는 쇼핑몰 도메인이 표시될 수 있습니다. 이런 메시지는 SPF는 통과하지만, DKIM이 쇼핑몰 도메인으로 서명되어 있지 않다면 DMARC에서는 실패합니다.
Gmail과 Yahoo는 발신자에게 무엇을 요구하나요?
두 곳 모두 모든 발신자에게 인증을 요구하고, 대량 발신자에게는 더 엄격한 규칙을 추가로 적용합니다.
Gmail은 모든 발신자에게 SPF 또는 DKIM, 유효한 정방향 및 역방향 DNS, TLS, RFC 5322 형식 준수, 그리고 Postmaster Tools 기준 0.3% 미만의 스팸 비율을 요구합니다 (Google (새 탭에서 열림)). Yahoo는 최소한 SPF 또는 DKIM과 0.3% 미만의 스팸 비율을 요구합니다 (Yahoo Sender Hub (새 탭에서 열림)). 대량 발신자에 대한 요건은 다음과 같습니다.
| 요건 | Gmail | Yahoo |
|---|---|---|
| SPF와 DKIM | 둘 다 필요 | 둘 다 필요 |
| DMARC | 필수이며, 정책은 none이어도 됨 | 최소 p=none 이상의 유효한 정책이 있어야 하고 DMARC를 통과해야 함 |
| 정렬 | From 도메인이 SPF 또는 DKIM 도메인과 정렬되어야 함 | 동일하며, 완화(relaxed) 정렬도 허용 |
| 원클릭 수신 거부 | 마케팅 및 구독 메시지에 RFC 8058 방식으로 제공하고, 눈에 보이는 수신 거부 링크도 함께 제공 | 마케팅 및 구독 메시지에 원클릭을 지원하는 List-Unsubscribe 헤더 제공 |
| 수신 거부 처리 | 48시간 이내(권장) | 2일 이내 |
| 스팸 비율 | 0.3% 미만, Google은 0.10% 미만을 권장 | 0.3% 미만 |
쇼핑몰에 특히 중요한 세부 사항은 다음과 같습니다.
- Gmail은 도메인 단위로 집계합니다. 같은 기본 도메인에서 보낸 메시지는 모두 5,000건 기준에 합산되므로 주문 메일, 마케팅 메일, 고객 지원 답장이 모두 더해집니다.
- 개인 Gmail 계정으로 보낸 메일만 집계됩니다. 이 가이드라인은 Google Workspace 계정으로 보내는 메시지에는 적용되지 않습니다.
- 트랜잭션 메일은 원클릭 수신 거부 대상에서 제외됩니다. 다만 주문 확인 메일에도 인증은 필요합니다.
원클릭 수신 거부는 RFC 8058 (새 탭에서 열림)에 정의된 두 헤더를 사용하며, 이 RFC는 두 헤더를 포함하는 유효한 DKIM 서명도 요구합니다.
List-Unsubscribe: <https://example.com/unsubscribe/opaquepart>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
마케팅 플랫폼이 이 헤더를 추가하는지 확인하려면 직접 발송한 캠페인 메일 하나의 원본 소스를 열어 보면 됩니다.
2024년 2월 이후 무엇이 바뀌었나요?
시행은 단계적으로 강화되었고, 다른 메일 서비스 제공업체들도 비슷한 규칙을 도입했습니다.
| 날짜 | 변경 사항 | 출처 |
|---|---|---|
| 2024년 2월 | Gmail과 Yahoo 요건 시행(Yahoo는 단계적으로 시행) | Google (새 탭에서 열림), Yahoo (새 탭에서 열림) |
| 2024년 6월 | Gmail: 스팸 비율이 0.3%를 넘는 대량 발신자는 완화 조치(mitigation) 대상에서 제외 | Gmail FAQ (새 탭에서 열림) |
| 2024년 6월 1일 | 이미 수신 거부 링크가 있던 발신자에 대한 Gmail의 원클릭 수신 거부 적용 기한 | Gmail FAQ (새 탭에서 열림) |
| 2025년 5월 5일 | 하루 5,000건이 넘는 이메일을 보내는 도메인에 대한 Outlook.com 요건 시행. Microsoft의 4월 29일 업데이트에 따르면 요건을 충족하지 못한 메시지는 550 5.7.515로 거부됨 | Microsoft (새 탭에서 열림) |
| 2025년 11월 | Gmail, 일시적 거부와 영구 거부를 포함해 시행 강화 | Gmail FAQ (새 탭에서 열림) |
| 2026년 5월 | RFC 9989가 RFC 7489를 대체하는 DMARC 사양이 됨 | IETF (새 탭에서 열림) |
Outlook.com의 규칙은 개인용 주소(outlook.com, hotmail.com, live.com)에 적용되며, SPF와 DKIM 통과, 그리고 SPF 또는 DKIM과 정렬된 p=none 이상의 DMARC를 요구합니다.
Shopify에서 SPF, DKIM, DMARC는 어떻게 설정하나요?
Shopify 관리자에서 발신자 도메인을 인증한 다음, DNS 호스트에 DMARC 레코드 하나를 추가합니다.
Shopify의 이메일 설정 가이드 (새 탭에서 열림)에 따르면 2024년 2월 1일부터 Gmail과 Yahoo는 브랜드 주소로 메일을 보내려면 인증된 도메인과 DMARC 레코드를 요구합니다. 인증 레코드가 구성되어 있지 않으면 Shopify는 발신자 주소를 store+123@shopifyemail.com 형식으로 바꿉니다. 설정 단계는 다음과 같습니다.
- Shopify 관리자에서 설정 > 알림(Settings > Notifications)으로 이동합니다.
- 발신자 이메일(Sender email) 섹션에서 도메인 인증(authenticate your domain)을 클릭합니다.
- 화면에 표시된 모든 CNAME 레코드를 DNS 제공업체에 추가합니다. 레코드 수는 다를 수 있습니다. Shopify는 이 레코드가 발신자 주소의 SPF와 DKIM을 처리하며 IP 주소를 추가할 필요는 없다고 설명합니다.
- DNS 변경 사항이 반영되기까지 최대 48시간이 걸릴 수 있습니다.
- 이름이
_dmarc이고 값이v=DMARC1; p=none;인 TXT 레코드를 추가합니다. 이 값은 Shopify가 기본값으로 사용하는 값입니다.
Shopify에서 도메인을 구입했거나 Shopify로 도메인을 이전했다면 Shopify가 이 레코드를 대신 관리합니다. 또한 Shopify는 한 도메인에 DMARC 레코드가 하나만 있을 수 있으며, 엄격한 정렬 설정(adkim=s 또는 aspf=s)은 삭제하거나 r로 바꿔야 한다고 안내합니다.
Shopify의 인증은 Shopify가 보내는 메일에만 적용됩니다. 캠페인용으로 다른 플랫폼을 쓰거나, 헬프데스크를 쓰거나, 직원 메일에 Google Workspace를 쓴다면 각각 별도의 DKIM 설정이 필요하고, 반송 처리에 쇼핑몰 도메인을 사용하는 서비스라면 별도의 SPF 항목도 필요합니다.
WooCommerce에서는 이메일 인증을 어떻게 설정하나요?
WooCommerce 공식 문서가 권장하는 대로, 쇼핑몰 도메인으로 서명하는 전용 서비스 제공업체를 통해 WooCommerce 메일을 보냅니다.
WooCommerce는 WordPress의 wp_mail() 함수로 메일을 보내며, 이메일 FAQ (새 탭에서 열림)에서는 자체 서버의 메일 기능보다 전용 SMTP 서비스가 더 안정적이라며 이를 권장합니다. 일반적인 설정 방법은 다음과 같습니다.
- 트랜잭션 이메일 서비스 제공업체를 선택하고 해당 업체에서 도메인을 인증합니다. 업체가 게시할 DKIM 레코드와 SPF include 값을 알려 줍니다.
- SMTP 또는 API 플러그인으로 WordPress를 해당 업체에 연결합니다.
- WooCommerce > 설정 > 이메일(WooCommerce > Settings > Emails)에서 보낸 사람 주소(From address)를 자체 도메인의 주소로 설정합니다. WooCommerce는 Gmail이나 Yahoo 같은 공개 메일 서비스의 주소를 사용하면 스팸함으로 분류되거나 차단될 가능성이 높다고 경고합니다.
_dmarc.yourdomain에 DMARC 레코드를 게시합니다.- WooCommerce > 상태 > 로그(WooCommerce > Status > Logs)에서
transactional-emails소스로 필터링해 어떤 메시지가 발송되었고 어떤 메시지가 실패했는지 확인합니다.
웹 호스팅 서버도 해당 도메인으로 메일을 보낸다면 그 서버를 인증하거나 메일 발송을 꺼야 합니다. 정렬된 SPF나 DKIM 없이 쇼핑몰 도메인 이름으로 메일을 보내는 시스템은 모두 DMARC에서 실패합니다.
SPF 10회 조회 제한이란 무엇이며, 어떻게 지킬 수 있나요?
SPF 검사에서는 DNS 조회가 필요한 항목을 최대 10개까지만 사용할 수 있습니다. 하나라도 넘으면 결과는 permerror가 되어 SPF를 통과하지 못합니다.
RFC 7208 4.6.4절 (새 탭에서 열림)은 횟수에 포함되는 항목으로 include, a, mx, ptr, exists 메커니즘과 redirect 수정자를 꼽습니다. ip4, ip6, all 메커니즘은 횟수에 포함되지 않습니다. 제한은 전체 평가 과정에 적용되므로 include 안에 중첩된 include도 함께 계산됩니다. RFC는 또한 “빈 조회(void lookup)”(응답이 없는 쿼리)를 2회로 제한할 것을 권장하며, ptr 메커니즘은 게시하지 말아야 한다고 명시합니다.
10회 이내로 유지하는 방법은 다음과 같습니다.
- 더 이상 사용하지 않는 서비스의 include를 삭제합니다.
- 고정 주소로 직접 운영하는 서버에는
ip4또는ip6를 사용합니다. - 마케팅 메일을
news.example.com같은 하위 도메인으로 옮깁니다. 하위 도메인은 자체 SPF 레코드와 별도의 조회 횟수를 가집니다. - SPF 레코드를 절대 두 개 게시하지 않습니다. RFC 7208은 여러 레코드를 금지하며, 이 경우 평가 결과는
permerror가 됩니다.
example.com. TXT "v=spf1 include:_spf.google.com include:spf.example-esp.com ~all"
news.example.com. TXT "v=spf1 include:spf.example-marketing.com ~all"
spf.example-esp.com과 spf.example-marketing.com은 각 서비스 제공업체가 안내하는 실제 값을 대신하는 예시입니다.
DMARC를 p=none에서 p=reject로 어떻게 전환하나요?
보고서 수신을 설정한 p=none으로 시작하고, 보고서에서 드러난 모든 정상 발신원을 수정한 다음 정책을 강화합니다.
| 단계 | 레코드 | 목표 |
|---|---|---|
| 1. 모니터링 | v=DMARC1; p=none; rua=mailto:dmarc@example.com | 누가 쇼핑몰 도메인으로 메일을 보내는지 집계 보고서 수집 |
| 2. 수정 | 변경 없음 | 모든 정상 발신원이 정렬된 SPF 또는 DKIM을 통과하도록 조치 |
| 3. 격리(quarantine) | v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com | 인증에 실패한 메일은 스팸함으로 이동 |
| 4. 거부(reject) | v=DMARC1; p=reject; rua=mailto:dmarc@example.com | 인증에 실패한 메일은 수신 거부 |
쇼핑몰 플랫폼, 마케팅 도구, 헬프데스크, 직원 메일이 모두 통과한다는 것이 보고서로 확인될 때만 다음 단계로 넘어갑니다. 집계 보고서는 RFC 9990 (새 탭에서 열림)에 정의되어 있습니다. rua 주소가 보고서 분석 서비스처럼 다른 도메인에 있다면, 해당 도메인이 보고서 수신을 승인하는 레코드를 게시해야 합니다.
예전 가이드에서는 pct=25나 pct=50으로 단계적으로 적용하라고 권하기도 합니다. 그러나 0과 100 이외의 값이 일관되지 않게 적용되었기 때문에 RFC 9989는 pct를 삭제했습니다(레지스트리 항목은 현재 “historic” 상태입니다). 그 대신 t=y는 수신 측에 한 단계 낮은 정책, 예를 들어 reject 대신 quarantine을 적용하도록 요청합니다. 시험 단계를 두고 싶다면 부분 비율 대신 t=y를 사용하는 것이 좋습니다.
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com"
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com"
정책을 시행 단계로 올리면 BIMI도 사용할 수 있습니다. BIMI는 이를 지원하는 받은편지함에 브랜드 로고를 표시합니다. Gmail에서 BIMI를 사용하려면 p=quarantine 또는 p=reject 수준의 DMARC와 VMC(Verified Mark Certificate) 또는 CMC(Common Mark Certificate)가 필요합니다 (Google (새 탭에서 열림)). 도메인으로 들어오는 메일의 경우, MTA-STS(RFC 8461 (새 탭에서 열림))를 사용하면 메일 서버가 신뢰할 수 있는 인증서로 TLS를 제공하지 않을 때 발신 서버가 메일 전달을 거부하도록 지정할 수 있습니다.
쇼핑몰의 레코드는 어떻게 확인하나요?
dig로 세 가지 레코드 유형을 조회하거나, 레코드를 대신 읽어 주는 검사 도구를 사용합니다.
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector._domainkey.example.com
DKIM 선택자(selector)는 서비스 제공업체가 정하며, 직접 보낸 메시지의 DKIM-Signature 헤더에 있는 s= 값에서 확인할 수 있습니다. 이메일 도달률 리포트는 공개 DNS를 읽어 SPF 조회 횟수를 세고, 흔히 쓰이는 DKIM 선택자를 시도하며, DMARC 정책, rua, pct, BIMI, MTA-STS를 검사합니다. 올바른 레코드는 도움이 되지만, 메일 서비스 제공업체는 스팸 신고와 발송 패턴도 함께 고려하므로 어떤 레코드 조합도 받은편지함 도달을 보장하지는 않습니다.
자주 묻는 질문
쇼핑몰에서 하루 5,000건 미만의 이메일을 보내도 DMARC가 필요한가요?
Gmail은 대량 발신자에게만 DMARC를 요구하지만, Shopify는 브랜드 주소로 메일을 보내려면 Gmail과 Yahoo가 인증된 도메인과 DMARC 레코드를 요구한다고 안내합니다. p=none 레코드는 위험이 낮고 보고서도 받을 수 있으므로, 대부분의 쇼핑몰은 DMARC 레코드를 게시하는 것이 좋습니다.
도메인에 SPF 레코드를 두 개 둘 수 있나요?
아니요. RFC 7208에 따르면 한 도메인에 여러 SPF 레코드가 있어서는 안 되며, 여러 개가 있으면 SPF 평가 결과는 permerror가 됩니다. 모든 발신원을 하나의 레코드로 통합해야 합니다.
p=reject로 설정하면 Shopify 주문 이메일이 차단되나요?
Shopify의 CNAME 레코드가 설정되어 있고 DMARC 보고서에서 Shopify 메일이 정렬된 DKIM을 통과하는 것으로 나타난다면 차단되지 않습니다. p=none 이후 단계로 넘어가기 전에 보고서를 확인하고, Shopify의 권장대로 정렬은 완화(relaxed) 설정으로 유지해야 합니다.
DMARC pct 태그는 아직 유효한가요?
2026년 5월에 발행된 RFC 9989는 pct를 삭제하고 테스트 모드용으로 t=y를 도입했습니다. Google의 BIMI 안내는 여전히 pct=100을 요구하지만, 이는 태그가 없을 때의 기본값이므로 새 레코드에서는 pct를 생략하는 것이 가장 간단합니다.
SPF, DKIM, DMARC를 통과하면 이메일이 받은편지함에 도달하는 것이 보장되나요?
아니요. 인증은 필수 요건일 뿐 보장이 아닙니다. Gmail과 Yahoo는 스팸 신고율, 수신 거부 처리, 메시지 형식도 함께 살펴봅니다.
출처
- Email sender guidelines (새 탭에서 열림), Google, 2026년 10월 22일 확인
- Email sender guidelines FAQ (새 탭에서 열림), Google, 2026년 10월 22일 확인
- Sender best practices (새 탭에서 열림), Yahoo Sender Hub, 2026년 10월 22일 확인
- Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders (새 탭에서 열림), Microsoft Tech Community, 2025년 4월 2일(2025년 4월 29일 업데이트)
- Setting up your email (새 탭에서 열림), Shopify 도움말 센터, 2026년 10월 22일 확인
- Email FAQ (새 탭에서 열림), WooCommerce 문서, 2026년 10월 22일 확인
- RFC 7208: Sender Policy Framework (SPF) (새 탭에서 열림), IETF, 2014년 4월
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures (새 탭에서 열림), IETF, 2011년 9월
- RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (새 탭에서 열림), IETF, 2015년 3월(RFC 9989로 대체됨)
- RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (새 탭에서 열림), IETF, 2026년 5월
- RFC 9990: DMARC Aggregate Reporting (새 탭에서 열림), IETF, 2026년 5월
- RFC 8058: Signaling One-Click Functionality for List Email Headers (새 탭에서 열림), IETF, 2017년 1월
- RFC 8461: SMTP MTA Strict Transport Security (MTA-STS) (새 탭에서 열림), IETF, 2018년 9월
- Set up BIMI (새 탭에서 열림), Google Workspace 관리자 고객센터, 2026년 10월 22일 확인
전체 가이드
- ADA 웹사이트 요구서를 받았다면: 먼저 확인할 것ADA 웹사이트 요구서(디맨드 레터)의 흔한 주장, WCAG와의 관계, 준비할 자료, 오버레이의 한계, 변호사 상담 시점을 정리합니다. 법률 자문이 아닙니다.
- 상품 상세페이지 체크리스트: 구매를 막는 요소Baymard·WebAIM 연구를 바탕으로 한 상품 상세페이지 체크리스트: 가격, 배송·반품, 이미지, 리뷰, 모바일 장바구니 버튼, 팝업, 검색, 키보드 사용.
- 쇼핑몰 Core Web Vitals 가이드: LCP·INP·CLSLCP·INP·CLS의 의미와 75번째 백분위수 기준 임계값, 실험실 데이터와 필드 데이터의 차이, Shopify·WooCommerce 쇼핑몰의 개선 방법을 정리합니다.