550 5.7.23: SPF 검사 실패 바운스 해결

Problem

메일이 550 5.7.23과 “The message was rejected because of Sender Policy Framework violation” 같은 문구로 바운스됩니다. 수신 서버 — 아주 흔하게 Exchange Online / Microsoft 365 — 가 메시지가 온 IP를 발신 도메인의 SPF 레코드에 대조했는데 승인된 것을 못 찾아 거부한 것입니다. 받은편지함에 아무것도 도착하지 않았고, 같은 서버에서 같은 메시지를 다시 보내도 결과는 바뀌지 않습니다.

Symptoms

• 바운스나 NDR에 550 5.7.23과 “Sender Policy Framework” 또는 “SPF” 문구가 있습니다. Microsoft의 정확한 표현은 “The message was rejected because of Sender Policy Framework violation”입니다.
• 주력 메일 시스템의 메일은 잘 전달되는데, 새 앱·스크립트·마케팅 도구·온프레미스 서버에서 보낸 메일이 바운스됩니다.
• 직접 보내면 받아들여지는 메시지가, 중간자를 거쳐 전달될 때는 바운스됩니다.
• Microsoft 365 / Outlook 수신자는 거부하는데 일부 다른 제공업체는 여전히 받아들입니다.
• 도메인의 SPF 조회는 “멀쩡해 보이는데” 메일은 실패합니다 — 실패하는 IP나 리턴패스 도메인이 당신이 확인한 그것이 아니기 때문입니다.

What 550 5.7.23 Actually Means

두 사실로 읽으세요. 550은 영구 SMTP 거부(RFC 5321)입니다 — 수신자가 이 메시지를 끝낸 것이지 나중에 다시 시도하라는 게 아닙니다. 5.7.23은 향상된 상태 코드이고, 애매한 5.7.1과 달리 이유를 지목합니다: Sender Policy Framework 실패. 수신 서버가 자신에게 접속한 IP 주소를 가져와 발신 도메인의 SPF 레코드를 조회했고, 레코드의 규칙이 그 IP는 이 도메인으로 보낼 수 없다고 말한 것입니다 — 대개 레코드가 -all(하드 페일)로 끝나는데 그 IP가 목록에 없기 때문입니다.

여기서 모든 걸 가르는 단어가 둘인데, 둘 다 사람들이 먼저 확인하는 것이 아닙니다. SPF는 접속한 IP를 평가합니다 — 서버 이름도, 헤더 From도 아닙니다. 그리고 리턴패스(MAIL FROM) 도메인, 즉 봉투 발신자의 레코드를 평가하는데, 제3자를 거쳐 보낸 메일에서 이 도메인은 당신 눈에 보이는 From과 다른 경우가 많습니다. 그래서 도메인의 SPF 레코드가 완벽한 From 주소를 단 메시지도 5.7.23을 받을 수 있습니다: 수신자가 다른 도메인을 확인했거나, 당신이 레코드에 넣은 적 없는 IP를 확인한 것입니다.

이것이 정렬(alignment)이나 DMARC 실패가 아니라는 점도 중요합니다. Gmail의 5.7.26은 “정렬된 SPF도 정렬된 DKIM도 없음”을 뜻합니다. Microsoft의 5.7.509는 “당신 자신의 DMARC 정책이 거부하라고 함”을 뜻합니다. 5.7.23은 더 좁고 더 구식입니다: 봉투 도메인에 대한 순수 SPF 검사가 fail을 반환한 것입니다. 실제 발신 경로의 SPF 승인을 고치면 DKIM이나 DMARC가 무엇을 하든 5.7.23은 사라집니다.

Top 3 Causes

