Support 내에서 이메일 시스템이 작동하도록하기위한 성공 사례는 무엇인가요?

질문

이메일 시스템이 Zendesk와 제대로 작동하는지 확인하려면 어떻게해야하나요?

답변

Zendesk는받은 편지함에서 스팸을 없애기 위해 노력하지만 고객과 대화하기 위해 사용하는 채널을 보호하기 위해 취할 수있는 특정 조치가 있습니다. 이 문서에서는 이메일 서버의 신뢰 수준을 높이는 방법에 대한 개요를 제공합니다.

이 문서는 다음 섹션으로 구성되어 있습니다.

Zendesk에 이메일을 보내는 SMTP 서버에 대한 PTR 레코드
HELO 및 EHLO 안내 말 호스트 이름
SPF 레코드
DMARC 및 DKIM
스크립트 및 웹 양식을 사용하여 이메일 보내기
Zendesk가 신뢰하지 않는 이메일

Zendesk에 이메일을 보내는 SMTP 서버에 대한 PTR 레코드

Support에 이메일을 보내는 데 사용하는 모든 IP 주소에 PTR (포인터) 레코드가 있는지 확인하세요. PTR 레코드는 해당 IP 주소가 도메인 소유자와 연결되어 있음을 더욱 확신시켜줍니다. 예를 들어, domain.com의 누군가가 Support에 이메일을 보내는 경우 IP 주소 1.2.3.4는 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 안내 말 호스트 이름

SMTP 서버는 서로 인사를하기 위해 HELO 이름을 사용합니다. 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
자세한 내용은 Wikipedia의 다음 문서를 참조하세요. 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를 사용해야합니다. 허용하는 동시에 권장하는 스팸 공격을 막을 수는 없습니다.
웹 양식, 웹 애플리케이션 또는 자동화 스크립트를 사용하여 Support에 이메일을 보낼 때 이메일은RFC 5322에 따라 올바른 형식이어야합니다.
메시지는 올바른 형식의제목 :,보낸 사람 :,받는사람: 및답장 : 헤더를포함해야합니다.
보내는 IP 주소에 PTR 레코드가 있어야합니다 (역 DNS 확인).
Support에서는 올바른 SPF 레코드를 추가하고, 보내는 도메인 DNS 영역에 게시 된 DKIM 키로 이러한 이메일에 서명하고, 이메일 처리 방법을 지정하는 DMARC 정책을 게시 할 것을 권장합니다.
HELO 안내 말에는 유효한 확인 가능한 DNS 이름이 있어야합니다.
데이터 중복성을 확보하고 일시 중단 가능성을 줄이기 위해 웹 양식의 모든 이메일을 외부 지원 주소를 통해 전달하세요.
기본 Zendesk 지원 주소 (support@subdomain.zendesk.com)로 보내는 경우 양식에서 일시적인 네트워크 오류를 처리 할 수 있어야합니다. 4xx응답합니다.
어떤 MX 레코드에도 MX 릴레이를 하드 코딩하지 마세요. 각 릴레이는 MX 조회를 수행해야합니다.
웹 양식에서 제출할때 스팸으로 표시기능을 사용하지 마세요. 양식의 전송 평판에 부정적인 영향을 미칩니다.
Zendesk 고객 지원팀은 웹 양식의 기능에 대한 지원을 제공하지 않습니다.

Zendesk가 신뢰하지 않는 이메일

Zendesk는 다음을 신뢰하지 않습니다.

도메인 소유자의 DNS 영역에 권한 부여 SPF 레코드를 게시하지 않고 이메일 보낸 사람을 스푸핑하는 이메일
스푸핑 된 보낸 사람 주소가 있거나, DKIM 서명이 올바르지 않거나, SPF 검사에 실패한 이메일.*
이메일의 보낸 사람 및받는 사람 헤더에 올바르지 않거나, 존재하지 않거나, 확인할 수없는 도메인 이름을 사용하는 이메일.

Support는 PTR 레코드가 없거나 잘못된 HELO 안내 말이 포함 된 SMTP 서버를 통해 전송 된 이메일에 대해 낮은 신뢰도를 나타냅니다.

*도메인에서 Zendesk 지원 하위 도메인 (예 : support@yourdomain.com >> support@subdomain.zendesk.com))으로 이메일을 전달하는 경우 Zendesk가 전달 된 이메일을 감지하려고 시도합니다. Zendesk가 이메일 전달을 감지하는 경우, Zendesk는 발신 SMTP 서버를 인증하는 다른 접근 방식을 취합니다. 하지만 원래 이메일 본문과 민감한 헤더를 변경하지 않고 DKIM 서명을 보존하도록 전달 SMTP 서버를 구성합니다.

번역 고지 사항: 본 문서는 콘텐츠에 대한 기본적인 이해를 제공하기 위해 자동 번역 소프트웨어를 사용하여 번역되었습니다. 정확한 번역을 제공하고자 합당한 노력을 기울였으나 Zendesk는 번역의 정확성을 보장하지 않습니다.

번역된 문서에 포함된 정보의 정확성과 관련하여 질문이 있으시면 문서의 공식 버전인 영문 버전을 참조하시기 바랍니다.

질문

답변