거래 이메일에 대해 알아야 하지만 물어보지 못한 모든 것

사용자 인증이 있는 모든 애플리케이션은 이메일 없이 존재할 수 없지만 이메일이 항상 주목을 받는 것은 아닙니다. 최신 이메일 서비스 제공업체를 사용하면 사용자를 위한 일류 트랜잭션 이메일 경험을 그 어느 때보다 쉽게 ​​만들 수 있지만 대부분의 경우 자신이 무엇을 모르는지 모른다는 사실이 문제입니다. 웹 애플리케이션의 나머지 부분과 함께 거래 이메일을 최신 상태로 유지하는 데 필요한 모든 것에 대한 종단 간 분석을 자세히 살펴보겠습니다.

거래 이메일과 대량 이메일의 차이점과 이메일 인증을 사용하는 방법과 이유에 대해 설명합니다. 또한 전달 에지 케이스를 우아하게 처리하고, 훌륭한 이메일 콘텐츠를 제작하고, 이메일을 보내고 전달을 모니터링하는 데 필요한 핵심 인프라에 대해 이야기할 것입니다. 그러면 곧 거래 이메일 전문가가 될 수 있습니다.

거래 이메일의 문제점

이메일은 귀하가 얼마나 잘하고 있는지 모니터링하고 이해하기가 더 어렵기 때문에 전통적으로 2급 시민이었습니다. 애플리케이션에는 프론트엔드, 백엔드, 데이터베이스, 오류 등에 대한 통찰력을 제공하는 수많은 성능 모니터링 도구가 있습니다. 이메일의 경우 도구가 덜 알려져 있고 효과적으로 사용하기가 조금 더 어렵습니다. 따라서 이메일 모니터링 및 보고가 직면한 몇 가지 문제를 살펴보고 문제 및 제약 조건 내에서 작동하여 거래 이메일에 대한 정보에 입각한 정보를 제공할 수 있는 사용 가능한 도구와 전술을 살펴보겠습니다.

이메일 모니터링의 가장 큰 근본적인 문제는 모든 수신자의 받은 편지함에 로그인하여 이메일을 받았는지 확인하는 것이 문자 그대로 불가능하다는 것입니다. 따라서 우리가 기대할 수 있는 최상의 통찰력은 단순히 성능에 대한 프록시 또는 추정입니다. 두 번째로 큰 문제는 모든 ISP가 자체 규칙에 따라 작동한다는 것입니다. Outlook에서 스팸으로 분류될 수 있는 항목은 Gmail의 받은편지함으로 바로 이동할 수 있습니다. 그리고 받은 편지함 공급자는 스패머에 의해 즉시 악용될 것이기 때문에 "비밀 소스"를 공유할 수 없습니다. 그렇다면 개발자는 무엇을 해야 할까요?

개방률은 대략적인 근사치를 제공할 수 있지만 쉽게 차단될 수 있는 추적 픽셀에 의존하기 때문에 불완전한 그림입니다. 받은 편지함 요금과 배달 속도도 직접 측정할 수 없습니다. 따라서 테스트할 수 있는 시드 계정으로 정기적인 테스트를 보내는 것으로 해결해야 합니다. 완벽하지는 않지만 다양한 받은 편지함 제공업체에 대한 배달을 이해하는 데 사용할 수 있는 가장 좋은 프록시입니다. 이 가이드의 뒷부분에서 이를 자동화하는 데 도움이 되는 도구를 다룰 것입니다.

DKIM, SPF 및 DMARC 형식으로 도메인 인증을 추가하는 것은 어렵고 혼란스러울 수 있으며, 회사 규모에 따라 DNS 변경에 대한 액세스 또는 승인을 받는 것이 번거롭거나 불가능할 수 있습니다. 그럼에도 불구하고 DNS 항목을 부정확하게 만드는 것은 매우 쉽습니다. 도메인 인증에 익숙하지 않더라도 걱정하지 마세요. 나중에 자세히 다루겠습니다.

물론 일반적으로 훌륭한 전달을 달성할 수 있더라도 반송 처리는 전달에 더 많은 가변성을 가져옵니다. 받는 사람의 받은 편지함이 가득 찼을 수 있습니다. 사람들이 직업을 바꾸고 이메일 주소가 비활성화됩니다. 사람들은 이메일 주소로 오타를 냅니다. 사람들은 그룹 별칭으로 가입한 다음 해당 그룹의 주소 중 하나가 반송될 수 있습니다. 일시적인 서버 또는 DNS 중단은 지정된 도메인의 모든 사람에 대한 배달에 영향을 줄 수 있습니다. 그리고 스팸 신고가 있습니다.

따라서 게이트 바로 바깥쪽에 갑판이 쌓여 있습니다. 에지 케이스가 많고 정확한 배송 상황을 파악하기가 매우 어렵습니다. 지속적인 모니터링은 복잡하고 실수할 여지가 많습니다. 그것은 우울한 그림을 그립니다. 알고 있습니다. 다행스럽게도 이메일은 많은 발전을 이루었고 사소한 일은 아니지만 이러한 모든 문제에 대한 좋은 솔루션이 있습니다.

