SPF 레코드 설정 — 발송 서버를 늘릴 때 가장 먼저 깨지는 것

메일 도달 문제로 연락 주시는 분들의 설정을 열어 보면, SPF가 아예 없는 경우보다 예전에 넣어 두고 그 뒤로 손대지 않은 경우가 훨씬 많습니다. 발송 경로는 늘었는데 레코드는 그대로인 상태입니다.

SPF가 실제로 하는 일

SPF는 “내 도메인 이름으로 메일을 보낼 자격이 있는 서버 목록”을 DNS에 공개해 두는 표준입니다. 받는 서버는 메일이 도착하면 발신 IP가 그 목록에 있는지 대조합니다.

레코드는 이렇게 생겼습니다.

v=spf1 ip4:203.0.113.10 include:_spf.example.net ~all

v=spf1 — SPF 레코드임을 표시
ip4: — 허용할 발송 IP를 직접 지정
include: — 다른 도메인의 SPF를 끌어와 포함 (외부 발송 서비스를 쓸 때)
~all / -all — 목록에 없는 발신을 어떻게 볼지

DNS에 넣는 자리

관리 화면마다 칸 이름이 조금씩 다르지만 넣는 값은 같습니다.

칸	값
타입	TXT
이름(호스트)	`@` — 서비스에 따라 빈 칸이거나 도메인 이름 그대로
값	`v=spf1 …` 전체

여기서 갈리는 지점이 몇 개 있습니다.

SPF라는 별도 타입은 쓰지 않습니다. 예전에 그런 타입이 있었지만 지금은 TXT로 통일됐고, SPF 타입으로만 넣으면 대조하는 쪽이 읽지 않습니다.
이름 칸에 spf나 _spf를 적으면 spf.example.com에 레코드가 생깁니다. 메일 주소의 도메인과 같은 이름에 있어야 합니다.
mail.example.com처럼 하위 도메인 주소로 보낸다면 그 하위 도메인에도 따로 필요합니다. SPF는 상위 도메인 것을 물려받지 않습니다.
반영까지는 TTL만큼 걸립니다. 바꾼 직후에는 옛 값이 조회될 수 있습니다.

가장 흔한 사고 — 경로가 늘었는데 레코드는 그대로

메일을 보내는 경로는 생각보다 쉽게 늘어납니다.

그룹웨어에서 보내던 것에 마케팅 발송이 추가되고
결제·주문 알림은 쇼핑몰 솔루션이 따로 보내고
고객 문의 자동응답은 또 다른 도구가 보내고

이 중 하나라도 SPF 목록에 없으면, 그 경로로 나간 메일만 조용히 스팸으로 분류됩니다. 전체가 아니라 일부만 문제가 되기 때문에 발견이 늦습니다.

발송 경로를 추가·변경할 때는 SPF 레코드도 같은 날 함께 손대는 것을 규칙으로 두는 편이 안전합니다.

룩업 10회 제한

SPF에는 include·a·mx 같은 항목을 최대 10번까지만 조회한다는 제한이 있습니다. 이를 넘기면 검증이 permerror로 끝나고, 받는 서버는 SPF를 통과로 쳐 주지 않습니다.

세는 대상은 정해져 있습니다. include·a·mx·ptr·exists가 각각 1회로 잡히고, ip4:·ip6:·all은 세지 않습니다. IP를 직접 나열하는 쪽은 개수가 늘어도 이 제한에 걸리지 않습니다.

세기 어려운 것은 include 안쪽입니다. include:_spf.example.net 하나가 그 도메인의 레코드 안에서 또 include를 두세 번 물고 있는 경우가 흔해서, 겉으로 보이는 개수보다 실제 횟수가 큽니다. 서비스 서너 개만 붙여도 10회에 닿는 이유입니다. 증상이 “어느 날부터 갑자기 인증이 실패한다”로 나타나서 원인을 찾기 어렵습니다.

정리하는 방향은 두 가지입니다.

쓰지 않는 include를 걷어낸다 (해지한 서비스가 남아 있는 경우가 많습니다)
고정 IP로 발송한다면 include 대신 ip4:로 직접 지정한다

`~all` 과 `-all`

~all (softfail) — 목록에 없는 발신을 “의심스럽지만 일단 받음”
-all (hardfail) — “거부”

-all이 더 엄격하지만, 발송 경로를 전부 파악하지 못한 상태에서 걸면 누락된 경로의 정상 메일이 차단됩니다. 경로를 다 확인하기 전까지는 ~all로 두고, DMARC 리포트로 실제 발신 목록을 확인한 뒤 -all로 조이는 순서가 안전합니다.

SPF가 보는 주소는 화면의 보낸사람이 아닙니다

메일에는 주소가 두 군데 있습니다. 수신자가 화면에서 보는 보낸사람과, 배달·반송에 쓰이는 봉투의 반송 주소입니다. SPF가 대조하는 것은 뒤쪽입니다.

그래서 이런 일이 생깁니다.

외부 발송 도구가 반송 주소를 자기 도메인으로 쓰면, 내 도메인 SPF에 그 도구가 없어도 SPF는 통과로 나옵니다
반대로 보낸사람만 내 도메인으로 적은 사칭 메일도, 봉투 주소가 남의 도메인이면 SPF 검사에서는 걸리지 않습니다

SPF만으로 사칭이 막히지 않는 이유가 여기 있습니다. 두 주소가 서로 맞는지 보는 것은 DMARC의 정렬 조건이라, 셋을 같이 걸어야 그림이 완성됩니다.

확인하는 법

설정 후에는 실제로 조회해서 확인합니다.

dig +short TXT example.com

레코드가 하나만 있는지도 같이 봅니다. 한 도메인에 SPF 레코드가 두 개 이상이면 그 자체로 검증 실패입니다. 새로 넣지 말고 기존 레코드 하나에 항목을 합쳐야 합니다.

실제로 통과하는지는 보낸 메일의 원본 헤더에서 확인합니다. 받는 쪽이 붙이는 Authentication-Results에 spf=pass가 있고, 같은 줄의 smtp.mailfrom=이 내 도메인이면 통과입니다. smtp.mailfrom이 낯선 도메인이면 앞 절의 반송 주소가 다른 경우입니다.

결과 값이 몇 가지 더 있습니다.

permerror — 룩업 10회를 넘겼거나 레코드 문법이 깨진 상태
none — 레코드 자체를 못 찾음 (이름 칸이 틀렸거나 아직 반영 전)
softfail — 목록에 없는 IP인데 ~all이라 거부까지는 안 간 상태

SPF는 인증 세 가지 중 첫 번째일 뿐입니다. DKIM 설정과 DMARC 정책까지 맞물려야 받는 서버가 발신자를 온전히 신뢰합니다. 셋의 관계는 SPF·DKIM·DMARC 정리에 정리해 두었습니다.

발송 도메인 인증, 무료로 점검해 드립니다

도메인만 알려주시면 SPF·DKIM·DMARC·역방향 DNS 설정을 조회해서, 무엇이 빠졌고 무엇이 위험한지 정리해 보내드립니다. 비용도 조건도 없습니다.

카카오톡 상담방에 도메인을 남겨 주세요.

전용 IP로 대량 발송할 인프라가 필요하시면 전용 IP 대량 발송 안내에서 구성과 가격을 확인하실 수 있습니다.