이메일 공급업체를 전환한 후 SPF가 작동하지 않음 — 마이그레이션 수정 방법 (2026)

게시일 2026-07-08

기준일: 2026-06-29 · 방법론 v7. 261백만 개 등급 도메인에 대한 집계 센서스 데이터. 등급 산정 방식을 참고하세요.

SPF는 대개 이메일 공급업체를 전환한 후 새 공급업체의 레코드가 기존 레코드 옆에 추가되었기 때문에 고장납니다. 두 개의 v=spf1 레코드는 영구적인 오류입니다 — SPF가 완전히 무효화됩니다. Defaults.Exposed의 261백만 도메인 센서스에 따르면 1,013,416 도메인 — SPF를 시도하는 도메인 138개 중 약 1개 — 이 그 상태입니다. 하나로 병합하세요.

수정에 약 10분이 걸립니다: 도메인을 검사하여 마이그레이션이 남긴 것을 정확히 확인하고, 권위 네임서버에서 모든 SPF 레코드를 목록으로 작성하고, 새 공급업체만 포함하는 단일 레코드로 병합하고, dig으로 재확인하세요. 이 가이드는 각 단계를 안내하며, 대부분의 마이그레이션이 잊어버리는 DKIM 및 네임서버 확인도 포함합니다.

마이그레이션 직후 SPF가 고장난 이유는?

새 공급업체의 설정 가이드가 “이 TXT 레코드를 추가하세요”라고 했고 — 기존 레코드 옆에 추가했기 때문입니다. 그것이 SPF 표준이 허용하지 않는 단 하나의 것입니다. RFC 7208(§3.2, §4.5에 규정된 오류 결과)은 도메인당 정확히 하나의 v=spf1 레코드를 허용합니다; 두 개 이상을 발견한 수신자는 어느 것이 권위 있는지 추측하는 대신 PermError를 반환해야 합니다. PermError는 SPF가 무효를 의미합니다: 이전 레코드도, 새 레코드도, SPF 자체가 없는 것입니다.

그리고 거기서 끝나지 않습니다. DMARC는 PermError를 SPF 다리의 실패로 처리하므로, 메일이 이제 DKIM에 완전히 의존하게 됩니다. 새 공급업체의 DKIM도 아직 설정되지 않았다면 — 마이그레이션 중간에 흔한 일 — 인프라를 변경한 바로 그 순간에 미인증 상태로 발송하게 되는데, 이때 수신자들이 가장 엄격하게 검토합니다.

이것이 공급업체를 전환할 때 보호를 무효화하는 복사-붙여넣기이며, 드물지 않습니다: Defaults.Exposed의 261백만 도메인 센서스(기준: 2026-06-29)에 따르면 현재 1,013,416 도메인이 두 개 이상의 SPF 레코드를 게시하고 있습니다 — SPF를 시도하는 139백만 도메인 중 약 138개 중 1개. 두 레코드 함정의 전체 수치는 별도 보고서에 있습니다; 이 페이지는 절차적 수정입니다.

마이그레이션이 무엇을 남겼나요?

다섯 가지 잔재가 거의 모든 마이그레이션 후 SPF 실패를 일으킵니다. 이 순서대로 확인하세요:

남겨진 것	보이는 것	수정 방법
기존 SPF 레코드, 새 것 옆에 DNS에 여전히 있음 (두 개의 `v=spf1` 레코드)	체크 도구가 “복수의 SPF 레코드” 또는 PermError를 보고; SPF 완전 작동 중단	하나로 병합하고 나머지 삭제 — 아래 단계
하나의 레코드 안에 이전 공급업체의 `include:`	SPF는 작동하지만 DNS 조회를 낭비하고 이전 공급업체 서버가 여전히 귀사 명의로 발송 가능	이전 시스템에서 메일이 완전히 이전된 후 제거
새 공급업체의 `include:` 미추가	새 공급업체의 메일이 수신자에서 SPF 실패	기존 단일 레코드에 추가 — 절대 새 레코드로 추가하지 마세요
새 공급업체를 위한 DKIM 셀렉터 미생성	`dkim=fail` 또는 공급업체 기본 도메인의 서명; DMARC에 두 번째 다리 없음	새 셀렉터 게시 — 아래 6단계
이전 네임서버에만 레코드 업데이트	묻는 사람에 따라 다른 응답; 간헐적 실패	권위 네임서버의 영역 수정; 전환 중 두 세트 모두 확인