거래 및 대량 판촉

더 진행하기 전에 대량 홍보 이메일과 애플리케이션의 거래 이메일 간의 중요한 차이점을 해결해야 합니다. 전자를 사용하면 이메일이 분실되거나 지연되더라도 아무도 이메일을 놓치지 않을 것입니다. 그러나 후자의 경우 비밀번호 재설정이 누락되거나 크게 지연되면 추가 지원 요청이 발생할 수 있습니다. 거래 이메일은 애플리케이션의 페이지만큼 중요합니다. 누락되거나 지연된 이메일은 웹 애플리케이션의 깨진 페이지와 대략적으로 동일하다고 생각할 수 있습니다. 이메일은 다른 매체이지만 여전히 애플리케이션 사용 경험의 중심 부분입니다.

사람들은 거래 이메일을 기대하고 받기를 원하기 때문에 대량 홍보 이메일보다 열기 및 클릭률 측면에서 참여도가 더 높습니다. 마찬가지로 거래 이메일은 대량 이메일보다 스팸으로 보고되는 빈도가 훨씬 적습니다. 그리고 이 모든 것이 대량 프로모션 이메일보다 거래 이메일에 대한 더 나은 평판으로 이어집니다. 경우에 따라 받은 편지함과 스팸 폴더의 차이일 수 있습니다. 또는 Gmail이 이메일을 넣는 탭의 문제일 수 있습니다. 그럼에도 불구하고 트랜잭션과 대량의 차이는 Gmail에서도 공식적으로 스트림 분리를 권장할 만큼 충분히 뚜렷합니다. 그렇게 하면 대량 평판이 거래 평판을 떨어뜨리지 않습니다.

이것은 우리에게 첫 번째 팁을 제공합니다.

1. 다른 도메인 또는 하위 도메인을 사용하여 트랜잭션 및 대량 전송 스트림을 분리합니다.

완벽한 세상에서는 기본 도메인을 통해 트랜잭션을 보내고 [email protected] 과 같은 하위 도메인으로 대량을 이관하고 각 범주에도 고유한 IP 주소가 있습니다.

스트림을 분리하는 것은 수신자에게 가능한 최상의 이메일 경험을 위한 토대를 마련하는 첫 번째 단계이며 중요합니다. 받은 편지함으로의 배달을 보장할 수는 없지만 몇 가지 작업을 수행하여 데크를 유리하게 쌓을 수 있습니다. 인증은 정확히 이를 수행하기 위한 다음 단계입니다. 보안 인증서 없이 최신 웹 응용 프로그램을 시작하지 않는 것처럼 전자 메일을 완전히 인증하지 않고 보내고 싶지 않습니다.

이메일 인증

DKIM, SPF 또는 DMARC와 같은 약어를 들어봤을 수 있으며 일부 DNS 항목을 복사하여 붙여넣어 설정했을 수도 있습니다. 또는 너무 복잡하다고 생각되어 건너 뛸 수 있습니다. 어느 쪽이든, 이들은 모두 구현할 가치가 있는 표준이며, 모두 서로를 보완하고 협력하여 평판을 구축하고 보호합니다. 이에 대한 정확한 접근 방식은 공급자마다 다르지만 항상 구현할 가치가 있습니다.

DKIM부터 시작하겠습니다. 기술적인 세부 사항을 너무 많이 다루지 않고 DKIM은 두 가지 작업을 수행합니다. 첫째, 이메일에 일종의 가상 밀랍 봉인 역할을 하여 이메일이 전송 중에 수정되지 않았음을 보여줍니다. 둘째, 도메인 평판을 구축할 수 있습니다. DKIM은 도메인에 초점을 맞추는 반면 SPF는 승인된 IP 주소 목록을 제공하여 수신 메일 서버가 이메일이 합법적인 출처에서 전송되고 있는지 더 잘 알 수 있도록 합니다.

DKIM의 중요한 이점 중 하나는 Gmail의 "통해" 레이블이나 Outlook의 "대신" 레이블을 방지하는 데 핵심적인 역할을 한다는 것입니다. 이러한 요소는 이메일을 스팸으로 보이게 만들고 받는 사람의 신뢰를 훼손할 수 있습니다. 따라서 DKIM은 비하인드 스토리 표준 그 이상입니다. 그것은 받는 사람의 경험에 직접적인 영향을 줄 수 있는 것입니다.

이 모든 것이 다음 기본 팁으로 이어집니다.

2. DKIM 및 SPF로 이메일 인증

인증이 전달을 보장할 수는 없지만, 이는 평판을 구축하고 훌륭한 전달을 보장하기 위해 할 수 있는 모든 일을 하는 핵심 측면입니다.

DMARC는 피싱 공격으로부터 보호하도록 설계되었습니다. DKIM과 SPF를 모두 통합하여 도메인에 대한 전송을 모니터링하고 DMARC 정책을 게시할 수 있도록 하여 도메인 평판을 보호합니다. 이 정책은 이메일이 DMARC 정렬에 실패할 때 받은 편지함 제공자에게 무엇을 해야 하는지 알려줍니다.

