Email Delivery FAQ

개요
FAQ

FAQ 주제

공통 질문
이메일 전송
전달성
상용

일반적인 질문

Email Delivery란 무엇입니까?

Oracle Cloud Infrastructure Email Delivery는 대용량 이메일이 사용자의 받은 편지함에 잘 도착할 수 있도록 빠르고 안정적으로 관리해주는 이메일 전송 서비스입니다. Email Delivery는 고객에게 수신 확인, 사기 감지 알림, 다단계 ID 검증 및 암호 재설정과 같은 미션크리티컬 커뮤니케이션을 위한 애플리케이션 생성 이메일을 빠르고 안정적으로 전송하는 데 필요한 도구를 제공합니다. Email Delivery는 확장성이 뛰어나고 비용 효율적이며 안정적인 인프라 서비스로, 사내 이메일 전송 솔루션을 구축하는 과정에서 발생하는 복잡성과 비용을 해소해줍니다.

Email Delivery의 사용 대상은 어떻게 됩니까?

이메일이 포함된 모든 클라우드 기반 애플리케이션에서 Email Delivery를 활용해야 하며,
사용자의 받은 편지함에 도달할 메시지를 비용 효율적인 방식으로 전송하려는 모든 기업은 Email Delivery를 사용해야 합니다.

Email Delivery가 필요한 이유는 무엇입니까?

이메일은 기업이 고객과 커뮤니케이션할 수 있는 가장 직접적인 수단이므로 기업에서 전송하는 이메일이 사용자의 받은 편지함에 도달하는 것이 무엇보다 중요합니다. 자동화된 아웃바운드 이메일 수와 빈도가 증가함에 따라, 여러 스팸 필터링 시스템으로 인해 메시지가 고객의 받은 편지함에 도달하기가 점점 어려워지고 있습니다.
Email Delivery는 이메일 전송에 따른 구성, 인프라, 보안 및 인증 문제를 해결하는 개발자 친화적인 서비스입니다.

Email Delivery를 사용하여 어떤 종류의 이메일을 전송할 수 있습니까?

Email Delivery는 수신 확인, 사기 감지 알림, 다단계 ID 검증 및 암호 재설정과 같은 트랜잭션 애플리케이션 생성 이메일에 가장 적합하지만 산업 규정 및 법률을 준수하는 다른 모든 이메일도 전송할 수 있습니다.

Email Delivery는 Eloqua 및 Responsys와 같은 프런트 엔드 공급자입니까?

Email Delivery는 Eloqua 또는 Responsys와 같은 프런트 엔드 공급자와 통합할 수 있는 백엔드 인프라입니다. Email Delivery는 사용자에게 HTML 캠페인을 개발하거나 수신자 목록을 관리할 수 있는 기능을 제공하지 않습니다.

Email Delivery는 Amazon SES 또는 SendGrid와 동일합니까?

예, Email Delivery 서비스는 Amazon SES 또는 SendGrid와 유사한 서비스입니다.

Email Delivery를 사용하여 이메일을 전송하려면 어떻게 해야 합니까?

API 또는 Oracle Cloud Infrastructure 콘솔에서 아래 단계에 따라 이메일을 전송하세요.

Email Delivery를 구성하고 사용하는 방법에 대한 자세한 지침은 여기를 참고하세요.

1. Oracle Cloud Infrastructure 콘솔에서 SMTP 자격 증명을 생성할 사용자를 찾습니다. 사용자가 승인된 발신자를 관리하는 정책(예: MyGroup 그룹이 MyCompartment 구획에서 승인된 발신자를 사용하도록 허용)이 있는 그룹에 포함되어 있는지 확인합니다.

2. 새 사용자 설정 왼쪽에 있는 SMTP 인증서를 선택한 다음 SMTP 인증서를 생성합니다.

3. Oracle Cloud Infrastructure 콘솔에서 이메일을 선택합니다. 올바른 구획을 선택했는지 확인합니다. 사용자가 이 구획에서 승인된 발신자를 관리할 수 있는 권한이 있는 그룹에 포함되어 있어야 합니다.

4. 지정된 구획 내에 승인된 발신자를 하나 이상 생성합니다. 발신자는 이메일의 '발신자'란에 표시되는 이메일 주소입니다. 승인된 발신자는 해당 지역에 따라 다릅니다. 피닉스에서 승인된 발신자를 생성하면 애슈번을 통해 메일을 전송할 수 없습니다.

