SPF 레코드 확인·설정 방법

문제

새 메일 서비스 — Microsoft 365, 뉴스레터 도구, 헬프데스크 — 를 붙였더니 “이 SPF 레코드를 DNS에 추가하세요”라고 안내합니다. 그래서 이미 있던 레코드 바로 옆에 추가했습니다. 그리고 조용히, 전부 실패하기 시작합니다. 정당한 메일이 스팸함으로 가거나 PermError로 반송되고, 돌아오는 진단은 SPF에 대해 별 도움 안 되는 소리만 합니다.

레코드를 건네주며 아무도 말해주지 않는 사실: SPF는 계속 추가해 나가는 레코드 목록이 아닙니다. 엄격한 규칙을 가진 단 하나의 레코드고, 사람들이 이걸 깨뜨리는 방법은 두세 가지로 늘 똑같습니다. 그 방법이 보이기 시작하면 SPF는 마법에서 5분짜리 점검으로 바뀝니다.

SPF 레코드가 실제로 하는 일

SPF — Sender Policy Framework, RFC 7208로 정의 — 는 도메인에 두는 하나의 DNS TXT 레코드로, 수신 메일 서버에 단 하나의 질문에 답합니다: 이 메시지를 보내려는 기계가 이 도메인으로 보낼 자격이 있는가? 발송원을 공개한 허용 목록입니다.

최소 레코드는 이렇습니다:

v=spf1 include:_spf.google.com ~all

v=spf1이 SPF임을 표시합니다. 가운데는 메커니즘 목록 — include:·a·mx·ip4:·ip6: — 으로, 각각 발송이 허용된 출처를 지정합니다. 끝의 all은 목록에 없는 나머지를 어떻게 할지 정하는 캐치올입니다. 수신 서버는 이 레코드를 읽어 접속한 서버를 대조하고 결과를 반환합니다: pass·fail·softfail, 그리고 실수했다는 뜻인 두 가지 — permerror·temperror.

SPF를 깨뜨리는 실수 3가지

깨진 SPF 레코드는 거의 전부 세 가지 이유 중 하나로 실패합니다. 어느 것도 눈으로 알아챌 문법 오류로는 안 보입니다.

1. 하나가 아니라 둘. RFC 7208 §3.2는 단호합니다: 도메인은 v=spf1로 시작하는 레코드를 정확히 하나 둡니다. 레코드 두 개는 “커버리지 추가”가 아니라 즉각 PermError고, PermError는 두 레코드 모두 허용했을 서버의 메일까지 포함해 전부의 인증을 실패시킵니다. 기존 레코드 옆에 두 번째 레코드를 붙여넣을 때 벌어지는 일입니다. 몸에 새길 규칙: 병합하지, 추가하지 않는다. 구글 위에 Microsoft를 더한다는 건 양쪽 include를 가져와 한 줄에 넣는다는 뜻입니다:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

2. 10회 조회 한도. SPF 평가는 최대 10회의 DNS 조회만 유발할 수 있습니다(§4.6.4). 악의적 레코드가 인바운드 메일마다 DNS 폭주를 일으키지 못하게 막는 상한입니다. include·a·mx·ptr·exists·redirect가 각각 조회 1회를 쓰고, include는 중첩되므로 다른 셋을 참조하는 include: 하나는 4회를 씁니다. 대형 제공자 include 하나가 혼자 3~5회를 태우니, 서너 개만 쌓으면 선을 넘어 PermError를 법니다. 함정은 이 레코드가 멀쩡해 보인다는 것 — 짧고, 유효하고, 오직 include가 끌어오는 것 때문에만 실패합니다. 더 조용한 상한이 또 있습니다: 아무것도 해석되지 않는 메커니즘(void 조회)은 2회까지 — 몇 년 전 버린 서비스를 가리키는 죽은 include:가 레코드 전체를 조용히 오염시키는 경로입니다.