DMARC 이전에는 DKIM 및/또는 SPF로 인증되지 않은 이메일을 처리하는 방법을 선택하는 것은 전적으로 받은 편지함 제공자에게 달려 있었지만 DMARC를 사용하면 제공자에게 검역소로 보내도록 지시하는 공개 정책을 만들 수 있습니다. 스팸 폴더) 또는 DMARC 정렬에 실패한 이메일을 거부(완전히 삭제)합니다.

DMARC의 또 다른 이점은 ISP가 도메인을 사용하여 보낸 이메일 소스와 DKIM 또는 반환 경로를 통한 정렬 실패로 전달된 수량에 대한 보고서를 제공할 수 있다는 것입니다. 이를 통해 정렬에 실패한 합법적인 소스를 추적하고 해당 소스가 인증되었는지 확인하기 위한 조치를 취할 수 있습니다. 또한 도메인을 사용하여 전송을 시도하는 불법 이메일의 양을 정량화하는 데 도움이 될 수 있습니다.

PayPal은 좋은 DMARC 정책의 중요성을 보여주는 전형적인 예입니다. 수년에 걸쳐 수많은 사기꾼이 PayPal 이메일을 스푸핑하려고 시도했지만 이제 DMARC를 통해 PayPal은 DMARC를 통과하지 못하는 이메일을 거부하도록 ISP에 알리는 DMARC 정책을 게시했습니다. 따라서 사기꾼이 PayPal 이메일을 스푸핑하려고 하면 DMARC 정렬에 실패하고 ISP는 해당 이메일을 완전히 거부할 수 있습니다. PayPal에는 이메일 정렬에 실패하면 거부되어야 한다는 공개 정책이 있기 때문입니다.

이것은 DMARC에 대한 매우 간단한 개요이지만 세 번째 팁에 대한 컨텍스트를 제공하는 데 도움이 되기를 바랍니다.

3. DMARC 정책 수립 및 발표

또한 가능하면 맞춤 반환 경로를 설정하여 정렬 가능성을 최대화하십시오. 그런 다음 DMARC 보고서를 모니터링하고 합법적인 이메일 소스에 맞게 조정합니다. 마지막으로, 제품 또는 브랜드가 대량의 피싱 공격의 대상이 되는 경우 시간이 지남에 따라 점진적으로 더 공격적인 검역 또는 거부 정책을 단계적으로 시작하십시오.

Postmark의 DMARC 도구는 DMARC 정책을 수립하고 도메인에 대한 주간 보고서를 수신할 수 있는 무료이고 쉬운 방법입니다. 대량 및 트랜잭션 전자 메일 스트림을 분리하고 위에서 언급한 모든 인증을 설정하면 배달의 모든 기본 측면을 처리할 수 있습니다. 이제부터는 애플리케이션 내에서 이메일 처리 및 처리에 중점을 둘 것입니다.

이메일 수명 주기 이해

표면적으로 이메일은 매우 단순하게 들릴 수 있지만 이메일 수명 주기를 세분화하면 표면 아래에 많은 미묘함과 기회가 있습니다. 더 잘 이해할수록 수신자에게 더 미묘하고 풍부한 경험을 제공할 수 있습니다. 이메일 경험을 개선할 수 있는 대부분의 기회는 이메일 전달의 미묘한 차이를 이해하고 그에 따라 처리 및 처리하는 애플리케이션의 기능을 자동화하는 것입니다. 이제 모든 이메일의 주요 사건을 살펴보겠습니다.

대기 중

애플리케이션이 다양한 콘텐츠에서 이메일을 조합하면 배달을 위해 대기열에 추가됩니다. 애플리케이션 내에서 백그라운드 처리를 통해 이메일을 보내고 있는지 확인하고 싶을 것입니다. 이에 대해서는 나중에 자세히 논의할 것이지만 간단한 버전은 애플리케이션이 타사 서비스와 통신할 때마다 백그라운드에서 해당 통신을 처리하기를 원한다는 것입니다. 이메일 서비스 제공업체를 사용하고 있다고 가정하고 해당 API에 요청하면 해당 서비스 제공업체에서도 보내기 위해 대기열에 추가됩니다.

전송 된

다른 서비스와 마찬가지로 이메일 서비스 제공업체에는 이메일을 처리하고 보내기 위한 자체 대기열이 있습니다. 대부분의 경우 이러한 대기열은 매우 빠릅니다. 수천 명의 수신자에게 대량 전자 메일을 보내는 데 몇 초 또는 몇 분이 소요될 수 있지만 대부분의 트랜잭션 전자 메일은 훨씬 빠르게 전송됩니다.

수락됨

이메일 제공업체에서 이메일을 보낸 후 받은 편지함 제공업체에서 이메일을 수락하는 것이 이상적입니다. 그러나 "수락됨"이 "전달됨"을 의미하지는 않습니다. 우체국과 같다고 생각하시면 됩니다. 귀하의 편지가 있기 때문에 배달된 것으로 간주되기 전에 처리해야 합니다. 또한 일부 받은 편지함 공급자는 이메일을 수락하지만 다양한 이유로 궁극적으로 전달하지 않습니다. 따라서 이메일이 수락된 경우에도 결국 전달된다는 보장은 없습니다.