5. 지침에 따라 해당 도메인 아래에 TXT 레코드를 추가하여 SPF(발신자 정책 프레임워크)에 대한 DNS를 구성합니다.

6. Email Delivery를 통해 시스템에서 SMTP 연결을 설정하고 테스트합니다. Postfix와 SendMail이 가장 많이 사용되는 SMTP 제품이지만 다른 SMTP 라이브러리를 사용할 수도 있습니다.

Email Delivery를 지원하는 지역은 어디입니까

이메일 딜리버리는 모든 OCI 지역 및 영역에서 제공됩니다. 전체 목록은 지역 및 가용성 도메인을 참조하세요.

참고: 메일을 전송하는 애플리케이션은 메일이 전송되는 지역에 있지 않아도 되지만 더 나은 성능을 위해 전송 애플리케이션과 동일한 지역에서 이메일을 구성하는 것이 바람직합니다.

승인된 발신자를 추가하려고 할 때 오류가 발생하는 이유는 무엇입니까?

선택한 구획에서 승인된 발신자를 관리할 수 있는 권한이 있는지 확인하세요. (정책 기본 사항)
승인된 발신자 수 한도에 도달했을 수 있습니다. My Oracle Support를 사용하여 필요에 따라 이메일 전송 한도 증가를 위한 서비스 요청을 제출할 수 있습니다.
계정이 일시 중단되어 승인된 발신자 제한이 0으로 줄었을 수 있습니다.

이메일 전송

승인된 발신자란 무엇입니까?

승인된 발신자는 Email Delivery에서 일치하는 주소로 이메일을 전송하도록 해주는 리소스입니다. 승인된 발신자는 구획과 연결되어 있으며 구성된 지역에만 존재합니다.

Email Delivery를 사용하여 대량 이메일을 전송할 수 있습니까?

예. Oracle Email Delivery를 사용하여 대량 이메일을 프로그래밍 방식으로 전송할 수 있습니다.

참고 - GA에서는 보고 기능을 사용할 수 없습니다.

SMTP에 TLS가 필요합니까?

Oracle은 엄격한 보안 정책을 시행하고 있으며 Email Delivery 역시 해당 정책을 준수합니다. 따라서 고객이 TLS를 통해 전송한 이메일만 수락합니다.
TLS(TLS은 필수임)
이전 버전은 보안 수준이 낮으므로 TLS 버전 1.2만 지원됩니다.
Java 애플리케이션을 최신 버전으로 업데이트해야 업데이트된 보안 프로토콜, 암호 및 패치로 Oracle의 보안 정책을 준수할 수 있습니다.
승인된 암호는 다음과 같습니다.
- TLSv1.2:
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,
- TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
- TLS_RSA_WITH_AES_256_CBC_SHA,
- TLS_RSA_WITH_AES_256_CBC_SHA256,
- TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

지원되는 SMTP Auth 명령은 무엇입니까?

SMTP Plain만 지원됩니다.
참고 - 전송 애플리케이션이 Auth 명령에서 유연하지 않은 경우 SMTP 프록시/릴레이를 사용할 수 있음

내 애플리케이션에서 공용 인터넷에 액세스하지 않고 Email Delivery로 이메일을 전송할 수 있습니까?

예, 애플리케이션은 프록시 또는 릴레이 서비스와 같이 인터넷에 액세스할 수 있는 서비스로 메일을 전송해야 합니다.
향후에는 Email Delivery에서 공용 인터넷을 통과하지 않고도 서비스 게이트웨이 서비스를 사용하여 Oracle Cloud Infrastructure 내에서 이메일을 수락할 수 있게 될 예정입니다.

Email Delivery와 관련된 제한 사항은 무엇입니까?

Email Delivery 플랫폼은 Oracle Cloud Infrastructure의 Email Deliverability 팀에서 관리합니다. 서비스와 고객 신뢰도를 보호하기 위한 목적으로 계정에 한도를 두었습니다. My Oracle Support에서 서비스 요청을 열어 한도를 늘리면 대규모 전송 요구 사항을 충족할 수 있습니다.

