550 5.7.1: SPF 정책 거부 바운스 해결

Problem

메일이 550 5.7.1과 함께 “Email rejected per SPF policy”나 ” is not allowed to send mail from ” 같은 줄을 달고 되돌아옵니다. 메시지는 받은편지함에 닿지도 못했습니다 — 배달 전에, 문 앞에서, 영구적으로 거부됐습니다. 수신 서버는 메일이 스팸이라고 말하는 게 아닙니다. 연결한 서버가 당신 도메인이 발송을 허용한다고 선언한 머신 목록에 없다고 말하는 겁니다.

Symptoms

• 바운스에 550 5.7.1 뒤로 SPF, “not permitted sender”, “policy”를 언급하는 텍스트.
• 내 서버에서 보낸 메일은 통과하는데 새 앱/서비스에서 보낸 메일은 바운스.
• 마케팅 도구, 헬프데스크, 청구 시스템을 추가한 직후 시작됨.
• 포워딩된 사본은 바운스되는데 원본은 잘 배달됨.
• DMARC 리포트에 깜빡한 정당한 출처의 SPF fail이 찍힘.

550 5.7.1이 실제로 뜻하는 것

코드를 둘로 쪼개세요. 550은 기본 SMTP 응답(RFC 5321): 영구 실패입니다. 수신 서버는 이 메시지를 받지 않을 것이고 그대로 재시도해봐야 소용없습니다 — “나중에 다시 시도하라”는 4xx 일시 지연과 다른 점입니다. 5.7.1은 향상 상태 코드(RFC 3463)로, 정확히는 “배달 미인가, 메시지 거부”를 뜻합니다. “사서함 가득 참”도, “사용자 없음”도 아닌 — 정책상 거부. 서버가 결정을 내린 겁니다.

그 결정 뒤의 가장 흔한 정책이 SPF입니다. SPF(RFC 7208)는 도메인이 DNS TXT 레코드에 자기를 대신해 발송하도록 인가된 IP 주소 목록을 발행하게 하고, 끝에 한정자를 답니다: -all은 “목록에 없는 건 하드 실패해야 함”, ~all은 “softfail — 의심스럽지만 수용”. 수신 서버가 SPF를 평가할 때 실제로 연결한 IP를 그 목록과 대조하는데 — 결정적으로, 봉투 발신자의 도메인(MAIL FROM / Return-Path)에 대해 대조하지, 메일 클라이언트에 보이는 From 헤더가 아닙니다. -all을 발행한 도메인에서의 하드 실패가 550 5.7.1의 교과서적 트리거입니다. 하지만 코드가 범용이라, 동반 텍스트를 읽어서 SPF가 정말 원인인지, 아니면 같은 숫자를 쓴 DMARC나 로컬 차단인지 확인해야 합니다.

Top 3 Causes

1. 새 발송 서비스가 SPF 레코드에 없음. CRM, 티켓 플랫폼, 이메일 서비스 제공자를 통해 메일을 라우팅하기 시작했는데 그 IP 대역이 v=spf1 레코드에 추가된 적이 없습니다. 서비스는 당신 도메인으로 정당하게 보내고, 수신 서버는 SPF를 확인하고, IP가 인가돼 있지 않고, -all이 그걸 하드 거부로 바꿉니다. 단서: 내 메일 서버는 잘 배달되고 새 도구에서 온 메일만 바운스.
2. 엉뚱한 도메인이 검사됨 — 봉투 vs 헤더 혼동. 보이는 From은 내 도메인인데 MAIL FROM / Return-Path는 다른 도메인(벤더의 바운스 도메인)이고, SPF는 그것에 대해 평가됩니다. 벤더의 SPF가 깨졌거나, 내 SPF가 그 메일까지 덮는다고 잘못 가정한 거죠. 단서: 내 SPF는 완벽한데 SPF가 여전히 실패 — 수신 서버가 내 레코드를 아예 안 봤으니까.
3. SPF가 PermError를 반환하거나 포워딩에서 깨짐. include:가 너무 많이 엮여 RFC 7208 §4.6.4의 DNS 조회 10회 한도를 넘으면 SPF가 PermError를 반환해 엄격한 수신 서버가 거부합니다. 또는 메일이 포워딩됐습니다: 포워딩은 포워더의 IP로 재전송하는데 당신 SPF엔 그게 없으니, 원본은 완벽히 인가됐어도 마지막 홉에서 SPF가 실패합니다. 단서: 바운스 텍스트의 PermError, 또는 포워딩된 메일에서만 나는 바운스.

Diagnose with DechoNet

• Email Check는 도메인의 SPF 레코드를 파싱하고 그것이 유발하는 DNS 조회 횟수를 세어, 한도 초과 레코드(터지기 직전의 PermError), 누락된 -all/~all 한정자, 해석 안 되는 include를 표시합니다 — 개별 발신자를 쫓기 전에 레코드 자체가 문제인지 먼저 볼 수 있습니다.
• Email Header Analyzer는 바운스됐거나 수신된 메시지의 Authentication-Results와 Return-Path를 읽어 정확한 SPF 결과, 실제로 평가된 도메인, 연결 IP를 보여줍니다 — SPF가 내 도메인을 봤는지 벤더 도메인을 봤는지, 어느 IP를 거부했는지 확인하는 방법입니다.

Resolution Checklist

• 550 5.7.1 뒤 전체 바운스 텍스트를 읽으세요. SPF를 지목하는지 확인 — DMARC, relay, 평판을 말하면 이 가이드가 아닙니다.
• 실제 평가된 도메인을 찾으세요: 보이는 From이 아니라 바운스된 메시지의 Return-Path / MAIL FROM. SPF는 그 도메인의 레코드에 대해 검사됩니다.
• 바운스에서 연결 IP(“does not designate …”)를 뽑아, 해당 SPF 레코드에 인가돼 있는지 확인하세요.
• 새 서비스가 발송한다면, 벤더가 문서화한 include:나 IP 대역을 v=spf1 레코드에 추가하세요 — 바뀌는 IP를 손으로 베끼지 말고 벤더가 안내하는 include를 쓰세요.
• SPF DNS 조회 횟수를 세세요; 10에 가깝거나 넘었으면 include를 평탄화/통합해 RFC 7208 §4.6.4의 PermError를 해소하세요.
• 포워딩된 메일에서만 실패한다면 그건 정상적인 SPF 동작입니다 — 모든 포워더를 인가하려 들지 말고 DKIM(포워딩에서 살아남음)과 DMARC 정렬에 기대세요.

When to Escalate

• SPF가 당신이 아니라 벤더의 바운스 도메인에서 실패하면, 수정은 벤더 쪽입니다 — 그들의 SPF가 자기네 발송 IP를 인가해야 합니다. 당신 DNS가 아니라 그 서비스에 티켓을 여세요.
• 레코드도 맞고 IP도 인가돼 있는데 특정 수신 서버가 계속 550 5.7.1을 반환하면, 그 거부는 그 수신 서버의 로컬 정책이거나 5.7.1 코드를 공유하는 평판 차단입니다. 전체 바운스와 메시지 헤더를 들고 수신 조직의 postmaster에게 연락하세요.