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

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

권장 사항 1: Zendesk에 이메일을 보내는 SMTP 서버에 대한 PTR 레코드 설정

Support에 이메일을 보내는 데 사용하는 모든 IP 주소에 포인터(PTR) 레코드가 있는지 확인하세요. 공개 테스트 서버 레코드는 해당 IP 주소가 도메인 소유자와 연결되어 있음을 더욱 확실하게 보여줍니다. 예를 들어 IP 주소 1.2.3.4는 domain.com의 누군가가 Support에 이메일을 보낸 경우 mail.domain.com으로 확인되어야 합니다.

PTR 레코드는 Support에 이메일을 보내는 도메인과 동일한 도메인에 속해야 합니다. IP 주소 번호나 IP 주소가 주택용 ISP에 속해 있음을 나타내는 키워드를 포함해서는 안 됩니다.

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에 이메일을 보내는 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 서버 리턴 코드 목록을 참조하세요.

권장 사항 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: SPF, DKIM, DMARC 및 ARC

수신할 수 있는 스푸핑된 이메일 및 스팸 수를 줄이려면 SPF, DKIM, DMARC 및 ARC로 보낸 사람 인증을 사용 설정하여 수신 이메일에 대한 보안을 한층 더 강화하세요. 자세한 내용은 수신 이메일 인증하기(SPF, DKIM, DMARC 및 ARC)를 참조하세요.

권장 사항 5: ARC 헤더 추가하기

Zendesk에 트래픽을 전달하는 계정의 경우에는 트래픽이 전달 서버에 도착했을 때 트래픽의 인증 평가를 통합할 수 있도록 ARC 헤더를 추가하는 것이 좋습니다.

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

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

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

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

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

  • 도메인 소유자의 DNS 영역에 게시되는 권한 부여 SPF 레코드 없이 이메일 보낸 사람을 스푸핑하는 이메일

  • 스푸핑된 발신자 주소, 올바르지 않거나 일치하지 않는 DKIM 서명, 또는 SPF 검사 실패가 포함된 이메일

    참고: 회사 도메인에서 Zendesk Support 하위 도메인(예: Support@yourdomain.com)으로 이메일을 전달하고 있다면 Zendesk는 전달된 이메일을 감지하려고 시도합니다.>> Support@yoursubdomain .zendesk.com. Zendesk가 이메일 전달 감지하는 경우에는 Zendesk는 발신 SMTP 서버를 인증하기 위한 다른 접근 방식을 사용합니다. 하지만 실패의 원인이 될 수 있으므로 원래 이메일 본문과 민감한 헤더를 변경하지 않고 DKIM 서명을 보존하도록 전달 서버를 구성하려고 시도합니다. 또한 가능하면 ARC 헤더를 활용하세요.
  • 이메일의 보낸 사람 및 수신자 헤더에 올바르지 않거나, 존재하지 않거나, 확인할 수 없는 도메인 이름을 사용하는 이메일은 일시 중단되거나 거부될 가능성이 높습니다.

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

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

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

Zendesk 제공