새 뉴스레터 도구를 연결한 뒤 회사메일이 반송되기 시작했다면, 새 도구부터 탓하기 쉽습니다. 그런데 관리 화면에서는 새 도구의 SPF 값이 정상으로 보이고, 기존 업무 메일도 그대로입니다. 이런 상황에서 먼저 확인할 것은 어느 서비스가 잘못됐는지가 아니라 도메인에 SPF 정책이 몇 줄 게시되어 있는지입니다.
기존 값을 지우고 새 값을 붙이면 문제가 끝날 것처럼 보입니다. 하지만 그러면 원래 쓰던 업무 메일이 실패할 수 있습니다. 오늘은 두 줄을 찾는 방법부터 실제 발송 경로를 확인해 한 줄로 합치고 테스트하는 순서까지 살펴보겠습니다.
이 글의 핵심
v=spf1로 시작하는 TXT 레코드가 두 개면 SPF 평가가 오류로 끝날 수 있습니다.도메인의 DNS 관리 화면에서 TXT 레코드를 검색해 보세요. v=spf1로 시작하는 항목이 같은 호스트 이름에 두 개 있으면 이번 문제와 맞닿아 있습니다. 이름이 @ 또는 빈칸으로 보이는지는 DNS 업체마다 다릅니다. 표시 방식보다 중요한 것은 두 레코드가 최종적으로 같은 도메인 이름을 가리키는지입니다.
하나의 긴 TXT 값을 관리 화면이 여러 문자열로 나누어 보여주는 것과, 독립된 SPF TXT 레코드 두 개를 게시한 것은 다릅니다. RFC 7208은 동일한 이름에서 SPF 레코드가 여러 개 선택되면 permerror로 처리하도록 규정합니다. 화면의 줄 수만 보지 말고 각 항목이 독립된 레코드인지 확인해야 합니다.
첫 줄은 평소 쓰는 회사메일, 둘째 줄은 새 발송 서비스를 위해 따로 추가했다고 가정해 보겠습니다. 두 서비스가 각각 맞는 값을 안내했더라도 같은 도메인에 두 정책을 나란히 둘 수는 없습니다.
example.com TXT "v=spf1 include:mail-a.example.net ~all" example.com TXT "v=spf1 include:mail-b.example.net ~all"
이 샘플의 도메인은 설명용입니다. 실제 설정에는 사용 중인 제공업체가 공식 문서에서 안내하는 값을 써야 합니다.
두 번째 줄이 새로 생겼다는 이유만으로 삭제하면 지금 발생한 반송은 멎을 수 있습니다. 그러나 뉴스레터, 문의 접수 알림, 결제 안내처럼 다른 사람이 당장 눈치채지 못하는 메일이 끊길 수도 있죠. 수정 전에 최근 실제 발송 경로를 표로 적어두면 이런 실수를 줄일 수 있습니다.
| 보내는 곳 | 대표적인 메일 | 확인할 값 |
|---|---|---|
| 업무용 메일함 | 직접 작성한 답장 | 제공업체의 공식 SPF 안내 |
| 자동 발송 서비스 | 가입 확인, 정산 알림 | 서비스의 공식 도메인 또는 IP 안내 |
| 마케팅 도구 | 뉴스레터 | 현재 계약 및 실제 발송 여부 |
이 표는 가상의 예시입니다. 이름만 남아 있는 오래된 도구라면 담당자와 마지막 발송 기록을 확인하세요. 더는 쓰지 않는 경로를 기계적으로 합칠 필요도 없습니다.
필요한 발송 경로를 확정했다면 DNS에는 SPF 정책을 한 개만 남깁니다. 앞의 가상 사례라면 두 include를 한 줄에 담는 방향입니다. 끝의 ~all이나 -all 같은 종료 방식은 각 서비스의 공식 지침과 현재 운영 정책을 고려해 결정하고, 단순히 두 줄을 통째로 이어 붙이지 마세요.
example.com TXT "v=spf1 include:mail-a.example.net include:mail-b.example.net ~all"
여기서 끝내기 전에 확인할 것이 하나 더 있습니다. SPF에는 평가 과정에서 발생하는 DNS 조회 횟수 제한이 있습니다. include를 여러 개 모으면 레코드는 한 줄이어도 조회 한도 때문에 다시 permerror가 날 수 있습니다. 업체가 안내한 include 안에서 또 다른 조회가 일어날 수 있으므로, 합친 뒤 검증 도구와 실제 메시지 헤더로 결과를 확인해야 합니다.
주의: 예시 값을 실제 DNS에 복사하지 마세요
위 example.net 주소는 구조를 보여주기 위한 가상 값입니다. 사용하는 메일 서비스의 최신 공식 문서에 적힌 값으로 바꾸고, 변경 전 원본 레코드를 따로 보관하세요.
DNS를 저장한 뒤에는 조회 환경마다 이전 값이 잠시 남을 수 있습니다. TTL과 전파 시간을 고려해 다시 조회하고, 동일 이름에 SPF 정책이 하나만 보이는지 확인하세요. 이어서 업무용 메일함, 자동 알림, 새 발송 도구에서 각각 시험 메일을 보냅니다. 한 서비스의 성공만으로 전체가 해결됐다고 판단하면 놓치는 경로가 생깁니다.
받은편지함에 도착했는지만 보지 말고 원본 헤더의 인증 결과도 살펴보세요. SPF 결과가 pass인지, 보이는 From 도메인과 평가에 사용된 도메인이 어떻게 연결되는지 확인해야 합니다. SPF만 통과해도 다른 인증이나 도메인 정렬 문제 때문에 전달률이 나쁠 수 있으니 테스트 결과를 기록해 다음 변경 때 비교할 기준으로 남겨두면 좋습니다.
한 번에 점검할 순서가 필요하다면
두 줄을 구분하는 기준, 발송 경로 점검표, 합친 뒤의 검증 순서를 원문에 더 자세히 정리했습니다.
SPF PermError 점검 순서와 원문 보기SPF 두 줄 문제는 새 도구를 붙일 때 흔히 생기지만, 해결은 한 줄을 지우는 것보다 조금 더 신중해야 합니다. 누가 보내는지 적고, 한 정책으로 정리하고, 각 경로에서 다시 보내보기. 이 세 단계만 지켜도 기존 고객 메일을 살리면서 새 발송 도구를 연결할 수 있습니다.