모든 웹사이트는 이메일을 보냅니다. 주문 확인, 비밀번호 재설정, 문의 양식 접수, 예약 알림까지, 웹사이트 트랜잭션 이메일은 미리 계획하는 사람은 거의 없지만 누구나 의존하는 영역입니다. 보통 사이트를 만든 사람이 한 번 설정한 뒤 다시 들여다보지 않습니다.
그러다 고객에게 주문 확인 메일이 도착하지 않기 시작하고, 알고 보니 8개월 동안 스팸함으로 들어가고 있었다는 사실을 뒤늦게 알게 됩니다. 이 글에서는 사용하는 플랫폼과 관계없이 이런 일이 생기는 이유와 이를 막을 수 있는 구성을 설명합니다.
웹사이트 트랜잭션 이메일이 조용히 실패하는 이유
대부분의 플랫폼은 기본 설정에서 프로그래밍 언어가 제공하는 메일 함수를 이용해 웹 서버가 직접 이메일을 보내도록 되어 있습니다. 테스트할 때는 잘 작동합니다. 본인의 받은편지함으로 확인하고 있고, 본인이 이용하는 메일 서비스도 본인을 신뢰하기 때문입니다.
운영 환경에서 실패하는 원인은 코드와 무관합니다. 웹 서버에는 발송 평판이 없고, IP 주소는 호스팅 업체가 운영하는 다른 서비스와 공유됩니다. 게다가 이메일은 도메인이 허용한 적 없는 곳에서 발송되면서도 발신자가 해당 도메인인 것처럼 표시됩니다. 수신 메일 서비스는 바로 이런 패턴을 위조로 판단합니다. 실제로 대부분 위조 메일이 이런 형태이기 때문입니다. Google의 이메일 발신자 가이드라인에서 인증을 요구하는 이유도 여기에 있습니다.
발신자 쪽에서는 실패 여부를 알기 어렵습니다. 사이트에는 이메일을 보냈다고 표시되고 로그에도 오류가 없지만, 수신 측에서 정크 메일로 분류됐다는 징후는 어디에도 남지 않습니다. 웹사이트 트랜잭션 이메일은 작동하지 않는다는 사실을 유독 알아채기 어려워서, 대개 몇 달 뒤 고객의 불만을 받고서야 문제가 드러납니다.
어떤 플랫폼이든 문제는 같습니다
WordPress에서 가장 자주 문제로 지목되기는 하지만, WordPress만의 문제는 아닙니다. 작동 원리는 어디서나 같습니다.
WordPress는 기본적으로 PHP의 메일 함수를 사용합니다. 앞서 설명한 문제가 모두 있는 웹 서버 직접 발송 방식입니다. 이를 SMTP 플러그인으로 대체하는 것이 일반적인 해결책입니다.
Shopify, Wix, Squarespace는 자체 인프라에서 트랜잭션 이메일을 보내며, 이 인프라는 대체로 잘 관리됩니다. 하지만 별도로 설정하지 않으면 적절한 인증을 거쳐 자체 도메인으로 발송하도록 해주지 못하는 경우가 있습니다. 따라서 내 이름으로 발송된 이메일이 실제로 내가 보낸 것인지 확인할 수 없게 됩니다.
Webflow, Ghost, 맞춤형 애플리케이션은 서비스마다 다르지만 기본적인 양상은 같습니다. 기본 발송 방식이 자체 도메인으로 인증되어 있는 경우는 드뭅니다.
어떤 플랫폼에서든 일관된 해결책은 웹사이트 트랜잭션 이메일을 인증된 SMTP 연결로 보내고, 해당 연결에 발송 권한이 있다는 사실을 도메인의 DNS에 명시하는 것입니다.
세 가지를 모두 갖춰야 하는 해결책
필요한 요소는 세 가지이며 모두 갖춰야 합니다. 둘만 설정하면 이메일은 여전히 스팸함으로 들어갈 수 있습니다.
발송에 사용할 SMTP 계정. 웹 서버가 직접 보내는 대신 사이트가 메일 서버에 인증한 뒤 메시지를 넘깁니다. 모든 플랫폼이 자체 기능이나 플러그인을 통해 이 방식을 지원합니다.
발송을 허용하는 DNS 설정. 발송 서버를 지정한 SPF 레코드와 검증 가능한 서명을 메시지에 추가하는 DKIM 서명이 필요합니다. 이 설정이 없으면 인증된 발송도 수신자에게는 권한 없는 발송처럼 보입니다. 실제 레코드 설정 방법은 SPF와 DKIM 가이드에서 확인할 수 있습니다.
실제로 존재하는 발신 주소. 실제 사서함이 없는 noreply@yourdomain.com 주소로 보내는 것은 작지만 분명한 부정적 신호이며, 답장도 사라지게 됩니다. 여기서는 사서함별로 요금을 받지 않으므로 해당 사서함을 만들어도 비용이 들지 않습니다.
일반 업무 메일과 분리하기
발송량이 어느 정도 늘었다면 웹사이트 트랜잭션 이메일에 별도 경로를 사용하는 구성을 권장합니다.
자동 이메일과 사람이 작성한 이메일은 행동 양상이 다르고 평가 방식도 다릅니다. 보안 사고 뒤에 비밀번호 재설정 메일 500건이 한꺼번에 발송되는 모습은 사람이 직접 이메일을 쓰는 것과 전혀 다릅니다. 두 종류의 메일이 같은 경로로 나가면 자동 발송 트래픽의 평판이 업무 메일의 평판에도 그대로 영향을 줍니다.
도메인별 SMTP 프로필을 사용하면 쉽게 분리할 수 있습니다. 애플리케이션의 발신 도메인은 한 경로로, 직원들이 업무 메일을 보내는 도메인은 다른 경로로 지정합니다. 그러면 한쪽의 문제가 다른 쪽으로 번지지 않습니다. 구체적인 설정 방법은 도메인별 맞춤 SMTP에서 확인할 수 있습니다.
자동 이메일에 아예 별도 하위 도메인을 사용해 평판을 완전히 분리하는 기업도 있습니다. 다만 보낸 사람 주소가 조금 덜 깔끔해 보일 수 있습니다. 그만한 가치가 있는지는 발송량에 따라 달라집니다.
트랜잭션 이메일 전문 서비스가 적합한 경우
적용 범위를 솔직히 말하자면, 발송량이 정말 많을 때는 트랜잭션 이메일 전문 서비스가 존재하는 데 그만한 이유가 있습니다.
하루에 수만 건을 발송한다면 메시지별 전송 이벤트, 반송 시 웹훅 콜백, 템플릿 관리, 상세 분석 기능이 필요합니다. 이런 기능이 전문 서비스의 핵심이며, 일반 메일 호스팅이 같은 수준으로 제공하기는 어렵습니다.
저희 일일 한도는 캠페인이 아닌 업무 메일에 맞춰져 있습니다. Starter는 사서함당 하루 1,000건, Agency는 최대 2,500건입니다. 소규모 쇼핑몰이나 예약 시스템의 웹사이트 트랜잭션 이메일은 이 범위에 충분히 들어옵니다. 발송량이 많은 플랫폼에는 맞지 않습니다. 그런 경우에는 맞춤 SMTP 프로필로 트랜잭션 이메일 전문 서비스를 연결하는 것이 올바른 구성입니다. 메일 호스팅과 대량 발송을 분리하면서도 메일 서비스 업체를 두 곳이나 둘 필요는 없습니다.
실제로 작동하는지 확인하기
이 영역은 문제가 생겨도 티가 나지 않으므로, 짐작하지 말고 직접 검증하는 습관이 무엇보다 중요합니다.
테스트 주문을 하거나 비밀번호 재설정을 요청해 실제 이메일을 발생시킨 뒤, 서로 다른 주요 메일 서비스 두 곳의 주소로 보내보세요. 메일 헤더를 열어 SPF와 DKIM이 통과했고 DMARC 정렬도 정상인지 확인합니다. 세 가지를 모두 통과했다면 구성이 제대로 완료된 것입니다.
이 검사를 분기마다 반복하고, 누군가 DNS를 수정하거나 호스팅을 변경한 직후에도 다시 진행하세요. 웹사이트 트랜잭션 이메일은 최초 설정 때보다 주변 환경이 바뀔 때 더 자주 고장납니다. 네임서버를 옮긴 뒤 주문 확인 메일까지 다시 테스트해야 한다고 생각하는 사람은 드물기 때문입니다.
이메일은 도착하지만 스팸함으로 들어간다면, 도메인의 전송 통계와 DMARC 보고서를 확인하는 편이 내용 수정을 짐작으로 시도하는 것보다 원인을 훨씬 빨리 찾을 수 있습니다.
