비밀번호 재설정, 결재 요청, 장애 알림처럼 업무 흐름을 이어 주는 메일이 고객에게 도착하지 않았습니다. 그런데 애플리케이션 로그에는 “발송 성공”이라고 찍힙니다. 대개 그 로그는 메일 발송 서비스가 요청을 접수했다는 뜻일 뿐, 수신 서버가 받아들였거나 고객의 수신함에 표시됐다는 증거가 아닙니다. 신뢰할 수 있는 업무 알림을 만들려면 발송 요청부터 최종 실패까지의 상태를 분리하고, 도메인 인증과 반송 처리를 함께 운영해야 합니다.
SPF·DKIM·DMARC는 각각 다른 질문에 답한다
SPF는 이 IP 또는 발송 서버가 해당 도메인을 대신해 메일을 보낼 권한이 있는지 확인합니다. DKIM은 메시지에 서명하여 전송 중 주요 내용이 바뀌지 않았는지와 서명 도메인을 확인합니다. DMARC는 표시되는 From 도메인과 인증된 도메인의 정렬을 검사하고, 실패한 메일을 수신 측이 어떻게 다룰지 정책으로 알립니다. 세 기술은 서로 대체재가 아닙니다. 한 서비스를 통해 메일을 보내면서 SPF만 넣고 실제 From 도메인과 DKIM 서명 도메인이 맞지 않으면 여전히 문제가 생길 수 있습니다.
Gmail의 발신자 가이드라인은 개인 Gmail 계정으로 보내는 메일에 대해 발신자 유형별 인증 요구사항과 발송 관행을 안내합니다. 요구사항은 수신 사업자와 발송 유형에 따라 달라지므로 최신 공식 지침을 확인해야 합니다. 기본 설계는 모든 발송 경로를 목록화하고 각 도메인·하위 도메인의 SPF, DKIM, DMARC 설정을 실제 메일 헤더로 검증하는 것입니다. 고객지원 도구나 마케팅 도구를 새로 붙였다면 DNS 레코드만 추가하고 끝내지 말고 해당 도구가 어떤 From·Return-Path·DKIM 도메인을 쓰는지도 봐야 합니다.
‘수락’과 ‘전달’ 사이의 상태를 남긴다
애플리케이션은 메시지마다 업무 이벤트 ID를 만들고, 발송 서비스의 메시지 ID와 연결합니다. 상태는 최소한 생성, 발송 요청 접수, 수신 서버 수락, 일시 실패, 영구 실패, 불만 신고로 나눕니다. 제공업체가 실제 수신함 도착을 보장하지 않는다면 상태 이름을 “전달 완료”처럼 과장하지 않아야 합니다. 메일 열람 추적도 이미지 차단이나 프라이버시 기능 때문에 완전한 증거가 아닙니다. 중요한 결재나 보안 알림이라면 메일 하나만 유일한 통지 수단으로 삼지 말고 앱 내 알림이나 재확인 경로를 둡니다.
일시적인 서버 응답 오류는 제한적으로 재시도할 수 있지만 존재하지 않는 주소나 명시적 수신 거부 같은 영구 실패를 계속 보내면 도메인 평판에 해롭습니다. 반송 유형을 해석해 주소를 억제하고, 고객 관리자가 주소 오류를 수정할 수 있는 경로를 제공하세요. 사용자의 수신 거부와 업무상 필수 통지를 혼동하지 않도록 메일 종류별 정책도 나눕니다. 반복된 반송률과 불만 신고율은 발송량만큼 중요한 운영 지표입니다.
발신 도메인을 하나로만 운영할지 알림 유형별로 분리할지도 검토할 만합니다. 계정 보안 메일과 대량 홍보 메일이 동일한 발신 경로를 공유하면 한쪽의 발송 관행이 다른 쪽에 영향을 줄 수 있습니다. 분리하더라도 도메인을 많이 만드는 것만으로 도달률이 좋아지지는 않습니다. 각 경로의 인증과 발송량, 수신 동의, 주소 품질을 따로 관리해야 합니다. 새 발신 경로를 열 때는 적은 양으로 테스트하고 실패 유형을 관찰한 뒤 확대하는 편이 안전합니다.
테스트와 운영에서 확인할 것
새 도메인을 붙일 때는 여러 수신 사업자의 테스트 계정으로 실제 메시지를 보내 헤더 인증 결과를 확인합니다. 정상 주소뿐 아니라 없는 주소, 임시 오류, 수신 거부도 시험해 반송 이벤트가 우리 시스템에 도착하는지 봅니다. 발송 서비스의 웹훅이 중복 전달될 수 있으므로 메시지 ID와 이벤트 ID로 중복 처리를 막아야 합니다. 또한 메일 본문에 불필요한 개인정보를 넣지 않고, 만료되는 링크와 최소한의 정보만 담는 편이 안전합니다.
메일 장애가 발생하면 “몇 건 발송 요청했는가”보다 “어느 도메인에서 어떤 실패가 늘었는가”를 먼저 확인하세요. DNS 인증 오류, 특정 수신자 도메인의 지연, 주소 품질 문제는 해결책이 다릅니다. 업무 메일은 단순한 문자열 전송이 아니라 고객 여정의 일부입니다. 발송 완료라는 한 줄 로그 대신 인증·반송·고객 조치까지 이어지는 관측 가능한 흐름을 만들 때 비로소 운영할 수 있습니다.
