SPF, DKIM, DMARC 설명: 스토어 운영자를 위한 이메일 인증

SPF, DKIM, DMARC는 이메일이 정말 내 도메인에서 왔음을 증명하는 세 가지 DNS 레코드예요. 이 레코드가 없으면 누구나 내 스토어에서 보낸 것처럼 메일을 보낼 수 있고, 받은편지함 제공업체는 진짜 뉴스레터와 사기 메일을 구분할 방법이 없어요. 이제 Gmail, Yahoo, Outlook이 대량 발신자에게 이를 요구하므로, 이메일 마케팅을 하는 스토어에 더는 선택 사항이 아니에요.

이 가이드는 레코드별 역할을 쉬운 말로 설명하고, 어떻게 생겼는지 보여 주고, 설정 과정을 안내하고, 많은 사람이 헷갈리는 정렬을 다뤄요. 마지막에는 일부 받은편지함에 로고를 보여 주는 새로운 표준 BIMI를 살펴봐요.

SPF(Sender Policy Framework)는 내 도메인으로 이메일을 보내도 되는 서버와 서비스의 목록이에요. 메시지가 도착하면 수신 서버가 발신 서버가 목록에 있는지 확인해요. 간단한 SPF 레코드는 이렇게 생겼어요.

v=spf1 include:_spf.google.com include:sendingservice.example ~all

• v=spf1: 이 레코드가 SPF임을 표시해요.
• include:: 메일박스 제공업체나 이메일 마케팅 도구처럼 다른 서비스의 서버 목록을 추가해요.
• ~all 또는 -all: 그 외 모든 서버를 어떻게 처리할지 정해요. ~all은 “soft fail”(의심스럽게 처리), -all은 “fail”이에요.

많은 사람이 놓치는 규칙이 두 가지 있어요. 도메인당 SPF 레코드는 하나만 둘 수 있으므로, 새 서비스는 두 번째 레코드를 만들지 말고 기존 레코드에 추가하세요. 또 SPF는 DNS 조회를 최대 10회까지만 허용해요. 표준인 RFC 7208, section 4.6.4는 구현체가 include, a, mx, ptr, exists 메커니즘과 redirect 수정자를 10회로 제한해야 하며, 넘으면 영구 오류를 반환한다고 정해요. include마다 횟수에 들어가고, 어떤 include는 그 안에 다른 include를 담고 있어서, 긴 레코드는 조용히 망가져요.

DKIM(DomainKeys Identified Mail)은 각 이메일에 디지털 서명을 더해요. 발송 서비스가 개인 키로 메시지에 서명하고, 짝이 되는 공개 키는 내가 DNS에 게시해요. 수신 측은 이 키로 서명이 유효한지, 메시지가 도중에 바뀌지 않았는지 확인해요.

레코드는 발송 서비스가 정한 이름인 “셀렉터” 아래에 있어요. s1._domainkey.yourstore.com 같은 형태예요. 발송하는 서비스마다 자기 셀렉터를 받으므로, DKIM 레코드를 여러 개 둬도 충돌하지 않아요. 게시할 정확한 이름과 값은 이메일 도구가 알려 줘요.

DMARC(Domain-based Message Authentication, Reporting and Conformance)는 SPF와 DKIM을 사람들이 보는 발신자(From) 주소와 연결하고, 실패한 메일을 어떻게 처리할지 수신 측에 알리고, 리포트를 보내 달라고 요청해요. 시작용 레코드는 이렇게 생겼어요.

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourstore.com

• p=none: 모니터링만 해요. 수신 측은 평소처럼 배달하고 리포트를 보내요. Gmail, Yahoo, Outlook은 이를 대량 발신자의 최소 요건으로 인정해요.
• p=quarantine: 실패한 메일은 스팸함으로 가요.
• p=reject: 실패한 메일은 거부돼요.
• rua=: 일일 집계 리포트를 받는 곳이에요. 누가 내 도메인으로 메일을 보내고 있고 그 메일이 통과하는지 보여 줘요.

p=none으로 시작해 몇 주 동안 리포트를 읽으며 내 도메인으로 보내는 서비스(스토어, 헬프데스크, 청구서 도구)를 모두 찾고, 실패하는 곳을 고친 뒤 quarantine으로, 나중에 reject로 옮기세요. 바로 reject로 가면 내 정상 메일까지 막힐 수 있어요.

DMARC는 SPF나 DKIM이 통과하고 확인한 도메인이 발신자(From) 주소의 도메인과 일치할 때만 통과해요. 이를 정렬이라고 불러요. 메시지가 이메일 도구의 도메인으로 SPF를 통과해도 From 주소가 yourstore.com이면 DMARC에 실패할 수 있어요. 보통은 내 도메인으로 DKIM 서명을 하면 해결돼요. 이메일 도구가 준 DKIM 레코드를 추가하면 도구가 설정해 줘요. Gmail의 발신자 가이드라인은 대량 발신자의 From 도메인이 SPF 또는 DKIM과 정렬되도록 요구해요.

