SPF란? 회사 이메일이 스팸으로 가지 않게 도와주는 이메일 인증 쉽게 이해하기

회사 도메인으로 이메일을 사용하다 보면 SPF라는 용어를 접하게 됩니다. 기업메일·Google Workspace·Microsoft 365 등을 연결할 때 DNS에 SPF 값을 등록하라는 안내를 볼 수 있습니다.

쉽게 말하면 “우리 회사 이름으로 이메일을 보내도 되는 곳은 여기입니다.”라고 미리 등록해 두는 것입니다.

SPF를 쉽게 비유하면 회사의 공식 발송처 명단입니다

회사 이름만 봉투에 적으면 누구나 같은 회사처럼 꾸며 편지를 보낼 수 있습니다. “공식 우편물은 본사와 지점에서만 발송합니다.”라고 알려두면 관계없는 장소에서 보낸 편지는 의심할 수 있습니다. SPF도 비슷합니다. example.com이 DNS에 허용 메일 서버를 등록하면, 받는 서버가 실제 허용된 곳에서 왔는지 확인할 수 있습니다.

SPF는 왜 필요할까?

이메일의 발신자 주소는 겉보기만으로 진짜인지 판단하기 어려울 수 있습니다. 관계없는 사람이 [email protected]처럼 보이게 보내려 할 수 있고, 이런 사칭은 피싱·스팸에 악용될 수 있습니다. SPF는 “이 이메일을 보낸 서버가 example.com에서 허용한 곳인가?”를 확인하도록 돕습니다.

SPF는 어디에 설정할까?

일반적으로 DNS의 TXT 레코드에 등록합니다.

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

암호처럼 보여도 일반 사용자가 직접 만드는 경우는 많지 않습니다. 이메일 서비스가 안내한 값을 DNS에 등록하면 됩니다.

받는 설정일까, 보내는 설정일까?

SPF는 주로 이메일 발신 인증과 관련됩니다. 어디에서 받을지는 MX 레코드입니다.

• MX — “우리 회사로 오는 이메일은 이 메일 서버에서 받아주세요.”
• SPF — “우리 회사 이름으로 이메일을 보내도 되는 서버는 여기입니다.”

MX는 수신, SPF는 발신 인증과 관련되어 있습니다.

SPF가 없으면 이메일을 보낼 수 없을까?

반드시 그런 것은 아닙니다. 발송 자체는 가능할 수 있지만, 상대 서버가 얼마나 신뢰하느냐가 문제입니다. 인증이 약하면 스팸 분류·신뢰 저하·수신 거부 가능성이 커질 수 있습니다. 견적·상담·주문 안내처럼 중요한 메일을 보낸다면 설정을 확인하는 것이 좋습니다.

SPF가 있다고 스팸이 무조건 사라지진 않습니다

메일 서비스는 SPF만 보고 판단하지 않습니다. 내용·발송량·서버 신뢰도·DKIM·DMARC 등도 영향을 줍니다. SPF는 스팸을 완전히 막는 기능이라기보다, 정상적인 발신 서버임을 확인하는 데 도움을 주는 기본 인증으로 이해하는 것이 정확합니다.

어떻게 발신자를 확인할까?

example.com에서 이메일 도착
        ↓
실제로 이메일을 보낸 서버 확인
        ↓
example.com의 SPF 정보 확인
        ↓
해당 서버가 허용된 발신 서버인지 확인
        ↓
인증 결과를 이메일 처리에 참고

회사 명찰만 보는 것이 아니라 “이 사람이 실제 직원 명단에 있는가?”까지 확인하는 과정과 비슷합니다.

등록되지 않은 서버에서 보내면?

실제로 쓰는 메일 서버인데 SPF에 없으면 상대가 의심할 수 있습니다. 기업메일 A와 CRM B를 같이 쓰는데 SPF에 A만 있으면 B 발송이 실패할 수 있습니다. 같은 도메인으로 메일을 보내는 서비스가 SPF에 포함돼 있는지 확인해야 합니다.

홈페이지 문의폼 메일도 관계가 있을까?

있을 수 있습니다. 문의폼이 [email protected]으로 관리자 알림을 보내고, 홈페이지 서버가 도메인 이름으로 직접 발송하면 인증 문제가 날 수 있습니다. 발신자 주소만 바꾸는 것이 아니라 SMTP·이메일 인증을 함께 쓰는 편이 좋습니다.

SPF는 여러 개 만들어도 될까?

특히 주의해야 합니다. 하나의 도메인에 SPF 정책을 여러 개 따로 두면 문제가 날 수 있습니다. 서비스 A·B를 쓴다고 SPF를 각각 만드는 방식이 항상 올바른 것은 아닙니다. 보통 하나의 SPF 안에 필요한 서비스를 포함합니다.