1. SPF 레코드에 없는 발신 소스. 새 SaaS 플랫폼, 트랜잭션 메일 서비스, 온프레미스 릴레이, 일회성 스크립트가 당신이 추가한 적 없는 IP에서 “당신 도메인으로” 보내는데, 레코드는 -all로 끝납니다. 하드 페일 + 미등록 IP가 정확히 5.7.23 조건입니다. 지문: 최근 추가됐거나 특이한 발신자이고, 그 IP나 벤더 include:가 v=spf1 레코드에 빠져 있습니다.
2. 전달이 SPF 경로를 깬다. 최초 발송은 통과하는데, 사서함이나 리스트가 메시지를 다른 곳으로 전달하면서 전달 서버가 자기 IP로 릴레이하므로 마지막 홉에서 SPF가 실패합니다. 지문: 메시지가 전달될 때만 바운스되고, 헤더의 실패 IP가 당신이 아니라 포워더의 것입니다.
3. 검사에 실패하는 공유·하이브리드 IP. 위험으로 분류된 아웃바운드 메일이 레코드에 없는 공유 고위험 배달 풀 IP로 라우팅되거나, 하이브리드/온프레미스 커넥터가 당신이 승인하는 걸 잊은 주소에서 보냅니다. 지문: 메일 일부에서 간헐적 5.7.23이 나고, 그 IP가 SPF 레코드가 커버하지 않는 당신 제공업체나 자체 인프라 안의 것입니다.

Diagnose with DechoNet

• Email Check는 도메인의 SPF 레코드를 가져와 평가합니다 — 정확한 메커니즘, -all로 끝나는지 ~all로 끝나는지, 그리고 all 규칙에 닿기 전에 10회 조회 한도(RFC 7208 §4.6.4) 안에서 해석되는지 볼 수 있습니다. 이것이 지금 레코드가 어떤 IP를 승인하는지 알려 줍니다.
• Email Header Analyzer는 바운스되거나 수신된 메시지의 Authentication-Results와 Received-SPF 줄을 읽어, 수신자가 평가한 IP와 확인한 도메인을 보여 줍니다 — 5.7.23이 누락된 IP에서 왔는지, 예상치 못한 리턴패스 도메인에서 왔는지, 전달 홉에서 왔는지 가장 빨리 파악하는 방법입니다.

Resolution Checklist

• 코드가 5.7.1·5.7.26·5.7.509가 아니라 5.7.23인지 확인하세요 — 5.7.23은 순수 SPF 승인 실패이므로, 해결책은 DMARC 정책이나 DKIM 정렬이 아니라 SPF 레코드에 있습니다.
• 바운스와 헤더에서 수신자가 확인한 정확한 발신 IP와 리턴패스 도메인을 Email Header Analyzer로 식별하세요.
• 그 도메인에 Email Check를 돌려 누락된 IP나 서비스가 현재 레코드에 커버되지 않는지 확인하세요.
• 정상 소스를 추가하세요: 벤더가 문서화한 include:(Microsoft 365는 include:spf.protection.outlook.com)나 자체 릴레이의 구체적 ip4:/ip6: — 총 DNS 조회 10회 미만, 도메인당 SPF TXT 레코드는 하나만 유지합니다.
• 전달에서만 실패한다면 포워더 IP를 쫓지 마세요 — DKIM을 설정해 메시지가 홉을 넘어도 인증을 유지하게 하고, DMARC를 게시해 SPF가 깨질 때 DKIM 정렬로 통과하게 하세요.
• 다시 보내고 헤더를 재확인해 실제 발신 IP와 봉투 도메인에 대해 spf=pass가 나오는지 확인하세요.

When to Escalate

• 실패 IP가 이메일 제공업체의 공유 인프라(고위험 배달 풀이나 플랫폼 릴레이)에 속하는데 그들이 문서화한 include:가 여전히 커버하지 않는다면, 제공업체 측 라우팅 문제입니다 — 레코드를 무턱대고 넓히지 말고 바운스와 문제 IP를 그들 지원팀으로 가져가세요.
• 봉투 도메인에 대해 SPF가 이제 통과하는데도 수신자가 여전히 5.7.23을 돌려준다면, 전체 바운스와 Received-SPF·Authentication-Results 헤더를 캡처하세요 — 수신자가 당신이 계산에 넣지 않은 도메인이나 IP를 평가하고 있고, 그 줄들이 정확히 어느 것인지 지목합니다.