Zendesk가 이메일 도메인을 대신해서 이메일을 보내도록 허용하기

모든 Suite 플랜에서 사용 가능 모든 Support 플랜에서 사용 가능

자신의 이메일 주소를 사용하여 지원 요청을 받고자 하며, Zendesk에서 자신의 이메일 주소를 지원 주소로 추가한 경우에는 사용자 지정 이메일 도메인을 설정하여 Zendesk가 해당 이메일 서버를 대신하여 이메일을 보낼 수 있는지 확인할 수 있습니다.

예를 들어 고객의 이메일을 help@acme.com에서 받고, 여기서 받는 모든 이메일을 Support로 전달하도록 자동 리디렉션을 설정해 놓은 경우에는 마치 회사 자체 이메일 주소(예: help@acme.com)에서 보낸 것처럼 Zendesk가 알림을 보낼 수 있도록 권한을 부여할 수 있습니다. 이로써 전체 프로세스에서 회사 브랜딩을 유지할 수 있습니다.

꼭 이런 식으로 이메일 도메인을 구성할 필요는 없지만 자체 사용자 지정 이메일 도메인을 사용하면서 외부 이메일 주소로 전달을 설정해 놓은 경우에는 이렇게 구성하는 것이 좋습니다. @gmail.com 또는 @yahoo.com으로 끝나는 주소와 같이 사용자 지정 도메인이 아닌 도메인을 사용하는 경우에는 계정 DNS 설정에 액세스할 수 없게 되므로 이 기능을 사용할 수 없습니다.

참고: Gmail용 Zendesk 커넥터를 사용하여 이메일을 보내는 경우에는 Zendesk가 대신 이메일을 보낼 수 있도록 SPF 레코드를 설정하는 것이 좋습니다(Gmail 받은편지함의 자동 티켓 만들기 사용 설정하기 참조).

이 문서에서 다루는 주제는 다음과 같습니다.

이 구성의 장점
도메인의 레코드 설정하기
도메인 확인하기
SPF 검사 이해하기

이 구성의 장점

참고: 이 구성을 사용하려면 진행하기 전에 Zendesk에서 이메일 주소를 지원 주소로 추가해야 합니다.

그렇다면 Zendesk가 회사 이메일 도메인을 대신해서 이메일을 보내도록 허용해야 할까요? 짧게 대답한다면 아닙니다. 하지만 좀 길게 대답한다면 다음과 같이 말할 것입니다. 고객이 메시지에서 Zendesk 이름을 보는 것을 정말 원하지 않는 경우에만 그렇게 하세요.

Zendesk가 회사 이메일 주소를 사용하여 이메일 메시지를 보내면(전달 기능으로 지원 주소를 설정한 경우) 메시지가 거부되는 것을 피하기 위해 보낸 사람을 zendesk.com으로 식별합니다. 하지만 Zendesk가 회사 이메일 도메인을 대신하여 이메일을 보낼 수 있도록 허용한 경우에는 Zendesk가 더 이상 zendesk.com에서 메시지를 보내지 않고 회사 브랜딩을 전적으로 유지하면서 회사 도메인에서 메시지를 보냅니다.

이 문서에 설명된 작업을 완료하지 않으면 고객에게 다음과 같이 표시될 수 있습니다.

또한 상담사 인터페이스에서 외부 지원 주소 옆에 다음과 같은 경고가 나타날 것입니다.

하지만 이 문서에 설명된 작업을 완료하면 다음을 통해: 문과 경고가 나타나지 않습니다.

도메인의 레코드 설정하기

참고: 도메인의 레코드를 설정하는 일은 대부분의 사람들이 좀처럼 하지 않는 작업이므로 혼동될 수 있습니다. 계속 진행하기 전에 시스템 관리자와 상의하시기 바랍니다.

도메인 등록 기관에 따라 SPF 레코드를 설정하는 프로세스가 다릅니다. 예를 들어 GoDaddy, Namecheap, 1&1, Network Solutions 및 Google Domains에서 제공하는 안내를 참조하세요.

Zendesk를 참조하도록 SPF 레코드를 만들거나 편집하려면 다음과 같이 하세요.

도메인의 DNS 설정을 편집하여 TXT 레코드를 추가합니다. 도메인 등록 기관에 따라 단계가 다릅니다. SPF 레코드의 유효성이 검증될 수 있도록 TXT 레코드가 필요합니다.

Zendesk는 다음 SPF 레코드를 사용할 것을 권합니다.