v=spf1 include:service-a.com include:service-b.com ~all

실제 값은 사용하는 서비스 안내에 따릅니다.

새 서비스를 추가할 때 기존 SPF를 지우면 안 되는 이유

새 SPF만 남기고 기존 내용을 지우면 기존 기업메일 인증이 깨질 수 있습니다. 뉴스레터·CRM·예약·쇼핑몰·자동메일 등을 추가할 때는 기존과 함께 쓸 수 있는지 확인하세요.

include는 무엇일까?

“이 서비스에서 허용하는 메일 서버 목록도 우리 도메인의 허용 목록에 포함해 주세요.”라는 의미로 생각할 수 있습니다. 업체가 여러 서버를 운영하면 주소를 하나씩 넣지 않고 제공 SPF를 포함합니다.

~all, -all은 무엇일까?

~all은 허용되지 않은 서버를 의심스러운 발신자로 보는 비교적 완화된 방식이고, -all은 인증 실패로 보는 더 엄격한 방식입니다. 무조건 엄격하게만 하면, 빠진 정상 발송 서버까지 실패할 수 있습니다. 실제 발송 환경을 확인한 뒤 결정하세요.

잘못 설정하면 어떤 문제가 생길까?

• 직원 메일은 정상인데 홈페이지 자동메일만 인증 실패
• CRM·뉴스레터만 스팸 처리되거나 전달 실패
• 기존 기업메일을 새 SPF에서 빠뜨림

정상인지 어떻게 확인할까?

기업메일 업체가 DNS 완료 여부를 알려주거나, DNS 조회로 TXT를 확인할 수 있습니다. 문법 전체를 분석할 필요는 없고, (1) 쓰는 이메일 서비스 (2) 도메인으로 발송하는 서비스 개수 (3) 각 서비스가 요구하는 SPF (4) 기존 SPF를 덮어쓰지 않았는지 를 먼저 보면 됩니다.

변경하면 바로 적용될까?

DNS 설정이라 반영에 시간이 필요할 수 있습니다. 직후 옛 값이 보이면 잠시 후 다시 확인하세요.

홈페이지 제작업체를 바꾸면 SPF도 바꿔야 할까?

반드시 그런 것은 아닙니다. 기존 이메일을 그대로 쓰면 SPF도 유지해야 할 수 있습니다. 다만 홈페이지가 직접 발송하거나 새 SMTP를 쓰면 변경이 필요할 수 있습니다. 네임서버를 바꾸면 TXT의 SPF가 새 DNS에 옮겨졌는지 확인하세요. 준비물은 홈페이지 준비물 5가지도 참고하세요.

SPF만 설정하면 이메일 보안은 끝날까?

아닙니다. SPF·DKIM·DMARC를 함께 접하는 경우가 많습니다.

• SPF — 어떤 서버가 도메인 이름으로 보낼 수 있는지
• DKIM — 이메일에 전자 서명으로 정상 발신인지
• DMARC — SPF·DKIM 결과를 바탕으로 의심 메일을 어떻게 처리할지

쉽게 비유하면 SPF는 직원 명단, DKIM은 회사 도장, DMARC는 가짜 문서를 발견했을 때 처리 규칙입니다.

자주 묻는 질문

SPF란 무엇인가요?

어떤 메일 서버가 특정 도메인 이름으로 이메일을 발송할 수 있는지 알려주는 이메일 인증 방식입니다.

어디에 설정하나요?

일반적으로 도메인 DNS의 TXT 레코드로 등록합니다.

없으면 이메일을 보낼 수 없나요?

발송은 될 수 있지만 신뢰가 낮아져 스팸·인증 실패 가능성이 커질 수 있습니다.

SPF와 MX는 같은가요?

아닙니다. MX는 수신 서버, SPF는 발신 허용 서버 확인입니다.

여러 개 등록해도 되나요?

일반적으로 하나의 정책에 필요한 정보를 포함하는 방식을 사용하고, 여러 SPF를 따로 두는 것은 피합니다.

홈페이지를 이전하면 SPF도 변경해야 하나요?

항상 그런 것은 아닙니다. DNS·발송 환경이 바뀌면 기존 SPF가 유지되는지 확인하세요.

정리

SPF = 회사 이메일의 공식 발송처 명단

기업메일뿐 아니라 문의 알림·예약·쇼핑몰·CRM·뉴스레터처럼 여러 서비스가 같은 도메인으로 발송한다면 SPF를 더 주의해서 관리해야 합니다.

SPF는 발송 서버가 허용된 곳인지 확인하는 역할에 가깝습니다. 메일이 발송 과정에서 변조되지 않았고 정상적인 회사 메일인지 더 확인하려면 함께 쓰이는 대표적인 방식이 DKIM입니다.