거부됨

일부 받은 편지함 제공업체는 이메일을 조용히 거부하지만 대부분의 경우 이메일이 거부되면 명시적으로 거부되며 이메일 문제에 대한 설명을 받게 됩니다. 경우에 따라 IP나 도메인 평판일 수도 있고 이메일 내용일 수도 있습니다. 불행히도 거절 이유에 대한 명확한 설명을 얻지 못할 수도 있습니다.

바운스

반송은 보다 구체적인 유형의 거부입니다. 이메일 주소가 존재하지 않거나 받은 편지함이 가득 찼거나 다른 이유로 메일 서비스에서 배달이 실패하고 이메일이 반송되었다고 보고합니다. 이러한 경우 ESP의 반송 처리 알림을 사용하여 문제를 해결하기 위한 조치를 사전에 취할 수 있습니다. 우리는 나중에 더 자세히 논의할 것입니다.

배달됨

배달됨은 메시지가 받는 사람에게 제공된 상태입니다. 받은 편지함, 스팸 폴더 또는 Gmail의 탭 중 하나로 전달되었을 수 있지만 어느 정도 전달되었습니다. 이메일이 배달되었다는 명시적인 알림을 받지는 못하지만 이는 수명 주기의 핵심 상태입니다.

열림/클릭

이메일이 언제 열렸는지 확인하는 데 사용되는 방법이 이메일 클라이언트에 의해 차단될 수 있으므로 공개 추적은 완전히 신뢰할 수 없습니다. 공개 추적은 이메일 클라이언트에 의존하여 보이지 않는 이미지를 로드하므로 이미지 로드를 차단하는 클라이언트는 해당 열기가 보고되지 않음을 의미합니다. 공개 요금은 배달을 위한 좋은 대리인 역할을 할 수 있습니다. 예를 들어, 이메일에 대해 아무 것도 변경하지 않고 이메일 서비스 제공업체를 변경하고 개방률이 크게 상승하는 경우 첫 번째 이메일 서비스 제공업체가 메시지의 일부를 전달하지 못했다고 가정하는 것이 안전합니다.

클릭 추적은 공개 추적보다 더 안정적이지만 그 자체로 복잡성이 발생할 수 있습니다. 예를 들어 Bit.ly 또는 기타 URL 단축 서비스를 사용하는 것은 스패머가 사용하는 일반적인 전술이므로 대부분의 경우 Bit.ly URL이 있으면 이메일이 스팸 폴더로 빠르게 이동합니다. 그러나 이메일 서비스 제공업체의 클릭 추적을 통해 잘 수행하면 이메일에 유용한 통찰력을 제공할 수 있습니다. 또한 클라이언트가 공개 추적을 차단하더라도 누군가 이메일을 클릭하면 이메일이 열려 있다고 가정하는 것이 안전합니다. 따라서 클릭 추적은 오픈 요율에 대한 보다 정확한 통찰력을 제공하는 데도 도움이 될 수 있습니다.

공개 및 클릭 추적을 사용하면 개인 정보를 어느 정도 고려하는 것이 중요합니다. 받는 사람의 경험을 풍부하게 하고 이메일을 개선하는 데 사용할 수 있는 통찰력을 제공하는 강력한 도구가 될 수 있지만 개인 정보 보호 문제도 다룹니다. 그들이 제공하는 데이터로 아무 것도 하지 않으려면 사용하지 않는 것이 좋습니다. 또는 개인 정보가 매우 민감한 산업에 종사하는 경우 활성화하기 전에 다시 한 번 생각하고 싶을 것입니다.

구독 취소

구독 취소는 거래 이메일과 관련이 덜하지만 여전히 존중받아야 하는 요청입니다. 거래 이메일 수신 거부를 지원해야 할 법적 의무가 없을 수도 있지만 이는 발생할 수 있는 상태이며 그렇게 할 때 이를 존중해야 합니다.

스팸 신고

구독 취소와 마찬가지로 스팸 불만은 거래 이메일의 경우 덜 자주 발생하지만 여전히 발생합니다. 스팸 신고 비율이 높다면 보내는 거래 이메일의 양 및/또는 품질을 조정해야 한다는 좋은 신호입니다. 반송 처리와 마찬가지로 스팸 신고에 대해서도 사전 예방적 조치를 취해야 합니다. 그들을 존중하고 싶지만 일부 스팸 불만은 우발적이라는 것을 기억하는 것이 중요합니다. 누군가 이메일을 스팸으로 보고하면 향후 청구서나 송장을 받는 데 영향을 미칠 수 있습니다.

이것은 우리에게 네 번째 팁을 제공합니다.

4. 메시지 이벤트를 애플리케이션에 긴밀하게 통합