• 내 도메인으로 이메일을 보내는 서비스를 모두 적으세요. 메일박스 제공업체, 스토어 플랫폼, 이메일 마케팅 도구, 헬프데스크, 청구서 도구 등이에요.
• DNS 호스트(보통 도메인 등록 업체나 Cloudflare)에서 SPF TXT 레코드를 찾거나 만들고 서비스를 각각 include하세요. 레코드는 하나만 두고 조회 횟수를 세세요.
• 발송 서비스마다 주는 DKIM 레코드를 추가하세요.
• _dmarc에 p=none과 리포트 받을 주소를 넣은 DMARC 레코드를 추가하세요.
• Gmail로 테스트 이메일을 보내고 “Show original”을 열어 SPF, DKIM, DMARC가 모두 PASS인지 확인하세요.
• 몇 주 동안 DMARC 리포트를 읽고, 실패하는 부분을 고친 뒤 정책을 강화하세요.

DNS 변경 사항이 모든 곳에 반영되려면 시간이 걸릴 수 있어요. 게시 직후 확인에 실패하면 레코드를 바꾸기 전에 기다렸다가 다시 시도하세요.

BIMI(Brand Indicators for Message Identification)는 지원하는 받은편지함에서 이메일 옆에 로고를 보여 줘요. DMARC를 대체하지 않고 그 위에 더해져요. 2026년 10월 19일에 확인한 Google의 BIMI 설정 가이드에 따르면 Gmail에는 다음이 필요해요.

• pct가 100으로 설정된 quarantine 또는 reject DMARC 정책. 모니터링 전용(p=none)은 해당되지 않아요.
• 상표 등록된 로고가 필요한 Verified Mark Certificate(VMC), 또는 로고가 상표 등록되지 않았다면 Common Mark Certificate(CMC).
• SVG Tiny Portable/Secure(SVG Tiny PS) 형식에 최소 96×96픽셀인 로고.

BIMI는 이미 엄격한 DMARC를 갖추고 브랜드 인지도를 더 높이고 싶은 브랜드에 값어치가 있어요. 대부분의 스토어는 SPF, DKIM, DMARC를 제대로 갖추는 것이 먼저예요. SmartyTap은 BIMI를 대신 설정해 주지 않아요. BIMI 레코드와 인증서는 DNS 호스트와 인증서 제공업체를 통해 직접 게시해야 해요.

SmartyTap에 발신 도메인을 추가하면 SmartyTap이 게시할 DKIM 레코드를 알려 주고, 도메인의 DNS 레코드(DKIM과 DMARC 포함)를 확인하고, 아직 고쳐야 할 것을 알려 줘요. 새 발신 도메인은 이후 웜업 일정을 따르고, 원클릭 수신 거부와 반송·스팸 신고의 자동 발송 제외가 기본으로 들어 있어요. 문서의 이메일 도메인 인증을 보세요.

SmartyTap Starter는 월 US$20에 연락처 2,500개, 이메일 25,000통, SMS 크레딧/세그먼트 250개를 제공해요. Pro는 월 US$199(또는 연 US$1,990)에 연락처 25,000개, 이메일 250,000통, SMS 크레딧/세그먼트 2,500개를 제공해요. 크레딧 1개는 세그먼트 1개에 쓰이고 2센트예요. 새 워크스페이스에서 발송하려면 유료 요금제가 필요하고, 무료 체험은 없어요. SmartyTap 가격을 보세요.

용어집: SPF, DKIM, DMARC, BIMI. 다음 글: 이메일 전달률 가이드, 이메일 수신자 목록 정리 방법, Shopify 이메일 마케팅, 블랙 프라이데이 이메일·SMS 체크리스트.

SPF는 내 도메인으로 메일을 보내도 되는 서버를 나열해요. DKIM은 메시지마다 서명해서 수신 측이 내 도메인에서 바뀌지 않고 왔음을 확인할 수 있게 해요. DMARC는 둘 중 하나가 From 주소와 일치하는지 확인하고, 일치하지 않을 때 수신 측이 할 일을 알리고, 리포트를 보내 줘요.

대량으로 보낸다면 필요해요. Gmail, Yahoo, Outlook은 대량 발신자에게 SPF, DKIM, DMARC 레코드(최소 p=none)를 요구하고(2026년 10월 19일 확인), 세 가지 모두 소규모 발신자의 받은편지함 도착에도 도움이 돼요.

아니요. 도메인에는 SPF 레코드가 정확히 하나만 있어야 해요. 두 개면 SPF가 실패해요. 모든 서비스를 레코드 하나로 합치고 DNS 조회를 10회 아래로 유지하세요.

p=none과 리포트 받을 주소로 시작하세요. 리포트에서 정상 메일이 모두 통과하는 것을 확인하면 p=quarantine으로, 그다음 p=reject로 옮기세요.