이메일 Reply-To 검수, 답장 주소가 달라졌을 때

답장 주소는 Reply-To를 먼저 보고, 없으면 From을 기본으로 봅니다. 다른 주소는 업무상 승인 근거를 확인합니다. 2026년 11월 10일 기준입니다.

고객이 보낸 메일의 화면에는 작성자 주소가 보이지만 답장 초안에는 별도 접수 주소가 들어갈 수 있습니다. 이때 확인할 일은 두 가지입니다. 메일 헤더가 어디로 답하라고 제안하는지 읽고, 그 주소에 업무 내용이나 첨부를 보낼 근거가 있는지 별도로 확인합니다.

From과 Reply-To는 각각 무엇을 뜻하나요?#

RFC 5322에서 From은 메시지 작성자 주소를 나타냅니다. Reply-To가 있으면 작성자가 제안한 회신 주소이며, 필드가 없으면 답장을 작성하는 사람이 따로 지정하는 경우를 제외하고 기본적으로 From의 주소를 사용합니다. Sender는 전송을 담당한 주체의 주소를 나타낼 수 있습니다. 이 글은 일반 답장의 한 명 수신자 후보만 다루며 전체 답장의 참조 배치는 별도입니다. RFC 5322 §3.6.2

Gmail 연동이라면 users.messages.get의 format=METADATA와 metadataHeaders로 확인할 헤더를 지정할 수 있습니다. 최상위 메시지의 From, Reply-To, 필요하면 Sender를 읽습니다. 전달문과 인용문에 표시된 주소는 원본 추적에 쓸 수 있으며, 초안 후보는 현재 메시지의 최상위 헤더에서 추출합니다. Gmail 메시지 조회

가상 회신 7개를 어떻게 대조하나요?#

아래는 회신 초안에 수신자 한 명만 제안하는 가상 정책입니다. 별도 접수 주소는 이전에 확인한 업무 채널이나 주소록에서 해당 작성자·과제의 대체 회신 경로로 승인된 경우에 후보로 올립니다. 주소가 다른 사실만으로 공격이라고 판정할 수는 없습니다.

아래 함수에는 파서가 표시 이름을 분리한 메일함 주소를 넘깁니다. 로컬 부분이 다른 주소는 별도 확인 없이 같은 값으로 합치지 않습니다. valid는 필수 작성자 헤더·구문과 필드 수를 확인한 결과입니다. replyTo가 실제로 없을 때만 undefined를 사용합니다. approvedAlternates는 현재 작성자·과제에 대해 이미 확인한 주소 집합입니다. 일반 메일에 허용되는 복수 주소와 일부 그룹 구문도 이 한 명 초안 흐름에서는 보류합니다. RFC 5322 필드 수 · RFC 6854 그룹 구문

export function replyCandidate(headers, approvedAlternates) {
  if (!headers.valid || headers.from.length !== 1) {
    return { state: "hold-headers" };
  }
  const [author] = headers.from;
  if (headers.replyTo === undefined) {
    return { state: "candidate", recipient: author };
  }
  if (headers.replyTo.length !== 1) {
    return { state: "hold-address-count" };
  }
  const [requested] = headers.replyTo;
  if (requested !== author && !approvedAlternates.has(requested)) {
    return { state: "hold-recipient-change" };
  }
  return { state: "candidate", recipient: requested };
}

실제 인수표에는 헤더에서 고른 후보, 주소가 달라진 이유, 주소 확인 근거와 사람이 승인한 최종 수신자를 함께 적습니다. 파서나 주소록, 메시지 전달 규칙을 바꾸면 같은 표본을 다시 검수합니다.

별도 접수 주소를 언제 보류하나요?#

거래처가 티켓 시스템이나 공동 메일함을 회신 창구로 지정했다면 별도 Reply-To에 업무상 이유가 있을 수 있습니다. 새 주소는 이 메일에 적힌 설명과 다른 경로에서 확인하세요. 주소 변경이 검증된 뒤에도 본문과 첨부의 공유 권한, 최종 To·Cc·Bcc, 승인 뒤 변경 여부를 발송 전에 확인합니다.

DMARC 통과는 From 헤더의 작성자 도메인에 정렬된 인증 식별자가 확인됐다는 뜻입니다. RFC 9989 작성자 도메인 회신 제안 주소가 이 과제의 업무 수신자로 승인됐는지는 별도 근거로 확인합니다. 답장할 원문 메시지를 찾는 과정은 Gmail 답장 원문 연결 검수에서 다룹니다.

어떤 문서에서 기준을 확인했나요?#

• IETF RFC 5322는 From·Sender·Reply-To의 역할과 회신 기본값을 정의합니다. 2008년 10월 공개.
• IETF RFC 6854는 From과 Sender의 그룹 구문을 갱신했습니다. 2013년 3월 공개.
• IETF RFC 9989는 DMARC의 확인 기준을 작성자 도메인으로 설명합니다. 2026년 5월 공개.
• Google Gmail API 메시지 조회는 METADATA 응답에서 지정한 헤더를 받는 방법을 안내합니다. 2026년 4월 15일 UTC 갱신.
• 알파카랩스 업무 자동화·API 연동은 예외와 수동 전환, 운영 인수 범위를 협의하는 서비스를 안내합니다.

원문은 2026년 11월 10일 확인했습니다. 표의 한 명 후보와 보류 판정은 이 글의 설계 예시입니다.

자주 묻는 질문#

답장 주소의 인수 범위를 정할 때#