대부분의 이메일 서비스 제공업체는 각 메시지와 함께 주요 이벤트에 대해 애플리케이션에 자동으로 알리는 광범위한 웹 후크를 제공합니다. 반송 처리는 추적하고 처리해야 하는 가장 중요한 이벤트이지만 다른 이벤트는 애플리케이션을 강화하고 트랜잭션 이메일을 사용자 경험의 더 원활하게 통합된 요소로 만드는 데 유용한 정보를 제공할 수 있습니다.

이메일 콘텐츠 관리

이메일 내용은 전달과 참여 모두에서 중요한 역할을 할 수 있습니다. 일부 규칙(예: "비아그라"라는 단어를 피하는 것과 같은)은 명백할 수 있지만 다른 규칙은 더 미묘합니다. 좋은 콘텐츠를 만드는 데 주의를 기울이면 공개율이나 참여도를 크게 높일 수 있습니다.

훌륭한 거래 이메일을 위한 다섯 번째 팁으로 몇 가지 고려 사항을 그룹화할 것입니다.

5. 이메일의 내용과 구조를 만드는 데 시간을 할애하십시오.

발신자 이름 및 이메일 주소, 제목, 프리헤더 및 MIME 유형과 같은 항목은 참여, 전달 및 공개 비율에 의미 있는 영향을 미칠 수 있습니다. 이러한 요소를 나중에 생각하게 하지 마십시오. 시간을 할애하여 애플리케이션의 다른 페이지인 것처럼 지속적으로 테스트하고 개선하십시오.

발신자, 제목 및 프리헤더

모든 이메일 클라이언트는 다르지만 모두 일종의 미리보기를 통해 이메일을 열기 전에 이메일에 대한 일정 수준의 통찰력을 제공합니다. 보낸 사람과 제목을 표시하는 것처럼 간단할 수 있지만 때로는 콘텐츠 미리 보기도 포함됩니다. 이 주제는 기사 자체를 정당화할 수 있지만 수신자가 원하는 방식으로 이메일을 보는 데 시간을 할애할 가치가 있다고 말하기에 충분합니다. 여기에는 보낸 사람의 이름을 명확하게 지정하고, 유용하고 간결한 제목을 작성하고, 완벽한 프리헤더를 만드는 것이 포함됩니다. 이러한 요소는 오픈율에 상당한 영향을 미칠 수 있으므로 나중에 고려하지 마십시오.

HTML 및 일반 텍스트

이메일의 실제 내용은 중요하며 이메일의 HTML 및 일반 텍스트 버전을 모두 포함하면 수신자에게 큰 영향을 미칠 수 있습니다. 어떤 사람들은 일반 텍스트를 선호합니다. 성능, 개인 정보 보호 또는 접근성 측면에서 형식이 적절하고 고려된 일반 텍스트 옵션을 제공하는 것은 해당 수신자에게 유리합니다. 그리고 일부 스팸 필터는 HTML 버전과 쌍을 이루는 일반 텍스트 버전을 선호합니다. Litmus는 이메일에서 일반 텍스트 옵션의 중요성에 대해 자세히 설명합니다.

답장을 수락하고 "무응답" 주소를 피하세요.

"무응답" 이메일 주소를 사용하지 않도록 할 수 있는 일을 하십시오. 그들은 가능한 모든 방법으로 잘못된 신호를 보냅니다. 결과적으로 사람들이 구독 취소에 답장을 보낼 수 없기 때문에 스팸 신고를 더 많이 받게 됩니다. 이는 단방향 커뮤니케이션이며 전달 가능성을 향상시킬 수 있는 참여를 줄입니다.

이상적으로는 보낸 사람 주소 또는 회신 주소가 모니터링되는 지원 받은 편지함으로 회신을 보낼 것입니다. 이렇게 하면 받는 사람에게 최상의 경험을 제공하고 회신이 혼동되지 않도록 합니다. 그러나 명심해야 할 한 가지 주요 고려 사항이 있습니다. 사용자가 비밀번호 재설정 URL을 수신하고 회신하면 회신에 액세스할 수 있는 모든 사용자가 해당 비밀번호 재설정 URL에도 액세스할 수 있습니다. 특히 민감한 정보도 마찬가지지만 모든 것을 고려하면 매우 민감한 정보를 이메일로 보내고 싶지 않을 것입니다.

또 다른 옵션은 인바운드 수신 이메일 주소를 사용하는 것입니다. 수신자가 이메일에 직접 응답하는 것이 유용한 댓글 알림과 같은 경우 인바운드 이메일 처리를 설정하면 회신 없는 이메일 주소를 피할 수 있습니다.

방법에 관계없이 항상 응답하지 않는 주소를 피하기 위해 최선을 다해야 합니다. 당신의 고객들은 그것을 높이 평가할 것이고 당신이 모든 채널에서 듣는다면 중요한 피드백을 받을 가능성이 훨씬 더 커질 것입니다.

이메일을 조심스럽게 다루십시오