v=spf1 include:mail.zendesk.com -all

다음 사항을 참고하세요.

include:mail.zendesk.com을 사용하는 경우에는 첫 번째 레이어 조회에 있어야 합니다.
SPF 매크로가 지원됩니다.
redirect: 구문이 지원됩니다.
레코드 플래트닝 서비스가 작동하지만 이 방법은 include:, redirect: 또는 매크로 구문보다 덜 안정적일 수 있습니다.

참고: 선택하는 SPF 메커니즘은 도메인 관리자에게 달려 있지만 이메일 스푸핑에 대해 가장 강력한 보안을 제공하는 하드 페일 SPF 메커니즘(-all)을 활용하는 것이 좋습니다. 올바르지 않은 SPF 레코드로 인해 확인이 실패할 수 있습니다. Zendesk는 DNS 또는 보안 레코드 및 정책 관리에 도움을 줄 수 없으므로 해당 도메인 제공업체의 지원을 받으세요.

다른 용도로 이미 SPF 레코드를 설정해 놓은 경우에는 Zendesk에 대한 참조를 추가하세요. SPF 명세에 따라 도메인에 하나의 SPF 레코드만 있어야 합니다. 레코드가 여러 개 있으면 문제가 생겨 이메일이 거부될 수도 있습니다.

예를 들어 v=spf1 include:_spf.google.com -all 및 v=spf1 include:mail.zendesk.com -all, 이렇게 두 개의 별도 레코드를 사용하는 대신 다음과 같이 하나로 결합하세요.

v=spf1 include:_spf.google.com include:mail.zendesk.com -all

과거에는 Zendesk에서 include:smtp.zendesk.com 및 include:support.zendesk.com을 포함한 SPF 레코드의 대체 형식을 제안했지만 이 두 가지 모두 오래된 SPF 레코드입니다. 여전히 사용할 수는 있지만 최선의 옵션은 아닙니다. 아직 사용하고 있다면 오래된 레코드를 설정했다는 경고 플래그가 나타날 것입니다.

팁: 고객의 이메일 클라이언트에서 이메일을 차단하는 것을 방지하기 위해 Zendesk에서 보내는 발신 이메일을 디지털 서명하도록 추가 업데이트 작업을 하는 것을 고려하세요. 이메일을 디지털 서명하면 해당 조직을 가장하는 사람이 아닌 진짜 그 조직에서 이메일을 보낸 것임을 증명해 줍니다. 자세한 안내는 DKIM 또는 DMARC로 이메일 디지털 서명하기를 참조하세요.

레거시 DNS 입력 항목 제거하기

이전에는 Zendesk에서 아래 4개의 cname 레코드(별칭)를 추가하도록 권장했습니다. 이제 이러한 레거시 DNS 입력 항목을 제거할 것을 권장합니다. 어떤 해를 끼치는 것은 아니지만 기능을 수행하지 않는 레코드는 제거하는 것이 좋습니다.

zendesk1.yourdomain.com >> mail1.zendesk.com
zendesk2.yourdomain.com >> mail2.zendesk.com
zendesk3.yourdomain.com >> mail3.zendesk.com
zendesk4.yourdomain.com >> mail4.zendesk.com

참고: 이러한 cname 레코드는 DKIM 레코드와 다릅니다. 실수로 DKIM 레코드를 제거하는 일이 없도록 하세요. 레코드가 위에 표시된 것과 일치하는 경우에만 조치를 취하세요.

도메인 확인하기

참고: 현재로서는 이 섹션에 설명된 작업을 반드시 수행하지 않아도 되지만 Zendesk Support에 계획된 향상 기능의 일부로 장차 필요하므로 지금 수행하는 것이 좋습니다.

Zendesk Support에서 회사를 대신하여 이메일을 보내려면 Support에서 사용할 도메인을 회사에서 진짜 소유하고 있는지 확인해야 합니다. DNS 서버에 Support가 검사할 TXT 레코드(도메인 확인 레코드)를 추가하면 됩니다. 도메인 확인 레코드는 각 Support 계정 및 도메인 조합마다 고유합니다.

도메인 확인 레코드를 추가하지 않으면 Support가 Zendesk가 제공한 이메일 주소에서 이메일을 보냅니다. 모든 Zendesk 브랜딩을 숨겨 고객에게 화이트 레이블 경험을 제공하려면 이 레코드를 추가해야 합니다.

도메인이 회사에 속한 것이 맞다고 확인하려면 다음과 같이 하세요.

