이 가이드를 사용하여 이메일 시스템이 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.4Host 4.3.2.1.in-addr.arpa. domain name pointer mail.domain.com
누락된 레코드의 예:
host 1.2.3.4Host 4.3.2.1.in-addr.arpa. not found: 3(NXDOMAIN)
이메일을 보내는 데 사용해서는 안 되는 레코드의 예:
host 1.2.3.4Host 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.comHELO localhostHELO 1.2.3.4HELO invalid.tld-
HELO not.existing.domain.com
자세한 내용은 다음 Wikipedia 문서를 참조하세요. SMTP 서버 리턴 코드 목록입니다.
권장 사항 3: SPF 레코드
Support 에 이메일을 보내는 도메인에는 도메인을 대신하여 이메일을 보낼 수 있도록 IP 주소에 권한을 부여하는 유효한 SPF 레코드가 있어야 합니다.
아래에서 다음 상황에 대한 올바른 SPF 레코드의 두 가지 예를 찾아보세요.
domain.comSMTP servers with address 1.2.3.4MX 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로 보낸 사람 인증을 사용 설정하여 수신 이메일의 보안을 더욱 강화하세요. 자세한 내용은 수신 이메일 인증하기
권장 사항 5: ARC 헤더 추가하기
Zendesk로 트래픽을 전달하는 계정의 경우에는 전달 서버에 도착했을 때 트래픽의 인증 평가를 통합할 수 있도록ARC 헤더를추가하는 것이 좋습니다.
스크립트 및 웹 양식을 사용하여 이메일을 보내기 위한 성공 사례
웹 양식이나 자동화된 스크립트를 사용하여 Support 에 이메일을 보내는 것은 권장되지 않으며 현재 지원되지도 않습니다. 이러한 유형의 이메일을 보내려는 고객은 아래에 설명된 규칙을 따라야 합니다.
- 모든 전송 웹 양식은 인증을 요구하거나 CAPTCHA를 사용하거나, 둘 다 사용해야 합니다. Zendesk는 귀사가 허용하고 장려하는 스팸 공격을 방지할 수 없습니다.
- 웹 양식, 웹 애플리케이션 또는 자동화 스크립트를 사용하여 Support 에 이메일을 보낼 때 이메일은RFC 5322에 따라 올바른 형식이어야 합니다.
- 메시지에는 올바른 형식의제목:,보낸 사람: ,받는 사람:및답장:헤더가 포함되어야 합니다.
- 보내는 IP 주소에 PTR 레코드가 있어야 합니다(역 DNS 확인).
- 유효한 SPF 레코드를 추가하고, 보내는 도메인 DNS 영역에 게시된 DKIM 키로 이러한 이메일에 서명하고, 이메일 처리 방식을 지정하는 DMARC 정책을 게시하도록 Support 합니다.
- HELO 안내말에는 확인할 수 있는 유효한 DNS 이름이 있어야 합니다.
- 데이터 중복성을 위해 그리고 일시 중단 또는 트래픽 중단 가능성을 줄이기 위해 외부 지원 주소 통해 웹 양식의 모든 이메일을 전달합니다.
- 기본 Zendesk 지원 주소 (support@하위 도메인.zendesk.com)로 보내는 경우 양식에서 일시적인 네트워크 오류를 처리할 수 있어야 합니다.
4xx을 참조하세요. - MX 릴레이를 MX 레코드에 하드코딩하지 마세요. 각 릴레이는 MX 조회를 수행해야 합니다.
- 웹 양식에서 제출한 내용에 대해서는스팸으로 표시기능을 사용하지 마세요. 이는 양식의 전송 평판에 부정적인 영향을 미칩니다.
- Zendesk 고객 Support 웹 양식의 기능에 대한 지원을 제공하지 않습니다.
신뢰할 수 있는 이메일을 보내기 위한 성공 사례
Zendesk는 다음을 신뢰하지 않습니다.
- 도메인 소유자의 DNS 영역에 게시된 권한 부여 SPF 레코드 없이 이메일 보낸 사람을 스푸핑하는 이메일.
- 스푸핑된 발신자 주소, 올바르지 않거나 정렬되지 않은 DKIM 서명 또는 SPF 검사에 실패한 이메일
참고: 도메인에서 Zendesk 지원 하위 도메인(예: support@yourdomain.com)으로 이메일을 전달하는 경우 Zendesk는 전달된 이메일을 감지하려고 시도합니다. >>support@하위 도메인.zendesk.com. Zendesk가 이메일 전달 감지하는 경우 Zendesk는 보내는 SMTP 서버를 인증하기 위한 대체 접근 방식을 취합니다. 하지만 DKIM 서명을 보존하고 원래 이메일 본문과 민감한 헤더를 변경하지 않도록 전달 서버를 구성해 보세요. 실패할 수 있습니다. 또한 가능하면 ARC 헤더를 활용하세요.
- 이메일의 보낸 사람 및 받는 사람 헤더에 올바르지 않거나, 존재하지 않거나, 확인할 수 없는 도메인 이름을 사용하는 이메일은 일시 중단되거나 거부될 가능성이 높습니다.
Support PTR 레코드가 없거나 잘못된 HELO 안내말이 있는 SMTP 서버를 통해 보낸 이메일에 대해 낮은 신뢰 수준을 행사합니다.
번역 고지 사항: 본 문서는 콘텐츠에 대한 기본적인 이해를 제공하기 위해 자동 번역 소프트웨어를 사용하여 번역되었습니다. 정확한 번역을 제공하고자 합당한 노력을 기울였으나 Zendesk는 번역의 정확성을 보장하지 않습니다.
번역된 문서에 포함된 정보의 정확성과 관련하여 질문이 있으시면 문서의 공식 버전인 영문 버전을 참조하시기 바랍니다.