이메일의 내용도 중요하지만 이메일을 어떻게 전달하고 전달과 함께 극단적인 경우에 대응하는가도 마찬가지로 중요할 수 있습니다. 보내는 이메일마다 많은 일이 발생합니다(또는 발생할 수 있음). 대부분의 이메일 대화는 단순히 보내는 데 중점을 두지만 보내는 방법 도 중요할 수 있습니다.

우리는 이 배치를 훌륭한 트랜잭션 이메일 전달을 위한 여섯 번째 상위 레벨 팁으로 그룹화할 것입니다.

6. 이메일을 안정적으로 보내고 전달하기 위한 인프라 투자

이메일을 보내는 것은 간단해 보이지만 몇 줄의 코드를 작성하는 것보다 훨씬 더 많은 것이 있습니다. 이메일에 대해 가능한 최고의 안정성을 보장하려면 백그라운드 처리 및 반송 처리와 같은 적절한 인프라를 구축하고 유지 관리하는 것이 중요합니다.

백그라운드 처리

이메일 서비스 제공업체를 사용하고 있다고 가정하면 모든 이메일 전송이 백그라운드 프로세스를 통해 이루어지도록 하고 싶을 것입니다. 이것은 외부 서비스와의 모든 통신의 경우이며 몇 가지 이유가 있습니다. 무엇보다도 외부 서비스의 경우 항상 다운될 가능성이 있습니다. 따라서 요청이 실패하면 정해진 시간 후에 자동으로 요청을 재시도할 수 있는 것이 중요합니다. 또는 요청에 문제가 있거나 외부 서비스의 일부가 변경되었을 수 있습니다. 이유에 관계없이 이메일 전송에 탄력성을 부여하면 어느 시점에서 슬픔을 덜 수 있습니다.

마찬가지로, 백그라운드 처리 설정을 잘하면 문제가 발생했을 때 쉽게 경고를 받고 문제를 해결할 수 있습니다. 대기열이 많을 때 알림을 설정하면 문제가 있을 때 더 빨리 알 수 있습니다. 또한 백그라운드 처리가 오류를 캡처하고 기록한다고 가정하면 문제의 원인을 훨씬 더 쉽게 식별할 수 있습니다.

전용 IP 이해

거래 이메일을 어느 정도 조사했다면 전용 IP 주소를 사용한다는 개념을 접했을 것입니다. 전용 IP 주소를 사용하면 이점이 있지만 흑백 문제는 아닙니다. 경우에 따라 전용 IP 주소가 도움이 되는 것보다 더 큰 피해를 줄 수 있습니다.

거의 모든 이메일 서비스 제공업체에는 두 가지 전송 옵션이 있습니다. 첫 번째 옵션은 공유 IP 풀에서 보내는 것입니다. 이러한 경우 동일한 IP 주소를 사용하는 다른 발신자의 행동에 의해 귀하의 배달이 영향을 받을 수 있습니다. 이러한 발신자가 사악한 경우 IP 주소의 평판이 떨어질 수 있습니다. 그러나 해당 발신자가 좋은 경우 IP 주소의 평판을 높일 수 있습니다.

두 번째 옵션은 전용 IP 주소입니다. 전용 IP 주소를 사용하면 IP 주소에 평판 문제가 있는 경우 자신에게만 책임이 있습니다. 문제는 전용 IP 주소가 제대로 작동하려면 평판을 구축하고 유지하기에 충분히 높은 일관된 일일 볼륨이 있어야 한다는 것입니다. 하루에 약 10,000-20,000개의 이메일이 있습니다. 또한 일정 기간 동안 지속적으로 지속적으로 더 많은 메일을 보내어 IP 주소를 천천히 워밍업하도록 주의해야 합니다. 그리고 평판을 떨어뜨릴 나쁜 발신자는 없지만 IP 평판을 높이는 데 도움이 될 수 있는 좋은 발신자로부터 어떤 이점도 얻지 못합니다. 대부분의 이메일 서비스 제공업체에서 전용 IP 주소도 비용이 더 많이 듭니다.

마지막으로, IP 평판이 여전히 역할을 하지만 받은 편지함 제공업체는 IP 평판과 함께 도메인 평판을 점점 더 중요하게 생각하고 있습니다. IP 주소가 점점 더 처분될 수 있기 때문에 도메인에 더 많은 평판을 부여하면 새 도메인이 평판을 구축해야 하기 때문에 도메인을 순환하는 스패머를 완화하는 데 도움이 됩니다. 이는 또한 광범위한 배달 문제가 있는 경우 해당 문제가 IP 주소나 도메인에 기인할 수 있음을 의미합니다. 따라서 IP 주소를 바꾸는 것이 도움이 될 수 있지만 도메인 평판이 좋지 않은 경우 IP 주소를 변경해도 도움이 되지 않습니다. 대신 도메인 평판을 정리하는 데 집중해야 합니다.

전용 IP 주소는 적절한 상황에서 훌륭할 수 있지만 슬램덩크는 아닙니다. 또한 공유 IP 주소를 사용하는 경우 다른 발신자가 해당 주소의 평판을 망치거나 블랙리스트에 올리지 않도록 해당 주소를 면밀히 모니터링해야 합니다.

반송 처리

