새 발송 도구를 붙인 뒤 SPF가 깨졌다면: TXT 정책을 합치는 개발자 점검 순서

새 뉴스레터나 알림 서비스를 연결한 직후 메일 인증이 실패하면 새 서비스의 설정값부터 다시 복사하기 쉽습니다. 하지만 같은 도메인에 v=spf1 정책을 두 개 게시했다면, 각각의 값이 올바르더라도 SPF 평가는 오류로 끝날 수 있습니다. RFC 7208은 같은 이름에서 여러 SPF 레코드가 선택되면 permerror로 처리하도록 정합니다.

먼저 두 줄이 정말 별개의 정책인지 확인합니다

DNS 관리 화면에서 줄이 두 개 보인다는 이유만으로 중복이라고 단정하지는 않습니다. 긴 TXT 문자열이 화면에서 여러 조각으로 보이는 경우와, 같은 호스트 이름에 독립된 v=spf1 TXT 레코드가 두 개 있는 경우는 다릅니다. 조회한 이름과 각 레코드의 시작 값을 함께 확인하세요.

example.com TXT "v=spf1 include:mail-a.example.net ~all"
example.com TXT "v=spf1 include:mail-b.example.net ~all"

위 주소는 설명용 가상 값입니다. 운영 DNS에 그대로 넣으면 안 됩니다.

삭제 버튼보다 발송 경로 목록이 먼저입니다

둘 중 나중에 추가한 줄만 지우면 새 도구가 실패하고, 먼저 있던 줄을 지우면 기존 업무 메일이 실패할 수 있습니다. 변경 전에는 실제 발송 주체를 적어 봅니다.

목록을 만들면 남겨야 할 include와 제거할 오래된 권한을 구분하기 쉬워집니다.

한 정책으로 합친 다음에도 검증이 남습니다

필요한 발송 경로를 한 SPF 정책에 모으되, 두 문자열을 단순히 이어 붙이지 않습니다. 각 서비스의 최신 공식 문서를 기준으로 값을 구성하고, SPF의 DNS 조회 한도도 확인하세요. 한 줄이 되었다는 사실만으로 permerror가 사라졌다고 확신할 수는 없습니다.

저장 후에는 DNS 조회 결과에서 같은 이름에 정책이 하나인지 확인합니다. 이어 업무 메일함, 자동 알림, 새 발송 도구에서 각각 시험 메일을 보내고 원본 헤더의 인증 결과를 살핍니다. 받은편지함 도착 여부만 보면 다른 인증 문제를 놓칠 수 있습니다.

핵심은 '어느 줄을 지울까'보다 '현재 누가 이 도메인으로 보내는가'입니다. 실제 발송 경로를 보존한 채 정책을 하나로 합치는 상세 순서는 SPF PermError와 중복 TXT 레코드 점검 가이드에 정리했습니다.