무료 체험판으로 oracle.com에 등록한 고객은 24시간 동안 전송 가능한 이메일 수가 200개로 제한되며 최대 전송 속도는 분당 이메일 10개입니다. 승인된 발신자 수는 2,000명으로 제한됩니다. base64 인코딩 및 헤더를 포함한 최대 메시지 크기는 2MB입니다.
엔터프라이즈 계정은 24시간 동안 전송 가능한 이메일 수가 50,000개로 제한되며 최대 전송 속도는 분당 이메일 18,000개입니다. 엔터프라이즈 고객의 경우 승인된 발신자 수는 10,000명으로 제한됩니다. base64 인코딩 및 헤더를 포함한 최대 메시지 크기는 2MB입니다.
Email Delivery은 대용량을 지원하지만 고객 신뢰도를 보호하기 위해 한도가 설정되어 있습니다.
사용 사례를 파악하고 필요에 따라 전송 한도를 늘리려면 My Oracle Support에 문의하세요.

Email Delivery로 전송할 수 있는 이메일 유형에는 제한이 있습니까?

서비스 설명에 언급된 바와 같이 Email Delivery로 전송하는 이메일 유형에는 다음과 같은 의무가 적용됩니다.

기존 비즈니스 또는 개인적 관계가 없는 수신자에게 대량으로 배포되는 '스팸' 메일, 원치 않는 대량 인스턴트 메시지 또는 기타 형태의 원치 않는 전자 통신을 배포할 목적으로 본 서비스를 사용해서는 안 됩니다.

전송할 수 있는 이메일 용량은 어떻게 됩니까?

처음에는 메시지 헤더, 본문, base64 인코딩, 첨부 파일을 포함한 최대 2MB 크기의 기본 최대 메시지 크기가 지원됩니다.

용량 한도가 늘어나면 일일 전송량 및 요금 한도에 대해 '이메일' 1개당 데이터 2MB이 가산됩니다.

이메일 예시

단일 수신자에게 전송되는 10MB의 이메일 = 10MB/이메일당 2MB = 이메일 5개
메시지 크기가 10MB, 수신자가 10개인 단일 전자메일 요청 = 10MB/이메일 당 2MB * 수신자 10명 = 이메일 50개

첨부 파일이 있는 이메일을 전송할 수 있습니까?

Email Delivery는 SMTP를 통해 MIME(다목적 인터넷 메일 확장) 메시지 전송을 지원합니다. MIME는 첨부 파일의 작동 방식을 부분적으로 지정하는 RFC 표준입니다. 자세한 내용은 여기를 참조하세요.

어떤 전송 방법을 사용할 수 있습니까?

현재 Email Delivery를 통해 이메일을 전송하는 유일한 방법은 SMTP입니다. Email Delivery를 사용할 수 있는 Oracle Cloud Infrastructure 지역마다 고유한 SMTP 엔드포인트가 있습니다.

Email Delivery에 대해 제공되는 SDK가 있습니까?

예, Email Delivery는 Oracle Cloud Infrastructure SDK에 포함되어 있습니다.

전달성

Email Delivery는 어떻게 안정적인 전송을 보장합니까?

Email Delivery는 업계 모범 사례를 준수하는 시스템을 통해 안정적인 서비스를 제공합니다. 이 플랫폼은 Oracle Cloud Infrastructure의 Email Deliverability 팀이 관리하며 주요 전송 가능성 지표 검토함으로써 가능한 최상의 전송 신뢰도를 보장합니다. Email Delivery을 사용하여 이메일을 전송하면 다음과 같은 사항을 처리할 수 있습니다.

사서함 공급업체 고유 SMTP 구성
반송 메일 수집
사용자 불만 수집
이메일 인증 표준(예: SPF)
IP 풀 관리

Email Delivery는 어떻게 SMTP 구성을 사용자 지정합니까?

Email Delivery는 사서함 공급업체별 속도 제한, 백오프 모드 및 SMTP 구성으로 구성됩니다. 이러한 구성은 전 세계 사서함 공급업체 간에, 받은 편지함 배치 및 전송 속도를 최적화하기 위해 산업 관계를 통해 수년간의 조정을 거쳐 설정되었습니다.

Email Delivery가 반송된 이메일을 수집합니까?

예. 반송된 이메일은 수집되어 해당 반송 코드에 따라 적절하게 분류됩니다.

이메일이 반송되면 어떻게 해야 합니까?

하드 바운스와 같이 영구적으로 전송할 수 없는 것으로 간주되는 모든 수신자 주소는 고객의 제외 목록에 포함됩니다. 제외 목록에 있는 주소에 대한 지속적인 전송 시도는 Email Delivery에 의해 전송되지 않으며 이러한 시도는 차단 보고서에 기록됩니다. 발신자가 존재하지 않는 수신자 주소로 메시지를 전송하려고 할 때 하드 바운스 발생율(전송된 메시지에 대한 하드 바운스 비율)이 높아집니다. 사서함 공급업체는 발신자에게 하드 바운스 코드를 반환합니다. 하드 바운스는 목록 품질을 나타내는 좋은 지표이며, 2% 미만이어야 합니다.