이메일이 반송됩니다. 방법이 없습니다. 바운스가 발생하는 이유는 다양하지만 바운스를 정상적으로 처리해야 하는 필요성은 보편적입니다. 반송 처리를 이메일에 대한 예외 처리로 생각하십시오. 예외가 발생하면 자동으로 삭제되는 것을 원하지 않습니다. 당신은 그것을 고칠 수 있도록 그것이 발생하고 그 원인이 무엇인지 알고 싶어합니다. 한 가지 주의 사항이 있는 바운스 처리도 마찬가지입니다. 반송 처리를 사용하면 사용자가 대부분의 문제를 스스로 해결할 수 있도록 권한을 부여할 수 있습니다. 이는 동시에 고객 만족도를 높이고 지원 요청을 줄입니다.

이메일이 하드 바운스로 반송될 때 가장 중요한 단계는 해당 주소로의 전송 시도를 중지하는 것입니다. 일부 하드 바운스는 결국 자체적으로 다시 작동하기 시작할 수 있지만 동일한 주소로 반복되는 바운스는 받은 편지함 제공자에게 매우 부정적인 신호입니다. 그들의 관점에서 그것은 당신이 당신의 목록을 깨끗하게 유지하지 않고 있고 당신이 스팸 발송자가 될 가능성이 높다는 것을 의미합니다.

유감스럽게도 주소로의 배달 시도를 중지하고 해당 주소가 다시 작동하기 시작하면 수신자는 이메일을 받을 수 없습니다. 이것이 반송 처리가 필요한 곳입니다. 웹훅을 사용하여 이메일 서비스 공급자는 새로운 반송 메시지를 자동으로 알려줄 수 있습니다. 그런 다음 해당 정보를 사용하여 이메일을 전달하는 데 문제가 있다는 경고를 애플리케이션 내에서 표시할 수 있습니다. 이렇게 하면 사용자가 문제를 수정한 다음 전달을 다시 활성화할 수 있습니다.

Postmark는 사용자 정의 및 애플리케이션에 포함할 수 있는 간단한 JavaScript 스니펫인 Rebound를 사용하여 이 작업을 훨씬 더 쉽게 만들어 사용자에게 배달 문제를 사전에 경고하여 더 큰 문제나 지원 요청으로 이어지기 전에 문제를 수정할 수 있습니다.

알림 관리

거래 이메일의 경우 구독 취소는 대량 프로모션 이메일보다 문제가 덜하지만 수신자가 수신하는 거래 이메일의 양이나 유형을 구독 취소하거나 관리할 수 있는 방법을 제공하는 것은 여전히 ​​좋은 일입니다.

보내는 각 유형의 이메일에 대해 한 번의 클릭으로 수신거부를 하면 수신자가 특정 유형의 알림에 대한 이메일 수신을 원하지 않는 경우 편리하게 사용할 수 있습니다. 또는 트랜잭션 전자 메일에 대한 기본 설정 센터를 제공하는 것은 수신자의 손에 더 많은 제어 권한을 부여하는 좋은 방법입니다. 그러나 기본 설정 중심 경로로 이동하는 경우 옵션을 최소한으로 유지하십시오. 체크박스가 많은 페이지는 압도적이거나 혼란스러울 수 있습니다. 따라서 세분화된 제어는 좋지만 너무 많은 옵션은 역효과를 낼 수 있습니다.

빈번한 알림을 줄이는 가장 좋은 방법 중 하나는 인스턴트, 일일 또는 주간 요약과 같은 옵션을 제공하는 것입니다. 그렇게 하면 수신자에게 알림에 대한 상당한 제어 권한을 부여하여 수십 가지 다양한 유형의 알림에 대한 세분화된 제어를 통해 사용자를 압도하지 않고 양을 크게 줄일 수 있습니다.

방법에 관계없이 알림 빈도를 제어하면 고객에게 큰 도움이 되는 동시에 전체 이메일 양을 줄이는 데 도움이 될 수 있습니다. 고객과 이메일 비용 모두에게 윈-윈(win-win)입니다.

도구 및 모니터링

애플리케이션 개발의 다른 측면이 도구, 모범 사례 및 안정성에서 인상적인 발전을 이루었지만 이메일은 여전히 ​​어느 정도 블랙박스입니다. 애플리케이션을 사용하면 가동 시간, 페이지 로드 시간, 애플리케이션 성능 및 기타 수많은 측면을 모니터링할 수 있습니다. 그러나 이메일 받은 편지함은 비공개이므로 실제 배달 정보를 정확하게 측정할 수 있는 방법이 없습니다. 열기 및 클릭률은 적절한 프록시 역할을 할 수 있지만 여전히 프록시일 뿐입니다. 다행히도 서로를 보완하고 함께 이메일 전송에 대한 비교적 명확한 그림을 제공할 수 있는 몇 가지 훌륭한 도구가 있습니다.

이것이 일곱 번째이자 마지막 팁을 이해하는 데 중요합니다.

7. 사용 가능한 도구를 사용하여 전달을 모니터링하고 개선합니다.

