SPF는 도메인을 대신해 이메일을 보낼 수 있는 서버를 나열하는 DNS 레코드입니다. 누락되거나 중복되거나 모두에게 열려 있으면 해당 도메인의 이메일을 위조하기 쉬워지고, 거부되거나 스팸으로 분류될 가능성이 커집니다.
의미
수신 메일 서버는 SPF 레코드를 조회해, 내 도메인에서 보냈다고 주장하는 메시지가 허용된 서버에서 전송되었는지 판단합니다. 도메인에는 SPF 레코드가 하나만 있어야 하며, 다른 모든 서버를 표시(~all)하거나 거부(-all)하는 것으로 끝나야 합니다.
발생 조건
DNS 및 이메일 보안 점검은 하루에 한 번 공개 DNS를 통해 등록된 도메인의 TXT 레코드를 읽고 v=spf1로 시작하는 레코드를 살펴봅니다. 이 이슈는 다음 세 가지 버전 중 하나로 발생합니다:
- SPF 레코드가 두 개 이상(높음): 수신 서버가 도메인의 SPF를 손상된 것으로 처리합니다. 소유자와 관리자에게 이메일과 채팅으로 한 번 알림이 전송됩니다.
- SPF 레코드가 누구나 이메일을 보낼 수 있도록 허용(높음): 레코드가 +all로 끝나 인터넷의 모든 서버를 허용합니다. 소유자와 관리자에게 이메일과 채팅으로 한 번 알림이 전송됩니다.
- SPF 레코드 없음(보통): 도메인에 MX 레코드가 있어 이메일을 수신하는 경우에만 발생합니다. 앱에 표시되며 이메일로는 보내지 않습니다.
일반적인 원인
- 뉴스레터, CRM 또는 헬프데스크 서비스를 설정하면서 기존 레코드에 추가하지 않고 별도의 v=spf1 레코드를 만든 경우.
- +all로 끝나는 레코드를 템플릿에서 복사했거나 전송 실패를 막으려고 추가한 경우.
- 이메일을 새 제공업체로 옮기면서 제공업체가 요구한 SPF 레코드를 게시하지 않은 경우.
해결 방법
- 도메인 이름으로 이메일을 보내는 모든 서비스를 나열하세요: 메일함 제공업체, 뉴스레터 도구, 웹사이트, 헬프데스크, 청구서 발행 소프트웨어. 각 서비스의 설정 가이드에 사용할 include가 나와 있습니다.
- DNS 제공업체에서 v=spf1로 시작하고 모든 서비스를 포함하는 TXT 레코드 하나만 유지하고(예: v=spf1 include:_spf.google.com include:sendgrid.net ~all) 나머지는 삭제하세요.
- ~all 또는 -all로 끝내고 +all은 절대 사용하지 마세요. 또한 DNS 조회를 10회 이하로 유지하세요(include마다 1회로 계산). 그렇지 않으면 수신 서버가 어차피 실패로 처리합니다.
- SPF가 올바르게 설정되면 DMARC 레코드도 추가하세요. DMARC 레코드 없음을(를) 참고하세요.
해소 시점
더 이상 문제를 발견하지 않는 다음 일일 점검 후 이슈가 사라지고, 그 7일 후 조치가 실행 계획에서 사라집니다.
조치를 완료로 표시했는데 14일 후에도 문제가 여전히 발견되면 “수정이 효과가 없었습니다”로 다시 나타납니다. 실행 계획 사용을(를) 참고하세요.