새 도메인에서 이메일 설정: 20분 SPF, DKIM, DMARC 체크리스트 (2026)

게시일 2026-07-08

2026-06-29 기준 수치 · 방법론 v7. 261백만 개의 평가된 도메인에 대한 집계 데이터. 평가 방식 보기.

새 도메인은 첫 번째 이메일 전에 네 가지가 필요합니다: 기준선 스캔, 실제 공급자를 지정하는 SPF 레코드 하나, 사용자 정의 도메인 DKIM 서명, 첫날부터 보고가 있는 DMARC 레코드. 대부분의 도메인은 결코 거기까지 도달하지 못합니다 — Defaults.Exposed 센서스(2026-06-29 기준)에 따르면 46.4%(261,086,232개 평가 도메인 중 121,145,609개)가 SPF가 전혀 없습니다.

모든 것을 게시하는 데 약 20분이 걸립니다: 기준선 스캔, SPF 레코드 하나 추가, 공급자의 사용자 정의 도메인 DKIM 활성화, 보고 주소와 함께 DMARC p=none 게시, 선택적으로 MTA-STS 추가, 재스캔 및 보고서 저장. 더 오래 걸리는 것은 어떤 체크리스트도 서두를 수 없는 것들입니다 — DNS 전파와 발송 평판 — 이 가이드는 두 가지 모두에 대해 솔직합니다.

정말 20분이면 충분한가요?

레코드를 게시하는 것에는 맞습니다 — 아래의 모든 단계는 DNS 항목과 공급자 관리 콘솔에서의 몇 번의 클릭입니다. 두 가지는 더 오래 걸리며, 그렇지 않다고 가정하는 것이 새 도메인이 스팸으로 끝나는 이유입니다:

전파. 새 레코드는 보통 몇 분 안에 해석되지만, 리졸버는 TTL에 따라 캐시하고 새로 위임된 도메인은 일관되게 응답하는 데 몇 시간이 걸릴 수 있습니다. dig으로 확인하세요; 캐시가 따라잡는 동안 공황 상태로 편집하지 마세요.
워밍업. 새 도메인에는 발송 평판이 전혀 없으며, 인증은 평판의 전제 조건이지 대체물이 아닙니다. 낮은 인간적 규모의 볼륨으로 시작하여 몇 주에 걸쳐 점진적으로 늘리세요.

솔직한 주장: 20분은 올바르게 게시된 인증을 구매합니다. 합리적인 발송의 다음 몇 주가 배달성을 구매합니다.

20분 체크리스트

