SPF, DKIM, DMARC 이메일 인증은 이제 기본 요건입니다. 2025년 또는 2026년에 자체 도메인으로 업무 메일을 보낸다면 이 레코드는 수신자의 판단에 중요한 신호가 됩니다. 받은편지함, 스팸 또는 거부 결과는 다른 요인의 영향도 받습니다. 더 큰 구성을 먼저 고르려면 중소기업용 비즈니스 이메일부터 확인하세요.
많은 팀이 콘텐츠만 의심하지만 잘못된 도메인 구성도 흔한 원인입니다. SPF 레코드 하나가 잘못됐거나 DKIM 키가 없거나 DMARC 정책을 게시하지 않았을 수 있습니다. 그러면 반송, 속도 제한, 스팸 분류 또는 전달 문제가 생길 수 있습니다.
이론은 단순하지만 실제 작업에는 주의가 필요합니다. SPF는 실제 발신 경로를 승인하고 DKIM은 서명과 서명된 데이터의 무결성을 검증합니다. DMARC는 검사 실패 시 수신자에게 요청할 정책을 밝히고 표시되는 From 도메인의 정렬을 검사합니다. 올바른 설정은 판단을 돕지만 전달을 보장하지 않습니다.
SPF, DKIM, DMARC 이메일 인증의 실제 역할
세 계층은 메일박스 사업자가 메시지를 평가하도록 돕습니다. SPF는 발신 경로, DKIM은 서명, DMARC는 정렬과 정책을 확인합니다. 해당 대량 발신자 규칙은 세 가지 게시를 모두 요구할 수 있지만 DMARC 통과에는 정렬된 SPF 또는 DKIM 통과 하나면 충분합니다.
| 프로토콜 | 주요 역할 | 확인 대상 | 일반적인 실패 |
|---|---|---|---|
| SPF | 승인 | 연결 IP가 envelope 도메인에 허용됐는지 | DNS 조회 과다 또는 전달로 인한 실패 |
| DKIM | 무결성 | 서명이 유효하고 서명된 데이터가 유지됐는지 | 잘못된 selector, 오래된 키 또는 전송 중 변경 |
| DMARC | 정책 + 정렬 | SPF 또는 DKIM이 통과해 표시되는 From과 정렬됐는지 | SaaS가 자체 도메인으로 보내 정렬 실패 |
DMARC는 SPF와 DKIM 모두의 통과를 요구하지 않습니다. 둘 중 하나가 통과하고 수신자에게 보이는 From 도메인과 정렬되어야 합니다.
SPF: 도메인으로 메일을 보낼 수 있는 주체
SPF는 첫 번째 계층입니다. 수신 서버는 실제 MAIL FROM 또는 envelope 도메인의 SPF TXT 레코드를 읽고 연결 IP의 승인을 확인합니다. 전달과 긴 include 체인은 평가를 망가뜨릴 수 있습니다.
SPF는 DNS의 TXT 레코드입니다. 일반적인 예는 다음과 같습니다.
v=spf1 include:_spf.google.com include:spf.trekmail.net -all각 항목의 의미는 다음과 같습니다.
v=spf1은 레코드 유형을 선언합니다.include:는 다른 도메인이 게시한 발신 인프라를 참조합니다.-all은 그 밖의 소스에 fail을 요청합니다.
중요한 한계는 DNS 조회 10회 제한이며 RFC 7208에 규정되어 있습니다. 각 include뿐 아니라 DNS를 조회하는 중첩 메커니즘과 modifier도 포함됩니다. 초과하면 수신자가 PermError를 반환할 수 있으며 유효한 SPF pass가 아닙니다.
두 해 전에 해지한 CRM의
include:가 남아 있고 마케팅 플랫폼은 세 개, 지원 시스템은 하나를 더했다고 가정해 보세요. 전체 체인을 평가하기 전에는 문제가 드러나지 않을 수 있습니다.
전달 과정에서도 SPF가 실패할 수 있습니다. 대학 시스템이 Gmail로 전달하면 Gmail은 원래 서버 대신 대학 서버를 연결 소스로 볼 수 있습니다. 원래 SPF가 정확해도 전달 뒤에는 실패할 수 있으므로 SPF만으로 충분하지 않습니다.
TrekMail을 사용한다면 최신 문서에서 필요한 include와 중복 없이 기존 레코드에 합치는 방법을 확인하세요. 필수 DNS 레코드.
DKIM: 누가 서명했고 데이터가 유지됐는지 확인
DKIM은 개인 키로 메시지에 서명하고 수신자가 DNS의 공개 키로 검증하게 합니다. 유효하며 정렬된 서명과 정규화된 서명 데이터가 유지될 때 전달 경로를 통과할 수 있습니다. 본문이나 서명된 헤더가 크게 바뀌면 실패합니다.
DKIM 레코드는 selector1._domainkey.example.com 또는 dkim._domainkey.example.com 같은 selector 아래에 있습니다. 발신자는 해당 selector로 서명하고 수신자는 DNS에서 공개 키를 가져옵니다.
일반적인 DNS 값은 다음과 같습니다.
Host: dkim._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G...흔한 운영 오류는 다음과 같습니다.
- 키를 교체했지만 메일 서버는 이전 selector를 사용합니다.
- 사업자를 바꾼 뒤 새 공개 키를 게시하지 않았습니다.
- DNS 호스트가 긴 TXT 값을 잘못 처리했습니다.
- 메일링 리스트가 본문을 고쳐 서명을 망가뜨렸습니다.
호환되는 환경에서는 특별한 사유가 없다면 2048비트 키를 권장 기본값으로 고려하세요. 기존 서버에는 1024비트 구성이 남아 있을 수 있으므로 2026년에 실제 호환성을 시험한 뒤 이전해야 합니다.
관리형 SMTP와 도메인 DKIM을 지원하는 TrekMail 유료 요금제에서는 설정이 실제 활성화된 뒤 도메인 키로 서명할 수 있습니다. 문제 해결은 이메일이 스팸으로 가는 문제를 참고하세요.
DMARC: 수신자에게 요청하는 정책
DMARC는 SPF와 DKIM 위의 정책 계층입니다. 실패 시 적용할 정책을 요청하고 표시되는 From과 SPF 또는 DKIM 도메인의 정렬을 검사합니다. 정렬된 통과가 없으면 DMARC가 통과하지 않습니다.
_dmarc.example.com에 게시합니다. 먼저 다음처럼 시작할 수 있습니다.
v=DMARC1; p=none; rua=mailto:dmarc@example.com발신자 목록, 보고서와 실제 시험에서 충분한 근거를 얻은 뒤 강화하세요.
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.comv=DMARC1; p=reject; rua=mailto:dmarc@example.comp=none은 DMARC 제한을 요청하지 않고 p=quarantine은 의심스러운 처리를, p=reject는 거부를 요청합니다. 수신자의 로컬 정책이 우선하므로 결과를 보장하지 않습니다.
정렬이 핵심 함정입니다.
표시되는 From:
newsletter@yourcompany.com
Return-Path:bounce.vendor.com
DKIM 도메인:vendor.com
SPF와 DKIM이 기술적으로 통과해도 둘 다 yourcompany.com과 정렬되지 않으면 DMARC는 실패합니다.
Mailchimp, HubSpot, Zendesk 및 CRM에서 고객 도메인 인증이 실제로 활성화되지 않았을 때 이런 일이 생깁니다. Google의 현재 FAQ는 개인 Gmail 계정으로 보내는 해당 대량 발신자에게 SPF와 DKIM을 모두 요구하고 직접 메일에서는 최소 하나가 From과 정렬되어야 한다고 설명합니다. p=none을 포함한 최소 DMARC 레코드도 요구합니다. Google 이메일 발신자 가이드 FAQ.
SPF, DKIM, DMARC 중 무엇이 가장 중요한가?
역할이 서로 다릅니다. DKIM은 조건이 유지되면 전달에 더 잘 견디고 SPF는 IP 경로를 승인하며 DMARC는 정렬과 요청 정책을 연결합니다. 현재 적용되는 규칙에 맞게 전체 구성이 필요합니다.
| 질문 | SPF | DKIM | DMARC |
|---|---|---|---|
| 발신 IP 확인? | 예 | 아니요 | SPF 결과를 통해 간접 확인 |
| 메시지 무결성 확인? | 아니요 | 예 | DKIM 결과를 통해 간접 확인 |
| 전달 경로를 잘 견딤? | 아니요 | 보통, 서명된 데이터가 유지될 때 | SPF 또는 DKIM 정렬이 유지될 때만 |
| 수신자 정책 게시? | 아니요 | 아니요 | 예, 요청 형태로 |
| 스푸핑 억제에 도움? | 일부 | 일부 | 예, 수신자 시행에 따라 |
메일 서버 하나만 쓰면 비교적 단순할 수 있습니다. 지원 시스템, 뉴스레터, CRM과 전달을 한 도메인에서 쓰면 DMARC로 실제 정렬 경로를 확인해야 합니다. 보고서는 일부만 제공될 수 있으므로 헤더와 로그도 검증하세요.
전달과 메일링 리스트에서 이상한 실패가 생기는 이유
forwarder가 다시 보내면 SPF가 깨질 수 있습니다. 유효하며 정렬된 DKIM 서명이 유지되면 도움이 되지만 중간 시스템이 본문이나 제목을 고치면 DKIM도 실패할 수 있습니다.
간접 경로에서는 IP가 바뀌고 메일링 리스트가 footer를 추가해 두 정렬 신호가 모두 사라질 수 있습니다. 이는 DMARC 실패를 설명하지만 최종 전달 결과를 증명하지는 않습니다.
ARC는 중간 시스템이 관찰한 인증 이력을 기록해 수신자의 로컬 판단에 맥락을 줄 수 있지만 신뢰를 보존하거나 실패를 자동 통과로 바꾸지는 않습니다. 발신자는 DKIM을 정상화하고 취약한 전달 체인을 피해야 합니다. DMARC 정렬과 이메일 전달을 참고하세요.
전달에 영향을 주는 다른 검사
유효한 인증 레코드도 받은편지함 배치를 보장하지 않습니다. 수신자는 reverse DNS, TLS, 신고율, 평판과 수신 거부도 평가합니다. SPF, DKIM, DMARC는 기반이지 전부가 아닙니다.
- Forward-confirmed reverse DNS: 발신 IP에는 PTR이 필요하고 그 호스트 이름은 같은 IP로 확인되어야 합니다. Google은 해당 발신자 요건에서 정방향 및 역방향 DNS를 명시합니다.
- TLS: 주요 사업자는 TLS를 기대하며 Google FAQ는 비 TLS 메일을 임시 또는 영구 오류의 한 원인으로 설명합니다.
- 스팸 신고: Google의 현재 해당 지침은 0.1% 미만을 권고하고 0.3% 도달을 경고합니다. 보편적인 전달 보장은 아닙니다.
- 원클릭 수신 거부: 해당 프로모션 메일에는 숨은 footer 링크만이 아니라 RFC 8058 방식 헤더가 요구됩니다.
새 도메인은 점진적이며 동의에 기반한 발송이 특히 중요합니다. 갑작스러운 캠페인이나 관리되지 않은 목록은 초기 평판 신호를 해칠 수 있습니다.
운영 환경을 해치지 않고 구성하기
먼저 모든 발신자를 조사하고 한 번씩 정확히 게시한 뒤 실제 메시지로 검증하고 DMARC를 단계적으로 강화하세요. 여러 대표 기간에 걸쳐 드물지만 중요한 경로도 시험하고 롤백 계획을 준비하세요.
- 메일박스 호스트, CRM, 지원 시스템, 뉴스레터, 폼, 청구 및 서버를 모두 기록합니다.
- 지원되는 발신자를 SPF 레코드 하나에 합치고 SPF TXT 레코드를 두 개 게시하지 않습니다.
- 각 발신자가 실제 쓰는 DKIM selector를 게시합니다.
p=none으로 시작해 보고서, 로그와 실제 헤더를 검토합니다.- 외부 발신자의 사용자 지정 도메인 인증을 활성화하고 정렬을 검증합니다.
- 대표 데이터가 뒷받침하면
p=quarantine, 이후p=reject로 통제된 방식으로 이동합니다.
TrekMail 관리형 전송 도메인의 기본 예는 현재 계정 설정에 따라 다음과 같을 수 있습니다.
MX @ mail.trekmail.net. priority 10
TXT @ v=spf1 include:spf.trekmail.net -all
TXT dkim._domainkey v=DKIM1; k=rsa; p=...unique key from dashboard...
TXT _dmarc v=DMARC1; p=quarantine; rua=mailto:dmarc@trekmail.net이 예시는 모든 환경에 그대로 적용되지 않습니다. 실제 계정 값과 필수 DNS 레코드, DNS 상태 확인 절차를 따르세요. 초기 단계에는 내 도메인에 이메일 설정하기도 참고할 수 있습니다.
기존 방식과 새로운 방식
기존에는 큰 제품군에 사용자별 비용을 내거나 DNS, TLS, selector와 평판을 직접 관리했습니다. 모듈형 환경은 메일박스 호스팅과 전송을 분리하고 검증과 마이그레이션을 한곳에 모을 수 있습니다.
현재 안내상 Nano는 최대 10개 도메인, 5 GB 공유 스토리지와 BYO SMTP를 제공할 수 있습니다. 유료 요금제는 현재 월 $3.50부터 시작하며 관리형 SMTP를 포함할 수 있습니다. 사용자 지정 도메인, IMAP, catch-all, 전달, IMAP 마이그레이션과 API 접근은 요금제에 따라 다릅니다. 유료 요금제에는 신용카드가 필요한 14일 무료 체험이 적용될 수 있고 Nano는 현재 조건상 카드 없이 무료일 수 있습니다. 최신 가격, 기능과 한도를 확인하세요.
도메인이 많다면 대시보드 하나, 공유 스토리지, 계정별 DNS 값과 서버 측 마이그레이션이 운영을 모을 수 있지만 비용 절감을 보장하지는 않습니다. 다중 도메인 이메일 호스팅과 TrekMail 요금을 비교하세요.
결론: SPF, DKIM, DMARC는 현재의 기본선
SPF는 envelope 도메인의 IP를 승인합니다. DKIM은 서명과 서명된 데이터의 무결성을 검증합니다. DMARC는 정렬 결과를 표시되는 From에 연결하고 수신자에게 정책을 요청합니다.
유효한 SPF 레코드 하나, 작동하는 DKIM 및 우선 p=none인 DMARC를 게시하세요. 드문 경로를 포함해 모든 발신자를 실제 메시지로 검증하세요. 여러 대표 기간과 롤백 준비 뒤에 시행 정책으로 이동해야 합니다. 사후 진단을 줄일 수 있지만 비용이나 결과를 보장하지는 않습니다.
