아웃룩은 받는 같은 메일을 왜 지메일만 반송하나요?

RFC 5322를 서로 다르게 집행하기 때문입니다. 메일에 형식 결함이 있고 — 단일 인스턴스 헤더 중복이 대표적 — Microsoft 수신 서버는 이를 관대하게 넘기는 반면 지메일은 아예 거부합니다. 이 갈림이 사실 가장 쓸모 있는 단서입니다: 문제가 SPF·DKIM·DMARC·IP 평판이 아니라 메일이 *어떻게 만들어지는지*에 있다는 뜻이니까요. '아웃룩은 되는데 지메일만 반송'은 거의 매번 발신측 형식 버그이고, 고칠 곳은 DNS가 아니라 메일 생성기입니다.

SPF·DKIM·DMARC가 다 통과하는데 왜 거부되나요?

550 5.7.1 'not RFC 5322 compliant'은 인증이 아니라 메일 *구조* 문제, 완전히 다른 층이기 때문입니다. 인증은 '이 발신자가 이 도메인을 쓸 자격이 있나'를 묻고, RFC 5322 준수는 '애초에 제대로 생긴 메일인가'를 묻습니다. 인증이 완벽해도 From이 두 개, Message-ID가 두 개인 메일을 내보낼 수 있고, 지메일은 완벽한 SPF가 작동하기도 전에 그 구조를 거부합니다. DNS를 다시 뒤지지 말고 원문 헤더를 읽으세요.

정확히 뭐가 잘못됐나요? 메일 클라이언트에선 멀쩡해 보입니다.

클라이언트는 메일을 렌더링할 뿐, 결함이 사는 원문 헤더 블록을 보여주지 않습니다. 지배적 원인은 단일 인스턴스 헤더가 두 번 나타나는 것 — Date 두 줄, From 두 줄, Message-ID 두 줄, 혹은 Subject 여러 개 — 인데, 한 구성요소(앱)가 헤더를 넣고 다른 구성요소(메일 라이브러리·릴레이)가 자기 사본을 또 붙이기 때문입니다. 드물게는 Message-ID 누락, 깨진 주소 문법, 잘못된 줄 접힘, 헤더 속 비ASCII 문자입니다. 보려면 원문을 봐야 합니다 — 예쁜 화면은 바로 그 틀린 부분을 숨깁니다.

550 5.7.1 RFC 5322 미준수 메일 반송

문제

메일이 550-5.7.1 ... This message is not RFC 5322 compliant로 반송되고, 그건 거의 항상 내 시스템이 보낸 메일입니다 — 트랜잭션 메일, 모니터링 도구의 알림, 내가 만들거나 설정한 앱의 알림. 미칠 노릇인 건 똑같은 메일이 아웃룩이나 다른 받은편지함엔 아무 불평 없이 들어간다는 점이라, 지메일이 괜히 까다롭게 구는 것처럼 느껴집니다. 아닙니다. 메일은 실제로 잘못 만들어졌고, 대부분의 수신 서버가 그냥 봐줄 뿐이며 지메일은 안 봐줍니다.

이건 평판이나 인증 문제가 아니라 구조 문제이고, 이 구분이 빨리 고치는 열쇠 전부입니다.

증상

반송문에 This message is not RFC 5322 compliant라는 문구가 그대로 들어 있고, 보통 향상 상태코드 5.7.1 아래, 종종 Google 도움말 포인터가 붙습니다.
특정 종류의 메일(한 앱, 한 스크립트, 한 알림 연동에서 나오는 전부)에서 재현됩니다 — 무작위가 아닙니다.
똑같은 메일을 Microsoft 365 / Outlook.com과 다른 제공자는 받아들여, 지메일 전용 결함처럼 보입니다.
SPF·DKIM·DMARC 점검은 다 통과해서, 흔한 전달성 조언으론 아무 데도 못 갑니다.

550 5.7.1 “Not RFC 5322 Compliant”의 실제 의미

RFC 5322는 인터넷 메시지 형식 — 메일이 어떻게 구성되는가의 명세입니다: 어떤 헤더 필드가 있는지, 주소를 어떻게 쓰는지, 긴 줄을 어떻게 접는지, 헤더와 본문을 가르는 빈 줄까지. 특히 §3.6은 한 가지에 엄격합니다: 메일에는 Date 필드가 정확히 하나, From 필드가 최소 하나 있어야 하고, 단일 인스턴스로 정의된 헤더 — From·Date·Subject·Message-ID 등 — 는 많아야 한 번 나와야 합니다. 그중 무엇이든 두 개면 위반입니다.