Email Delivery가 사용자 불만을 수집합니까?

예, 사용자 불만은 사서함 공급자 불만 피드백 루프를 통해 수집 및 처리됩니다. 이러한 불만 피드백 루프 설정은 Email Delivery에서 완전히 자동화됩니다.

사용자 스팸 불만이 수집되면 고객의 전송 신뢰도를 보호하기 위해 해당 사용자가 비표시 목록에 추가됩니다. 이때 메일 그룹에서 해당 사용자 제거까지 마치는 것이 좋지만, 별다른 조치를 취하지 않더라도 우수한 이메일 전송 가능성이 보장됩니다.

비표시 목록이란 무엇입니까?

비표시 목록은 Email Delivery 콘솔 사용자 인터페이스와 API, SDK 및 CLI에 포함되어 있습니다.

Email Delivery는 영구 오류 또는 사용자 불만을 표시하는 바운스 코드가 포함된 이메일 주소를 비표시 목록에 자동으로 추가하여 발신자 신뢰도를 보호합니다. Email Delivery는 향후 이러한 수신자에게 메시지를 전송하지 않습니다. 표시되지 않는 이메일 주소로 전송하려는 반복된 시도는 차단 보고서에 표시됩니다.

현재 전송 제외 이유로는 스팸 관련 불만 사항, 하드 바운스, 반복적인 소프트 바운스, 수동 입력 및 목록 구독 취소 요청이 있습니다.

SPF(발신자 정책 프레임워크)란 무엇이며 어떻게 사용합니까?

SPF는 이메일 주소 스푸핑을 방지하고 인바운드 스팸을 최소화합니다. 도메인은 SPF를 통해 해당 도메인 이름을 사용할 수 있는 호스트를 명시적으로 승인할 수 있습니다. SPF는 도메인 이름을 사용할 수 있는 호스트를 선언하는 DNS 리소스 레코드인 SPF(코드 99) 또는 TXT(코드 16) 레코드를 게시하여 작동합니다. 수신 메일 서버는 이메일을 전송한 것으로 식별된 도메인에서 SPF 레코드를 검사하여 이메일이 시작된 원본 IP가 해당 도메인에서 이메일을 전송할 권한이 있는지 확인합니다.

사서함 공급자와 ISP는 SPF를 검사하여 발신자(Email Delivery)가 귀사의 도메인을 대신하여 이메일을 전송할 권한이 있는지 확인합니다. SPF는 귀사의 도메인에 우수한 전송 가능성을 제공하고 스팸 또는 피싱 공격과 같은 악용으로부터 귀사를 보호하는 데 기반이 되는 필수 요소입니다.

SPF를 설정하려면 승인된 발신자가 사용하는 도메인에 TXT 레코드를 포함시켜야 합니다. Email Delivery가 이 도메인에 승인된 유일한 발신자인 경우 다음과 같이 나타납니다.

전송 위치	SPF
북미	v=spf1 include:rp.oracleemaildelivery.com ~all
아시아 태평양	v=spf1 include:ap.rp.oracleemaildelivery.com~all
유럽	v=spf1 include:eu.rp.oracleemaildelivery.com~all
모든 상업 지역	v=spf1 include:rp.oracleemaildelivery.com include:ap.rp.oracleemaildelivery.com include:eu.rp.oracleemaildelivery.com~all

'v'는 사용된 SPF 버전을 나타냅니다. 다른 메커니즘은 이메일의 합법성을 테스트합니다. 'MX' 및 'A'는 이메일과 SPF 레코드를 비교하여 해당 이메일을 수락할지 여부를 결정하는 리소스 레코드입니다. 'all'은 항상 일치하며 기본 동작입니다. 이 메커니즘은 한정자와 결합하여, 일치를 처리하는 방법을 결정합니다. 가장 간단한 방법은 +(생략 시 포함됨) 및 -이며 각각 성공 또는 실패로 이어집니다. 이러한 결과를 처리하는 방법은 수신 도메인 관리자의 몫으로 남겨집니다. 일반적으로 '실패'는 거부되고 소프트 오류는 잠재적인 스팸으로 표시됩니다.

