이메일이 스팸함으로 빠지거나 거절당하거나 “인증되지 않은 발신자” 경고가 뜬다면, 가장 먼저 확인해야 할 건 이메일 인증 설정 입니다.
즉, 이 세 가지 핵심 레코드를 점검해야 한다는 뜻이에요:
- SPF (Sender Policy Framework)
- DKIM (DomainKeys Identified Mail)
- DMARC (Domain-based Message Authentication, Reporting, and Conformance)
이 DNS 레코드들은 Gmail, Outlook, Yahoo 같은 메일박스 사업자에게 “이 도메인이 정말로 이메일을 보낼 권한이 있는지”를 알려줍니다. 셋 중 하나라도 빠지거나 깨졌거나 너무 약하면, 메시지에 대한 신뢰는 빠르게 무너져요.
이 무료 2026 가이드에서 배울 수 있는 것:
- SPF 레코드 확인하는 방법
- DKIM 레코드 확인하는 방법
- DMARC 레코드 확인하는 방법
- 레코드가 존재해도 메일이 스팸으로 가는 이유
- 가장 흔한 이메일 인증 실수
- 어떤 도메인이든 deliverability 문제를 가장 빠르게 점검하는 방법
비즈니스 도메인, 뉴스레터, 지원 받은편지함, 아웃리치 캠페인, SaaS 제품, 콜드 이메일을 운영한다면, 이건 가장 중요한 기술 점검 중 하나예요.
빠른 답변: 어떤 도메인의 SPF / DKIM / DMARC, 어떻게 확인하나요?
임의의 도메인에서 SPF, DKIM, DMARC 확인 절차:
- 도메인의 DNS TXT 레코드를 조회한다
- SPF 레코드 가 존재하고 유효한지 확인한다
- DKIM 셀렉터 가 유효한 공개 키로 해석되는지 확인한다
_dmarc.당신의도메인.com에 DMARC 정책 이 있는지 본다- 레코드가 단순히 존재하는 게 아니라 제대로 구성 되었는지 확인한다
- 그래도 스팸으로 가면, 실제 이메일 헤더 를 분석해 무엇이 통과하고 무엇이 실패했는지 본다
초심자에게 가장 빠른 방법은 Email Health Checker 로 도메인 전체 스캔을 먼저 돌려본 다음, 이상한 부분이 있으면 개별 레코드로 들어가는 거예요.
2026년에 SPF, DKIM, DMARC 가 중요한 이유
이메일 사업자들은 그 어느 때보다 엄격해졌어요.
요즘 받은편지함은 메시지 본문만 보지 않습니다 — 도메인의 발신 설정이 신뢰할 만한지를 봅니다.
탄탄한 SPF, DKIM, DMARC 구성은 다음을 도와줍니다:
- 받은편지함 도달률 향상
- 이메일 스푸핑 위험 감소
- 도메인을 이용한 피싱 악용 방지
- 스팸함 으로 빠질 가능성 감소
- Gmail, Outlook, Yahoo, 기업용 메일 게이트웨이의 신뢰 상승
- 시간이 지나며 더 건강한 발신자 평판 구축
다음 중 하나라도 보내고 있다면:
- 트랜잭션 메일
- 인증 코드
- 뉴스레터
- 콜드 아웃리치
- 지원 답변
- 비밀번호 재설정 메일
- SaaS 알림
…이메일 인증은 더 이상 선택사항이 아니에요.
SPF, DKIM, DMARC 가 뭔가요? (쉽게 설명)
레코드를 점검하기 전에 각각이 무엇을 하는지 알아두면 좋아요.
SPF: 도메인을 대신해 메일을 보낼 자격이 있는 주체
SPF 는 어떤 메일 서버나 서비스가 이 도메인을 대신해 메일을 보낼 수 있는지를 나열한 DNS TXT 레코드입니다.
예를 들어 다음을 사용 중이라면:
- Google Workspace
- Microsoft 365
- Mailgun
- SendGrid
- Amazon SES
- Brevo
- Zoho Mail
…보통 이 서비스들은 SPF에 포함되어야 해요.
SPF가 막아주는 것: 당신 도메인을 사칭해 보내는 미인가 발신자.
SPF가 보장하지 않는 것: 표시되는 “From” 주소가 DMARC가 받아들이는 방식대로 정렬되는 것.
DKIM: 메일이 서명되었음을 증명
DKIM 은 보내는 메일에 암호 서명을 추가합니다.
받는 서버가 메시지를 받으면, DNS에 있는 공개 키를 보고 다음을 확인해요:
- 이 메일이 인가된 발신자가 서명한 것인지
- 전송 중에 변조되지 않았는지
DKIM이 막아주는 것: 변조와, 유효한 서명이 없는 위조 메일.
중요: DNS에 DKIM 레코드가 있는 것 = 실제 발송 시 DKIM이 정상 작동, 이라는 뜻은 아닙니다.
DMARC: SPF / DKIM 이 실패했을 때 받는 쪽이 어떻게 할지를 지시
DMARC 는 SPF, DKIM 위에 얹혀집니다.
수신 서버에 다음을 알려주죠:
- 실패한 메일을 모니터링할지, 격리할지, 거부할지
- 집계 리포트 를 어디로 보낼지
- 인증된 도메인이 표시되는 “From” 도메인과 정렬되는지
DMARC 정책 값:
p=none→ 모니터링만p=quarantine→ 의심 메일은 스팸함으로p=reject→ 실패한 메일은 거부
DMARC가 막아주는 것: 도메인 스푸핑, 사칭, 인증의 약한 시행.
도메인의 SPF / DKIM / DMARC 확인하는 방법
가장 쉽고 실용적인 워크플로우입니다.
1단계: 먼저 이메일 인증 종합 점검을 돌린다
레코드를 한 줄씩 수동으로 보지 말고, 도메인 단위의 광범위 스캔 부터 돌리세요.
Email Health Checker 로 다음을 빠르게 파악할 수 있어요:
- SPF 상태
- DKIM 존재 여부
- DMARC 존재 여부
- MX 설정
- 인증의 기본 건강 상태
- 흔한 위험 신호
이게 가장 좋은 첫 번째 단계예요 — 깊이 들어가기 전에 도메인에 명백한 빈틈이 있는지 즉시 알려주거든요.
왜 중요한가: 대부분의 도메인은 DMARC가 없거나, DKIM이 없거나, MX가 빠졌거나, SPF 구조가 깨진 것 같은 단순한 문제로 실패합니다.
2단계: SPF 레코드 확인하는 방법
SPF 레코드 확인하는 방법 을 제대로 알고 싶다면, “있냐?”만 묻지 마세요. 유효하고, 깨끗하고, 한도 안에 있냐 를 물어야 해요.
유효한 SPF 레코드 모양
SPF 레코드는 보통 이렇게 시작합니다:
v=spf1 include:_spf.google.com ~all
확인할 점
v=spf1으로 시작- 도메인에 SPF TXT 레코드가 단 하나
- 현재 사용 중인 발송 서비스가 포함됨
- 합리적인 정책으로 끝남:
~all(소프트 페일)-all(하드 페일)
- DNS 룩업 10회 한도 를 넘지 않음
흔한 SPF 실수
- 여러 개의 SPF 레코드 게시
- 과거 메일 사업자의
include:항목이 남아 있음 +all같은 너무 관대한 규칙- 10 룩업 한도 초과
- ESP 변경 후 SPF 업데이트 안 함
2026년의 큰 SPF 문제: 10 룩업 한도
이건 deliverability 의 가장 흔한 ‘조용한 살인자’ 중 하나예요.
SPF에 너무 많은 중첩 사업자, 포워딩 서비스, SaaS 도구가 들어가면 허용된 DNS 룩업을 초과해 조용히 실패합니다.
SPF가 복잡하다면 SPF Flattening Tool 로 include 체인을 명시적인 IP로 평탄화해 한도 안에 머물게 할 수 있어요.
3단계: DKIM 레코드 확인하는 방법
DKIM 레코드 확인하는 방법 을 검색 중이라면, 핵심은 이거예요:
DKIM은 셀렉터 기반입니다.
따라서 보통 다음이 필요합니다:
- 도메인
- 발송 플랫폼이 사용하는 셀렉터
DKIM 레코드는 보통 이런 위치에 있어요:
selector1._domainkey.example.com
확인할 점
- 셀렉터가 정상적으로 해석된다
- TXT 레코드가 존재한다
- 공개 키 (
p=) 가 들어 있다 - 레코드 형식이 올바르다
- 키 강도가 충분하다
- 플랫폼이 실제 발송 메일에 서명하고 있다
흔한 DKIM 실수
- 잘못된 셀렉터 사용
- 레코드만 게시하고 사업자 측에서 DKIM 활성화 안 함
- DNS의 TXT 형식이 깨짐
- 약하거나 오래된 키 크기
- 잘못된 키 로테이션
- “레코드가 있다 = DKIM 통과” 라고 착각
레코드 자체를 더 깊이 기술적으로 들여다보고 싶다면 DKIM Analyzer 로 키 강도, 레코드 구조, 가능한 DKIM 설정 문제를 점검해 보세요.
4단계: DMARC 레코드 확인하는 방법
DMARC 레코드 상태 확인하는 방법 을 제대로 알고 싶다면, 다음 위치의 TXT 레코드를 보세요:
_dmarc.example.com
기본 DMARC 레코드는 이런 형태입니다:
v=DMARC1; p=none; rua=mailto:dmarc@example.com
확인할 점
v=DMARC1으로 시작- 정책이 있음:
p=nonep=quarantinep=reject
- 가능하면 보고 주소 포함:
rua=mailto:...
- 선택적인 포렌식 보고:
ruf=mailto:...
- 정렬 설정이 있을 수 있음:
adkim=aspf=
- 선택적 점진 적용:
pct=
흔한 DMARC 실수
- DMARC 레코드 자체가 없음
- 영원히
p=none - 보고용 메일박스 미설정
- 깨진 구문
- 정렬 실패 무시
- 일반 레코드를 이해 없이 복붙
레코드를 빠르게 검증하고 모니터링만 하는지 실제로 시행 중인지 보려면 DMARC Checker 를 사용하세요.
SPF / DKIM / DMARC 가 있어도 메일이 스팸으로 가는 이유
deliverability 에서 가장 자주 오해되는 부분이에요.
도메인에 SPF, DKIM, DMARC 레코드가 존재 해도 메일은 여전히 스팸함으로 갈 수 있어요.
왜?
존재 와 올바른 구성 은 같은 게 아니거든요.
흔한 이유:
- SPF는 있지만 10 룩업 한도를 초과
- SPF는 통과하지만 정렬 실패
- DKIM 레코드는 있지만 실제 서명이 실패
- 포워딩이나 재작성 후 DKIM이 깨짐
- DMARC는 있지만
p=none에 머묾 - 도메인 평판이 나쁨
- 발송 IP 평판이 나쁨
- 본문이 스팸 필터를 자극
- 링크가 의심스러워 보임
- 바운스 비율이 높음
- 불만 비율이 높음
- 역방향 DNS가 없거나 약함
- 발송량 패턴이 갑자기 변함
중요한 진실
SPF + DKIM + DMARC 는 토대지, deliverability 시스템 전체가 아닙니다.
이 셋은 사업자가 당신을 신뢰하도록 도와주지만, 나쁜 평판이나 스팸성 행동을 덮어주진 않아요.
메일이 왜 스팸으로 갔는지 알아내는 방법
DNS 레코드는 멀쩡한데 실제 메일이 스팸으로 간다면, DNS만 들여다보지 말아야 해요.
원본 이메일 헤더 를 살펴봐야 합니다.
받는 서버가 실제로 본 게 거기 다 적혀 있거든요.
Email Header Analyser 로 다음을 확인해 보세요:
- SPF pass/fail
- DKIM pass/fail
- DMARC pass/fail
- Authentication-Results
- 메일 홉 / 릴레이 경로
- 정렬 단서
- 스팸 라우팅 단서
이게 결정적이에요: 많은 사람들이 DNS 레코드만 확인하고 실제로 도착한 메시지 는 테스트하지 않거든요. 숨은 문제는 거기서 드러납니다.
이메일 인증을 가장 빠르게 점검하는 워크플로우
2026년 가장 단순하고 실용적인 순서는 이렇습니다:
- Email Health Checker 로 광범위 스캔
- DMARC Checker 로 DMARC 정책과 시행 수준 확인
- DKIM Analyzer 로 DKIM 품질과 셀렉터 유효성 확인
- SPF Flattening Tool 로 SPF 구조와 룩업 수 검토
- 받은편지함 도달이 여전히 실패하면 Email Header Analyser 로 실제 헤더 분석
이렇게 하면 다음을 다 얻습니다:
- DNS 레벨 시각
- 정책 레벨 시각
- 실제 메시지 레벨 시각
기본 TXT 룩업 하나만 돌리는 것보다 훨씬 유용합니다.
피해야 할 흔한 SPF / DKIM / DMARC 실수
비즈니스 도메인, SaaS 앱, 콜드 이메일 환경에서 반복적으로 보이는 패턴들입니다.
SPF 실수
- 여러 개의 SPF TXT 레코드
- 너무 많은
include:룩업 - 사용 안 하는 옛 사업자가 그대로 남음
+all또는 너무 느슨한 정책- 사업자 변경 후 SPF 업데이트 안 함
DKIM 실수
- 잘못된 셀렉터
- 레코드만 게시, 서명은 비활성
- TXT 형식이 깨짐
- 약한 키
- 실제 보낸 메일로 테스트하지 않음
DMARC 실수
- DMARC 레코드 없음
- 영원히
p=none rua=보고 주소 없음- 정렬 무시
- 깨진 구문
- 시행으로의 진전 없음
2026년을 위한 SPF / DKIM / DMARC 베스트 프랙티스
올해 더 좋은 받은편지함 도달을 원한다면 이 기준선을 목표로 잡으세요:
- SPF 레코드는 깔끔하게 단 하나만 게시
- SPF는 10 룩업 한도 아래로 유지
- 사용하지 않거나 옛 사업자는 SPF에서 제거
- 강력한 DKIM 키 사용
- DKIM이 실제 발송 메일 에 서명 중인지 확인
- 발송하는 모든 활성 도메인에 DMARC 게시
- 모니터링으로 시작 → 시행으로 이행
- DMARC 보고서를 수집
- pass/fail 만이 아니라 정렬도 점검
- DNS / ESP 변경 후 재테스트
- 무언가 이상하면 헤더 살펴보기
- 평판과 바운스 추세 모니터링
이 체크리스트는 누구에게 유용할까?
다음을 운영한다면 이 가이드가 유용해요:
- 비즈니스 웹사이트
- SaaS 제품
- 지원 받은편지함
- 뉴스레터 시스템
- 트랜잭션 메일
- 콜드 아웃리치 캠페인
- 에이전시 관리 클라이언트 도메인
- 자체 도메인 메일 포워딩
- 이커머스 알림
- 비밀번호 재설정 / 인증 시스템
이메일이 비즈니스에 중요하다면, 인증도 중요합니다. 그리고 테스트에 일회용 이메일 을 쓴다면, 인증을 이해하면 정말로 잘 도착하는 사업자를 고를 수 있어요.
마무리
자기 도메인에서 이메일을 보낸다면, SPF, DKIM, DMARC 확인 방법을 익히는 것은 ROI가 가장 높은 기술 스킬 중 하나예요.
이를 통해:
- 받은편지함 도달을 개선
- 스푸핑 위험 감소
- 메일이 왜 스팸으로 가는지 진단
- 숨은 DNS 실수 포착
- 메일 사업자와의 신뢰 구축
가장 중요한 한 줄 요약:
SPF, DKIM, DMARC 레코드가 있는 것만으론 부족합니다 — 유효해야 하고, 정렬되어야 하고, 실제 메일 동작에 대해 테스트되어야 합니다.
언뜻 “설정됨” 처럼 보이는 도메인이 운영 환경에서 실패하는 일이 흔해요.
그래서 가장 똑똑한 접근은 이거예요:
- 도메인을 점검
- 레코드를 검사
- 정책을 검증
- 실제 메시지를 테스트
이걸 꾸준히 한다면, 인증 문제 대부분은 deliverability 가 망가지기 전에 잡아낼 수 있어요.
자주 묻는 질문 (FAQ)
도메인의 SPF는 어떻게 확인하나요?
v=spf1 로 시작하는 DNS TXT 레코드를 찾으세요. SPF 레코드가 단 하나 인지, 현재 발송 사업자가 포함되어 있는지, DNS 룩업 10회 한도 를 넘지 않는지 확인합니다.
도메인의 DKIM은 어떻게 확인하나요?
DKIM 확인에는 도메인 과, 보통 발송 플랫폼이 쓰는 셀렉터 가 필요합니다. DKIM TXT 레코드는 유효한 공개 키와 올바른 형식을 가져야 하며, 실제 보내는 메일이 정말로 서명되는지도 함께 확인해야 합니다.
도메인의 DMARC는 어떻게 확인하나요?
_dmarc.당신의도메인.com 의 TXT 레코드를 보세요. v=DMARC1 로 시작하고 p=none, p=quarantine, p=reject 같은 정책이 들어 있어야 합니다. 보고용 rua= 주소도 강력히 권장됩니다.
가장 좋은 SPF / DKIM / DMARC 체커는?
가장 좋은 워크플로우는 단일 점검이 아니라 다음의 조합입니다:
- 도메인 단위 이메일 인증 스캔
- DMARC 직접 검증
- DKIM 레코드 검사
- SPF 구조 검토
- 실제 이메일 헤더 분석
이렇게 해야 DNS 시각과 실제 메시지 시각을 모두 얻습니다.
SPF, DKIM, DMARC 가 있어도 메일이 스팸으로 가는 이유는?
레코드의 존재가 받은편지함 도달을 보장하지 않기 때문입니다. 다음 이유로 스팸함에 갈 수 있습니다:
- 정렬 실패
- 깨진 DKIM 서명
- 약한 SPF 구조
- 도메인 / IP 평판 악화
- 스팸 트리거 콘텐츠
- 높은 불만 / 바운스 비율
- 시행이 약한 DMARC 정책
DMARC 는 SPF 와 DKIM 둘 다 필요한가요?
DMARC 는 SPF, DKIM 모두 올바르게 설정되어 있을 때 가장 잘 동작합니다. 기술적으로는 둘 중 하나 가 정렬과 함께 통과해도 DMARC 는 통과할 수 있지만, 둘 다에 의존하는 게 훨씬 견고하며 권장됩니다.
SPF 의 10 룩업 한도가 뭔가요?
SPF 평가는 최대 10번의 DNS 룩업 까지만 수행할 수 있어요. include: 메커니즘이 너무 많아 한도를 넘으면 SPF 가 실패할 수 있고, 이는 deliverability 에 악영향을 줍니다.
DMARC 에서 p=none 과 p=reject, 어느 쪽?
도입 초기에는 모니터링 목적의 p=none 이 유용합니다. 하지만 장기간 p=none 에 머무는 건 보호를 약화시켜요. 인증이 안정되면 대부분의 도메인은 p=quarantine 이나 p=reject 를 향해 나아가야 합니다.
SPF, DKIM, DMARC 만 있으면 deliverability 가 충분한가요?
아니요. 이 레코드들은 필수지만, deliverability 는 다음에도 의존합니다:
- 도메인 평판
- IP 평판
- 콘텐츠 품질
- 불만 비율
- 바운스 비율
- 발송 행동
- 리스트 위생
- 인프라 품질
인증은 토대지, 시스템 전체가 아닙니다.
함께 읽기
Your temp mail is ready right now
No signup, no password. A disposable inbox waiting the moment you open the page.
Get My Free Temp Mail →