지메일은 이를 집행합니다. 2024년 2월 1일부터 시행 중인 Google 대량 발송자 요건은 메일을 RFC 5322에 맞춰 구성하고 유효한 Message-ID를 넣으라고 명시하며 — Google은 중복 헤더 RFC 5322 반송만을 다루는 전용 문제해결 페이지까지 운영합니다. 그 원인이 얼마나 흔한지 알 수 있습니다. 여기 향상 상태코드 5.7.1은 지메일의 스팸 정책 거부(“this message is likely unsolicited”)와 공유되므로 코드만 보지 말고 문구를 읽으세요 — 숫자 뒤의 단어가 이게 평판이 아니라 형식 문제임을 알려줍니다.

주요 원인 3가지

단일 인스턴스 헤더가 두 번 나타남(압도적 1위). 애플리케이션이 헤더 — 예를 들어 Date나 Message-ID — 를 넣고, 그다음 메일 라이브러리·프레임워크·릴레이가 자기 사본을 또 찍어서 메일이 두 개를 달고 나갑니다. From 둘, Date 둘, Subject 둘, Message-ID 둘: 무엇이든 걸립니다. 손으로 짠 MIME, 잘못 쓴 SMTP 라이브러리, 이미 완성된 메일에 헤더를 덧붙이는 알림 연동이 단골입니다.
필수 헤더 누락 또는 주소 문법 깨짐. Date 없음, 유효한 From 없음, 또는 제대로 안 생긴 주소(꺾쇠 괄호 누락, 떠도는 쉼표, 특수문자가 든 따옴표 없는 표시 이름). Google은 추가로 유효한 Message-ID를 요구하므로, RFC 5322 자체는 권장일 뿐인데도 Message-ID가 없는 메일이 거부될 수 있습니다.
잘못된 줄 접힘 또는 허용 안 되는 문자. 너무 길어 잘못 접힌 헤더 줄, encoded-word가 필요한 자리의 날것 비ASCII, 깨진 =?utf-8?...?= 인코딩. 중복보다 드물지만 같은 반송을 냅니다.

DechoNet으로 진단

이메일 헤더 분석은 원문 소스를 파싱해 헤더 블록을 펼쳐, 중복된 단일 인스턴스 필드(Date 둘, Message-ID 둘)와 깨진 주소를 바로 보여줍니다 — 결함은 메일 클라이언트가 숨기는 원문 헤더에 있습니다.
이메일 / 도메인 점검은 SPF·DKIM·DMARC가 실제로 멀쩡함을 확인해, 인증을 배제하고 메일 틀에 사는 문제를 DNS에서 쫓는 삽질을 멈추게 합니다.
DNS 조회는 발신 도메인의 레코드(참조한다면 Message-ID 도메인)가 해석되는지 점검하는 안전장치입니다 — 생성된 헤더가 존재하지 않는 도메인을 참조할 때 가끔 관련됩니다.

해결 체크리스트

반송된 메일의 원문 소스(렌더된 화면 말고)를 받아 헤더 블록을 보세요.
단일 인스턴스 헤더가 두 번 나오는지 훑으세요 — From·Date·Subject·Message-ID. 중복이 가장 유력한 원인입니다.
중복을 찾으면 두 번째 사본을 넣는 구성요소(내 코드 vs 메일 라이브러리·릴레이)를 가려내 둘 중 하나만 넣게 하세요.
Date 정확히 하나, 제대로 생긴 From 최소 하나, 유효한 Message-ID 하나를 확인하세요.
주소 문법과 헤더 인코딩(꺾쇠 괄호, 비ASCII용 encoded-word, 올바른 줄 접힘)을 점검하세요.
지메일 주소로 다시 보내 수신을 확인하세요 — 고침은 클라이언트에서 멀쩡해 보이는 게 아니라 전달로 검증됩니다.

이럴 땐 넘기세요

중복 헤더를 내가 통제 못 하는 외부 발송 서비스나 장비가 주입한다면, 그건 벤더 티켓입니다 — 두 번 나온 필드가 보이는 원문 헤더를 넘기세요. 고칠 곳은 그들의 파이프라인입니다.
모든 단일 인스턴스 헤더가 깨끗이 하나뿐임을 확인했는데도 반송된다면, 인증을 다시 보지 말고 새 원문 샘플을 떠서 더 미묘한 위반(줄 접힘, encoded-word 문법)을 찾으세요.
반송문이 사실 다른 5.7.1 — “our system has detected that this message is likely unsolicited mail” — 이라면 다른 문제입니다. 550 5.7.1 SPF/정책 반송과 정렬 중심의 550 5.7.26 지메일 미인증을 보세요.

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.