SPF를 사용하면 클라이언트 신뢰도를 높일 수 있습니다. SPF를 구현하는 도메인은 스푸핑될 가능성이 훨씬 낮습니다. SPF가 없으면 스팸 이메일을 스푸핑하여 특정 도메인을 표시할 수 있으며, 이 경우 수신자가 해당 이메일을 스팸으로 보고할 수 있습니다. 이러한 보고서가 일정량 이상 축적되면 베이지언 스팸 필터가 도메인을 차단할 가능성이 커지며 이로 인해 합법적인 이메일까지 모두 차단될 수 있습니다. 도메인이 SPF를 구현했지만 위조된 경우 수신 서버에서 사기성 이메일을 차단할 가능성이 큽니다.

전용 IP에서 이메일을 전송할 수 있습니까?

예, Email Delivery는 전용 IP를 지원합니다. 기본적으로 고객 계정은 이메일 특성에 따라 계층화된 공유 전송 풀에 구성됩니다. 전송 볼륨이 큰 경우에는 전용 IP를 사용하는 것이 좋습니다. 단, 전용 IP는 우수한 수준의 전송 신뢰도를 지원하지 않으므로 이메일 전달률에 영향을 줄 수 있으므로 용량이 작거나 산발적인 이메일 전송에 대해서는 사용하지 않는 것이 좋습니다.

각 고객의 메일 특성(볼륨, 버스트 속도, 신뢰도 등)은 전용 IP 전략에 따라 다릅니다. Oracle의 담당 팀은 숙련된 담당자들로 구성되어 있으며 전용 IP 요구를 지원할 준비가 되어 있습니다. 이 구성과 관련하여 도움을 받으려면 지원팀에 문의해주세요.

내 이메일이 전송 가능성 모범 사례를 준수하도록 하려면 어떻게 해야 합니까?

전달 가능성 모범 사례는 사용자가 원하는 투명한 이메일을 제공할 때 구축됩니다. CASL(캐나다 안티 스팸법)은 법률과 사용자의 요구 및 대부분의 사서함 공급업체가 사용하는 의도된 필터링을 준수하도록 하는 모범 사례 중 하나입니다. https://help.dyn.com/casl-faq/에서 CASL의 개요와 업계 우수 사례에 대한 설명을 확인할 수 있습니다.

신뢰도가 중요한 이유는 무엇입니까?

이메일을 전송하는 데 있어 이메일을 전송할 깨끗한 네트워크를 보유하는 것이 그 어느 때보다 중요해졌습니다. 스팸 메일 발신자 및 신뢰도가 낮은 다른 발신자와 IP 주소를 공유하는 경우 이메일이 받은 편지함으로 전송될 가능성이 크게 줄어듭니다. 네트워크를 감독하는 데 있어 경계를 늦추지 않음으로써 위험 요소를 제거하고 더 많은 이점을 제공할 수 있습니다.

신뢰도에 영향을 미치는 요소는 무엇입니까?

인증

타사 이메일 전송 서비스를 사용하는 경우 이메일 인증을 통해 SPF 및 도메인 키(DKIM)를 DNS 레코드에 각인함으로써 발신자(Email Delivery)와 수신자 서버(ISP 및 기업 메일 서버) 간의 ID와 신뢰를 확인할 수 있습니다. 수신 서버는 원치 않거나 위조된 메일이 받은 편지함에 도달하지 못하도록, 귀사 도메인의 DNS 레코드를 조회하여 타사 발신자가 귀사를 대신하여 메일을 전송할 권한이 있는지 확인합니다.

볼륨/빈도

일정한 볼륨과 빈도는 신뢰할 수 있는 발신자라는 신뢰도를 얻는 데 도움이 됩니다. 불규칙한 트래픽 스파이크는스팸 메일 발신자와 관련성이 높은 동작입니다. ISP를 수신하여 신뢰할 수 있는 발신자로 자리잡기 전에 IP에서 충분한 볼륨을 전송해야 합니다.

반송률

반송률은 전송한 총 이메일 수를 기준으로 전송할 수 없는 메시지(반송)의 비율입니다. 반송률은 2% 미만으로 유지하는 것이 좋습니다. 반송률이 높을수록 대개 목록 관리 및 정리가 부적절하거나, 목록이 오래되거나, 대여되거나, 구매되었음을 나타냅니다. Email Delivery는 반송이 일어난 주소를 자동으로 비표시 목록에 추가하여 반송률을 낮춥니다.

스팸 신고율