애플리케이션의 가동 시간이나 성능을 모니터링하는 것처럼 이메일 전달을 모니터링하는 것도 똑같이 중요합니다. 하나의 도구가 모든 것을 말해 줄 수는 없지만 훌륭한 도구의 조합은 신뢰할 수 있는 이메일 전송을 보장하고 그렇지 않은 경우 문제를 해결하는 데 큰 차이를 만들 수 있습니다.

적용 범위를 넓히려면 다음 도구를 사용하고 시간이 지남에 따라 패턴에 세심한 주의를 기울여야 합니다.

1. 이메일의 열기 및 클릭률 추세를 모니터링합니다. 프록시일 뿐이지만 상대적인 역사적 수치에 좋습니다. 예를 들어 시간이 지남에 따라 열기 또는 클릭률이 급격히 떨어지는 것을 발견하면 이는 종종 배달 문제가 발생할 수 있다는 조기 경고 신호입니다. 이메일이 제대로 전달되지 않으면 열 수 없기 때문에 전달 문제로 인해 오픈율이 감소할 수 있습니다.
2. Gmail은 IP 및 도메인 평판을 측정하여 전송 문제가 있을 수 있는 이메일 소스를 이해하는 데 도움이 되는 Postmaster 도구를 제공합니다. 이것은 배달 문제가 있을 수 있다고 의심될 때 사용할 수 있는 훌륭한 포렌식 도구입니다. Gmail의 통찰력만 제공하지만 다른 제공업체에도 귀하의 평판이 어떻게 보일지 이해하는 데 충분한 프록시가 되는 경우가 많습니다.
3. MXToolBox 블랙리스트 확인을 사용하여 도메인 또는 IP 주소가 블랙리스트에 있는지 확인하십시오. 공유 IP 주소를 사용하는 경우 해당 공유 IP 주소에 대한 영구적이고 자동 모니터를 설정하여 블랙리스트에 오르는 경우 더 빨리 알 수 있습니다.
4. GlockApps 또는 250ok와 같은 도구를 사용하여 이메일의 받은 편지함 배치를 모니터링합니다. 이러한 도구는 전달을 테스트하기 위해 시드 목록에 의존한다는 점을 명심하는 것이 중요합니다. 즉, 실제 받는 사람의 받은 편지함에 배달을 테스트할 수 없으므로 테스트 주소를 프록시로 사용해야 합니다. 대부분의 이메일 전송 도구와 마찬가지로 이것은 완벽한 과학은 아니지만 실제로는 전송 품질을 측정하는 데 여전히 매우 유용할 만큼 가깝습니다.

모니터링 및 경고가 많을수록 문제를 더 빨리 파악하고 수정할 수 있습니다. 종종 불량한 이메일 전달은 지원 요청이 나타나기 시작할 때만 표면화되는 보이지 않는 문제가 될 수 있지만 그때쯤에는 이미 100개 또는 1,000개의 이메일이 스팸 폴더에 있거나 전혀 도착하지 않았을 수 있습니다. 고객이 애플리케이션 다운타임에 대해 경고하는 것을 원하지 않는 것처럼 잠재적인 배달 문제에 대해 가장 먼저 경고하는 것도 고객이 원하지 않습니다.

모두 함께 가져오세요

이메일을 보낼 때 많은 옵션이 있습니다. 서버와 메일 전송 에이전트(MTA)를 설정하고 원하는 경우 직접 보낼 수도 있지만 많은 책임과 오버헤드가 발생합니다. 평판 관리가 어렵습니다. ISP와 관계를 구축하는 것은 훨씬 더 어렵습니다.

이메일을 보내는 것이 핵심 서비스가 아니라면 이메일 서비스 제공업체에 문의하는 것이 좋습니다. 그럼에도 불구하고 훌륭한 전달이 예측할 수 있는 결론이 될 수 없다는 점을 인식하는 것이 중요합니다. 모든 ESP가 뛰어난 전달력을 제공한다고 주장하지만 항상 그런 것은 아닙니다. In most cases, when you're evaluating ESP's, you'll be much better off if you use the tools mentioned above to get quantifiable delivery information for yourself rather than taking their word for it. This is true whether you use a shared IP address or a dedicated IP address. Great delivery isn't automatic, and you should always be gathering hard data on your delivery.

Regardless of how you handle email, make sure to treat it as an extension of your application's user experience rather than an afterthought. Take time to write concise and helpful emails, and do everything possible to seamlessly integrate it into the user experience. Be judicious about firing off too many emails, and give your users the ability to tune email notifications for their needs.

Finally, monitor your transactional email delivery like you would any other service in your stack. If your users aren't receiving critical emails like password resets and invoices, you'll be losing goodwill, and your support costs will increase. Don't let your email delivery fail quietly. Make sure that you're notified quickly and loudly of any potential delivery issues long before it gets bad enough for your customers to email you.

Your application can't work without email. While it's not as easy to measure or monitor as most aspects of your application, it's still a critical piece of functionality that deserves your full attention. Invest the time in making your email experience great, and you'll unquestionably reap the rewards.