질문
이메일 시스템이 Zendesk와 제대로 작동하도록 하려면 어떻게 해야 하나요?
답변
Zendesk는 받은 편지함에 스팸이 없도록 최선을 다하지만 고객과 소통하는 데 사용하는 채널을 보호하기 위해 취할 수 있는 특정 조치가 있습니다. 이 문서에서는 이메일 서버의 신뢰 수준을 높이는 방법에 대한 개요를 제공합니다.
이 문서는 다음 섹션으로 구성되어 있습니다.
- Zendesk에 이메일을 보내는 SMTP 서버에 대한 PTR 레코드
- HELO 및 EHLO 안내말 호스트 이름
- SPF 레코드
- DMARC 및 DKIM
- 스크립트 및 웹 양식을 사용하여 이메일 보내기
- Zendesk가 신뢰하지 않는 이메일
Zendesk에 이메일을 보내는 SMTP 서버에 대한 PTR 레코드
Support에 이메일을 보내는 데 사용하는 모든 IP 주소에 포인터(PTR) 레코드가 있는지 확인하세요. PTR 레코드는 해당 IP 주소가 도메인 소유자와 연결되어 있음을 더욱 확실하게 보여줍니다. 예를 들어, IP 주소 1.2.3.4는 domain.com의 누군가가 Support에 이메일을 보내는 경우 mail.domain.com으로 확인되어야 합니다.
이상적으로는 PTR 레코드가 Support에 이메일을 보내는 동일한 도메인에 속해야 합니다. IP 주소가 가정용 ISP에 속해 있음을 나타내는 IP 주소 번호나 키워드를 포함해서는 안 됩니다.
domain.com에 대한 올바른 레코드의 예:
host 1.2.3.4
Host 4.3.2.1.in-addr.arpa. domain name pointer mail.domain.com
누락된 레코드의 예:
host 1.2.3.4
Host 4.3.2.1.in-addr.arpa. not found: 3(NXDOMAIN)
이메일을 보내는 데 사용해서는 안되는 레코드의 예:
host 1.2.3.4
Host 4.3.2.1.in-addr.arpa. domain name pointer 4-3-2-1-cable-subscribers.isp.com
HELO 및 EHLO 안내말 호스트 이름
HELO 이름은 SMTP 서버에서 서로를 안내하는 데 사용됩니다. RFC 5321(§2.3.5)에 따라 확인 가능한 HELO 레코드는 이메일을 보낸 사람의 도메인에 속해야 하며 MX 레코드와 일치해야 합니다. Support는 Support에 이메일을 보내는 SMTP 서버에 확인 가능한 HELO 호스트 이름이 있어야 합니다.
domain.com에 대한 올바른 레코드의 예:
HELO mail.domain.com
낮은 신뢰로 간주되는 HELO 안내말의 예:
HELO mail.otherdomain.com
HELO localhost
HELO 1.2.3.4
HELO invalid.tld
-
HELO not.existing.domain.com
자세한 내용은 SMTP 서버 리턴 코드 목록입니다.
SPF 레코드
Support에 이메일을 보내는 도메인에는 도메인을 대신하여 이메일을 보낼 수 있도록 IP 주소에 권한을 부여하는 유효한 SPF 레코드가 있어야 합니다.
아래에서 다음 상황에 대한 올바른 SPF 레코드의 두 가지 예를 찾으세요.
domain.com
SMTP servers with address 1.2.3.4
MX record mail.domain.com pointing on 1.2.3.4.
두 예 모두 1.2.3.4에서 domain.com을 대신하여 이메일을 보낼 수 있도록 합니다.
domain.com. 3600 IN TXT "v=spf1 mx:domain.com ~all”
domain.com. 3600 IN TXT "v=spf1 ip4:1.2.3.4 ~all”
DMARC 및 DKIM
수신하는 스푸핑된 이메일과 스팸의 수를 줄이려면 SPF, DKIM 및 DMARC 정렬로 보낸 사람 인증을 사용 설정하여 수신 이메일에 보안 계층을 더 추가하세요. 자세한 내용은 다음을 확인하세요. 수신 이메일 인증하기(SPF, DKIM, DMARC).
스크립트 및 웹 양식을 사용하여 이메일 보내기
웹 양식이나 자동화된 스크립트를 사용하여 Support에 이메일을 보내는 것은 권장하지 않으며 현재 지원되지도 않습니다. 이러한 유형의 이메일을 보내고자 하는 고객은 아래에 설명된 규칙을 따라야 합니다.
- 모든 웹 양식을 보낼 때 인증을 요구하거나 CAPTCHA를 사용하거나, 둘 다 사용해야 합니다. Zendesk는 귀사가 허용하면서 조장하는 스팸 공격을 방지할 수 없습니다.
- 웹 양식, 웹 애플리케이션 또는 자동화 스크립트를 사용하여 Support에 이메일을 보낼 때 이메일은RFC 5322에 따라 올바른 형식이어야 합니다.
- 메시지는 올바른 형식의Subject:,From:,To: 및Reply-To:헤더를 포함해야 합니다.
- 보내는 IP 주소에 PTR 레코드가 있어야 합니다(역 DNS 확인).
- 유효한 SPF 레코드를 추가하고, 보내는 도메인 DNS 영역에 게시된 DKIM 키로 이러한 이메일에 서명하고, 이메일 처리 방식을 지정하는 DMARC 정책을 게시하도록 권장합니다.
- HELO 안내말은 확인할 수 있는 유효한 DNS 이름을 가지고 있어야 합니다.
- 데이터 중복을 위해 그리고 일시 중단 가능성을 줄이기 위해 외부 지원 주소를 통해 웹 양식의 모든 이메일을 전달합니다.
- 기본 Zendesk 지원 주소(support@하위 도메인.zendesk.com)로 이메일을 보내는 경우 양식에서 일시적인 네트워크 오류를 처리할 수 있어야 하며,
4xx
제공할 수 있습니다. - MX 중계를 Zendesk의 MX 레코드에 하드코딩하지 마세요. 각 중계기는 MX 조회를 수행해야 합니다.
- 웹 양식에서 제출한 내용에 대해스팸으로 표시기능을 사용하지 마세요. 이는 양식의 보내기 평판에 부정적인 영향을 미칩니다.
- Zendesk 고객 지원팀은 웹 양식의 기능에 대한 지원을 제공하지 않습니다.
Zendesk가 신뢰하지 않는 이메일
Zendesk는 다음을 신뢰하지 않습니다.
- 도메인 소유자의 DNS 영역에 게시된 권한 부여 SPF 레코드 없이 이메일 보낸 사람을 스푸핑하는 이메일입니다.
- 스푸핑된 발신자 주소가 포함된 이메일, 올바르지 않은 DKIM 서명 또는 실패한 SPF 검사*
- 이메일의 보낸 사람 및 수신자 헤더에 올바르지 않거나, 존재하지 않거나, 확인할 수 없는 도메인 이름을 사용하는 이메일입니다.
Support는 누락된 PTR 레코드 또는 잘못된 HELO 안내말이 있는 SMTP 서버를 통해 보낸 이메일에 대해 낮은 신뢰 수준을 행사합니다.
*예를 들어, support@yourdomain.com >> support@subdomain.zendesk.com과 같이 해당 도메인에서 Zendesk 지원 하위 도메인으로 이메일을 전달하는 경우 Zendesk는 전달된 이메일을 감지하려고 시도합니다. Zendesk는 이메일 전달을 감지하는 경우 다른 방법을 사용하여 보내는 SMTP 서버를 인증합니다. 하지만 원래 이메일 본문과 민감한 헤더를 변경하지 않고 DKIM 서명을 보존하도록 전달 SMTP 서버를 구성하세요.
번역 고지 사항: 본 문서는 콘텐츠에 대한 기본적인 이해를 제공하기 위해 자동 번역 소프트웨어를 사용하여 번역되었습니다. 정확한 번역을 제공하고자 합당한 노력을 기울였으나 Zendesk는 번역의 정확성을 보장하지 않습니다.
번역된 문서에 포함된 정보의 정확성과 관련하여 질문이 있으시면 문서의 공식 버전인 영문 버전을 참조하시기 바랍니다.