기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon SES이란 무엇인가요?
[Amazon Simple Email Service(SES)](https://aws.amazon.com/ses)는 사용자의 이메일 주소와 도메인을 사용해 이메일을 보내고 받기 위한 경제적이고 손쉬운 방법을 제공하는 이메일 플랫폼입니다.
예를 들어, 특별 행사 안내 등의 마케팅 이메일, 주문 확인서 등의 거래 이메일, 뉴스레터 등의 기타 통신문을 발송할 수 있습니다. Amazon SES를 사용하여 메일을 수신하면 이메일 자동 응답기, 이메일 구독 해제 시스템, 수신 이메일에서 고객 지원 티켓을 생성하는 애플리케이션과 같은 소프트웨어 솔루션을 개발할 수 있습니다.
Amazon SES에 관련된 다양한 주제에 대한 자세한 내용은 [AWS 메시징 및 타겟팅 블로그](https://aws.amazon.com//blogs/messaging-and-targeting/)를 참조하세요.
## 이점
대규모 이메일 솔루션을 구축하는 것은 비즈니스에 있어서 고비용의 복잡한 작업입니다. 이메일 서버 관리, 네트워크 구성, IP 주소 신뢰도 등의 인프라 문제를 해결해야 하기 때문입니다. 또한 많은 타사 이메일 솔루션에는 계약 및 가격 협상은 물론 상당한 초기 비용이 필요합니다. Amazon SES를 사용하면 이러한 문제들을 해결하여 Amazon.com이 대규모 고객층을 위해 구축한 고급 이메일 인프라와 다년간의 경험을 마음껏 이용할 수 있습니다.
## 관련 서비스
Amazon SES는 다른 AWS 제품과 원활하게 통합됩니다. 예를 들어, 다음을 수행할 수 있습니다.
+ 애플리케이션에 이메일 전송 기능을 추가합니다.
+ [AWS SDK](https://aws.amazon.com/tools/#sdk)를 사용하거나, [Amazon SES SMTP 인터페이스](send-email-smtp.md)를 사용하거나, [Amazon SES API](https://docs.aws.amazon.com/ses/latest/APIReference/)를 직접 호출하여 Amazon EC2에서 이메일을 보낼 수 있습니다,
+ [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/)를 사용하여 이메일 지원 애플리케이션(예를 들어 Amazon SES를 사용하여 고객에게 뉴스레터를 발송하는 프로그램)을 작성할 수 있습니다.
+ 반송되었거나 수신 거부가 제출되었거나 수신자의 메일 서버로 성공적으로 전송된 이메일에 대한 알림을 수신하도록 [Amazon Simple Notification Service(Amazon SNS)](https://aws.amazon.com/sns/)를 설정할 수 있습니다. Amazon SES로 이메일을 수신하면 이메일 콘텐츠를 Amazon SNS 주제에 게시할 수 있습니다.
+ AWS Management Console 를 사용하여 이메일을 인증하는 방법인 Easy DKIM을 설정합니다. 어떤 DNS 공급자에서도 Easy DKIM을 사용할 수 있지만, [Route 53](https://aws.amazon.com/route53/)을 사용하여 도메인을 관리할 경우 설정이 특히 용이합니다.
+ [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/)을 사용하여 이메일 전송에 대한 사용자 액세스를 제어할 수 있습니다.
+ [Amazon Simple Storage Service(Amazon S3)](https://aws.amazon.com/s3/)에서 수신한 이메일을 저장합니다.
+ [AWS Lambda](https://aws.amazon.com/lambda/) 함수를 트리거하여 수신 이메일에 여러 가지 작업을 수행할 수 있습니다.
+ 필요에 따라 [AWS Key Management Service (AWS KMS)](https://aws.amazon.com/kms/)를 사용해 Amazon S3 버킷에 수신하는 메일을 암호화할 수 있습니다.
+ [AWS CloudTrail](https://aws.amazon.com/cloudtrail/)를 사용하여 콘솔 또는 Amazon SES API를 통해 생성한 Amazon SES API 호출을 기록할 수 있습니다.
+ 이메일 전송 이벤트를 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 또는 [Amazon Data Firehose](https://aws.amazon.com/firehose/)에 게시할 수 있습니다. 이메일 전송 이벤트를 Firehose에 게시하면 [Amazon Redshift](https://aws.amazon.com/redshift/), [Amazon OpenSearch Service](https://aws.amazon.com/elasticsearch-service/) 또는 [Amazon S3](https://aws.amazon.com/s3/)에서 액세스할 수 있습니다.
## 가격 책정
Amazon SES를 사용하면 전송 및 수신된 이메일의 볼륨에 따라 비용을 지불할 수 있습니다. 자세한 내용은 [Amazon SES 요금](https://aws.amazon.com/ses/pricing/)을 참조하세요.
# 리전 및 Amazon SES
SES는 AWS 리전 전 세계 여러에서 사용할 수 있습니다. AWS 는 각 리전에서 여러 가용 영역을 유지합니다. 이러한 가용 영역은 물리적으로 서로 분리되어 있지만, 지연 시간이 짧고 처리량과 중복성이 우수한 프라이빗 네트워크 연결로 통합됩니다. 이러한 가용 영역을 사용하여 아주 높은 수준의 가용성과 중복성을 제공하면서 지연 시간을 최소화할 수 있습니다.
SES 리전 엔드포인트의 전체 목록은 *AWS 일반 참조*의 [Amazon Simple Email Service 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/ses.html)을 참조하세요. 각 리전에서 사용할 수 있는 가용 영역의 수를 알아보려면 [AWS 글로벌 인프라](https://aws.amazon.com/about-aws/global-infrastructure/)를 참조하세요.
이 섹션에서는 여러 AWS 리전에서 SES를 사용하기 전에 꼭 알아야 할 내용을 설명합니다. 다음 내용으로 구성됩니다.
+ [SES 리전 및 엔드포인트](#region-endpoints)
+ [샌드박스 제거 및 발신 한도 증가](#region-quota-increases)
+ [이메일 주소 및 도메인 확인](#region-verification)
+ [Easy DKIM](#region-dkim)
+ [계정 수준 금지 목록](#region-suppression-list)
+ [피드백 알림](#region-feedback-notifications)
+ [SMTP 자격 증명](#region-smtp)
+ [전송 권한 부여](#region-sending-authorization)
+ [사용자 지정 MAIL FROM 도메인에 사용되는 피드백 엔드포인트](#region-feedback)
+ [이메일 수신](#region-receive-email)
+ [(MX) 레코드 설정](https://docs.aws.amazon.com/ses/latest/dg/receiving-email-mx-record.html)
에 대한 일반적인 내용은 일반 AWS 리전참조의 [AWS 서비스 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/rande.html)를 *AWS 참조하세요.*
## SES 리전 및 엔드포인트
SES를 사용하여 이메일을 전송하는 경우 SES API 또는 SMTP 인터페이스에 대한 엔드포인트를 제공하는 URL에 연결합니다. 이 *AWS 일반 참조*에는 SES를 통해 이메일을 보내고 받는 데 사용하는 엔드포인트의 전체 목록이 포함되어 있습니다. 자세한 내용은 아래 참조된 AWS 일반 참조특정 섹션의 [Amazon Simple Email Service 엔드포인트 및 할당량을 참조하세요](https://docs.aws.amazon.com/general/latest/gr/ses.html).
+ **[API 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/ses.html#ses_region)** - SES를 통해 이메일을 보낼 때 이 테이블에 나열된 URL을 사용하여 SES API에 HTTPS 요청을 할 수 있습니다.
+ **[SMTP 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/ses.html#ses_smtp_endpoints)** - SMTP 인터페이스를 사용할 때 이 테이블에 나열된 URL을 사용하여 이메일을 보낼 수 있습니다.
+ **[이메일 수신 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/ses.html#ses_inbound_endpoints)** - 도메인으로 전송되는 이메일을 수신하도록 SES를 구성한 경우 [도메인의 DNS 설정에서 메일 교환기(MX) 레코드를 설정](https://docs.aws.amazon.com/ses/latest/dg/receiving-email-mx-record.html)할 때 이 테이블에 나열된 인바운드 SMTP 엔드포인트 URL을 사용할 수 있습니다.
**참고**
인바운드 SMTP URL은 IMAP 서버 주소가 아닙니다. 즉, 이 URL은 Outlook과 같은 애플리케이션을 사용하여 이메일을 수신하는 데 사용할 수 없습니다. 수신 이메일용 IMAP 서버를 제공하는 서비스는 [Amazon WorkMail](https://aws.amazon.com/workmail)을 참조하세요.
## 샌드박스 제거 및 발신 한도 증가
계정의 샌드박스 상태는 AWS 리전마다 다를 수 있습니다. 즉, 계정이 미국 서부(오리건) 리전의 샌드박스에서 제거된 경우, 미국 동부(버지니아 북부) 리전의 샌드박스에서도 계정을 제거한 경우가 아니라면 후자 리전의 샌드박스에 계정이 남아 있을 수 있습니다.
발신 한도는 AWS 리전에 따라 다를 수도 있습니다. 예를 들면, 사용 중인 계정이 유럽(아일랜드) 리전에서 초당 10건의 메시지를 발신할 수 있는 경우, 다른 리전에서는 이보다 더 많거나 또는 더 적은 메시지를 보낼 수 있습니다.
[샌드박스에서 계정을 제거하라는 요청을 제출](request-production-access.md)하거나 [계정의 발신 할당량을 늘리라는 요청을 제출](manage-sending-quotas-request-increase.md#user-requested-increased-sending-quotas)할 때는 해당 요청이 적용되는 모든 AWS 리전 을 선택해야 합니다. 단일 지원 센터 사례에서 여러 건의 요청을 제출할 수 있습니다.
## 이메일 주소 및 도메인 확인
SES를 사용하여 이메일을 보내려면 먼저 발신 이메일 주소 또는 도메인이 사용자 본인의 소유인지 확인해야 합니다. 이메일 주소 및 도메인의 확인 상태도 AWS 리전마다 다릅니다. 예를 들면, 미국 서부(오리건) 리전의 도메인을 확인하는 경우, 미국 동부(버지니아 북부) 리전의 확인 프로세스를 다시 완료할 때까지 후자의 리전에서 이메일을 전송하기 위해 전자의 도메인을 사용할 수는 없습니다. 이메일 주소 및 도메인 확인에 대한 자세한 내용은 [Amazon SES에서 확인된 자격 증명](verify-addresses-and-domains.md)을 참조하세요.
## Easy DKIM
Easy DKIM을 사용하려는 각 AWS 리전 에 대해 Easy DKIM 설정 프로세스를 수행해야 합니다. 즉, 각 리전에서 SES 콘솔 또는 SES API를 사용하여 CNAME 레코드를 생성해야 합니다. 그런 다음, 도메인에 대한 DNS 구성에 모든 CNAME 레코드를 추가해야 합니다. Easy DKIM 설정에 대한 자세한 내용은 [Amazon SES에서 Easy DKIM](send-email-authentication-dkim-easy.md) 섹션을 참조하세요.
모든 사용자가 기본 SES DKIM 도메인을 AWS 리전 사용하는 것은 아닙니다. 리전에서 리전별 DKIM 도메인을 사용하는지 `dkim.amazonses.com`확인하려면에서 [DKIM 도메인 테이블](https://docs.aws.amazon.com/general/latest/gr/ses.html#ses_dkim_domains)을 확인하세요*AWS 일반 참조*.
## 계정 수준 금지 목록
SES 계정 수준 금지 목록은 현재의 AWS 계정 에만 적용됩니다 AWS 리전. SES API v2 또는 콘솔을 사용하여 계정 수준 금지 목록에서 주소를 개별적으로 또는 일괄적으로 수동으로 추가하거나 제거할 수 있습니다. 계정 수준 금지 목록 사용에 대한 자세한 내용은 [Amazon SES 계정 수준 금지 목록 사용](sending-email-suppression-list.md) 섹션을 참조하세요.
## 피드백 알림
여러 AWS 리전에서 피드백 알림을 설정하는 것에 대한 2가지 중요 사항은 다음과 같습니다.
+ 확인된 ID 설정(예: 이메일과 SNS 중 어느 것을 통해 피드백을 받는지 등)은 이를 설정하는 리전에만 적용됩니다. 예를 들어, 미국 서부(오리건)과 미국 동부(버지니아 북부) 리전에서 *user@example.com*을 확인하고 SNS 알림을 통해 반송된 이메일을 수신하려면 SES API 또는 SES 콘솔을 사용하여 두 리전 모두의 *user@example.com*에 대해 SNS 피드백 알림을 설정해야 합니다.
+ 피드백 전달에 사용하는 SNS 주제는 SES를 사용하는 리전과 동일한 리전에 있어야 합니다.
피드백 알림을 통한 전송 활동 모니터링에 대한 자세한 내용은 [Amazon SES에 대한 이벤트 알림 설정](monitor-sending-activity-using-notifications.md) 섹션을 참조하세요.
## SMTP 자격 증명
SES SMTP 인터페이스를 통해 이메일을 전송하는 데 사용하는 자격 증명은 각 AWS 리전마다 고유합니다. SES SMTP 인터페이스를 사용하여 둘 이상의 리전에서 이메일을 전송하는 경우, 각 리전에 대해 [SMTP 자격 증명 세트를 생성](smtp-credentials.md)해야 합니다.
**참고**
2019년 1월 10일 이전에 SMTP 자격 증명을 생성한 경우 이전 버전의 AWS 서명을 사용하여 SMTP 자격 증명을 생성했습니다. 보안을 위해 이 날짜 이전에 만든 자격 증명을 삭제하고 새로운 자격 증명으로 교체하세요. [IAM 콘솔을 사용하여 이전 자격 증명을 삭제](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_manage.html#id_users_deleting)할 수 있습니다.
## 사용자 지정 MAIL FROM 도메인에 사용되는 피드백 엔드포인트
사용자 지정 MAIL FROM 도메인을 사용하는 경우 SES에서 MX 레코드를 게시하도록 요구하여 해당 도메인이 이메일 공급자가 보내는 반송 메일과 수신 거부 알림을 받을 수 있도록 합니다. 반송 메일 및 수신 거부 알림이 리전별 피드백 엔드포인트로 전송 AWS 리전 되므로 다른에서 확인된 자격 증명에 동일한 사용자 지정 MAIL FROM 도메인을 사용할 수 있습니다.
사용자 지정 MAIL FROM 도메인을 구성하면 SES는 사용자 지정 MAIL FROM이 구성되고 있는 리전에 대해 올바른 피드백 엔드포인트를 자동으로 지정합니다. 이 엔드포인트는 도메인의 DNS 구성에 게시(추가)할 수 있도록 MX 레코드의 값 필드에 제공됩니다.
사용자 지정 MAIL FROM 설정 프로세스에 대한 설명은 [사용자 지정 MAIL FROM 도메인 사용](mail-from.md)에 나와 있습니다. 참고로 SES가 다른에 사용하는 피드백 엔드포인트 AWS 리전 는의 [피드백 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/ses.html#ses_feedback_endpoints) 표에 나열되어 있습니다 AWS 일반 참조.
## 전송 권한 부여
위임 발신자는 자격 증명 소유자의 자격 증명이 확인된 AWS 리전 에서만 이메일을 보낼 수 있습니다. 위임 발신자에게 권한을 부여하는 전송 권한 부여 정책이 해당 리전의 ID에 연결되어야 합니다. 권한 부여 전송에 대한 자세한 내용은 [Amazon SES에서 전송 권한 부여 사용](sending-authorization.md) 섹션을 참조하세요.
## 이메일 수신
Amazon S3 버킷을 제외하고 SES로 이메일을 수신하는 데 사용하는 모든 AWS 리소스는 AWS 리전 SES 엔드포인트와 동일해야 합니다. 예를 들어, SES를 미국 서부(오리건) 리전에서 사용하는 경우 사용하는 SNS 주제, KMS 키 및 Lambda 함수는 미국 서부(오리건) 리전에도 있어야 합니다. 마찬가지로 어떤 리전 내에서 SES로 이메일을 수신하려면 해당 리전 내에 활성 수신 규칙 세트를 만들어야 합니다. 이메일 수신 개념 및 설정 프로세스는 [Amazon SES로 이메일 수신](receiving-email.md)에 설명되어 있습니다.
의 [이메일 수신 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/ses.html#ses_inbound_endpoints) 테이블에는 SES가 이메일 수신을 지원하는 모든에 대한 이메일 수신 엔드포인트 AWS 리전 가 AWS 일반 참조 나열됩니다.
# Amazon SES의 서비스 할당량
다음 단원에서는 Amazon SES 리소스 및 작업에 적용되는 할당량을 나열하고 설명합니다. 일부 할당량만 늘릴 수 있습니다. 할당량 증가를 요청할 수 있는지 여부를 확인하려면 **증가 가능 여부(Adjustable)** 열을 참조하세요.
**참고**
SES 할당량은에서 AWS 리전 사용하는 각에 대한 할당량입니다 AWS 계정.
## 이메일 전송 할당량
다음 할당량은 SES를 통해 이메일을 보낼 때 적용됩니다.
### 전송 할당량
할당량은 메시지 수가 아니라 수신자 수를 기준으로 합니다.
| Resource | 기본 할당량 | 조정 가능 |
| --- | --- | --- |
| 24시간의 기간당 보낼 수 있는 이메일 수 | 계정이 샌드박스에 있는 경우 24시간당 최대 200개의 이메일을 보낼 수 있습니다. 계정이 샌드박스 외부에 있는 경우, 이 수는 구체적인 사용 사례에 따라 달라집니다. | [예](manage-sending-quotas-request-increase.md) |
| 초당 보낼 수 있는 이메일 수(발신 속도) | 계정이 샌드박스에 있는 경우 초당 이메일 1개를 보낼 수 있습니다. 계정이 샌드박스 외부에 있는 경우, 이 속도는 구체적인 사용 사례에 따라 달라집니다. | [예](manage-sending-quotas-request-increase.md) |
### 메시지 할당량
| Resource | 기본 할당량 | 조정 가능 |
| --- | --- | --- |
| **[SES v1](https://docs.aws.amazon.com/ses/latest/APIReference/) 사용** - 최대 메시지 크기(첨부 파일 포함) | 메시지당 10MB(base64 인코딩 후) | 아니요*(메시지 크기가 10MB를 초과하는 워크로드의 경우 [SES v2 API](https://docs.aws.amazon.com/ses/latest/APIReference-V2/)로 마이그레이션하는 것이 좋음)* |
| **[SES v2 API](https://docs.aws.amazon.com/ses/latest/APIReference-V2/) 또는 [SMTP](send-email-smtp.md) 사용** - 최대 메시지 크기(첨부 파일 포함) | 메시지당 40MB(base64 인코딩 후). | 아니요 |
**참고**
10MB보다 큰 메시지에는 대역폭 제한이 적용되며, 전송 속도에 따라 40MB/s까지 제한될 수 있습니다. 예를 들어 초당 1개의 40MB 메시지 또는 초당 2개의 20MB 메시지를 보낼 수 있습니다.
### 발신자 및 수신자 할당량
| Resource | 기본 할당량 | 조정 가능 |
| --- | --- | --- |
| 최대 테넌트 수 | 10,000 | [예](manage-sending-quotas-request-increase.md#user-requested-increased-sending-quotas) |
| 메시지당 최대 수신자 수 | 메시지당 수신자 50명 수신자는 모든 "To", "CC" 또는 "BCC" 주소입니다. | 아니요. |
| 확인할 수 있는 최대 자격 증명 수 | 당 10,000개의 자격 증명 AWS 리전 *자격 증명*은 SES를 통해 이메일을 보낼 때 사용하는 도메인 또는 이메일 주소입니다. | 사용 사례에 대해 논의하려면 AWS 계정 관리자에게 문의하세요. |
| 전용 IP 풀의 최대 수(관리형 및 표준 IP 풀 모두 포함) | 50 | 아니요 |
### 이벤트 게시와 관련된 할당량
| Resource | 기본 할당량 | 조정 가능 |
| --- | --- | --- |
| 최대 구성 세트 개수 | 10,000 | 아니요 |
| 구성 세트 이름의 최대 길이 | 구성 세트 이름에는 최대 64개의 영숫자가 포함될 수 있습니다. 또한 하이픈(-) 및 밑줄(\$1)을 포함할 수 있습니다. 이름에는 공백, 억양 표시가 되어 있는 문자 또는 기타 특수 문자를 사용할 수 없습니다. | 아니요 |
| 구성 세트당 최대 이벤트 대상 개수 | 10 | 아니요 |
| CloudWatch 이벤트 대상당 최대 크기 수 | 10 | 아니요 |
### 이메일 템플릿 할당량
| Resource | 기본 할당량 | 조정 가능 |
| --- | --- | --- |
| 각의 최대 이메일 템플릿 수 AWS 리전 | 20,000건 | 아니요 |
| 최대 템플릿 크기 | 500KB | 아니요 |
| 각 템플릿의 최대 대체 값 수 | 무제한 | 해당 사항 없음 |
| 각 템플릿 이메일의 최대 수신인 수 | 대상 50개. *대상*은 "To", "CC", "BCC" 줄의 이메일 주소입니다. 단일 API 호출에서 연락할 수 있는 대상 수는 계정의 최대 전송 속도에 의해 제한될 수 있습니다. | 아니요 |
## 이메일 수신 할당량
다음 테이블에 SES를 통한 이메일 수신과 관련된 할당량이 나와 있습니다.
| Resource | 기본 할당량 | 조정 가능 |
| --- | --- | --- |
| 수신 규칙 세트당 최대 수신 규칙 수 | 200 | 아니요 |
| 수신 규칙당 최대 작업 수 | 10 | 아니요 |
| 수신 규칙당 최대 수신자 수 | 500 | 아니요 |
| 당 최대 수신 규칙 세트 수 AWS 계정 | 40 | 아니요 |
| 당 최대 IP 주소 필터 수 AWS 계정 | 100 | 아니요 |
| Amazon S3 버킷에 저장할 수 있는 최대 이메일 용량(헤더 포함) | 40MB | 아니요 |
| Amazon SNS 알림에 게시할 수 있는 최대 이메일 용량(헤더 포함) | 150KB | 아니요 |
| Amazon SNS 알림을 사용하여 게시할 수 있는 최대 이메일 헤더 크기 | 10KB | 아니요 |
| AWS Lambda 함수를 사용하여 게시할 수 있는 최대 이메일 헤더 크기 | 50KB | 아니요 |
## Mail Manager 할당량
다음 테이블에는 Mail Manager와 관련된 할당량이 나열되어 있습니다.
| Resource | 기본 할당량 | 조정 가능 |
| --- | --- | --- |
| 진행 중인 최대 수신 엔드포인트 수 | 10 | 아니요 |
| 권한 있는 최대 수신 엔드포인트 수 | 50 | 아니요 |
| 메시지당 최대 수신자 수 | 100 | 아니요 |
| 최대 이메일 크기(헤더 포함) | 40MB | 아니요 |
| 최대 트래픽 정책 문 수 | 20 | 아니요 |
| 최대 트래픽 정책 문 조건 수 | 10 | 아니요 |
| 리전당 최대 트래픽 정책 수 | 100 | 아니요 |
| 최대 SMTP 릴레이 수 | 40 | 아니요 |
| 리전당 최대 주소 목록 수 | 100 | 아니요 |
| 주소 목록당 최대 주소 수 | 100,000건 | 아니요 |
| 최대 규칙 세트 수 | 40 | 아니요 |
| 규칙 세트당 최대 규칙 수 | 40 | 아니요 |
| 규칙당 최대 조건 수 | 10 | 아니요 |
| 규칙당 최대 작업 수 | 10 | 아니요 |
| 규칙 세트당 최대 릴레이 또는 전송 작업 수 | 10 | 아니요 |
| 최대 *활성* 아카이브 수 | 10 | 아니요 |
| 최대 아카이브 검색 결과 수 | 1000 | 아니요 |
| 내보낸 아카이브 검색 결과의 최대 수 | 250,000 | 아니요 |
| 병렬로 실행되는 최대 검색 요청 수 | 1 | 아니요 |
| 병렬로 실행되는 최대 내보내기 요청 수 | 1 | 아니요 |
| 주당 아카이브의 최대 보존 변경 횟수 | 1 | 아니요 |
## 일반 할당량
다음 테이블에 SES를 통한 이메일 송수신에 모두 적용되는 할당량이 나와 있습니다.
### SES API 전송 할당량
| Resource | 기본 할당량 | 조정 가능 |
| --- | --- | --- |
| Amazon SES API 작업을 호출할 수 있는 속도 | 모든 작업(`SendEmail`, `SendRawEmail` 및 `SendTemplatedEmail` 제외)이 초당 요청 하나로 제한됩니다. | 아니요 |
| MIME 부분 | 500 | 아니요 |
### SES 기타 할당량
| Resource | 기본 할당량 | 조정 가능 |
| --- | --- | --- |
| 최대 동시 가져오기 작업 수 | 20 | 아니요 |
| 최대 동시 내보내기 작업 수 | 20 | 아니요 |
# Amazon SES 자격 증명 유형
Amazon Simple Email Service(Amazon SES)와 상호 작용하려면 보안 자격 증명을 사용하여 본인을 확인하고 Amazon SES와 상호 작용할 권한이 있는지 확인합니다. 자격 증명에는 여러 유형이 있으며, 사용하는 자격 증명은 수행할 작업에 따라 다릅니다. 예를 들어, Amazon SES API를 사용하여 이메일을 보낼 때는 AWS 액세스 키를 사용하고, Amazon SES SMTP 인터페이스를 사용하여 이메일을 보낼 때는 SMTP 자격 증명을 사용합니다.
수행하는 작업에 따라 Amazon SES에서 사용할 수 있는 자격 증명 유형이 다음 표에 나와 있습니다.
****
| 액세스할 대상 | 사용할 자격 증명 | 자격 증명의 구성 요소 | 자격 증명을 가져오는 방법 |
| --- | --- | --- | --- |
| Amazon SES API(Amazon SES API에 직접 액세스하거나 AWS SDK, AWS Command Line Interface 또는 AWS Tools for Windows PowerShell을(를) 통해 간접적으로 액세스할 수 있습니다.) | AWS 액세스 키 | 액세스 키 ID 및 보안 액세스 키 | *AWS 일반 참조*의 [액세스 키](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys)를 참조하세요. 보안 모범 사례에서는 AWS 계정 계정 액세스 키 대신 AWS Identity and Access Management(IAM) 사용자 액세스 키를 사용합니다. AWS 계정 자격 증명은 모든 AWS 리소스에 대한 모든 액세스를 부여하므로 안전한 위치에 저장하고 대신 AWS와의 일상적인 상호 작용에는 IAM 사용자 자격 증명을 사용해야 합니다. 자세한 내용은 *AWS 일반 참조*의 [루트 계정 자격 증명과 IAM 사용자 자격 증명 비교](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html)를 참조하세요. |
| Amazon SES SMTP 인터페이스 | SMTP 자격 증명 | 사용자 이름 및 암호 | [Amazon SES SMTP 자격 증명 획득](smtp-credentials.md)을(를) 참조하세요. Amazon SES SMTP 자격 증명은 AWS 액세스 키 및 IAM 사용자 액세스 키와 다르지만 Amazon SES SMTP 자격 증명은 사실상 IAM 자격 증명의 일종입니다. IAM 사용자는 Amazon SES SMTP 자격 증명을 생성할 수 있지만 루트 계정 소유자는 IAM 사용자의 정책이 이들에게 "iam:ListUsers", "iam:CreateUser", "iam:CreateAccessKey" 및 "iam:PutUserPolicy" 등의 IAM 작업에 액세스할 권한을 부여하는지 확인해야 합니다. |
| Amazon SES 콘솔 | IAM 사용자 이름과 암호OR이메일 주소와 암호 | IAM 사용자 이름과 암호OR이메일 주소와 암호 | *AWS 일반 참조*의 [IAM 사용자 이름과 암호](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#iam-user-name-and-password) 및 [이메일 주소 및 암호](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#email-and-password-for-your-AWS-account)를 참조하세요. 보안 모범 사례에서는 이메일 주소와 암호 대신 IAM 사용자 이름과 암호를 사용합니다. 이메일 주소와 암호 조합은 AWS 계정을 위한 것이므로 AWS와의 일상적인 상호 작용에 사용하지 말고 안전한 위치에 저장해야 합니다. 자세한 내용은 *AWS 일반 참조*의 [루트 계정 자격 증명과 IAM 사용자 자격 증명 비교](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html)를 참조하세요. |
다양한 유형의 AWS 보안 인증 정보(Amazon SES에만 사용되는 SMTP 보안 인증 정보 제외)에 대한 자세한 내용은 *AWS 일반 참조*의 [AWS 보안 인증 정보](https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html)를 참조하세요.
# Amazon SES를 통한 이메일 전송 작동 방식
이 주제에서는 SES를 통해 이메일을 전송할 때 어떤 과정을 거치는지 설명하고 이메일 전송 후 발생할 수 있는 다양한 결과에 대해 설명합니다. 다음 그림은 전송 프로세스의 종합적 개요입니다.
![\[Email sending process with Amazon SES, showing potential bounces, complaints, and delivery outcomes.\]](http://docs.aws.amazon.com/ko_kr/ses/latest/dg/images/arch_overview-diagram.png)
****
1. 이메일 발신자 역할을 담당하는 클라이언트 애플리케이션이 SES에 하나 이상의 수신자에게 이메일을 전송하는 요청을 합니다.
1. 요청이 유효하면 SES가 이메일을 수락합니다.
1. SES는 인터넷을 통해 수신자의 수신 장치에 메시지를 보냅니다. SES로 전달된 메시지는 일반적으로 즉시 전송됩니다. 통상적으로 최초 전송 시도가 몇 밀리초 이내에 이루어집니다.
1. 이 시점에서 다양한 가능성이 존재합니다. 예:
1. ISP가 성공적으로 메시지를 수신자의 받은 편지함으로 전송합니다.
1. 수신자의 이메일 주소가 존재하지 않습니다. 따라서 ISP가 SES로 반송 메일 알림을 전송합니다. 그러면 SES가 알림을 발신자에게 전달합니다.
1. 수신자가 메시지를 수신하지만 이를 스팸으로 여겨 ISP에게 수신 거부를 제기합니다. SES와의 피드백 루프가 설정되어 있는 ISP가 SES로 수신 거부를 전송하고 SES가 이를 발신자에게 전달합니다.
다음 섹션에서는 발신자가 SES로 이메일 요청을 보낸 후, 그리고 SES가 수신자에게 이메일 메시지를 전송한 후 발생 가능한 개별 결과를 알아봅니다.
## 발신자가 SES로 이메일 요청을 보낸 후
발신자가 SES로 이메일 전송 요청을 할 경우 호출이 성공할 수도 실패할 수도 있습니다. 다음 단원에서 각 경우에 어떤 일이 벌어지는지 설명합니다.
### 전송 요청 성공
SES에 대한 요청이 성공하면 SES가 발신자에게 성공 응답을 반환합니다. 이 메시지에는 요청을 고유하게 식별하는 문자열인 *메시지 ID*가 포함됩니다. 메시지 ID를 사용하여 전송된 이메일을 식별하거나 전송 중에 발생한 문제를 추적할 수 있습니다(SES가 이메일을 수락할 때 반환하는 SES 메시지 ID와 식별자 사이의 [자체 매핑을 저장](faqs-enforcement.md#cm-feedback-loop-q8)해야 함). 그런 다음 SES가 요청 파라미터를 기반으로 이메일 메시지를 수집하고 메시지에서 의심스러운 콘텐츠 및 바이러스를 검사한 다음 간이 전자 우편 전송 프로토콜(SMTP)을 사용하여 인터넷을 통해 전송합니다. 메시지는 일반적으로 즉시 전송됩니다. 통상적으로 최초 전송 시도가 몇 밀리초 이내에 이루어집니다.
**참고**
SES가 발신자의 요청을 수락한 다음 메시지에 바이러스가 포함된 것을 확인할 경우 SES는 해당 메시지 처리를 중지하고 해당 메시지를 수신자의 메일 서버로 전송하지 않습니다.
### 전송 요청 실패
발신자가 SES로 보낸 이메일 전송 요청이 실패할 경우 SES가 발신자에게 오류를 반환하고 이메일을 거부합니다. 요청이 실패하는 원인은 여러 가지가 있을 수 있습니다. 예를 들어 요청이 적절한 형식이 아니거나 발신자가 이메일 주소를 확인하지 않았을 수 있습니다.
사용자가 요청 실패 여부를 확인할 수 있는 방법은 SES를 호출한 방법에 따라 다릅니다. 다음 예제는 오류 및 예외가 반환되는 방식입니다.
+ 쿼리(HTTPS) API(`SendEmail` 또는 `SendRawEmail`)를 통해 SES를 호출하는 경우 작업이 오류를 반환합니다. 자세한 내용은 [Amazon Simple Email Service API 참조](https://docs.aws.amazon.com/ses/latest/APIReference/) 단원을 참조하십시오.
+ 예외를 사용하는 프로그래밍 언어에 AWS SDK를 사용하는 경우 SES 호출 시 *MessageRejectedException*이 발생합니다. (예외의 이름은 SDK에 따라 약간 다를 수 있습니다.)
+ SMTP 인터페이스를 사용하는 경우 발신자가 SMTP 응답 코드를 수신하지만, 오류가 전달되는 방식은 발신자의 클라이언트에 따라 달라집니다. 클라이언트에 따라 오류 코드가 표시될 수도, 표시되지 않을 수도 있습니다.
SES를 통해 이메일을 전송할 때 발생할 수 있는 오류에 대한 자세한 내용은 [Amazon SES 이메일 전송 오류](troubleshoot-error-messages.md) 섹션을 참조하세요.
## Amazon SES가 이메일을 전송한 후
발신자가 SES로 보낸 요청이 성공할 경우 SES가 이메일을 전송하고 다음 결과 중 하나가 발생합니다.
+ **이메일이 성공적으로 전송되고 수신자가 이메일을 거부하지 않음 – **ISP가 이메일을 수락하고 ISP가 이메일을 수신자에게 전송합니다. 다음 그림에 전송 성공이 나와 있습니다.
![\[Email flow diagram showing sender, Amazon SES, receiver ISP, and recipient with successful delivery.\]](http://docs.aws.amazon.com/ko_kr/ses/latest/dg/images/successful-diagram.png)
+ **하드 바운스 – **영구적 조건으로 인해 ISP가 거부했거나 이메일 주소가 SES 금지 목록에 있어 SES가 거부한 이메일입니다. SES 금지 목록에는 최근 SES 고객에게 하드 바운스를 발생시킨 이메일 주소가 들어 있습니다. ISP에서의 하드 바운스는 수신자 주소가 유효하지 않기 때문에 발생할 수 있습니다. 하드 바운스 알림은 ISP에서 SES로 다시 전송되고, SES는 발신자의 설정에 따라 이메일 또는 Amazon Simple Notification Service(Amazon SNS)를 통해 발신자에게 이를 알립니다. SES는 동일한 방법으로 발신자에게 금지 목록 반송 메일 알림을 전송합니다. 다음 그림에는 ISP로부터 시작하는 하드 바운스의 경로가 나와 있습니다.
![\[Email flow diagram showing sender, Amazon SES, and receiver with arrows indicating message path.\]](http://docs.aws.amazon.com/ko_kr/ses/latest/dg/images/hard_bounce-diagram.png)
+ **소프트 바운스 – **ISP는 일시적 상태(예: ISP가 처리할 요청이 너무 많거나 수신자의 메일박스가 가득 차 있음)로 인해 수신자에게 이메일을 전송하지 못할 수 있습니다. 도메인이 존재하지 않는 경우에도 소프트 바운스가 발생할 수 있습니다 ISP는 SES로 소프트 바운스 알림을 다시 전송합니다. 또는 도메인이 없는 경우 SES가 해당 도메인의 이메일 서버를 찾을 수 없습니다. 두 경우 모두 SES는 이메일 전송을 장시간 재시도합니다. SES가 재시도에서도 이메일을 전송할 수 없는 경우에는 이메일 또는 Amazon SNS를 통해 반송 메일 알림을 전송합니다. 재시도에서 SES가 수신자에게 이메일을 전송할 수 있으면 전송은 성공입니다. 다음 그림에는 소프트 바운스가 나와 있습니다. 이 경우, SES가 이메일 전송을 재시도하여, 결국 ISP가 수신자에게 이메일을 전송합니다.
![\[Email flow diagram showing sender, Amazon SES, receiver, and recipient with soft bounce scenario.\]](http://docs.aws.amazon.com/ko_kr/ses/latest/dg/images/soft_bounce-diagram.png)
+ **수신 거부 – **ISP가 수락하여 수신자에게 전송되었지만 수신자가 이 이메일을 스팸으로 간주하여 이메일 클라이언트에서 ‘스팸으로 표시’와 같은 버튼을 클릭한 이메일입니다. SES에 ISP와의 피드백 루프가 설정되어 있는 경우, 수신 거부 알림이 SES에 전송되고 SES는 이 수신 거부 알림을 발신자에게 전달합니다. 대부분의 ISP가 수신 거부를 제출한 수신자의 이메일 주소를 제공하지 않으므로, SES가 전달하는 수신 거부 알림은 원래 메시지의 수신자 그리고 SES에 수신 거부를 보낸 ISP를 기준으로 수신 거부를 제출했을 수 있는 수신자의 목록을 발신자에게 제공합니다. 다음 그림에는 수신 거부의 경로가 나와 있습니다.
![\[Diagram showing email flow from sender through Amazon SES, ISP, and recipient, with complaint feedback loop.\]](http://docs.aws.amazon.com/ko_kr/ses/latest/dg/images/complaint-diagram.png)
+ **자동 응답 – **이 이메일은 ISP가 수락하여 수신자에게 전송한 이메일입니다. 그런 다음 ISP가 부재중(OOTO) 메시지와 같은 자동 응답을 SES로 전송합니다. 그러면 SES가 자동 응답 알림을 발신자에게 전달합니다. 다음 그림에는 자동 응답이 나와 있습니다.
![\[Diagram showing email flow from sender through Amazon SES, ISP, recipient, and auto-response back to sender.\]](http://docs.aws.amazon.com/ko_kr/ses/latest/dg/images/auto_response-diagram.png)
자동 응답을 생성하는 메시지는 SES 지원 프로그램이 전송을 재시도하지 않도록 하세요.
**작은 정보**
SES 메일박스 시뮬레이터를 사용하여 전송 성공, 반송 메일, 수신 거부, OOTO 또는 주소가 금지 목록에 포함된 경우의 결과를 테스트할 수 있습니다. 자세한 내용은 [수동으로 메일박스 시뮬레이터 사용](send-an-email-from-console.md#send-email-simulator) 단원을 참조하십시오.
# Amazon SES의 이메일 형식
클라이언트가 Amazon SES로 요청을 보내면 Amazon SES가 인터넷 메시지 형식 사양([RFC 5322](https://www.ietf.org/rfc/rfc5322.txt))을 준수하여 이메일 메시지를 구성합니다. 이메일은 아래에 설명된 대로 *헤더*, *본문* 및 *엔벌로프*로 구성됩니다.
+ **헤더 - **라우팅 지침과 메시지에 대한 정보를 포함합니다. 발신자 주소, 수신자 주소, 제목, 날짜 등이 그 예입니다. 헤더는 우편 서신의 상단에 기재되는 정보에 비유할 수 있지만, 메시지 형식 등 다른 많은 유형의 정보를 포함할 수 있습니다.
+ **본문 - **메시지 텍스트 자체를 포함합니다.
+ **엔벨로프 - **SMTP 세션에서 이메일 클라이언트와 메일 서버 사이에 통신되는 실제 라우팅 정보를 포함합니다. 이 이메일 엔벌로프 정보는 편지 봉투에 기재되는 정보에 비유할 수 있습니다. 이메일 엔벌로프의 라우팅 정보는 일반적으로 이메일 헤더의 라우팅 정보와 동일하지만 반드시 그런 것은 아닙니다. 예를 들어 숨은 참조 수신자(BCC)에게 전송할 경우, 실제 수신자 주소(엔벌로프로부터 파생)가 수신자의 이메일 클라이언트에 표시되는 "To" 주소(헤더로부터 파생)와 다릅니다.
다음은 간단한 이메일의 예입니다. 헤더 다음에 한 줄이 건너뛴 후 이메일 본문이 이어집니다. 엔벌로프는 이메일 자체의 일부가 아니라 SMTP 세션 도중 클리언트와 메일 서버 사이에서 통신되므로 표시되지 않습니다.
```
1. Received: from abc.smtp-out.amazonses.com (123.45.67.89) by in.example.com (87.65.43.210); Fri, 17 Dec 2010 14:26:22
2. From: "Andrew" ;
3. To: "Bob"
4. Date: Fri, 17 Dec 2010 14:26:21 -0800
5. Subject: Hello
6. Message-ID: <61967230-7A45-4A9D-BEC9-87CBCF2211C9@example.com>
7. Accept-Language: en-US
8. Content-Language: en-US
9. Content-Type: text/plain; charset="us-ascii"
10. Content-Transfer-Encoding: quoted-printable
11. MIME-Version: 1.0
12.
13. Hello, I hope you are having a good day.
14.
15. -Andrew
```
다음 단원에서는 이메일 헤더 및 본문에 대해 살펴보고 Amazon SES를 사용할 때 제공해야 하는 정보를 알아봅니다.
## 이메일 헤더
이메일 메시지당 하나의 헤더가 있습니다. 헤더의 각 줄은 필드를 포함하며 필드와 필드 본문 사이는 콜론으로 구분됩니다. 이메일 클라이언트에서 이메일을 읽을 때, 통상적으로 이메일 클라이언트가 다음 헤더 필드의 값을 표시합니다.
+ **To - **메시지 수신자의 이메일 주소입니다.
+ **CC - **메시지의 참조 수신자의 이메일 주소입니다.
+ **From - **이메일이 전송된 이메일 주소입니다.
+ **Subject - **메시지 주제의 요약입니다.
+ **Date - **이메일이 전송된 날짜 및 시간입니다.
라우팅 정보를 제공하고 메시지 내용을 설명하는 많은 추가 헤더 필드가 있습니다. 보통의 경우 이메일 클라이언트는 이러한 필드를 사용자에게 표시하지 않습니다. Amazon SES에서 사용 가능한 헤더 필드의 전체 목록은 [Amazon SES 헤더 필드](header-fields.md) 단원을 참조하십시오. Amazon SES를 사용할 때 특히 "From," "Reply-To," 및 "Return-Path" 헤더 필드의 차이를 이해해야 합니다. 앞서 언급한 대로, "From" 주소는 메시지 발신자의 이메일 주소이고, "Reply-To" 및 "Return-Path"의 정의는 다음과 같습니다.
+ **Reply-To - **회신을 전송할 이메일 주소입니다. 기본적으로 회신은 원래 발신자 이메일 주소로 전송됩니다.
+ **Return-Path - **반송 메일 및 수신 거부를 전송해야 할 이메일 주소입니다. "Return-Path"는 때때로 "envelope from", "envelope sender" 또는 "MAIL FROM"으로 불립니다.
**참고**
Amazon SES를 사용할 경우 항상 ‘Return-Path’ 파라미터를 반송 메일을 모니터링하고 반송 메일 발생 시 교정 조치를 취할 수 있도록 설정하는 것이 좋습니다.
반송된 메시지를 의도된 수신자와 간편하게 매칭하려면 VERP(Variable Envelope Return Path)를 사용할 수 있습니다. VERP에서는 각 수신자별로 다른 "Return-Path"를 설정합니다. 따라서 메시지가 반송될 경우 반송 메일 메시지를 열고 파싱할 필요 없이 자동으로 어느 수신자로부터 반송되었는지 알 수 있습니다.
## 이메일 본문
이메일 본문은 메시지의 텍스트를 포함합니다. 본문은 다음 형식으로 전송할 수 있습니다.
+ **HTML - **수신자의 이메일 클라이언트가 HTML을 해석할 수 있는 경우 본문이 서식 지정된 텍스트 및 하이퍼링크를 포함할 수 있습니다.
+ **일반 텍스트 - **수신자의 이메일 클라이언트가 텍스트 기반일 경우 본문이 인쇄되지 않는 문자를 포함할 수 없습니다.
+ **HTML 및 일반 텍스트 모두 - **두 형식을 모두 사용하여 동일한 콘텐츠를 단일 메시지로 전송할 경우 수신자의 이메일 클라이언트가 기능에 따라 어느 형식을 표시할지 결정합니다.
다수의 수신자에게 이메일 메시지를 전송하는 경우 HTML 및 텍스트 모두 형식으로 이메일을 전송하는 것이 나을 수 있습니다. HTML 지원 이메일 클라이언트를 사용하는 수신자라면 메시지에서 포함된 하이퍼링크를 직접 클릭할 수 있습니다. 텍스트 기반 이메일 클라이언트를 사용하는 수신자를 위해서는 URL을 복사하여 웹 브라우저를 사용하여 열 수 있도록 URL을 포함시켜야 합니다.
## Amazon SES로 제공해야 하는 이메일 정보
Amazon SES에서 이메일을 전송할 때 제공해야 하는 이메일 정보는 Amazon SES를 호출하는 방식에 따라 달라집니다. 사용자는 최소한의 정보만 제공하면 Amazon SES가 대신하여 형식 설정을 수행합니다. 또는, 첨부 파일 전송과 같은 고급 작업을 수행하려면 직접 원시 메시지를 제공할 수 있습니다. 다음 단원에서는 Amazon SES API, Amazon SES SMTP 인터페이스 또는 Amazon SES 콘솔을 사용하여 이메일을 전송할 때 무엇이 필요한지 알아봅니다.
### Amazon SES API
직접 Amazon SES API를 호출하는 경우 `SendEmail` 또는 `SendRawEmail` API를 호출할 수 있습니다. 사용자가 제공해야 하는 정보는 어느 API를 호출하는가에 따라 다릅니다.
+ `SendEmail API`을(를) 호출하는 경우 발신 주소, 수신 주소, 메시지 제목과 본문만 입력하면 됩니다. 선택 사항으로 "Reply-To" 주소를 제공할 수 있습니다. 이 API를 호출하면 Amazon SES가 이메일 클라이언트 소프트웨어를 통한 디스플레이에 최적화된 적절한 서식의 멀티파트 다목적 인터넷 전자 우편(MIME) 이메일 메시지를 자동으로 수집합니다. 자세한 내용은 [Amazon SES API를 사용하여 서식이 지정된 이메일 보내기](send-email-formatted.md) 단원을 참조하세요.
+ `SendRawEmail` API는 헤더, MIME 파트, 콘텐츠 유형 등 원시 이메일 메시지의 형식을 사용자가 원하는 대로 지정하여 전송할 수 있습니다. `SendRawEmail`은(는) 대개 고급 사용자가 사용합니다. 메시지 본문과 인터넷 메시지 형식 사양([RFC 5322](https://www.ietf.org/rfc/rfc5322.txt))에서 필수로 지정된 모든 헤더 필드를 제공해야 합니다. 자세한 내용은 [Amazon SES API v2를 사용하여 원시 이메일 보내기](send-email-raw.md) 단원을 참조하십시오.
AWS SDK를 사용하여 Amazon SES API를 호출하는 경우 위에 나열된 정보를 해당 함수(예: Java용 `SendEmail` 및 )`SendRawEmail`에 제공합니다.
Amazon SES API를 사용한 이메일 전송에 대한 자세한 내용은 [Amazon SES API를 사용하여 이메일 보내기](send-email-api.md) 단원을 참조하십시오.
### Amazon SES SMTP 인터페이스
SMTP 인터페이스를 통해 Amazon SES에 액세스하는 경우 SMTP 클라이언트 애플리케이션이 메시지를 수집합니다. 따라서 제공해야 할 정보는 어떤 애플리케이션을 사용하는가에 따라 달라집니다. 클라이언트와 서버 간의 SMTP 교환에는 최소한 원본 주소, 대상 주소 및 메시지 데이터가 필요합니다.
Amazon SES SMTP 인터페이스를 사용한 이메일 전송에 대한 자세한 내용은 [Amazon SES SMTP 인터페이스를 사용하여 이메일 보내기](send-email-smtp.md) 단원을 참조하십시오.
### Amazon SES 콘솔
Amazon SES 콘솔을 사용하여 이메일을 전송하는 경우 제공해야 할 정보는 서식 지정된 이메일 또는 원시 이메일을 전송하는지에 따라 달라집니다.
+ 서식이 지정된 이메일을 전송하려면 원본 주소, 수신 주소, 메시지 제목과 본문을 입력해야 합니다. Amazon SES가 이메일 클라이언트 소프트웨어를 통한 디스플레이에 최적화된 적절한 서식의 멀티파트 MIME) 이메일 메시지를 자동으로 수집합니다. 회신 및 반송 경로 필드도 지정할 수 있습니다.
+ 원시 이메일을 전송하려면 발신 주소, 수신 주소 및 메시지 내용을 입력해야 합니다. 메시지 내용은 메시지 본문과 인터넷 메시지 형식 사양([RFC 5322](https://www.ietf.org/rfc/rfc5322.txt))에서 필수로 지정된 모든 헤더 필드를 포함해야 합니다.
# Amazon SES를 통한 이메일 발송률 이해
발신자는 수신자가 이메일을 읽고, 이메일에서 가치를 발견하고, 이메일을 스팸으로 표시하지 않기를 원합니다. 즉, 이메일 *발송률*(수신자의 받은 편지함에 도착한 이메일의 비율)을 최대화하려 합니다. 이 주제에서는 Amazon SES를 사용할 때 숙지해야 할 이메일 발송률 개념에 대해 알아봅니다.
이메일 발송률을 극대화하기 위해서는 이메일 전송 문제를 이해하고, 이러한 문제를 방지하기 위해 사전에 조치를 취하고, 전송한 이메일의 상태를 추적하고, 필요한 경우 이메일 전송 프로그램을 개선하여 성공적인 전송의 가능성을 더 높여야 합니다. 다음 단원에서는 이러한 조치의 배경이 되는 개념과 Amazon SES가 프로세스에서 어떤 도움을 주는지 알아봅니다.
![\[Circular diagram showing four steps to improve email delivery: understand issues, be proactive, stay informed, and improve program.\]](http://docs.aws.amazon.com/ko_kr/ses/latest/dg/images/deliverability_concepts-diagram.png)
## 이메일 전송 문제의 이해
대부분의 경우, 메시지를 기대하는 수신자에게는 메시지가 성공적으로 전송됩니다. 하지만 전송이 실패하거나 수신자가 발송된 이메일을 수신하기를 원치 않는 경우도 간혹 있을 수 있습니다. 반송 메일, 수신 거부, 금지 목록이 이러한 전송 문제와 관련되며, 다음 섹션에서 이들 문제에 대해 설명합니다.
### 바운스
수신자의 수신기(예: 이메일 공급자)가 수신자에게 메시지를 전달하지 못하는 경우 수신기는 메시지를 Amazon SES로 반송합니다. 그러면 Amazon SES는 사용자가 시스템을 설정한 방식에 따라 이메일 또는 Amazon Simple Notification Service(Amazon SNS)를 통해 반송된 이메일을 알립니다. 자세한 내용은 [Amazon SES에 대한 이벤트 알림 설정](monitor-sending-activity-using-notifications.md) 단원을 참조하세요.
반송 메일에는 *하드 바운스*와 *소프트 바운스*가 있으며, 정의는 다음과 같습니다.
+ **하드 바운스 – **지속적인 이메일 전송 실패입니다. 예를 들어 메일박스가 존재하지 않습니다. Amazon SES는 하드 바운스를 재시도하지 않습니다(DNS 조회 실패는 예외). 하드 바운스가 발생한 이메일 주소는 전송 시도를 반복하지 않는 것이 좋습니다.
+ **소프트 바운스 – **일시적인 이메일 전송 실패입니다. 예를 들어 메일박스가 가득 찼거나 연결이 너무 많거나(*병목 현상*이라고도 함) 연결이 시간 초과된 경우입니다. Amazon SES는 소프트 바운스를 여러 번 재시도합니다. 그래도 이메일을 전송할 수 없을 경우 Amazon SES가 재시도를 중지합니다.
Amazon SES는 사용자에게 더 이상 전송을 재시도하지 않을 소프트 바운스 및 하드 바운스에 대해 알립니다. 단, 하드 바운스만 Amazon SES 콘솔 또는 `GetSendStatistics` API를 사용하여 검색하는 반송 메일 발생률 및 반송 메일 측정치에 반영됩니다.
또한 반송 메일은 *동기식* 또는 *비동기식*일 수 있습니다. 동기식 반송 메일은 발신자 및 받는 사람의 이메일 서버가 능동적으로 통신하는 동안 발생합니다. 비동기식 반송 메일은 받는 사람이 처음에는 이메일 메시지를 수락했다가 나중에 수신자에게 전송하지 못하는 경우 발생합니다.
### 불만 제기
대부분의 이메일 클라이언트 프로그램은 "스팸으로 표시" 등으로 표시된 버튼을 제공합니다. 이 버튼을 누르면 메시지가 스팸 폴더로 이동한 후 이메일 공급자로 전달됩니다. 또한, 대부분의 이메일 공급자는 침해 주소(예: abuse@example.net)를 유지합니다. 이 주소를 통해 사용자는 이메일 공급자에게 원치 않는 이메일 메시지를 전달하고 이러한 메시지를 방지하는 작업을 할 것을 요청할 수 있습니다. 두 경우 모두, 수신자가 수신 거부를 제기하는 것입니다. 이메일 공급자가 발신자를 스패머라고 판단하고 Amazon SES가 해당 이메일 공급자와 피드백 루프를 설정한 경우, 이메일 공급자가 수신 거부를 Amazon SES로 전송합니다. 그러한 수신 거부를 수신한 Amazon SES는 사용자가 시스템을 설정한 방식에 따라 이메일 또는 Amazon SNS 알림을 통해 사용자에게 수신 거부 알림을 전달합니다. 자세한 내용은 [Amazon SES에 대한 이벤트 알림 설정](monitor-sending-activity-using-notifications.md) 단원을 참조하세요. 수신 거부가 발생한 이메일 주소는 전송 시도를 반복하지 않는 것이 좋습니다.
### 전역 금지 목록
SES 공유 IP 풀에서 주소의 평판을 보호하기 위해 SES가 소유하고 관리하는 Amazon SES *전역 금지 목록*에는 최근에 모든 SES 고객에게 하드 바운스를 발생시킨 수신자 이메일 주소가 포함되어 있습니다. SES를 통해 금지 목록에 포함된 주소로 이메일을 전송할 경우 SES 호출은 성공하지만, SES가 해당 이메일을 전송하는 대신 하드 바운스로 취급합니다. 일반적인 반송과 마찬가지로 발송 금지 목록 반송은 발신 할당량과 반송률에 포함됩니다. 이메일 주소는 최대 14일까지 발송 금지 목록에 남아 있을 수 있습니다. 전송할 이메일 주소가 유효하다고 확신하는 경우 해당 주소가 계정 수준 금지 목록에 있지 않은지 확인하여 전역 금지 목록을 재정의할 수 있습니다. SES가 계속 전달을 시도하지만 반송되는 경우 반송 메일이 사용자의 평판에 영향을 미치지만, 고유한 계정 수준 금지 목록을 사용하지 않는 경우 해당 이메일 주소로 보낼 수 없기 때문에 아무도 반송을 받지 않습니다. 계정 수준 금지 목록에 대한 자세한 내용을 보려면 [Amazon SES 계정 수준 금지 목록 사용](sending-email-suppression-list.md) 섹션을 참조하세요.
## 사전 예방
인터넷 상에서 가장 심각한 이메일 문제 중 하나가 원치 않는 대량 메일(스팸)입니다. 이메일 공급자는 고객이 스팸을 수신하지 않도록 광범위한 조치를 취하고 있습니다. 또한 Amazon SES는 이메일 제공업체가 귀하의 이메일을 스팸으로 간주할 가능성을 줄이기 위한 조치를 취합니다. Amazon SES는 확인, 인증, 전송 할당량 및 콘텐츠 필터링을 사용합니다. 또한 Amazon SES는 이메일 제공업체와 신뢰할 수 있는 평판을 유지하며 고품질 이메일을 보내야 합니다. Amazon SES는 이러한 작업 중 일부를 자동으로 처리합니다(예: 컨텐츠 필터링). 다른 경우에는 인증 등의 도구를 제공하거나 올바른 방향(할당량 전송)을 안내합니다. 다음 단원에서는 각 개념에 대한 자세한 내용을 제공합니다.
### Verification(확인)
불행히도 스패머가 이메일을 다른 소스로부터 발송된 것처럼 보이기 위해 이메일 헤더를 조작하고 발신 이메일 주소를 스푸핑하는 것이 가능합니다. 이메일 공급자와 Amazon SES 사이에서 신뢰를 유지하기 위해, Amazon SES는 발신자가 사용자 본인이라는 것을 보증해야 합니다. 그러므로 사용자는 Amazon SES를 통해 이메일을 전송하는 모든 이메일 주소를 확인하여 전송 자격 증명을 보호해야 합니다. Amazon SES 콘솔을 사용하거나 Amazon SES API를 사용하여 이메일 주소를 확인할 수 있습니다. 전체 도메인을 확인할 수도 있습니다. 자세한 내용은 [이메일 주소 자격 증명 생성](creating-identities.md#verify-email-addresses-procedure) 및 [도메인 자격 증명 생성](creating-identities.md#verify-domain-procedure) 섹션을 참조하세요.
계정이 아직 Amazon SES 샌드박스에 있는 경우, Amazon SES 메일박스 시뮬레이터에서 제공하는 주소를 제외한 모든 수신자 이메일 주소 또한 확인해야 합니다. 샌드박스 해제에 대한 자세한 내용은 [프로덕션 액세스 요청(Amazon SES 샌드박스에서 이동)](request-production-access.md) 단원을 참조하세요. 메일박스 시뮬레이터에 대한 자세한 내용은 [수동으로 메일박스 시뮬레이터 사용](send-an-email-from-console.md#send-email-simulator) 단원을 참조하세요.
### Authentication
*인증*은 이메일 공급자에게 발신자가 사용자 본인이라는 것을 표시하는 또 하나의 방법입니다. 이메일을 인증하면 발신자가 계정의 소유자이고 발신자가 보낸 이메일이 전송 중에 수정되지 않았다는 증거를 제공하는 것입니다. 경우에 따라 이메일 공급자는 인증되지 않은 이메일의 전달을 거부합니다. Amazon SES는 두 가지 인증 방법, 즉 발신자 정책 프레임워크(SPF) 및 도메인키 식별 메일(DKIM)을 지원합니다. 자세한 내용은 [Amazon SES의 자격 증명 구성](configure-identities.md) 단원을 참조하십시오.
### 전송 할당량
예상치 못한 갑작스러운 이메일 볼륨 또는 속도 급증이 감지되면 이메일 공급자는 발신자를 스패머로 의심하여 이메일을 차단할 수 있습니다. 따라서 모든 Amazon SES 계정에는 발신 할당량이 있습니다. 이러한 할당량은 24시간 동안 보낼 수 있는 이메일 수와 초당 보낼 수 있는 수를 제한합니다. 이러한 발신 할당량은 이메일 공급자와의 신뢰를 보호하는 데 도움이 됩니다.
대부분의 경우 신규 사용자에게는 Amazon SES가 매일 소량의 이메일을 전송하도록 허용합니다. 사용자가 전송하는 메일이 이메일 공급자가 허용 가능한 수준이라면 이 할당량이 자동으로 증가합니다. 사용자가 더 많은 이메일을 더 빠른 속도로 전송할 수 있도록 발신 할당량이 꾸준히 증가합니다. [SES 전송 제한 증가 사례](https://aws.amazon.com/ses/extendedaccessrequest/)를 생성하여 추가 할당량 증가를 요청할 수도 있습니다.
발신 할당량 및 할당량을 높이는 방법에 대한 자세한 내용은 [Amazon SES 발신 한도 관리](manage-sending-quotas.md) 단원을 참조하세요.
### 콘텐츠 필터링
많은 이메일 공급자가 콘텐츠 필터링을 사용하여 수신 이메일이 스팸인지 여부를 결정합니다. 콘텐츠 필터는 의심스러운 콘텐츠를 검색하여 이메일이 스팸의 프로필에 해당하는 경우 해당 이메일을 차단합니다. Amazon SES는 콘텐츠 필터도 사용합니다. 애플리케이션이 Amazon SES로 요청을 전송하면 Amazon SES가 사용자를 대신해 이메일 메시지를 수집한 후 메시지 헤더 및 본문을 스캔하여 이메일 공급자가 스팸으로 간주할 수 있는 콘텐츠가 포함되었는지 판단합니다. 사용자의 메시지가 Amazon SES의 콘텐츠 필터에 스팸처럼 보일 경우 Amazon SES에서의 사용자 평판에 악영향을 주게 됩니다.
또한 Amazon SES는 모든 메시지에서 바이러스를 검사합니다. 메시지에 바이러스가 포함되는 경우 Amazon SES는 해당 메시지를 수신자의 메일 서버로 전송하지 않습니다.
### 신뢰도
이 이메일 전송과 관련하여, *평판*(IP 주소, 이메일 주소 또는 전송 도메인이 스팸의 출처가 아니라는 확신을 나타내는 척도)이 중요합니다. Amazon SES는 수신자의 받은 편지함으로 이메일을 전송할 수 있도록 이메일 공급자에 대한 강력한 평판을 유지하고 있습니다. 마찬가지로, 사용자는 Amazon SES에 대해 높은 평판을 유지해야 합니다. 사용자는 품질이 높은 콘텐츠를 전송함으로써 Amazon SES에서 평판을 쌓을 수 있습니다. 사용자가 품질이 높은 콘텐츠를 전송하면 장기적으로 평판이 상승하여 Amazon SES가 사용자의 발신 할당량을 늘립니다. 과도한 반송 메일 및 수신 거부는 사용자의 평판에 악영향을 미치며 Amazon SES가 계정의 발신 할당량을 낮추거나 사용자의 Amazon SES 계정이 종료되는 원인이 될 수 있습니다.
평판을 유지하는 한 방법은 시스템을 테스트할 때 사용자가 직접 생성한 이메일 주소로 이메일을 전송하는 대신 사서함 시뮬레이터를 사용하는 것입니다. 메일박스 시뮬레이터로 보낸 이메일은 반송 메일 및 수신 거부 지표에 영향을 미치지 않습니다. 메일박스 시뮬레이터에 대한 자세한 내용은 [수동으로 메일박스 시뮬레이터 사용](send-an-email-from-console.md#send-email-simulator) 단원을 참조하세요.
### 품질이 높은 이메일
품질이 높은 이메일은 수신자가 가치를 발견하고 수신을 희망하는 이메일입니다. 가치는 수신자마다 다른 것을 의미하며 제안, 주문 확인, 영수증, 뉴스레터 등의 형태를 띨 수 있습니다. 궁극적으로, 사용자의 발송률은 사용자가 전송하는 이메일의 품질에 달려 있습니다. 이메일 공급자는 낮은 품질로 간주되는 이메일을 차단하기 때문입니다.
## 최신 정보 파악
이메일 전송이 실패했는지, 수신자가 이메일에 대해 수신 거부를 제기했는지, Amazon SES가 성공적으로 이메일을 수신자의 메일 서버로 전달했는지 여부에 대해 Amazon SES는 알림을 제공하고 간편한 사용량 통계치 모니터링을 제공하여 사용자가 문제를 추적할 수 있게 지원합니다.
### 알림
이메일이 반송되면 이메일 공급자는 Amazon SES에 알리고 Amazon SES는 사용자에게 알립니다. Amazon SES는 사용자에게 Amazon SES가 더 이상 전송을 재시도하지 않을 소프트 바운스 및 하드 바운스에 대해 알립니다. 많은 이메일 공급자가 수신 거부를 전달하며, Amazon SES가 주요 이메일 공급자에게 수신 거부 피드백 루프를 설정하므로 사용자가 할 필요가 없습니다. Amazon SES는 사용자에게 반송 메일, 수신 거부 및 전송 성공을 알릴 수 있는 두 가지 방법, 즉 Amazon SNS를 통해 알림을 수신하도록 계정을 설정하거나 이메일(반송 메일과 수신 거부만 해당)을 통해 알림을 수신할 수 있습니다. 자세한 내용은 [Amazon SES에 대한 이벤트 알림 설정](monitor-sending-activity-using-notifications.md) 단원을 참조하세요.
### 사용량 통계
Amazon SES는 사용자가 실패한 전송을 통해 근본 원인을 파악하고 해결할 수 있도록 사용량 통계치를 제공합니다. 사용량 통계치는 Amazon SES 콘솔을 사용하거나 Amazon SES API를 호출하여 확인할 수 있습니다. 전송, 반송 메일, 수신 거부 및 바이러스 감염 거부 이메일 수를 확인할 수 있고, 또한 발신 할당량을 초과하지 않도록 발신 할당량을 확인할 수 있습니다.
## 이메일 전송 프로그램 개선
반송 메일 및 수신 거부 수가 증가하고 있다면 이메일 전송 전략을 재평가할 때입니다. 과도한 반송 메일, 수신 거부 및 저품질 이메일을 보내려는 시도는 악용을 구성하고를 종료 위험에 빠뜨린다 AWS 계정 는 점을 기억하세요. 궁극적으로, 사용자는 Amazon SES를 사용하여 중요 이메일을 전송하고 수신자가 수신을 희망하는 이메일만 전송해야 합니다.
## 최소 1회 전송
Amazon SES는 중복성과 고가용성을 위해 여러 대의 서버에 메시지 사본을 저장합니다. 드물게는 메시지 사본을 받거나 삭제할 때 메시지 사본을 저장하는 서버 중 하나를 사용할 수 없을 수도 있습니다.
이 문제가 발생할 경우 사용 불가능한 해당 서버에서 메시지의 사본이 삭지되지 않으며, 메시지를 받을 때 해당 메시지 사본을 다시 가져올 수 있습니다. 따라서 애플리케이션이 idempotent가 되도록 설계해야 합니다(다시 말해 동일한 메시지를 두 번 이상 처리할 경우 부정적인 영향을 받지 않아야 함).
# Amazon SES를 사용한 이메일 전송 모범 사례
이메일을 사용한 고객 커뮤니케이션을 관리하는 방법을 *이메일 프로그램*이라고 합니다. 이러한 이메일 프로그램은 성패를 결정 짓는 요인이 몇 가지 있지만 처음에는 혼란스럽거나 이해가 되지 않을 수도 있습니다. 하지만 이메일 전송 방식에 대해 이해하고 몇 가지 모범 사례를 따르다 보면 이메일이 고객의 메일 수신함까지 이르는 가능성을 높일 수 있습니다.
**Topics**
+ [
# 이메일 프로그램을 위한 성공 지표
](success-metrics.md)
+ [
# 긍정적인 발신자 평판 유지
](tips-and-best-practices.md)
# 이메일 프로그램을 위한 성공 지표
이메일 프로그램의 성공 측정에 도움이 되는 여러 지표가 있습니다.
**Topics**
+ [
## 반송 메일
](#metrics-bounce-rate)
+ [
## 수신 거부
](#metrics-complaints)
+ [
## 메시지 품질
](#metrics-quality)
## 반송 메일
*반송*은 이메일이 원하는 수신자에게 전송되지 않았을 때 발생합니다. 반송 메일에는 *하드 바운스* 및 *소프트 바운스*라는 두 가지 유형이 있습니다. 하드 바운스는 이메일 주소가 존재하지 않는 것과 같은 영구적인 문제로 인해 이메일이 전송되지 않을 때 발생합니다. 소프트 바운스는 일시적인 문제로 인해 이메일을 전송할 수 없을 때 발생합니다. 소프트 바운스는 수신자의 받은 편지함이 가득 찼거나 수신 서버가 일시적으로 중단되었을 때 발생할 수 있습니다. Amazon SES는 일정 기간 동안 소프트 바운스 이메일을 다시 전송하려고 시도합니다.
사용자는 이메일 프로그램에서 하드 바운스의 수를 모니터링하고 수신자 목록에서 하드 바운스를 일으키는 이메일 주소를 제거해야 합니다. 이메일 수신기가 높은 하드 바운스 발생률을 감지하면 사용자가 수신자에 대해서 잘 모른다고 가정합니다. 결과적으로 하드 바운스 발생률이 높으면 이메일 메시지의 발송률에 부정적인 영향을 미칠 수 있습니다.
다음은 반송 메일을 방지하여 발신자 평판을 높이는 데 도움이 될 수 있는 지침입니다.
+ 하드 바운스 발생률을 5% 미만으로 유지하세요. 이메일 프로그램의 하드 바운스 수가 적을수록 ISP가 메시지의 적합성과 가치를 인정할 가능성이 높습니다. 이러한 비율은 합리적이고 달성 가능한 목표로 간주해야 하지만 모든 ISP에게 동일하게 적용되는 규칙은 아닙니다.
+ 이메일 목록은 빌리거나 구매하지 마세요. 이메일 목록에는 잘못된 주소가 상당수 포함되어 하드 바운스 발생률이 크게 높아지는 원인이 될 수 있습니다. 또한 이러한 목록에는 스팸 트랩(불법 발신자를 포착하는 데 특별히 사용되는 이메일 주소)이 포함될 수 있습니다. 메시지가 이러한 스팸 트랩으로 전송되면 전송 완료율과 발신자 평판은 돌이킬 수 없을 정도로 손상될 수 있습니다.
+ 목록을 최신 상태로 유지하세요. 일부 수신자에게 장기간 이메일을 보내지 않았다면 몇 가지 수단(웹사이트 로그인 활동, 구매 이력 등)을 통해 고객 상태의 유효성을 검증하는 것이 좋습니다.
+ 고객 상태를 검증할 방법이 없다면 *윈백(win-back)* 이메일을 전송하는 것도 좋은 방법입니다. 윈백 이메일이란 오랫동안 소식을 듣지 못한 고객이 여전히 이메일 수신에 동의하는지 확인하는 것을 말합니다. 윈백 이메일을 전송한 후에도 응답이 없는 수신자는 모두 목록에서 제거하세요.
반송 메일을 받으면 다음 규칙을 준수하여 적절하게 대응해야 합니다.
+ 하드 바운스를 일으키는 이메일 주소는 즉시 목록에서 제거하세요. 또한 하드 바운스를 일으킨 주소로 메시지를 재전송하지 마세요. 하드 바운스가 반복되면서 누적되면 결국 수신자의 ISP가 판단하는 평판이 떨어지게 됩니다.
+ 반송 메일 알림을 받는 데 사용하는 주소가 이메일을 수신할 수 있는지 확인합니다. 반송 메일 및 수신 거부 알림 설정에 대한 자세한 내용은 [Amazon SES에 대한 이벤트 알림 설정](monitor-sending-activity-using-notifications.md) 단원을 참조하세요.
+ 인바운드 이메일이 자체 내부 서버가 아닌 ISP를 통해서 수신되는 경우에는 반송 메일 알림이 스팸 폴더로 도착하거나, 혹은 완전히 삭제될 수도 있습니다. 따라서 반송 메일을 수신할 때는 호스팅 이메일 주소를 사용하지 않는 것이 바람직합니다. 하지만 호스팅 이메일 주소를 사용해야 한다면 자주 스팸 폴더를 확인하여 반송 메일 메시지가 스팸으로 표시되지 않도록 하세요. Amazon SES에서는 반송 메일 알림이 전송되는 주소를 지정할 수 있습니다.
+ 일반적으로 반송 메일에는 전송을 거부하는 메일 수신함의 주소가 포함되어 있습니다. 하지만 수신자 주소를 특정 이메일 캠페인과 연계할 수 있는 세부 데이터가 추가로 필요하다면 X-헤더에 내부 추적 시스템까지 밝혀낼 수 있는 값을 추가하세요. 자세한 내용은 [Amazon SES 헤더 필드](header-fields.md) 단원을 참조하십시오.
## 수신 거부
수신 거부는 수신자가 자신의 웹 기반 이메일 클라이언트에서 "Mark as Spam" 또는 이와 비슷한 버튼을 클릭할 때 발생합니다. 이러한 수신 거부가 상당수 누적되면 ISP가 스팸을 전송하는 것으로 간주하여 발송률과 발신자 평판에 부정적인 영향을 미칠 수 있습니다. 전부는 아니지만 일부 ISP는 수신 거부가 보고되면 알림을 전송합니다. 이를 *피드백 루프*라고 합니다. Amazon SES는 피드백 루프를 제공하는 ISP로부터 수신 거부를 자동으로 전달합니다.
다음은 수신 거부를 방지하여 발신자 평판을 높이는 데 도움이 될 수 있는 지침입니다.
+ 수신 거부 발생률을 0.1% 미만으로 유지하세요. 이메일 프로그램의 수신 거부 수가 적을수록 ISP가 메시지의 적합성과 가치를 인정할 가능성이 높습니다. 이러한 비율은 합리적이고 달성 가능한 목표로 간주해야 하지만 모든 ISP에게 동일하게 적용되는 규칙은 아닙니다.
+ 고객이 마케팅 이메일에 수신 거부하는 경우 해당 고객에게 더 이상 마케팅 이메일을 보내서는 안 됩니다. 하지만 이메일 프로그램에 다른 유형의 이메일, 예를 들어 알림 메시지나 거래 이메일 등이 포함되는 경우에는 수신 거부를 선택한 수신자라고 해도 이러한 유형의 메시지는 계속해서 보낼 수 있습니다.
+ 하드 바운스와 마찬가지로 오랫동안 이메일을 전송하지 않은 목록이 있다면 수신자가 메시지를 받는 이유에 대해서 잘 알 수 있도록 해야 합니다. 이러한 경우에는 인사말 메시지를 보내서 본인이 누구이고, 왜 이메일을 보내는지 알려주는 것이 좋습니다.
수신 거부 메일을 받으면 다음 규칙을 준수하여 적절하게 대응해야 합니다.
+ 수신 거부 알림을 받는 데 사용하는 주소가 이메일을 수신할 수 있는지 확인합니다. 반송 메일 및 수신 거부 알림 설정에 대한 자세한 내용은 [Amazon SES에 대한 이벤트 알림 설정](monitor-sending-activity-using-notifications.md) 단원을 참조하세요.
+ 수신 거부 알림이 ISP 또는 메일 시스템에서 스팸으로 표시되지 않도록 하세요.
+ 수신 거부 알림에는 일반적으로 이메일 본문이 포함되므로, 이메일 헤더만 포함되는 반송 메일 알림과는 다릅니다. 하지만 수신 거부 알림에서는 수신을 거부한 개인의 이메일 주소가 제거됩니다. 수신을 거부한 이메일 주소를 식별할 수 있도록 이메일 본문에 포함된 사용자 지정 X-헤더나 특수 식별자를 사용하세요. 이 방법을 사용하면 수신을 거부한 이메일을 쉽게 식별하여 해당 이메일을 수신자 목록에서 제거할 수 있습니다.
## 메시지 품질
이메일 수신기는 *콘텐츠 필터*를 사용하여 메시지의 속성을 감지함으로써 메시지의 적합성 여부를 식별합니다. 이러한 콘텐츠 필터는 메시지 내용을 자동으로 검토하여 불필요하거나 악의적인 메시지의 공통 특성을 찾아냅니다. Amazon SES는 콘텐츠 필터링 기술을 사용하여 맬웨어가 포함된 메시지를 감지하여 발신 전에 미리 차단합니다.
이메일 수신기의 콘텐츠 필터가 메시지에 스팸 또는 악성 이메일의 특성이 포함되어 있다고 판단할 경우 해당 메시지는 플래그 처리되어 수신자의 메일 수신함이 아닌 다른 곳으로 전송될 가능성이 높습니다.
이메일을 설계할 때는 다음 사항에 주의하세요.
+ 최신 콘텐츠 필터는 지능적이어서 상황에 따라 적응하며 계속해서 바뀝니다. 사전 정의된 규칙에 의존하지도 않습니다. [ReturnPath](https://returnpath.com/) 또는 [Litmus](https://litmus.com/)와 같은 타사 서비스는 이메일에서 콘텐츠 필터를 트리거하는 내용을 식별하는 데 도움이 될 수 있습니다.
+ 이메일에 링크가 포함되어 있으면 [URIBL.com](http://uribl.com/)이나 [SURBL.org](http://www.surbl.org/) 등의 DNS 기반 블랙홀 목록(DNSBL)과 대조하여 해당 링크 URL의 유무를 확인하십시오.
+ 링크 단축 서비스는 사용하지 마세요. 악의적인 발신자는 링크 단축 서비스를 사용하여 실제 링크 목적지를 숨기기도 합니다. ISP는 링크 단축 서비스(심지어 가장 평판이 좋은 서비스조차도)가 악의적인 목적으로 사용되고 있음을 알게 되면 해당 서비스에 대한 액세스를 모두 거부할 수 있습니다. 이메일에 거부 목록에 등록된 링크 단축 서비스에 대한 링크가 포함되어 있는 경우 고객의 메일 수신함까지 이르지 못하기 때문에 성공적인 이메일 캠페인도 어렵게 됩니다.
+ 이메일의 링크가 모두 원하는 페이지를 가리키고 있는지 테스트하세요.
+ 웹사이트에는 개인정보 보호정책 및 이용 약관 문서가 포함되어야 하는 동시에 이러한 문서들이 최신 상태를 유지해야 합니다. 전송하는 이메일마다 이러한 문서에 대한 링크를 추가하는 것도 좋은 방법입니다. 이러한 문서 링크를 제공하면 고객에게 숨길 것도 없다는 것을 보여주면서 신뢰 관계를 형성하는 데 도움이 될 수 있습니다.
+ 잦은 빈도 수의 콘텐츠("일별 거래" 메시지 등)를 전송할 계획이라면 배포할 때마다 이메일 내용이 달라야 합니다. 잦은 횟수로 메시지를 보낼 때는 각 메시지가 일정한 시간에 적합성을 유지해야만 반복적이고 귀찮게 느껴지지 않습니다.
# 긍정적인 발신자 평판 유지
Amazon SES에서 발신자 평판은 이메일 공급자 및 스팸 필터가 인식하는 이메일 발신자의 진실성과 신뢰성을 나타냅니다. 이는 이메일이 합법적인 것으로 간주되어 수신자의 받은 편지함에 성공적으로 전달될 가능성을 측정하는 기준입니다.
다음 섹션에서는 발신자의 평판을 양호하게 유지하면서 이메일 커뮤니케이션이 의도한 대상에 도달하도록 하려면 염두에 두어야 하는 핵심 이메일 전송 보안 주체를 소개합니다.
## 도메인 및 "From(발신)" 주소 주의사항
+ 이메일을 보내는 주소에 대해서 주의 깊게 생각하세요. "발신" 주소는 수신자가 가장 먼저 보게 되는 정보 중 하나이기 때문에 마지막까지 첫 인상으로 남을 수 있습니다. 또한 일부 ISP는 평판을 "발신" 주소와 연계하기도 합니다.
+ 커뮤니케이션 유형에 따라 하위 도메인을 사용하는 것도 좋은 방법입니다. 예를 들어 도메인 *example.com*에서 마케팅 메시지와 거래 메시지를 모두 이메일로 전송할 계획이라고 가정하겠습니다. 이때는 두 메시지를 모두 *example.com*에서 전송하기 보다는 오히려 마케팅 메시지는 *marketing.example.com*에서, 그리고 거래 메시지는 *orders.example.com* 같은 하위 도메인에서 보내는 것이 좋습니다. 고유성을 지닌 하위 도메인이라면 평판을 높일 수 있습니다. 또한 예를 들어 마케팅 커뮤니케이션이 스팸 트랩으로 수신되거나 콘텐츠 필터를 트리거하는 경우에도 평판을 떨어뜨릴 위험을 완화하는 효과가 있습니다.
+ 다수의 메시지를 보낼 계획이라면 *sender@hotmail.com* 같은 ISP 기반 주소에서 메시지를 보내지 마세요. ISP가 *sender@hotmail.com*에서 대량의 메시지가 전송되는 것을 알아차리면 해당 이메일이 본인 소유의 아웃바운드 이메일 전송 도메인에서 발송되는 이메일과 다르게 처리됩니다.
+ 도메인의 WHOIS 정보가 정확할 수 있도록 도메인 등록 기관과 정보를 공유하세요. WHOIS 레코드를 거짓 없이 최신 상태로 유지할 경우 투명성을 중요하게 생각한다는 사실을 잘 드러낼 뿐만 아니라 사용자들은 도메인의 적합성 여부를 빠르게 판단할 수 있습니다.
+ *no-reply@example.com*과 같은 *발신 전용(no-reply)* 주소를 ‘발신’ 또는 ‘회신’ 주소로 사용하지 마십시오. *no-reply@* 이메일 주소를 사용하면 수신자가 따로 연락할 방법은 없으며, 보내주는 피드백에도 관심이 없다는 메시지를 분명하게 보여주는 셈입니다.
## Authentication
+ [SPF](send-email-authentication-spf.md) 및 SenderID를 사용하여 도메인을 인증합니다. 이러한 인증 방법은 전송하는 이메일 하나하나가 실제로 명시된 도메인에서 발송되었다는 사실을 이메일 수신자에게 입증하는 역할을 합니다.
+ [DKIM](send-email-authentication-dkim.md)을 사용하여 발신 메일에 서명합니다. 이 단계를 통해 발신자로부터 수신자에게 전송되는 도중 변경된 내용이 없다는 사실을 수신자에게 보장할 수 있습니다.
+ 개인용 Gmail이나 Hotmail 계정 같은 본인 소유의 ISP 기반 이메일 주소로 이메일을 보낸 다음 메시지 헤더를 확인하면서 SPF 인증 설정과 DKIM 인증 설정을 테스트할 수 있습니다. 헤더는 메시지 인증 및 서명의 성공 여부를 나타냅니다.
## 목록 작성 및 유지
+ 더블 옵트인 전략을 사용하세요. 사용자가 이메일 수신에 동의할 때는 확인 링크가 포함된 메시지를 보내세요. 그리고 사용자가 해당 링크를 클릭하여 주소를 확인할 때까지는 이메일을 보내지 마세요. 더블 옵트인 전략은 오타로 인한 하드 바운스 수를 줄이는 데 효과적입니다.
+ 웹 기반 형식으로 이메일 주소를 수집할 때는 제출 직후 실시하는 주소의 유효성 검증을 최소화하세요. 예를 들어 수집하는 주소가 올바른 형식인지(즉, *recipient@example.com* 형식 여부), 그리고 참조 도메인이 유효한 MX 레코드로 구성되어 있는지 확인하면 됩니다.
+ 사용자 정의 입력 데이터가 확인되지 않은 채로 Amazon SES로 전달될 때는 주의하세요. 포럼 등록이나 포럼 제출은 모두 사용자가 작성한 콘텐츠일 뿐만 아니라 스패머가 자신이 원하는 내용으로 포럼을 작성할 수도 있기 때문에 항상 고유 위험이 존재합니다. 고품질의 콘텐츠가 포함된 이메일만 보내도록 확인하는 것은 사용자의 책임입니다.
+ 표준 별칭(*postmaster@*, *abuse@*, *noc@* 등)은 의도적으로 이메일에 가입할 가능성이 매우 낮습니다. 메시지는 실제로 수신을 원하는 사람들에게만 보내야 합니다. 이러한 규칙은 특히 관례상 이메일 워치독 전용으로 사용되는 표준 별칭에서 더욱 그렇습니다. 이러한 별칭은 고의적 방해 행위로서 평판을 떨어뜨릴 목적으로 목록에 악의적으로 추가되기도 합니다.
## 규정 준수
+ 이메일을 전송하는 대상 국가와 리전의 이메일 마케팅 및 스팸 방지 법률과 규정에 대해서 잘 알고 있어야 합니다. 사용자는 전송하는 이메일이 이러한 법률을 준수하는지 확인할 책임이 있습니다. 본 안내서에서는 이러한 법률을 다루지 않으므로 사용자가 직접 조사해야 합니다. 법률 목록은 Wikipedia의 [Email Spam Legislation by Country](https://en.wikipedia.org/wiki/Email_spam_legislation_by_country)를 참조하세요.
+ 항상 변호사에게 문의하여 법률 자문을 받으세요.
# AWS SDK에서 Amazon SES 사용
AWS 소프트웨어 개발 키트(SDKs)는 널리 사용되는 많은 프로그래밍 언어에 사용할 수 있습니다. 각 SDK는 개발자가 선호하는 언어로 애플리케이션을 쉽게 구축할 수 있도록 하는 API, 코드 예제 및 설명서를 제공합니다.
| SDK 설명서 | 코드 예제 |
| --- | --- |
| [AWS SDK for C\$1\$1](https://docs.aws.amazon.com/sdk-for-cpp) | [AWS SDK for C\$1\$1 코드 예제](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/cpp) |
| [AWS CLI](https://docs.aws.amazon.com/cli) | [AWS CLI 코드 예제](https://docs.aws.amazon.com/code-library/latest/ug/cli_2_code_examples.html) |
| [AWS SDK for Go](https://docs.aws.amazon.com/sdk-for-go) | [AWS SDK for Go 코드 예제](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/gov2) |
| [AWS SDK for Java](https://docs.aws.amazon.com/sdk-for-java) | [AWS SDK for Java 코드 예제](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javav2) |
| [AWS SDK for JavaScript](https://docs.aws.amazon.com/sdk-for-javascript) | [AWS SDK for JavaScript 코드 예제](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javascriptv3) |
| [AWS SDK for Kotlin](https://docs.aws.amazon.com/sdk-for-kotlin) | [AWS SDK for Kotlin 코드 예제](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/kotlin) |
| [AWS SDK for .NET](https://docs.aws.amazon.com/sdk-for-net) | [AWS SDK for .NET 코드 예제](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/dotnetv3) |
| [AWS SDK for PHP](https://docs.aws.amazon.com/sdk-for-php) | [AWS SDK for PHP 코드 예제](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/php) |
| [AWS Tools for PowerShell](https://docs.aws.amazon.com/powershell) | [AWS Tools for PowerShell 코드 예제](https://docs.aws.amazon.com/code-library/latest/ug/powershell_5_code_examples.html) |
| [AWS SDK for Python (Boto3)](https://docs.aws.amazon.com/pythonsdk) | [AWS SDK for Python (Boto3) 코드 예제](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/python) |
| [AWS SDK for Ruby](https://docs.aws.amazon.com/sdk-for-ruby) | [AWS SDK for Ruby 코드 예제](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/ruby) |
| [AWS SDK for Rust](https://docs.aws.amazon.com/sdk-for-rust) | [AWS SDK for Rust 코드 예제](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/rustv1) |
| [AWS SDK for SAP ABAP](https://docs.aws.amazon.com/sdk-for-sapabap) | [AWS SDK for SAP ABAP 코드 예제](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/sap-abap) |
| [AWS SDK for Swift](https://docs.aws.amazon.com/sdk-for-swift) | [AWS SDK for Swift 코드 예제](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/swift) |
Amazon SES 관련 예는 [AWS SDK를 사용한 Amazon SES용 코드 예제](service_code_examples.md) 섹션을 참조하세요.
**예제 가용성**
필요한 예제를 찾을 수 없습니까? 이 페이지 하단의 **피드백 제공** 링크를 사용하여 코드 예시를 요청하세요.