553 5.1.8 발신 도메인이 존재하지 않음

Problem

메일이 영구처럼 보이는 553 5.1.8과 Domain of sender address <[email protected]> does not exist, Sender address rejected: Domain not found, 또는 MAIL-FROM domain does not exist in DNS 같은 문구로 반송됩니다. 본능적으로 수신자 주소를 확인하게 되는데, 거기가 틀린 곳입니다. 이 오류는 수신 서버가 당신 도메인 — 정확히는 봉투 발신자의 도메인 — 을 두고 항의하는 것입니다. DNS에서 그 도메인을 조회했는데 아무것도 못 찾았기 때문입니다.

Symptoms

• 반송문에 553 5.1.8(또는 일시적 형제인 450 4.1.8)과 Domain of sender address does not exist 또는 Sender address rejected: Domain not found가 실린다.
• 수신자 주소는 정확하고, 다른 사람은 그 수신자에게 메일이 잘 간다.
• 특정 앱·스크립트·기기·크론에서 보낸 메일만 반송되고, 평소 쓰는 메일 클라이언트에서 보낸 정상 메일은 통과한다.
• 새 도메인을 메일 서버에 막 연결한 직후(DNS 전파 전) 또는 누군가 도메인 레코드를 수정·삭제한 직후 나타난다.

이 오류가 실제로 뜻하는 것

영어 문구가 아니라 확장 상태 코드를 읽으세요. RFC 3463은 **X.1.8을 “발신자의 시스템 주소 불량(Bad sender’s system address)“**으로 정의합니다: 발신자 주소에 명시된 시스템이 존재하지 않거나 반송 메일을 받을 수 없다는 뜻입니다. 실전에선, 수신 서버가 당신 SMTP MAIL FROM의 @ 오른쪽 도메인 — 봉투 발신자 — 을 가져다 DNS 조회를 합니다. 그 도메인에 MX 레코드도 A 레코드도 없으면, 서버는 이게 실제 메일 가능한 도메인이 아니라고 판단하고 메일을 거절합니다.

이 논리는 SMTP만큼 오래된 스팸 방어입니다: 정상 발신자는 답장을 받을 수 있는 도메인을 씁니다. 아예 해석되지 않는 도메인은 아무것도 받을 수 없으니, 거기서 왔다는 메일은 설정 오류이거나 위조입니다. 거절 비용은 싸고, 잡히는 쓰레기는 많습니다.

553/550 대 450의 갈림은 영구성 플래그입니다. 5.1.8은 영구 — 도메인이 정말 존재하지 않으니 재시도 금지. 4.1.8은 일시 — 수신 측이 이번엔 해석하지 못했으니 큐에 넣고 다시 시도하라는 뜻. 그래서 Postfix의 reject_unknown_sender_domain은 기본값으로 4xx를 씁니다: DNS 실패가 순간적 장애일 수 있으니 한 번의 조회 실패로 정상 메일을 영구 거절하지 않는 겁니다. 관리자가 이 검사를 엄격히 하기로 하면 553/550으로 올리고, 그러면 하드 반송이 됩니다.

결정적 함정: 이건 봉투 발신자에 관한 것이고, 봉투 발신자는 사람이 From: 헤더에서 보는 주소와 다른 경우가 잦습니다. From:은 [email protected]인데 기계는 실제로 MAIL FROM:<[email protected]>이라고 알렸을 수 있고 — 수신 측이 검사해 거절한 건 눈에 안 보이는 그 두 번째 도메인입니다.

Top 3 Causes