어떻게 수정하나요? 마이그레이션 체크리스트

먼저 defaults.exposed에서 무료 검사를 실행하세요. 현재 DNS를 읽어 여러 SPF 레코드, 누락된 include, 또는 DKIM 미비점이 있는지 알려줍니다 — 아무것도 건드리기 전에 진단하세요.
권위 네임서버에서 모든 SPF 레코드를 목록으로 작성하세요. dig +short NS yourdomain.com, 그런 다음 그 중 하나에 대해 dig +short TXT yourdomain.com @<nameserver>. v=spf1로 시작하는 문자열 개수를 세세요. 안전한 개수는 1개뿐입니다.
단일 레코드로 병합하세요. 하나의 레코드, v=spf1로 시작하고, 새 공급업체의 include와 여전히 사용하는 다른 발송자(인보이스 도구, CRM, 뉴스레터 플랫폼)를 포함하고, 하나의 종단 -all 또는 ~all. 예시 — 이전 Google Workspace, 새 Microsoft 365, 이전 진행 중:
```
이전:  "v=spf1 include:_spf.google.com ~all"
       "v=spf1 include:spf.protection.outlook.com -all"

이후:  "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
나중:  "v=spf1 include:spf.protection.outlook.com -all"
```
공급업체 값과 DNS 패널 특이사항은 Google Workspace 및 Microsoft 365용 설정 가이드에 있습니다.
추가 레코드를 삭제하세요. 삭제 없이 병합하면 아무것도 해결되지 않습니다 — PermError는 개수에서 비롯됩니다.
이전 시스템이 여전히 발송하는 동안만 이전 공급업체의 include를 유지하세요 — 예약된 보고서, 이전 CRM 커넥터, 잊어버린 사서함. 이전이 완료되면 제거하세요: 오래된 include는 이전 인프라가 귀사 명의로 발송하도록 허용된 상태를 유지하고, 각 include는 SPF의 최대 10개 조회 제한에 대해 DNS 조회를 소비합니다 — 최소 797,263 도메인이 그 제한을 초과하여 SPF를 무효화했습니다(센서스, 2026-06-29).
새 공급업체의 DKIM을 설정하세요 — 그리고 이전 셀렉터를 아직 삭제하지 마세요. 새 셀렉터가 새 메일에 서명합니다; 이전 셀렉터는 그것들로 서명된 모든 메시지가 전달되고 모든 전달이 처리될 때까지 게시된 상태를 유지해야 합니다. 전체 안내: 이메일 도구 변경 후 DKIM 실패.
네임서버도 변경했다면 두 세트 모두 확인하세요. DNS 마이그레이션은 종종 이메일 마이그레이션과 함께 이루어집니다. 이전 및 새 NS 세트를 직접 쿼리하세요(dig TXT yourdomain.com @old-ns와 @new-ns) — 등록기관 위임이 완전히 전파될 때까지 일부 수신자는 여전히 이전 서버에 묻습니다. 따라서 수정된 레코드가 응답하는 세트 모두에 존재해야 합니다.
검사를 다시 실행하고 SPF가 단일의 유효한 레코드로 통과되는지 확인하세요.

SPF가 실제로 어떤 도메인을 확인하나요?

수신자는 수신자가 보는 From 헤더가 아닌 Return-Path(RFC5321.MailFrom) 도메인 — 바운스 주소 — 에 대해 SPF를 평가합니다. 마이그레이션 후 이것이 두 번 중요합니다: 새 공급업체가 커스텀 바운스 도메인을 설정하기 전까지 자체 바운스 도메인을 사용할 수 있으며, 귀사 것이 아닌 도메인에서 SPF “통과”는 DMARC에 정렬되지 않습니다. 이것의 수정 방법은 새 공급업체의 DKIM으로, 귀사 도메인으로 서명합니다.

