거래처 이메일 변경 요청, 주소록 수정 전에 확인할 세 가지

주소를 바꾸는 작업과 지난 자료를 넘기는 결정은 분리해서 확인하세요.

거래처에서 새 이메일 주소를 알려오면 연락처만 고치고 끝내기 쉽습니다. 하지만 새 주소가 맞는지, 그 사람이 지금도 해당 업무를 맡는지, 이전 대화까지 받을 권한이 있는지는 같은 질문이 아닙니다.

요청 확인과 자료 공유를 나누어 생각하기 위한 AI 생성 개념 그림입니다.

접수: 변경 요청은 받았지만 아직 적용 전

처음에는 기존 주소, 요청받은 새 주소, 바꾸려는 업무 범위만 정리합니다. 모르는 사람이 보낸 메일에 적힌 전화번호나 회신 주소를 확인 경로로 곧바로 쓰지 않는 것이 출발점입니다.

• 이미 확인해 둔 전화번호나 기존 거래 창구가 있는지 봅니다.
• 그 경로로 실제 변경 요청인지 확인합니다.
• 확인되지 않았다면 주소록 변경과 이전 자료 전송을 보류합니다.

확인: 연락처와 업무 역할을 따로 묻기

실제 거래처 담당자가 보낸 요청이어도 담당 업무가 바뀌었을 수 있습니다. “앞으로 이 프로젝트의 회신을 새 주소로 받으시는 것이 맞나요?”처럼 대상 업무를 좁혀 물어보세요. 수신만 바뀌는지, 승인 담당도 바뀌는지 구분하면 불필요하게 권한을 넓히지 않을 수 있습니다.

요청은 접수했습니다. 기존 연락 경로로 변경 의사를 확인한 뒤 새 주소를 반영하겠습니다. 이전 자료 전달 범위는 별도로 확인 중입니다.

공유: 필요한 자료만 다시 검토하기

담당 역할이 확인됐다고 과거 메일 전체를 전달할 이유는 없습니다. 견적서, 내부 메모, 다른 고객의 정보처럼 대화 안에 섞여 있는 자료를 먼저 나눕니다. 공유 범위가 불분명하면 해당 자료의 책임자에게 확인하고, 확인이 끝난 부분만 전달하세요.

1. 전달할 파일과 대화를 지정합니다.
2. 이번 업무에 필요한 범위인지 확인합니다.
3. 수신자와 링크 접근 권한을 다시 대조합니다.
4. 확인 중인 항목은 완료 목록에서 분리합니다.

반영 후: 발송 대기열까지 같은 주소인가요?

연락처 수정 뒤에도 예전 초안, 자동완성, 예약 발송에 옛 주소가 남을 수 있습니다. 이미 대기 중인 메일은 저장 당시 수신자를 다시 확인하세요. 주소록을 고쳤다는 사실만으로 모든 발송 대상이 바뀌었다고 판단하지 않는 것이 중요합니다.

긴급 요청이라도 확인 경로를 생략하지는 마세요. 대신 어떤 확인이 남았는지와 다음 안내 시점을 짧게 회신하면 됩니다.

오늘 변경 요청 한 건을 골라 요청 확인·담당 역할·자료 공유를 따로 점검해 보세요. 이 글은 일반적인 업무 점검 제안이며 특정 보안 사고를 막는다는 보장은 아닙니다.

참고: NIST의 피싱 대응 기본 안내

오피셜메일에서 업무 메일 확인하기