3. +all로 끝내기. all 메커니즘은 한정자를 받습니다: -all(fail)·~all(softfail)·?all(neutral)·+all(pass). +all은 인터넷의 모든 서버가 나로 발송할 자격이 있다는 뜻입니다. “오류를 없애려고” 붙여넣는 경우가 많고, 실제로 없애줍니다 — SPF를 무조건 통과시켜서, 이제 누구나 도메인을 위조하고 검사를 통과할 수 있으니 SPF가 없느니만 못해집니다. 레코드 어디든 +all이 보이면 그게 버그입니다.

레코드 읽고 확인하는 법

확인 순서는 늘 같고, 빠릅니다:

1. 정확히 하나인지 확인. 도메인 TXT 레코드를 조회해 v=spf1로 시작하는 게 몇 개인지 세세요. 둘 이상이면 다른 걸 보기 전에 그게 문제입니다.
2. 길이 말고 조회 횟수를 센다. 각 include·a·mx·redirect를, include는 그 안의 레코드까지 따라 들어가 합산하세요. 10을 넘으면 PermError 예약, 8을 넘으면 평탄화(flattening)를 시작하라는 경고입니다.
3. 막다른 곳을 확인한다. 아무것도 해석 안 되는 include:·redirect는 void 조회 예산을 태웁니다. 더는 안 쓰는 서비스의 메커니즘을 지우세요.
4. all 한정자를 읽는다. 목록을 만드는 중엔 ~all, 완성되면 -all, +all은 절대 금지.

새 발송처를 추가할 때의 규율: 기존 레코드를 찾아 새 제공자의 include를 넣고, 하나의 레코드를 다시 게시한다. 절대 둘을 남기지 않는다.

DechoNet으로 진단

• 이메일 / SPF 점검은 도메인의 SPF를 수신 서버처럼 평가합니다: 레코드가 여러 개면 표시하고, DNS 조회를 한도에 대조해 세고, 각 include를 해석해 어느 것이 비대한지 보여주고, 끝의 all 한정자를 읽습니다. 오류처럼 안 보이는 PermError 원인을 잡는 가장 빠른 방법입니다.
• DNS 조회는 도메인의 원본 TXT 레코드를 보여줘, v=spf1 줄이 정확히 하나뿐이고 옆에 낡은 게 숨어있지 않은지 직접 눈으로 확인하게 해줍니다.

해결 체크리스트

• 도메인에 v=spf1 TXT 레코드가 정확히 하나인지 확인. 둘이면 한 줄로 병합 — 양쪽 include를 한 번만 게시.
• DNS를 조회하는 메커니즘(include·a·mx·ptr·exists·redirect)을 중첩 include까지 따라 세기. 합계 10 미만 유지.
• 더는 발송 안 하는 서비스의 include:·redirect를 제거 — 조회를 낭비하고 void 상한을 건드립니다.
• 레코드가 ~all 또는 -all로 끝나는지 확인, +all은 절대 금지.
• 변경 후 이메일 점검으로 재확인하고 테스트 메일을 보내 결과가 permerror가 아니라 pass인지 확인.

에스컬레이션 시점

• 10회 조회로 감당 못 할 만큼 제공자가 정말 많다면 SPF 평탄화 — include: 체인을 해석된 ip4:/ip6: 범위로 치환 — 가 필요하지만, 그 범위를 최신으로 유지해주는 도구/서비스로만 하세요. 제공자가 IP를 바꾸면 손으로 평탄화한 레코드가 조용히 깨집니다.
• SPF는 통과하는데 메일이 여전히 DMARC를 실패한다면 문제는 SPF가 아니라 **정렬(alignment)**입니다: From: 헤더 도메인이 SPF 인증된 도메인과 일치해야 합니다. 별개의 점검입니다.
• 레코드가 맞는데도 수신 서버가 temperror를 반환하면 그건 상대측의 일시적 DNS 해석 실패지 고칠 레코드가 아닙니다 — 무엇을 바꾸기 전에 재시도하세요.