스팸 신고율은 전송한 총 이메일 수를 기준으로 사용자가 ISP에 제출한 신고 비율입니다. 이메일 수신자가 이메일 클라이언트의 UI에서 '스팸' 버튼을 클릭하면 스팸 신고가 발생합니다. 스팸 신고율은 0.05% 미만으로 유지하는 것이 좋습니다. Email Delivery는 스팸 신고가 발생한 주소를 자동으로 제외 목록에 추가합니다.

블랙리스트

ISP는 블랙리스트를 사용하여 신뢰도가 좋지 않은 발신자가 보내는 스팸을 차단합니다. 단, 합법적인 발신자도 의도치 않게 블랙리스트에 올라갈 수 있습니다. Email Delivery는 전송 IP에 대해 상위 10개의 블랙리스트된 서비스를 실시간으로 검사할 수 있습니다. 대부분의 블랙리스트는 24시간 차단 조치되며 이 기간이 지나면 목록에서 자동으로 삭제됩니다. 그러나 일부는 사용자가 직접 조치를 취해야 제외 목록에서 자신을 삭제할 수 있습니다.

내 하드 바운스 비율을 낮추려면 어떻게 해야 합니까?

발신자가 존재하지 않는 수신자 주소로 메시지를 전송하려고 할 때 하드 바운스 발생율(전송된 메시지에 대한 하드 바운스 비율)이 높아집니다. 사서함 공급업체는 발신자에게 하드 바운스 코드를 반환합니다. 하드 바운스는 목록 품질을 나타내는 좋은 지표이며, 2% 미만이어야 합니다.

일반적으로 수신자 주소에 다음과 같은 문제가 있는 경우 하드 바운스가 발생합니다.

잘못 입력된 주소
더 이상 사용되지 않는 주소(사용자가 계정 폐쇄)
웹사이트에서 웹을 스크랩하여 획득한 주소
목록 서비스 공급자가 제작한 주소

사서함 공급자는 하드 바운스의 발생을 어느 정도 예상하고 있습니다. 그러나 하드 바운스가 과도하게 발생하면 전달률이 감소하기 시작합니다. Email Delivery는 모든 하드 바운스 발생 수신자 주소를 제외 목록에 자동으로 추가하여 향후 전송 시도를 방지하고 전송 신뢰도를 보호합니다.

다음 작업을 수행하여 높은 반송률을 줄일 수 있습니다.

1. 옵트인 프로세스 구현대량 메일(여러 수신자에게 동시 발송)의 경우 옵트인 프로세스를 구현합니다. 옵트인 프로세스는 사용자가 귀사의 메일 그룹을 구독(메시지 전송 권한 부여)하는 방법입니다. 옵트인한 구독자에게만 메시지를 전송하는 것이 중요합니다. 옵트인 절차에는 두 가지 유형이 있습니다.

2. 단일 옵트인(확인되지 않음)—단일 옵트인은 사용자가 이메일 주소를 제공하고 관련 메시지를 수신할 수 있는 권한을 부여하는 것입니다. 사용자가 이메일 주소를 제공한 후에는 해당 사용자의 이메일 주소를 확인하지 않고도 메시지를 전송할 수 있습니다.

3. 이중 옵트인(확인됨)—이중 옵트인은 사용자가 전자 메일 주소를 제공하는 것입니다. 첫 번째 메일 전송 전에 사용자 작업이 필요한 확인 이메일이 전송되며 이 이메일을 통해 계정 소유자가 향후 메시지를 수신하고자 하는지 확인합니다. 소유자가 확인 이메일에 대한 응답으로 링크를 클릭하도록 하여 계정을 확인할 수 있습니다. 이렇게 하면 소유자 동의 없이 주소가 타사 메일 그룹에 추가되지 않습니다.

4. 참여하지 않는 사용자 제거 참여하지 않는 사용자를 제거하는 프로세스를 구현합니다. 수신자가 메일을 열지 않거나 클릭하지 않으면 해당 이메일 계정을 더 이상 사용하지 않음을 나타낼 수 있습니다. 이 경우, 사서함 공급자는 결국 계정을 종료하거나 스팸 트랩으로 변환합니다. 이러한 스팸 트랩을 건드리거나 닫힌 계정으로 이메일을 하드 바운스하지 않도록, 비즈니스 모델에서 정의된 기간 동안 참여하지 않은 수신자는 제거됩니다. 이는 또한 사용자 참여율을 높여서 전달률을 향상시킬 수 있습니다.

5. 구독자 목록 검토 구독자 목록을 검토할 때 다음을 확인합니다.

전송하기 전에 중복된 주소를 제거합니다. 존재하지 않는 주소로 이메일을 여러 번 전송하면 하드 바운스 비율이 높아질 수 있습니다.