반드시 SPF 레코드 설정을 마치세요.
관리 센터의 사이드바에서 채널을 클릭한 다음 Talk 및 이메일 > 이메일을 선택합니다.
DNS 레코드에 대한 확인 검사가 보입니다.
자세히 보기를 클릭하여 도메인 확인 값을 봅니다.
도메인 확인 TXT 레코드 검사 옆에서 값을 찾을 수 있습니다. 이 예에서는 값이 abcdef123456입니다.

참고: 지원 주소를 관리할 수 있는 권한이 있는 상담사는 지원 주소 API 엔드포인트를 사용하여 원하는 경우 대신 지원 주소의 도메인 확인 값을 찾을 수 있습니다. domain_verification_code 값을 찾아 보세요. 자세한 내용은 지원 주소에 대한 개발자 문서를 참조하세요.
도메인의 DNS 설정을 편집하여 이 TXT 레코드를 추가합니다.

유형 이름 값 TTL

TXT zendeskverification <Support에서 찾은 회사의 고유 값> 3600 또는 기본값 사용

참고: 도메인이 zendeskverification에 자동으로 첨부됩니다. 도메인이 두 개 이상의 Zendesk 계정에서 사용되는 경우에는 TXT 레코드에는 최대 255자의 띄어쓰기로 구분된 모든 확인 코드가 포함될 수 있습니다.
TXT 레코드를 추가한 후 DNS 레코드 확인 버튼을 클릭하여 레코드가 이제 올바르다는 사실을 확인합니다. 도메인 확인 레코드는 현재 사용 중이 아니며 보내거나 받는 동작에 영향을 미치지 않습니다.
레코드가 올바르면 빨간색 오류 메시지가 사라집니다. DNS 레코드를 올바르게 설정하는 데 문제를 겪고 있다면 DNS 레코드를 확인할 때 “DNS 레코드가 올바르게 설정되어 있지 않음” 오류가 표시되는 이유를 참조하세요.

유형	이름	값	TTL
TXT	zendeskverification	<Support에서 찾은 회사의 고유 값>	3600 또는 기본값 사용

도메인이 확인된 후 도메인 확인 레코드를 그대로 남겨 두세요.

나중에 Support 하위 도메인이나 호스트 맵핑을 변경하기로 결정하는 경우 도메인 확인 레코드를 업데이트할 필요가 없습니다.

SPF 검사 이해하기

SPF(Sender Policy Framework)는 도메인 수준 이메일 권한 부여 프로토콜로 어떤 IP 주소가 회사 도메인에서 보낸 것처럼 이메일을 보내도록 허용되는지 선언할 수 있습니다.

DNS(Domain Name System), TXT 레코드를 추가하여 그렇게 할 수 있습니다. DNS를 인터넷의 공개적으로 액세스 가능한 레코드로 생각하세요. 이 레코드를 통해 Zendesk가 회사 도메인에 대한 이메일을 보낼 수 있도록 권한을 부여받았음을 공개적으로 나타낼 수 있습니다.

이메일 클라이언트가 메시지를 받으면 보내는 도메인에서 SPF 검사를 수행하여 해당 도메인에서 온 이메일이 맞는지 확인합니다. 이 검사가 실패하거나 Zendesk가 이메일을 보낼 수 있도록 허가받았음을 나타내는 DNS 레코드가 없으면 스팸이나 피싱 시도로 간주하여 신뢰할 수 없다고 플래그를 지정하거나 고객에게 아예 표시하지 않을 수도 있습니다.

Zendesk가 회사 도메인을 사용하도록 권한을 부여받지 않은 경우에는 Zendesk의 자체 도메인을 사용하여 이메일을 보내거나, 적절한 SPF 레코드로 Zendesk에 권한을 부여하는 경우에만 회사 도메인을 사용함으로써 그런 문제를 방지합니다. 일반적으로 이는 Zendesk 계정에서 고객에게 보내는 이메일이 스팸으로 잘 못 표시되지 않도록 하는 데 도움이 됩니다. 하지만 이 문제를 겪고 있다면 어떻게 하면 이메일이 고객의 스팸 편지함으로 가지 않게 할 수 있나요? 문서를 참조하세요.

www.openspf.org에서 SPF에 대해 자세히 알아볼 수 있습니다. SPF 레코드를 확인하는 데 문제가 있으면 SPF 레코드가 확인되지 않는 이유가 무엇인가요? 문서를 참조하세요.