동시에 마이그레이션하고 리브랜딩하는 경우?

공급업체와 도메인을 동시에 변경했나요? 두 개의 작업으로 처리하세요. 새 도메인은 첫날부터 전체 스택 — SPF, DKIM, DMARC — 이 필요합니다; 새 도메인 이메일 체크리스트를 사용하세요. 이전 도메인은 전달 또는 회신 트래픽이 그것을 통해 흐르는 한 인증된 상태를 유지하고, 주차되면 단순히 방치하는 것이 아닌 명시적으로 잠겨야 합니다. 오래된 SPF가 남아 있고 반쯤 망가진 이전 도메인은 귀사의 옛 이름을 달고 있는 스푸핑 대상입니다.

자주 묻는 질문

마이그레이션하는 동안 두 개의 SPF 레코드를 유지할 수 있나요? 아니오. 표준에 유예 기간이 없습니다 — 두 개의 v=spf1 레코드는 두 번째 레코드가 존재하는 순간부터 PermError이며, 센서스(2026-06-29) 기준으로 1,013,416 도메인이 그 상태에 있습니다. 마이그레이션 안전 패턴은 겹치는 기간 동안 두 공급업체의 include를 모두 담은 하나의 레코드입니다.

이전 공급업체의 include를 얼마나 오래 유지해야 하나요? 이전 공급업체를 통해 아무것도 발송하지 않을 때까지 — 일반적으로 전환 기간의 길이, 며칠에서 몇 주. 이전 시스템을 통해 여전히 도달하는 것의 Return-Path를 지켜보세요; 그 트래픽이 멈추면 include를 제거하고 조회 수를 다시 확인하세요.

수정한 후에도 체크 도구에 이전 레코드가 보입니다. 왜인가요? DNS 캐싱이 레코드의 TTL을 준수하며, 네임서버가 변경된 경우 일부 리졸버는 여전히 이전 세트를 쿼리합니다. 권위 네임서버에서 dig TXT yourdomain.com @<ns>로 직접 확인하세요 — 거기서 답이 맞다면 수정이 완료된 것이며 캐시들이 따라잡을 것입니다. 한 NS 세트에서 틀리다면 ‘SPF 레코드를 찾을 수 없음’ — 실제 원인들을 참고하세요.

공급업체를 전환할 때 DMARC를 변경해야 하나요? 보통 레코드 자체는 아닙니다 — 레코드는 공급업체가 아닌 귀사의 보고 사서함과 정책을 명시합니다. 하지만 DMARC 결과는 방금 마이그레이션한 SPF와 DKIM에 달려 있습니다: 전환 중 보고서의 일시적 감소를 예상하고, 정책을 강화하기 전에 두 다리 모두 통과하는지 확인하세요. 검사에서 SPF 다리가 여전히 실패하는 것으로 나오면 SPF 수정으로 시작하세요.

보고서를 담당자에게 전달하세요

고객을 위해 이 마이그레이션을 하는 경우, 증거로 마무리하세요. 병합이 작동하면 무료 검사를 다시 실행하고 등급 보고서를 비즈니스 오너에게 전달하세요: 새 공급업체에서 SPF, DKIM, DMARC가 통과되고 있음을 일반 언어로, 날짜와 함께. 그것이 사이버 보험 갱신과 다음 공급업체 보안 설문지를 위해 파일에 보관하는 결과물입니다 — 마이그레이션이 도메인을 시작보다 더 잘 인증되도록 남겼다는 증거.

도메인 확인하기 → · 이메일 도구 변경 후 DKIM 실패 → · ‘SPF 레코드를 찾을 수 없음’ — 실제 원인들 → · 등급 산정 방식 → · 집계 데이터만 사용. 데이터는 EU 내에서 저장 및 처리됩니다.