이 가이드를 사용하여 이메일 시스템이 Zendesk와 원활하게 연동되도록 최적화되어 있는지 확인하세요. 이 문서에 설명된 성공 사례를 따르면 이메일 서버의 신뢰 수준을 높이고 Zendesk 작업 시 문제가 발생할 위험을 최소화할 수 있습니다.

이 문서에는 다음과 같은 설정 권장 사항 및 성공 사례가 포함되어 있습니다.

  • 권장 사항 1: Zendesk에 이메일을 보내는 SMTP 서버에 대한 PTR 레코드 설정
  • 권장 사항 2: HELO 및 EHLO 안내말 호스트 이름 설정
  • 권장 사항 3: SPF 레코드
  • 권장 사항 4: DMARC 및 DKIM
  • 스크립트 및 웹 양식을 사용하여 이메일을 보내기 위한 성공 사례
  • 신뢰할 수 있는 이메일을 보내기 위한 성공 사례

권장 사항 1: 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

권장 사항 2: 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 서버 리턴 코드 목록입니다.

권장 사항 3: 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” 

권장 사항 4: DMARC 및 DKIM

수신하는 스푸핑된 이메일과 스팸의 수를 줄이려면 SPF, DKIM 및 DMARC 맞춤으로 보낸 사람 인증을 사용 설정하여 수신 이메일의 보안을 더욱 강화하세요. 자세한 내용은 수신 이메일 인증하기(SPF, DKIM, DMARC).

스크립트 및 웹 양식을 사용하여 이메일을 보내기 위한 성공 사례

웹 양식이나 자동화된 스크립트를 사용하여 Support에 이메일을 보내는 것은 권장되지 않으며 현재 지원되지도 않습니다. 이러한 유형의 이메일을 보내려는 고객은 아래에 설명된 규칙을 따라야 합니다.

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

신뢰할 수 있는 이메일을 보내기 위한 성공 사례

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

  • 도메인 소유자의 DNS 영역에 게시된 권한 부여 SPF 레코드 없이 이메일 보낸 사람을 스푸핑하는 이메일
  • 스푸핑된 발신자 주소, 올바르지 않은 DKIM 서명 또는 SPF 검사 실패가 포함된 이메일
    참고: 도메인에서 Zendesk 지원 하위 도메인(예: support@yourdomain.com >> support@subdomain.zendesk.com)으로 이메일을 전달하는 경우 Zendesk는 전달된 이메일을 감지하려고 시도합니다. Zendesk가 이메일 전달을 감지하는 경우 Zendesk는 보내는 SMTP 서버를 인증하는 대체 접근 방식을 취합니다. 하지만 원래 이메일 본문과 민감한 헤더를 변경하지 않고 DKIM 서명을 보존하도록 전달 SMTP 서버를 구성하세요.
  • 이메일의 보낸 사람 및 받는 사람 헤더에 올바르지 않거나, 존재하지 않거나, 확인할 수 없는 도메인 이름을 사용하는 이메일

Support는 PTR 레코드가 없거나 잘못된 HELO 안내말이 있는 SMTP 서버를 통해 보낸 이메일에 대해 낮은 신뢰 수준을 행사합니다.

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

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

Zendesk 제공