먼저 defaults.exposed에서 무료 스캔을 실행하세요. DNS를 건드리기 전에 새 도메인을 스캔하세요. 평가된 “아무것도 설정 안 됨” 기준선은 캡처하는 데 몇 초면 됩니다 — 이후 보고서를 의미있게 만들어줍니다 — 전후 쌍(6단계)이 필요합니다.
실제 공급자를 위한 SPF 레코드 하나를 게시하세요. 공급자의 include가 포함된 v=spf1으로 시작하는 TXT 레코드 정확히 하나 — 예를 들어 Google Workspace는 v=spf1 include:_spf.google.com ~all, Microsoft 365는 include:spf.protection.outlook.com; DNS가 등록기관 패널에 있으면 GoDaddy 안내에서 UI 특이사항을 다룹니다. 레코드 하나만: 두 개의 v=spf1 레코드는 SPF를 완전히 무효화하는 영구 오류입니다 — 1,013,416개 도메인이 빠져 있는 상태로, SPF를 시도하는 도메인 약 138개 중 1개 꼴입니다(2026-06-29 기준 센서스), 보통 마이그레이션 잔재입니다. “혹시 모르니”라는 이유로 include를 추가하지 마세요: SPF는 DNS 조회를 10개로 제한하며, 최소 797,263개 도메인이 그 제한을 초과하여 레코드를 무효화했습니다. 그리고 SPF가 실제로 무엇을 확인하는지 아세요: 수신자는 수신자가 보는 From 헤더가 아닌 Return-Path(RFC5321.MailFrom) 도메인 — 반송 주소 — 에 대해 평가합니다.
사용자 정의 도메인 DKIM 서명을 활성화하세요. 공급자는 어느 쪽이든 메일을 서명합니다; 문제는 서명이 어떤 도메인을 지정하느냐입니다. 이 단계를 완료할 때까지 Google Workspace는 gappssmtp.com 기본값으로, Microsoft 365는 onmicrosoft.com으로 서명합니다 — DKIM을 통과하지만 도메인과 정렬되지 않는 서명이므로 DMARC는 여전히 실패합니다. 관리 콘솔에서 키를 생성하고 공급자가 제공하는 것을 게시하세요: Google은 2048비트 TXT 레코드, Microsoft 365는 두 개의 CNAME(selector1/selector2). 레코드가 DNS 패널에 맞지 않으면 DKIM 수정 참조 — UI로 인해 손상된 긴 키는 고전적인 문제입니다.
첫날부터 DMARC 게시 — 보고 주소와 함께 p=none. _dmarc.yourdomain.com에 TXT 레코드 하나: v=DMARC1; p=none; rua=mailto:[email protected]. 이것이 하는 일을 명확히 하세요: p=none은 아직 아무것도 보호하지 않습니다 — 모니터링 모드입니다. 하지만 비용이 없으며, 집계 보고서가 첫 번째 메시지부터 도메인의 발송 기록을 포괄합니다. 기존 도메인은 보고만으로 몇 주를 보내며 잊어버린 발송자를 발견합니다; 여러분은 그 가시성을 무료로, 0일부터 구매하고 있습니다. 레코드 구조는 DMARC 수정을 참조하세요.
선택적이지만 새 도메인에서는 저렴: MTA-STS와 TLS-RPT. MTA-STS는 발송 서버에 도메인이 인바운드 메일에 TLS를 요구한다고 알립니다(DNS 레코드와 작은 호스팅된 정책 파일); TLS-RPT는 배달 암호화 실패를 보고합니다. 기존 도메인에서는 주의가 필요합니다; 공급자가 하나인 새 도메인에서는 깨뜨릴 것이 없으며, mode: testing은 사실상 위험이 없습니다. 지금 설정하거나 건너뛰세요 — 하지만 결정하고, 표류하지 마세요.
재스캔 및 보고서 저장. 스캔을 다시 실행하세요 — SPF, DKIM, DMARC가 모두 녹색으로 표시되어야 합니다. 등급 보고서를 저장하세요: 출시 시 도메인 상태에 대한 날짜 기록된 증거이며, 정확히 보험사나 클라이언트 설문지가 요청할 항목입니다.

실제로 몇 개의 도메인이 이 체크리스트를 완성하나요?

매우 적습니다 — 대부분이 첫 번째 허들에서 쓰러집니다. Defaults.Exposed 센서스(2026-06-29 기준)에서 평가된 261,086,232개 도메인 중:

체크리스트 마일스톤	센서스 현실 (평가된 261,086,232개 도메인 중, 2026-06-29 기준)
2단계 — SPF 레코드 게시	46.4%가 하지 않음: 121,145,609개 도메인에 SPF 전혀 없음
4단계 이상 — 적용 중인 정책의 DMARC	10.59%(27,640,987개 도메인); 89.41%는 적용 정책 없음
전체 트리아드 — SPF + DKIM + 적용된 DMARC	3.87%(10,092,481개 도메인)

이 페이지에서 설명하는 20분은 전체 트리아드에서 브랜드 새 도메인을 인터넷의 약 96% 앞에 놓습니다. SPF 채택 성숙도 모델은 그 사다리의 모든 계단을 분류합니다.

새 도메인이 p=reject에 얼마나 빨리 도달할 수 있나요?

몇 달이 아닌 몇 주 — 새로 시작하는 진짜 장점입니다. 기존 도메인에서 DMARC 적용이 느린 이유는 레거시입니다: 잊혀진 CRM 커넥터, 2019년에 누군가 연결한 인보이스 도구, 아무도 문서화하지 않은 뉴스레터 플랫폼. 정책을 강화하기 전에 각각이 보고서에서 발견되고 수정되어야 합니다 — 따라서 표준 몇 달간의 전환이 필요합니다.

