550 5.7.26: Gmail 미인증 메일 차단 해결

Problem

Gmail로 보낸 메일이 550 5.7.26과 함께 “This mail has been blocked because the sender is unauthenticated. Gmail requires all senders to authenticate with either SPF or DKIM.” 같은 문구로 바운스됩니다. 받은편지함에 아무것도 도착하지 않았습니다. 스팸 점수 문제도, 평판 하락도 아닙니다 — Gmail이 신뢰하는 두 인증 방식 중 어느 것으로도 메일을 당신의 도메인에 묶지 못해 문 앞에서 거부한 것입니다.

Symptoms

• 바운스에 550-5.7.26과 발송자가 “미인증(unauthenticated)“이거나 인증이 필요하다는 문구가 나옵니다.
• 2024년 2월 즈음, 또는 그 이후에 시작되거나 악화됐습니다 — Google의 발송자 규칙이 2024~2025년에 걸쳐 시행·강화됐습니다.
• 주력 플랫폼 메일은 전달되는데, 새 도구나 스크립트에서 보낸 메일은 바운스됩니다.
• DMARC 리포트에서 거부된 소스에 대해 SPF와 DKIM이 둘 다 fail(또는 둘 다 미정렬)로 나옵니다.
• 같은 메일을 소규모 제공업체는 받아주는데 Gmail(그리고 흔히 Yahoo)만 거부합니다.

What 550 5.7.26 Actually Means

코드를 독립된 두 사실로 읽으세요. 550은 SMTP 응답(RFC 5321)으로 영구 실패 — 같은 메일을 다시 보내도 소용없습니다. 5.7.26은 향상된 상태 코드이고, 정확합니다: RFC 7372는 X.7.26을 **“Multiple authentication checks failed”(복수의 인증 검사 실패)**로 정의합니다. 메일이 수신자 정책에 대해 하나 이상의 인증 검사에 실패한 것입니다.

Gmail의 경우 그 두 검사는 SPF와 DKIM이고, From 도메인과의 정렬을 기준으로 평가됩니다. 2024년 2월 1일부터 시행된 Gmail 발송자 가이드라인은 모든 발송자가 둘 중 최소 하나로 인증할 것을, 대량 발송자(Gmail로 하루 5,000통 초과)는 SPF와 DKIM에 더해 최소 p=none의 DMARC 레코드를 요구합니다. 정렬된 SPF 통과도 정렬된 DKIM 통과도 없는 메일은 Gmail이 신경 쓰는 두 검사에 모두 실패한 것 — 규정대로 5.7.26입니다.

조용히 일하는 단어는 *정렬(aligned)*입니다. 메일이 SPF를 통과하고 유효한 DKIM 서명을 달고도 Gmail 눈에는 “미인증”일 수 있습니다. 어느 결과도 사람이 보는 From 필드의 도메인과 일치하지 않기 때문입니다. “어딘가에서 통과”와 “내 도메인과 정렬” 사이의 그 틈에 대부분의 5.7.26 바운스가 실제로 삽니다.

Top 3 Causes

1. 발송 소스에 인증이 아예 설정되지 않았다. 새 도메인, 트랜잭션 스크립트, 방금 추가한 앱이 “당신처럼” 보내는데, SPF를 게시한 적도 DKIM을 설정한 적도 없거나 둘 다입니다. 존재하지 않는 검사는 통과할 수 없습니다. 지문: 새롭거나 일회성 발송자이고, DNS에 그 소스용 DKIM 셀렉터가 없습니다.
2. SPF와 DKIM은 통과하지만 어느 쪽도 From 도메인과 정렬되지 않는다. ESP나 SaaS 도구로 보냅니다. SPF는 벤더의 바운스 도메인으로 통과하고, DKIM은 벤더 도메인으로 서명됩니다. 둘 다 “초록불”이지만 From은 you@yourdomain.com이라, Gmail의 정렬 관점에서 당신의 도메인은 아무것도 인증하지 않았습니다. 지문: 헤더에 spf=pass, dkim=pass가 보이는데도 Gmail이 미인증이라고 합니다 — 당신 도메인이 아니라 벤더 도메인을 검사했기 때문입니다.
3. 대량 발송자인데 DMARC 레코드가 없다. Gmail로 하루 5,000통 초과 기준을 넘고 SPF·DKIM은 멀쩡할 수 있지만, 도메인에 DMARC 레코드가 없습니다 — Gmail이 이제 대량 발송자에게 요구하는 항목입니다. 지문: Gmail로 대량 발송, 그리고 _dmarc.yourdomain.com TXT 조회가 아무것도 반환하지 않습니다.

Diagnose with DechoNet

• Email Check는 도메인의 SPF·DKIM·DMARC 레코드를 한 번에 가져옵니다 — 개별 발송자를 손대기 전에 SPF가 존재하고 10회 조회 한도 안에서 해석되는지, DKIM 셀렉터가 게시됐는지, DMARC 레코드가 있는지(Gmail 대량 규칙이 요구하는 바로 그 셋)를 확인할 수 있습니다.
• Email Header Analyzer는 바운스되거나 수신된 메일의 Authentication-Results를 읽어 SPF·DKIM 결과 와 각각이 평가된 도메인을 보여줍니다 — 둘 다 “통과”지만 어느 쪽도 From과 일치하지 않는 정렬 틈을 가장 빠르게 잡아냅니다.

Resolution Checklist

• 코드가 5.7.1이나 5.7.7이 아니라 5.7.26인지 확인하세요 — 5.7.26은 두 인증 검사 모두 실패라는 뜻이므로, 해결책은 “정책 하나 조정”이 아니라 “하나를 정렬시키기”입니다.
• From 도메인에 Email Check를 돌려 셋 다 있는지 확인하세요: SPF 레코드, DKIM 셀렉터, DMARC 레코드(최소 p=none).
• 활성 발송 서비스마다 DKIM을 당신의 도메인으로 설정하세요 — 벤더가 주는 CNAME/TXT 셀렉터를 게시해 서명이 벤더가 아니라 당신의 From과 정렬되게 하세요.
• 모든 정상 발송 소스를 벤더가 문서화한 include:로 v=spf1 레코드에 추가하고, 총 DNS 조회를 10회 미만으로 유지하세요(RFC 7208 §4.6.4).
• 실제 메일에 Email Header Analyzer를 써서 SPF나 DKIM 중 최소 하나가 이제 From 도메인과 정렬된 pass로 나오는지 확인하세요.
• Gmail로 대량 발송한다면 p=none이라도 DMARC 레코드를 게시하세요 — 대량 발송자에게는 DMARC 부재만으로도 SPF/DKIM과 무관하게 5.7.26이 발생합니다.

When to Escalate

• 벤더가 도메인 정렬 DKIM을 제공하지 못하고 자기네 서명 도메인만 준다면, 그것은 벤더 쪽 한계입니다 — 커스텀 DKIM/return-path 설정을 요구하세요. 정렬 없이는 그 메일이 계속 5.7.26에 걸립니다.
• 셋 다 정확하고 정렬됐는데도 Gmail이 여전히 5.7.26으로 거부한다면, 전체 바운스와 메일의 Authentication-Results 헤더를 캡처해 Google 발송자 지원이나 Postmaster Tools로 가져가세요 — 이제 실패하는 검사는 그쪽이 설명할 몫입니다.