이전 제외 목록(다른 이메일 서비스 공급업체가 제공했을 수 있음)이 실수로 포함되지 않았는지 확인합니다.

구독자가 옵트인했는지 확인합니다(이전 목록으로 전송해서는 안 됩니다).

사용자가 '모두 선택' 방식으로 이메일 클라이언트의 연락처 목록을 업로드하지 못하도록 제한합니다. 사용자가 주소를 개별적으로 선택하도록 강제하면 만료되거나 만료됐을 수 있는 주소가 실수로 포함되는 것을 방지할 수 있습니다.

6. 전송 빈도 평가 다음 메시지가 수신자에게 전송되기 전에 메시지가 하드 바운스로 등록되지 않으면 하드 바운스가 재차 발생하게 됩니다. 다른 메시지를 전송하기 전에 사서함 공급자와 이메일 서비스 공급자가 반송을 처리할 수 있는 시간을 주세요. 또한 전송 빈도를 줄이면 사용자가 여러 메시지를 수신하고 스팸으로 표시하게 되기 전에 구독을 취소할 수 있습니다.

내 소프트 바운스 비율을 낮추려면 어떻게 해야 합니까?

소프트 바운스 비율(# 전송된 메시지당 # 소프트 바운스 비율)은 메시지가 수신자에게 전송되고 수신 서버를 일시적으로 사용할 수 없거나 수신자가 메시지를 차단한 경우 발생합니다. 이는 전송되지 않은 임시 상태이며 사서함 공급자는 소프트 바운스 코드를 발신자에게 반환합니다. 이러한 주소는 존재하고 있으므로 비표시 목록에 추가되지 않습니다.

참고:Email Delivery는 24시간 내에 4개의 전자메일이 전송된 경우 제외 목록에 주소가 추가하므로 소프트 반송이 생성됩니다.

소프트 바운스는 보통 메시지 콘텐츠 품질 및 관련성을 잘 나타내 줍니다.

일반적으로 다음과 같은 경우 소프트 바운스가 발생합니다.

스팸처럼 보이는 콘텐츠—메시지 콘텐츠가 수신자에 의해 스팸으로 식별되어 일시적으로 차단됩니다.
수신자와 관련 없는 콘텐츠—이로 인해 스팸 신고가 증가할 수 있으며 수신자가 발신자의 IP 주소 또는 도메인에서 메시지를 일시적으로 차단하게 됩니다.
많은 스팸 신고 – 일부 수신자는 스팸 신고 임계값(IP당 일정 기간에 따른 스팸 신고 수)을 초과하면 IP 주소에서 수신되는 모든 메시지를 차단합니다.
수신측 서버의 응답 지연—이 경우 발신 메일 서버가 메시지를 4번 전송한 후 해당 메시지를 하드 바운스합니다.
메일함이 가득 차거나 할당량을 초과함 – 수신자의 메일함이 가득 차거나 할당량을 초과하면 메시지가 소프트 바운스될 수 있습니다.

스팸 신고율을 낮추려면 어떻게 해야 합니까?

스팸 신고는 여러 가지 이유로 발생할 수 있으며 일부는 사용자가 해당 메시지를 '스팸'이라고 생각하기 때문에 발생합니다. 때로는 받은 편지함이 혼잡하여 메시지를 줄이기 위해 스팸 버튼을 클릭할 가능성도 있습니다.

다음은 사람들이 메시지를 스팸으로 신고할 수 있는 몇 가지 일반적인 이유입니다.

실제로 스팸인 경우
콘텐츠가 더 이상 수신자가 기대하는 바와 관련이 없는 경우(옵트인한 것과 다름).
이메일 바닥글에 숨겨진 구독 취소 URL을 찾는 것보다 스팸 신고가 더 쉬운 경우.
수신자가 구독 취소 URL보다 ISP 사용자 인터페이스를 더 신뢰하는 경우.
수신자가 질려서 더는 메시지를 수신하는 것을 원치 않는 경우

다음은 스팸 신고율을 개선할 수 있는 방법입니다.

스팸 전송 금지
콘텐츠 관련성 유지 – 일일 식료품 쿠폰을 받기 위해 사이트에 가입한 사용자에게 자동차 대출 금리에 대한 메일을 전송하지 마세요.
구독 취소 URL을 쉽게 찾을 수 있게 배치— 스팸 신고보다는 구독 취소가 더 좋은 방법입니다. 이러한 방법을 사용하면 전송 대상 목록이 줄어들어 기분이 좋지 많을 수 있지만 실제로 메시지를 열거나 클릭하여 참여하는 수신자에게만 메일을 전송할 수 있게 해줍니다. 사람들이 스팸 신고를 하면 전송 신뢰도에 지장을 주게 되므로 목록에서 쉽게 제거할 수 있도록 해야 합니다. 최악의 방법은 메시지 하단에 구독 취소 URL을 숨겨두는 것입니다. 이메일 하단까지 스크롤하여 조그맣게 표시된 URL을 찾는 사용자는 극히 드물며, 대부분은 메시지를 스팸으로 표시하는 더 쉬운 방법을 선택합니다.
목록 구독 취소 헤더 구현—사서함 제공업체가 지원할 경우 이 기능을 사용하면 사용자가 메일을 스팸으로 표시하는 대신 신뢰할 수 있는 ISP 사용자 인터페이스를 통해 목록에서 안전하게 구독을 취소할 수 있습니다. 이는 Gmail의 피드백 루프와 가장 유사한 방법입니다.
이중 옵트인 프로세스 구현—현재 사용자에게 이메일을 전송하고 사용자가 메시지를 수신하고자 하는지 확인하는 것이 사용자가 메시지를 계속 소중히 여길 수 있도록 하는 좋은 방법입니다. 이는 스팸으로 표시되기 전에 수신자를 제거할 수 있는 좋은 방법이기도 합니다.
메일 전송 빈도 검토—짧은 시간 동안 너무 많은 메시지를 전송하여 수신자를 성가시게 하면 메시지를 스팸으로 표시할 수 있습니다. 메시지 케이던스가 예상된 콘텐츠 빈도와 일치할 수 있도록 하세요. 메일 전송 빈도를 줄이면 스팸 신고율도 줄어들 수 있습니다.
참여하지 않는 수신자 제거—수신자가 메시지를 열지 않거나 링크를 클릭하지 않으면 메시지를 수신하는 것을 원치 않을 수도 있습니다. 최후의 시도로도 수신자를 참여시키지 못한 경우 해당 수신자를 제거해야 합니다. 다음은 이 영역의 목록 관리 모범 사례를 이해하는 데 도움이 되는 몇 가지 팁입니다.

이메일이 전송되지 않았습니다. 이 문제를 해결하려면 어떻게 해야 합니까?

수신자가 제외 목록에 있는지 확인하세요.
SPF를 설정하여 받은 편지함 배치를 늘리세요.
애플리케이션 로그를 확인하여 문제(예: 인증 실패 또는 이메일 메시지 형식 관련 문제)가 없는지 확인하세요.
봉투와 본문에 서로 다른 두 개의 주소를 제공하는 경우 둘 모두 승인된 발신자여야 하며, 그렇지 않을 경우 메일이 거부됩니다.
SMTP FROM이 이메일 본문의 발신자와 동일하지 않은 경우 둘 다 승인된 발신자여야 합니다.
여전히 문제를 찾을 수 없습니까? 고객 지원 티켓 열기

Oracle Email Delivery가 전용 IP를 지원합니까?

예. Email Delivery는 신뢰도를 제어할 수 있는 전용 IP를 지원합니다. 전용 IP는 이메일 전송을 위해 예약된 Oracle Cloud IP 주소입니다. 기본적으로 고객 계정은 이메일 특성에 따라 계층화된 공유 전송 풀에 구성됩니다. 전송 볼륨이 큰 경우에는 전용 IP를 사용하는 것이 좋습니다. 단, 전용 IP는 우수한 수준의 전송 신뢰도를 지원하지 않으므로 이메일 전달률에 영향을 줄 수 있으므로 용량이 작거나 산발적인 이메일 전송에 대해서는 사용하지 않는 것이 좋습니다.

상용

Email Delivery에서 제공하는 오퍼링은 무엇입니까?

신뢰도 관리는 판매되는 추가 기능 서비스이며 이 서비스를 이용하려면 Universal Cloud 구독을 구매해야 합니다.

Email Delivery에 드는 비용은 얼마입니까?

Email Delivery 비용은 해당 서비스를 통해 전송된 이메일 수 1,000개당 미화 0.085 달러입니다. 전송된 이메일은 한 달 동안 이루어지는 고유한 아웃바운드 전송 수로 정의됩니다. 아웃바운드 전송은 고유의 메시지 개수와 메시지당 고유의 수신자 수에 따라 정해집니다.