새 도메인에는 레거시 발송자가 없습니다: 모든 발송 소스를 직접 이번 주에 설정했으며, 4단계의 보고서가 이를 확인할 것입니다. p=none으로 2~4주의 실제 발송을 실행하고, 보고서가 실제로 사용하는 모든 것(사서함, 인보이스, 영수증, 웹사이트 문의 양식)을 포괄하는지 확인하고, 정상적으로 실행되면 p=quarantine으로, 그 다음 p=reject로 이동하세요. 단계적 메커니즘 — pct 증가, 하위 도메인 정책, 감시 항목 — 은 p=none에서 p=reject로에 있습니다; 새 도메인에서는 빠르게 진행하여 평가된 도메인 중 10.59%만이 도달한 곳에 이를 것입니다.

교체하는 이전 도메인은 어떻게 하나요?

이 새 도메인이 리브랜딩의 일부라면 남기는 도메인은 이제 가장 큰 이메일 위험입니다: 여전히 여러분의 것이고, 상대방이 여전히 신뢰하며, 더 이상 감시되지 않습니다. 버리지 마세요 — 명시적으로 잠그세요. 이것은 자체 짧은 작업입니다: 리브랜딩 때의 예전 도메인은 열어둔 문입니다.

자주 묻는 질문

메일 공급자를 선택하기 전에 이 레코드를 게시할 수 있나요? DMARC는 가능합니다 — rua가 있는 p=none은 공급자 독립적이므로 등록하는 날 게시하세요. SPF에는 공급자의 include가 필요합니다; 선택할 때까지 v=spf1 -all(발송이 승인된 것 없음)을 게시하고 2단계에서 교체하세요. 이는 121,145,609개 도메인이 앉아 있는 레코드 없는 상태(평가된 261,086,232개의 46.4%, 2026-06-29 기준)보다 엄밀히 낫습니다.

SPF가 이미 통과하면 DKIM이 필요한가요? 예. SPF는 설계상 전달(forwarding) 시 깨지며, 많은 도구에서 Return-Path 도메인을 검증합니다 — 그게 여러분의 것이 아닐 수 있습니다. 정렬된 DKIM이 둘 다에서 살아남는 요소입니다. 평가된 도메인 중 3.87%만이 전체 SPF+DKIM+적용된-DMARC 트리아드를 완성합니다(2026-06-29 기준 센서스); DKIM은 대부분이 건너뛰는 단계입니다. 스캔에서 표시되면 DKIM 수정에서 시작하세요.

새 도메인은 ~all과 -all 중 어느 것을 사용해야 하나요? 기존 도메인에서 ~all은 잊혀진 발송자를 찾는 동안 신중한 선택입니다. 새 도메인에는 찾을 것이 없습니다: 공급자의 include가 들어오고 DKIM이 서명하면 -all이 훨씬 빨리 안전합니다. 확실히 하고 싶으면? 먼저 DMARC 보고서의 깨끗한 2주를 확인하세요.

세 레코드 모두 통과했는데 메일이 여전히 스팸으로 가나요? 인증과 평판은 다른 것이기 때문입니다: 레코드 통과는 수신자가 메일이 여러분 것임을 검증할 수 있다는 의미이지, 아직 신뢰한다는 것이 아닙니다. 새 도메인은 일관되고, 원하는, 낮은 볼륨의 메일을 발송하고 점진적으로 늘림으로써 신뢰를 얻습니다. 스팸으로 들어가는 것이 아니라 확인을 실패하는 경우 SPF 수정에서 시작하여 스캔 결과를 내려가세요.

소유자에게 보고서 전달

클라이언트를 위해 이 도메인을 설정하는 경우 증거로 작업을 마무리하세요. 6단계 후 무료 스캔을 다시 실행하고 등급 보고서를 비즈니스 소유자에게 전달하세요: SPF, DKIM, DMARC 통과, 알기 쉬운 언어, 출시 시 날짜 기록. 사이버 보험 갱신과 다음 공급업체 보안 설문지에 필요한 증거물입니다 — 도메인이 인터넷의 96%가 결코 해내지 못한 방식으로 시작했음을 증명합니다.

도메인 확인하기 → · 합법적인 이메일을 잃지 않고 p=none에서 p=reject로 → · 집계 데이터만 사용합니다. 데이터는 EU에서 저장 및 처리됩니다.