1. 발신 도메인에 작동하는 DNS가 없다. 전파 안 된 새 도메인, A와 MX가 둘 다 없는 도메인, 만료된 도메인, 또는 수정·삭제된 레코드. 수신 측이 당신 도메인을 조회해 아무것도 못 얻고 거절한다. 이건 5.1.8이 제 일을 하는 것.
2. 앱·기기가 가짜/내부 봉투 발신자로 보낸다. 프린터·스캐너·크론·모니터링 에이전트·웹앱은 흔히 root@localhost, www-data@server01, [email protected] 같은 봉투 발신자를 기본값으로 쓴다 — 공개 DNS가 없는 맨 호스트명이나 사설 도메인. 보이는 From:은 멀쩡한데 수신 측이 검사하는 봉투는 존재하지 않는다. 반송문에 뜨는 주소가 내가 의도한 발신 주소가 아니라서 가장 많이 오진되는 원인.
3. 발신 설정의 오타 또는 폐기된 도메인. 봉투 발신 도메인 철자 하나가 틀렸거나, 은퇴시킨 도메인인데 잊힌 스크립트가 아직 그걸로 보낸다. 주소 형식은 멀쩡한데 해석 안 되는 이름을 가리킨다.

Diagnose with DechoNet

• DNS 조회를 발신 도메인에 — 웹사이트도 수신자도 아니라 반송문이 지목한 그 도메인에 돌려라. MX도 A도 없이 돌아오면 찾은 것이다: 수신 서버가 당신을 거절하기 직전 본 게 바로 그거다. 여기선 레코드가 있는데 도메인이 방금 만든 것이라면 전파를 기다리는 중이다.
• 이메일 헤더 분석은 반송문(NDR)을 읽어 수신 측이 문제 삼은 정확한 봉투 발신 주소를 짚어준다. “From은 멀쩡한데 봉투는 [email protected]” 경우를 잡는 방법 — 헤더가 조회할 진짜 도메인을 알려준다.
• 이메일 점검을 발신 도메인에 돌리면 그게 애초에 메일을 주고받도록 설정돼 있는지(MX 존재, SPF 정상) 확인한다 — 해석은 되는데 실제 메일 도메인은 아닌 경우가 여기서 드러난다.

Resolution Checklist

• 반송문을 읽고 지목된 정확한 발신 주소를 복사하라. 코드가 5.1.8/4.1.8(발신 도메인)인지, 5.1.1/5.1.2(수신자)가 아닌지 확인하라 — 숫자가 누구 문제인지 정한다.
• 그 발신 도메인을 DNS 조회로 돌려라. A도 MX도 없는 게 직접 원인이니, 해석되는 레코드를 최소 하나 게시하라.
• 도메인이 갓 만든 것이면 레코드가 실제로 살아 있는지 확인하고, 고장으로 단정하기 전에 전파 시간을 줘라.
• 문제 주소가 내부/맨 호스트명(root@server01, @localhost, @*.local)이면 보내는 앱·기기가 공개 해석되는 진짜 봉투 발신 도메인을 쓰도록 고쳐라 — .local을 공개 인터넷에서 해석시키려 하지 마라.
• 해석되는 도메인인데 450 4.1.8이 계속 반복되면 수신 측 리졸버가 실패하는 것일 수 있다 — 재시도하고, 계속되면 수신 측에 연락하라.
• 발신 도메인을 DNS로 다시 확인하고, 반송됐던 같은 경로로 테스트 메일을 보내 고침을 검증하라.

When to Escalate

• 발신 도메인에 유효한 A·MX가 분명히 있는데도 메일이 계속 553 5.1.8로 반송되면, 수신 서버의 DNS 해석이 그쪽에서 깨진 것일 수 있다 — 반송문을 증거로 수신 측 메일 관리자와 풀 일이다.
• 잘못된 봉투 발신자가 당신이 완전히 통제하지 못하는 어플라이언스나 SaaS(프린터 다발, 청구 플랫폼, 헬프데스크 도구)에서 나온다면, 고칠 지점은 그 제품의 “send-as”/“return-path” 설정에 있다 — 설정할 수 없는 봉투 발신자는 고칠 수 없으니 그 시스템 담당자에게 넘겨라.
• 정상 도메인이 다른 데선 다 해석되는데 유독 한 대형 제공자에서만 반송되면, 도메인이 새것이거나 최근 옮겼는지 확인하라. 일부 수신 측은 네거티브 DNS 응답을 캐시하므로, 이제 막 해석되기 시작한 이름은 한동안 반송될 수 있다.