검색 결과가 없습니다

검색어와 일치하는 결과가 없습니다

원하시는 정보를 찾는 데 도움이 되도록 다음을 시도해 보십시오.

  • 검색에 사용하신 키워드의 철자가 올바른지 확인하십시오.
  • 입력한 키워드에 동의어를 사용하십시오. 예를 들어 “소프트웨어” 대신 “애플리케이션”을 사용해 보십시오.
  • 아래에 표시된 인기 검색어 중 하나를 사용해 보십시오.
  • 새로운 검색을 시작하십시오.

 

인기 질문

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를 구성합니다. 설정 방법은 Oracle Cloud Infrastructure DNS FAQ를 참조하십시오.

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

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

    Email Delivery는 애슈번, 암스테르담, 제다, 런던, 멜버른, 뭄바이, 오사카, 피닉스, 상파울로, 서울, 시드니, 도쿄 및 취리히에서 사용할 수 있습니다. Oracle은 사용 가능 지역을 확장하기 위해 노력하고 있습니다.

    Email Delivery 지역 전송 구성에 대한 몇 가지 중요한 참고 사항:

    • 메일을 전송하는 애플리케이션은 전송 메일을 수신하는 지역에 있지 않아도 됩니다.

      예:
      다른 지역에 애플리케이션이 있는 경우 사용 가능한 지역 중 하나에서 이메일을 구성합니다. 콘솔 UI에서 이메일을 사용할 수 있는 지역을 변경하고 승인된 발신자를 추가하십시오. ID는 글로벌 자산이므로 SMTP 자격 증명 생성은 모든 지역에서 동일합니다. 그런 다음 이메일이 없는 지역 내 애플리케이션이 SMTP 자격 증명을 사용하여 PHX smtp endpoint smtp.us-phoenix-1.oraclecloud.com 등으로 이메일을 전송하도록 합니다. 그런 다음 애플리케이션이 SMTP 자격 증명을 사용하여 승인된 발신자를 생성한 지역 SMTP 엔드포인트로 애플리케이션 이메일을 전송하도록 합니다.

    더 많은 지역에서 Email Delivery를 사용할 수 있게 되면 더 나은 성능을 위해 전송 애플리케이션과 동일한 지역에서 이메일을 구성하는 것이 바람직합니다.

  • 승인된 발신자를 추가하려고 할 때 오류가 발생하는 이유는 무엇입니까?
    • 선택한 구획에서 승인된 발신자를 관리할 수 있는 권한이 있는지 확인하십시오. (정책 기본 사항)
    • 승인된 발신자 수 제한에 도달했을 수 있습니다. 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 일반만 지원됩니다.
    • 참고 - 전송 애플리케이션이 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개입니다. 승인된 발신자 수는 5명으로 제한됩니다.
    • 엔터프라이즈 계정은 24시간 동안 전송 가능한 이메일 수가 50,000개로 제한되며 최대 전송 속도는 분당 이메일 18,000개입니다. 엔터프라이즈 고객의 경우 승인된 발신자 수는 10,000명으로 제한됩니다.
    • 큰 볼륨 이용을 지원하는 Email Delivery에 제한을 두는 이유는 고객 신뢰도를 보호하기 위함입니다.
    • 사용 사례를 파악하고 필요에 따라 전송 제한을 늘리려면 My Oracle Support에 문의하십시오.
  • Email Delivery로 전송할 수 있는 이메일 유형에는 제한이 있습니까?

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

    • "스팸" 이메일, 원치 않는 대량 인스턴트 메시지 또는 기존에 비즈니스나 개인적인 관계를 맺지 않은 수신자에게 대량으로 배포되는 다른 형태의 원치 않는 전자 커뮤니케이션을 배포할 목적으로 본 서비스를 사용해서는 안 됩니다.
  • 전송할 수 있는 이메일 용량은 어떻게 됩니까?

    처음에는 메시지 머리글, 본문 및 첨부 파일을 포함하여 최대 2MB의 메시지가 지원됩니다. 현재 용량을 구성할 수는 없지만 곧 제공될 예정입니다.

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

    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는 향후 이러한 수신자에게 메시지를 전송하지 않습니다. 표시되지 않는 이메일 주소로 전송하려는 반복된 시도는 차단 보고서에 나타납니다.

    비표시 이유는 현재 다음을 포함합니다. 스팸 불만, 하드 바운스, 반복적 소프트 바운스, 수동 입력 및 List-Unsubscribe 요청.

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

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

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

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

    v=spf1 include:spf.oracleemaildelivery.com -all

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

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

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

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

    각 고객의 메일 특성(볼륨, 버스트 속도, 신뢰도 등)은 전용 IP 전략에 따라 다릅니다. 당사 팀은 이 주제에 대한 교육을 받았으며 전용 IP 요구를 지원할 준비가 되어 있습니다. 이 구성과 관련하여 도움을 받으려면 지원팀에 문의하십시오.

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

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

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

    이메일을 전송하는 데 있어 이메일을 전송할 깨끗한 네트워크를 보유하는 것이 그 어느 때보다 중요해졌습니다. 스패머 및 신뢰도가 낮은 다른 발신자와 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. 전송 빈도를 평가하십시오. 다음 메시지가 수신자에게 전송되기 전에 메시지가 하드 바운스로 등록되지 않으면 하드 바운스가 재차 발생하게 됩니다. 다른 메시지를 전송하기 전에 사서함 공급자와 이메일 서비스 공급자가 반송을 처리할 수 있는 시간을 주십시오. 또한 전송 빈도를 줄이면 사용자가 여러 메시지를 수신하고 스팸으로 표시하게 되기 전에 구독을 취소할 수 있습니다.

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

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

    • 참고: 한 주소로 24시간 이내에 4개의 이메일이 전송되고 소프트 바운스가 발생하면 Email Delivery는 비표시 목록에 이 주소를 추가합니다.
    • 소프트 바운스는 보통 메시지 콘텐츠 품질 및 관련성을 잘 나타내 줍니다.

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

    • 스팸처럼 보이는 콘텐츠 – 메시지 콘텐츠가 수신자에 의해 스팸으로 식별되어 일시적으로 차단되고 있습니다.
    • 수신자와 관련 없는 콘텐츠 – 이로 인해 불만이 증가할 수 있으며 수신자가 발신자의 IP 주소 또는 도메인에서 메시지를 일시적으로 차단하게 됩니다.
    • 많은 불만 – 일부 수신자는 불만 임계값(IP당 일정 기간에 따른 불만 수)을 초과하면 IP 주소에서 수신되는 모든 메시지를 차단합니다.
    • 수신 메일 서버의 사용량이 많음 – 이 문제가 발생하면 발신 메일 서버가 메시지를 4번 전송한 후 해당 메시지를 하드 바운스합니다.
    • 사서함이 가득 차거나 할당량을 초과함 – 수신자의 사서함이 가득 차거나 할당량을 초과하면 메시지가 소프트 바운스될 수 있습니다.
  • 내 불만율을 낮추려면 어떻게 해야 합니까?

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

    다음은 사람들이 메시지에 대해 불만을 제기할 수 있는 몇 가지 일반적인 이유입니다.

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

    다음은 불만율을 개선할 수 있는 방법입니다.

    • 스팸 전송 금지
    • 콘텐츠 관련성 유지 – 수신자가 일일 식료품 쿠폰을 받기 위해 사이트에 가입한 경우 자동 대출 금리에 대한 메일을 전송하지 마십시오.
    • 쉽게 액세스할 수 있도록 구독 취소 URL 배치 – 구독 취소가 더 좋은 방법입니다. 목록이 축소되어 기분이 좋지는 않겠지만 이는 실제로는 메시지를 열거나 클릭하여 참여하는 수신자에게만 메일을 전송할 수 있게 해주는 방법입니다. 사람들이 불만을 제기하면 전송 신뢰도에 지장을 주게 되므로 목록에서 쉽게 제거할 수 있도록 해야 합니다. 가장 최악의 방법은 메시지 하단에 구독 취소 URL을 숨기는 것입니다. 극히 일부 사용자만 이메일 하단으로 스크롤하여 작은 URL을 찾습니다. 대부분은 더 쉬운 방법인, 해당 메시지를 스팸으로 표시하는 방법을 선택합니다.
    • List-Unsubscribe 머리글 구현 – 사서함 공급자가 이를 지원하는 경우 사용자는 메일을 스팸으로 표시하는 대신 이 기능을 사용하여 신뢰할 수 있는 ISP 사용자 인터페이스를 통해 목록에서 안전하게 구독을 취소할 수 있습니다. 이는 Gmail의 피드백 루프와 가장 유사한 방법입니다.
    • 이중 옵트인 프로세스 구현 – 현재 사용자에게 이메일을 전송하고 사용자가 메시지를 수신하고자 하는지 확인하는 것이 사용자가 메시지를 계속 소중히 여길 수 있도록 하는 좋은 방법입니다. 이는 스팸으로 표시되기 전에 수신자를 제거할 수 있는 좋은 방법이기도 합니다.
    • 메일 전송 빈도 검토 – 짧은 시간 동안 너무 많은 메시지를 전송하면 수신자의 기분을 언짢게 하여 메시지를 스팸으로 표시할 수 있습니다. 메시지 케이던스가 예상된 콘텐츠 빈도와 일치하는지 확인하십시오. 빈도를 줄이면 스팸 불만도 줄어들 수 있습니다.
    • 참여하지 않는 수신자 제거 – 수신자가 메시지를 열지 않거나 링크를 클릭하지 않으면 메시지를 수신하는 것을 원치 않을 수도 있습니다. 최후의 시도로도 수신자를 참여시키지 못한 경우 해당 수신자를 제거해야 합니다. 다음은 이 영역의 목록 관리 모범 사례를 이해하는 데 도움이 되는 몇 가지 팁입니다.
  • 내 이메일이 전송되지 않았습니다. 이 문제를 해결하려면 어떻게 해야 합니까?
    • 수신자가 비표시 목록에 있는지 확인하십시오.
    • SPF를 설정하여 받은 편지함 배치를 늘리십시오.
    • 애플리케이션 로그를 확인하여 문제(예: 인증 실패 또는 이메일 메시지 형식 관련 문제)가 없는지 확인하십시오.
    • 봉투와 본문에 서로 다른 두 개의 주소를 제공하는 경우 둘 모두 승인된 발신자여야 합니다. 그렇지 않으면 메일이 거부됩니다.
    • SMTP FROM이 이메일 본문의 발신자와 동일하지 않은 경우 둘 모두 승인된 발신자여야 합니다.
    • 여전히 문제를 찾을 수 없습니까? 고객 지원 티켓을 생성하십시오.
  • Oracle Email Delivery가 전용 IP를 지원합니까?

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

    각 고객의 메일 특성(볼륨, 버스트 속도, 신뢰도 등)은 전용 IP 전략에 따라 다릅니다. 당사 팀은 이 주제에 대한 교육을 받았으며 전용 IP 요구를 지원할 준비가 되어 있습니다. 이 구성과 관련하여 도움을 받으려면 지원팀에 문의하십시오.

    상업용

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

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

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

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

  • 시작하기
    다음을 위한 리소스:

    Integrated Cloud Applications & Platform Services