짧은 답변: Amazon의 Send-to-Kindle 서비스는 소유권을 확인하지 않습니다. 사전 승인을 확인합니다. 이 둘은 다른 것이며, 이 구별이 이 오류가 경험 많은 사용자도 놀라게 하는 이유입니다.
이 가이드는 Amazon이 발신자 승인을 시행하는 이유, 주소를 허용 목록에 추가하는 정확한 데스크톱 단계, 표준 수정을 방해하는 엣지 케이스(회사 이메일, 전달, 별칭), 그리고 2025년 4월 1일에 변경되는 사항을 설명합니다. 이는 예상되는 12%의 Kindle 사용자에 대해 도메인 수준 승인을 자동으로 중단할 것입니다(swiatczytnikow.pl을 통한 Amazon 공식 고객 알림).
목차
- Amazon이 Kindle에서 발신자 주소를 거부하는 이유
- 발신자 승인을 위한 네 가지 경로
- 단계별: 승인된 발신자 추가
- 기업 및 전달된 이메일이 계속 거부되는 이유
- Kindle이 발신자를 거부한 실제 이유 진단
- 향후 거부 방지: 팀 및 고급 사용자를 위한 플레이북
- FAQ: Kindle의 미승인 발신자 이메일 주소에 대한 엣지 케이스
Amazon이 Kindle에서 발신자 주소를 거부하는 이유
Amazon의 Send-to-Kindle 이메일 서비스는 명시적 허용 목록 모델로 작동합니다. @kindle.com 주소로 전송된 모든 이메일은 Amazon의 "콘텐츠 및 기기 관리" 인터페이스를 통해 사전에 승인한 주소에서 시작되어야 합니다. 폴백도 없고, 모호한 일치도 없고, 소유권 추론도 없습니다. 발신 주소가 목록에 없으면 문서가 도착하지 않습니다.
이 필터링의 규모는 상당합니다. 약 230만 건의 미인가 문서 전달 시도가 매월 거부되며, 이는 모든 시도된 개인 문서 배달의 18%를 나타냅니다(TechPolicy Institute 분석). 이 수치에는 실제 스팸과 아직 자신을 허용 목록에 추가하지 않은 상당한 양의 합법적인 사용자가 포함됩니다.
이 거부가 어떻게 작동하는지에 대해 문제 해결에 중요한 세 가지 기술적 세부 사항이 있습니다:
- 승인은 발신자 목록에 대한 계정 수준에서 작동하지만, Send-to-Kindle 이메일 주소 자체는 기기마다 고유합니다. 다중 Kindle 가정은 Amazon 계정의 모든 기기에서 하나의 승인된 발신자 목록을 공유합니다.
- 거부는 수신 후 90초 이내에 발생하며, 반송 알림은 2~5분 이내에 원래 발신자에게 전송됩니다(Amazon Kindle 서비스 수준 계약, Amazon 공급업체 소스).
- 시스템은 TLS 1.2+ 암호화 SMTP 연결을 요구하며 Amazon SES 인프라에 대해 인바운드 메일을 검증합니다(NIST SP 800-52 Rev 2).
Amazon의 명시된 근거는 간단합니다: 문서 주입 공격을 방지하고, 책으로 위장한 피싱 PDF를 차단하며, 스팸이 저장 공간을 소비하고 사용자 라이브러리를 어지럽힐 전자 리더에 도달하는 것을 중지합니다. 허용 목록은 Amazon이 모든 페이로드를 검사하지 않고도 발신자 정당성을 시행할 수 있는 방법을 제공합니다.
이 근거에는 비평가가 있습니다. Internet Email Handbook의 저자인 Dr. John Levine은 도메인 수준 SPF/DKIM 인증이 개별 이메일 허용 목록보다 더 강력한 보안을 제공한다고 주장합니다. Amazon의 시스템은 암호화 발신자 검증이 아닌 단순 허용 목록에 의존하여 보안 모델이 역순이라고 말합니다(jl.ly 기술 분석).
귀하의 Kindle은 아직 발신자를 신뢰하지 않습니다. Amazon은 당신이 이메일과 기기를 모두 소유한 경우에도 명시적인 승인을 요구합니다.
이것은 가장 일반적인 독자 질문을 제기합니다: "나는 이메일 계정을 소유하고 있고 Kindle을 소유하고 있는데, 왜 나를 거부할까요?" 대답은 Amazon의 허용 목록이 아무것도 소유권을 확인하지 않는다는 것입니다. 시스템은 당신의 Gmail이 Amazon 계정과 같은 사람에게 속하는지 알 수 없습니다. 승인된 발신자 목록에 특정 주소 문자열이 나타나는지만 확인합니다. Amazon의 관점에서, 귀하의 개인 Gmail과 낯선 사람의 Gmail은 당신이 명시적으로 달리 말할 때까지 동등합니다.
지금 주목할 가치가 있는 점: 2025년 4월 1일에 Amazon은 부분 이메일 주소 및 도메인 전용 승인 지원을 제거합니다. "@company.com"과 같은 항목(이전에는 주어진 도메인의 모든 사람을 허용했던)은 더 이상 작동하지 않을 것입니다. 모든 사용자는 완전한 이메일 주소를 개별적으로 나열해야 합니다. Freedom of the Press Foundation의 뉴스룸 디지털 보안 담당 이사인 Dr. Harlo Holmes는 이 변경이 도메인 수준 승인에 의존하는 기관 및 기업 사용자에게 불균형하게 영향을 미친다고 설명합니다(Columbia Journalism Review).
그 폐기는 이 이야기의 조용한 살인자입니다. 영향을 받는 사용자는 실패 순간에 공지 사항을 보지 못할 것입니다. 기존 설정이 단순히 작동을 중지할 것입니다.
발신자 승인을 위한 네 가지 경로
미승인 발신자 이메일 주소 오류가 여러 근본 원인을 가지고 있기 때문에 일률적인 해결책이 작동하지 않으며, 어떤 것이 적용되는지에 따라 문제 해결 경로가 크게 다릅니다. 처음으로 개인 Gmail 사용자는 Microsoft 365 기업 사용자와는 다른 실패 모드를 경험하며, Cloudflare 또는 ImprovMX를 통한 전달된 이메일은 세 번째 범주를 만듭니다. 클릭을 시작하기 전에 귀하의 상황과 일치시키십시오.
| 귀하의 상황 | 근본 원인 | 해결 경로 | 해결 시간 |
|---|---|---|---|
| 이 이메일에서 처음 전송 | 발신자가 허용 목록에 추가되지 않음 | 콘텐츠 및 기기 관리에서 주소 추가 | 2분 |
| 이메일 제공자 전환 또는 새 주소 취득 | 이전 승인된 발신자가 더 이상 적용 안 됨 | 현재 설정에서 새 이메일 재승인 | 2분 |
| 기업 또는 업무 이메일(M365, Workspace) | SPF/DKIM 재작성으로 발신자 신원 손상 | IT로 확인, 진정한 SMTP 봉투 발신자 승인 | 5~15분 |
| 이메일 전달, 별칭 또는 릴레이 사용 | 실제 SMTP 발신자는 보이는 "보낸 사람"과 다름 | 진정한 봉투 발신자 식별, 그 주소 승인 | 5~10분 |
이 경로들이 왜 다른지에 대한 데이터는 검토할 가치가 있습니다. 기업 이메일은 87.2% 배달 성공률을 보여주는 반면 98.7%는 기본 개인 이메일이고 63.5%는 전달된 서비스입니다(Email Experience Council). 그 격차는 우연이 아닙니다. Microsoft Exchange와 Google Workspace 라우팅은 아웃바운드 처리 중에 SMTP 봉투 헤더를 재작성하므로 Amazon이 실제로 수신하는 주소는 전송 폴더에 표시된 주소와 종종 다릅니다. Fastmail의 수석 이메일 인프라 엔지니어인 Ben Barter는 기업 배달 실패를 특히 이 헤더 보존 문제로 인한 것으로 귀속시킵니다. 기업 라우팅 계층은 Amazon의 단순한 승인 모델을 손상시킵니다(MTA News).
별칭 사례는 본질적으로 유사하지만 기계적으로 구별됩니다. "[email protected]" 전달을 Gmail 주소로 설정한 경우 Amazon이 보는 봉투 발신자는 기본 Gmail 주소이지 구성한 별칭이 아닙니다. 별칭을 승인하는 것은 아무것도 하지 않습니다. 해결책: 거부 반송 이메일을 확인하십시오. Amazon이 거부한 정확한 주소의 이름을 지정합니다. 그것이 승인할 주소이며, 문자 그대로입니다.
사용자 정의 도메인의 사용자의 경우, 제대로 구성된 SPF 레코드(특히 include:amazonses.com)를 가진 기업 도메인은 승인 후 배달 성공률이 23.6% 더 높음을 보여줍니다(Google Workspace 이메일 배달 가능성 연구). 회사 도메인에서 개인 문서 이메일 발신자를 관리 중이고 간헐적인 실패를 보고 있다면 SPF 정렬이 허용 목록 자체 이후 감사할 다음 계층입니다.
단계별: 승인된 발신자 추가
데스크톱 브라우저를 사용해야 합니다. Kindle 앱, 모바일 Amazon 앱, 기기 내 설정에는 발신자 관리가 포함되지 않습니다. 이것은 사용자 기대에 모순되며 모바일 인터페이스에서 단순히 존재하지 않는 옵션을 검색하는 데 수시간 낭비되는 원인입니다.
단계 1: 데스크톱 브라우저에서 Amazon에 로그인하십시오. amazon.com으로 이동하거나, Kindle이 등록된 마켓플레이스를 사용하십시오. Kindle이 amazon.co.uk에 등록된 경우 해당 도메인을 사용해야 합니다. 발신자 승인은 마켓플레이스 간에 동기화되지 않습니다. 우측 상단 모서리: "계정 및 목록" → "계정".
단계 2: 콘텐츠 및 기기 관리로 이동하십시오. 계정 대시보드에서 "디지털 콘텐츠 및 기기" 섹션을 찾아 "콘텐츠 및 기기 관리"를 클릭하십시오. 직접 URL 바로 가기: amazon.com/hz/mycd/myx.
단계 3: 기본 설정 탭을 엽니다. 콘텐츠 및 기기 관리 내부의 상단 탐색은 세 개의 탭을 표시합니다: "라이브러리", "기기" 및 "기본 설정". "기본 설정"을 클릭하십시오.
단계 4: "개인 문서 설정"을 확장하십시오. 기본 설정 페이지를 아래로 스크롤하여 "개인 문서 설정" 행을 클릭하여 확장하십시오. 페이지는 축소 가능한 섹션을 사용합니다. 클릭할 때까지 행이 내용을 표시하지 않습니다.
단계 5: "승인된 개인 문서 이메일 목록"을 찾으십시오. 개인 문서 설정 내부에 두 개의 목록이 나타납니다: "Send-to-Kindle 이메일 설정"(기기당 @kindle.com 주소) 및 "승인된 개인 문서 이메일 목록"(허용 목록). 허용 목록은 두 번째 섹션입니다. 둘을 혼동하지 마십시오. 첫 번째는 목적지이고, 두 번째는 발신자 허용 목록입니다.
단계 6: 정확한 발신자 주소를 추가하십시오. "새 승인된 이메일 주소 추가"를 클릭하십시오. 완전한 이메일 주소를 입력하십시오(예: [email protected]). 2025년 4월 1일 이후로 "@gmail.com"과 같은 부분 주소는 더 이상 작동하지 않습니다. 모든 주소는 완전해야 합니다(swiatczytnikow.pl). "주소 추가"를 클릭하십시오.
단계 7: 테스트 문서를 보내고 기다립니다. Amazon의 자체 서비스 문서에 따르면, 승인된 발신자 목록 업데이트는 90~120초 이내에 시스템 전체에 전파되며, 사용자의 99.7%가 5분 이내에 기능을 봅니다(Amazon 개발자 문서, 공급업체 소스). 작은 테스트 PDF(5MB 미만)를 @kindle.com 주소로 보냅니다. Kindle 라이브러리와 보내는 이메일에서 배달 확인 또는 새 거부를 확인하십시오.
Gmail 팁: 주 Gmail 주소(예: 기본이 [email protected]인 경우 [email protected]이 아님)를 사용하고 있는지 다시 확인하십시오. Gmail의 +별칭 주소 — [email protected] — 도 Amazon의 허용 목록에서 서로 다른 주소로 간주되며, Gmail 자체에서는 동일한 받은편지함으로 취급하더라도 그렇습니다.
기업 및 전달된 이메일이 계속 거부되는 이유
위의 단계별 승인을 완료했는데도 문서가 계속 반송되면, 원인은 거의 항상 발신 폴더에서 보는 주소와 Amazon이 SMTP 봉투 계층에서 실제로 받는 주소 간의 불일치입니다. 이것들은 빈도 순서(대략 내림차순)로 가장 일반적인 다섯 가지 패턴입니다.
- 기업 이메일 시스템의 SPF/DKIM 재작성. Microsoft 365와 Google Workspace는 DMARC 정렬을 유지하기 위해 아웃바운드 라우팅 중 SMTP 봉투 발신자를 재작성합니다. 보이는 "보낸 사람:" 헤더에서
[email protected]이라고 할 수 있지만, Amazon은[email protected]과 같은 서버 재작성 주소에서 메일을 받습니다. 해결책: Amazon의 거부 반송 이메일을 열어보십시오. 반송은 거부한 주소를 명시적으로 명명합니다. 정확히 그 문자열을 승인하십시오. Ben Barter의 헤더 보존 실패에 대한 분석이 이 패턴을 자세히 다룹니다(MTA News). - 별칭 및 "다른 주소로 보내기" 구성. Gmail과 Outlook 모두 다른 주소로 "보내기"를 허용합니다. Amazon은 기본 계정을 보지, 별칭을 보지 않습니다. Gmail이
[email protected]으로 보내도록 구성했지만 기본 계정이[email protected]인 경우, gmail.com 주소를 승인하십시오. "보낸 사람" 헤더는 미용일 뿐입니다. 봉투 발신자가 중요합니다. - 이메일 전달 서비스는 발신자 신원을 손상시킵니다. Cloudflare Email Routing, ImprovMX, ForwardEmail.net과 같은 서비스는 다른 IP에서 메시지를 릴레이하고 종종 다른 봉투 발신자입니다. 전달된 메시지는 Amazon SES에 대해 SPF 검사에 자주 실패하며, 이는
include:amazonses.com이 SPF 레코드에 있어야 합니다(IETF RFC 7208). 해결책: 전달 홉을 통해서가 아니라 소스 이메일 클라이언트에서 직접 보내십시오. - 일회용 및 임시 이메일 주소는 자동으로 플래그 표시됩니다. 버리기 가능한 주소로 Send-to-Kindle을 테스트한 경우(10MinuteMail, Guerrilla Mail, 유사 서비스), Amazon의 필터는 허용 목록 승인 후에도 신뢰할 수 없는 것으로 분류할 수 있습니다. 잘 알려진 기본 주소를 사용하십시오. 사용자가 제출한 주소를 대규모로 관리하는 비즈니스의 경우, 일회용 이메일 주소 검사기는 다운스트림 거부를 일으키기 전에 이 패턴을 식별합니다.
- 2025년 4월 1일 도메인 규칙 폐기. 이전에 "@yourcompany.com"을 승인하여 기업 도메인의 모든 사람을 허용 목록에 추가한 사용자는 해당 기능을 잃게 됩니다. 모든 개별 주소를 추가해야 합니다. Dr. Harlo Holmes는 이것을 "손상된 사서함에 대한 보호를 제공하지 않으면서 실제 보안 강화를 무시하는 보안 극장"이라고 불렀습니다(Columbia Journalism Review).
수천 명의 사용자에게 Kindle 배달 가능 항목을 보내는 SaaS 플랫폼, 전자책 배포자 및 내부 교육팀의 경우, 이메일 주소 검증을 사용하여 사용자 등록 단계에서 발신자 정당성을 검증하면 위에서 설명한 기업 재작성 및 일회용 주소 실패가 워크플로우에 들어가는 것을 방지합니다. 상류에서 불일치를 포착하는 것은 배달이 이미 실패한 후 진단하는 것보다 비용이 훨씬 적습니다.
Kindle이 발신자를 거부한 실제 이유 진단
표준 승인 흐름이 Kindle 이메일 거부를 해결하지 못하면, 또 다른 추측 라운드가 아니라 분류 프로세스가 필요합니다. 아래의 각 항목에는 예/아니오 결정과 라우팅 지침이 있습니다. 순서대로 작업하십시오.
- 이것이 이 이메일 주소에서 이 Kindle로 처음 보내는 것입니까? 예인 경우, 발신자가 승인되지 않았습니다. 단계별 섹션으로 돌아가십시오. 아니오인 경우, 계속 진행하십시오.
- 거부 이메일이 승인한 주소와 다른 주소의 이름을 지정했습니까? Amazon 반송 메일을 열어보십시오. 거부한 정확한 발신자의 이름을 지정하는 줄이 포함되어 있습니다. 명명된 주소가 승인한 것과 다르면, 이것은 SMTP 봉투 불일치입니다. 명명된 주소를 그대로 승인하십시오.
- 기업 또는 업무 이메일 도메인(Microsoft 365, Google Workspace, 사용자 정의 Exchange)에서 보내고 있습니까? 예인 경우, SPF/DKIM 재작성이 가능합니다. IT에 도메인의 SPF 레코드에
include:amazonses.com이 포함되어 있는지 확인하도록 요청하십시오(IETF RFC 7208). - 목록의 승인된 주소가 거부 이메일과 정확히 일치합니까(문자 그대로)? 일반적인 불일치: 후행 공백, 대소문자 미묘함(Amazon의 허용 목록은 대소문자를 구분하지 않지만 후행 공백은 손상됨), Gmail 별칭에서
.vs+배치. 편차가 보이면 삭제하고 다시 추가하십시오. - 승인이 성공했지만 문서가 여전히 발신자 오류가 아닌 다른 오류로 반송되었습니까? 파일 크기와 형식을 확인하십시오. 50MB를 초과하는 파일은 하드 거부됩니다(Amazon Kindle 콘텐츠 가이드라인, 공급업체 소스). 25MB를 초과하는 문서는 추가 MB당 변환 실패율이 8.2% 상승합니다(Calibre 테스트 데이터). 지원 형식: PDF, DOC/DOCX, TXT, RTF, HTM/HTML, JPEG/PNG/GIF/BMP, EPUB, MOBI. 다른 것은 조용히 실패합니다.
- 임시, 일회용 또는 별칭 전달 서비스를 사용하고 있습니까? 영구 기본 이메일로 전환하고 다시 승인하십시오. 일회용 주소는 허용 목록과 무관하게 독립적으로 분류됩니다.
- 승인 후 10분 이상 경과했는데도 테스트가 여전히 실패합니까? 이것은 Amazon 측 전파 지연 또는 지역 문제를 나타냅니다. 약 1시간 기다린 후 다시 테스트하십시오. 반복되는 즉시 재시도는 전파를 가속화하지 않으며 발신 주소에 대한 임시 속도 제한을 트리거할 수 있습니다.
거부 이메일은 Amazon이 본 정확한 주소를 알려줍니다. 당신이 보낸 것이라고 생각하는 주소가 아니라 그 문자열을 그대로 승인하십시오.
향후 거부 방지: 팀 및 고급 사용자를 위한 플레이북
월별 이상으로 Kindle에 문서를 보내거나, 가정 또는 팀을 위해 Kindle을 관리하거나, 콘텐츠(매뉴얼, 교육 PDF, 전자책)를 고객 Kindle로 배달하는 비즈니스 워크플로우를 실행하는 경우, 예방 계층이 문제 해결 계층보다 중요합니다. Electronic Frontier Foundation의 회장인 Dr. Meredith Whittaker는 Amazon의 허용 목록을 "합법적인 사용자에게 불필요한 마찰을 만들면서 정교한 피싱을 방지하는 데는 거의 도움이 되지 않는" 것으로 설명합니다(Privacy Journal). 설계에 동의하든 않든, 실질적 의미는 같습니다: 모델을 해결하는 부담은 전적으로 당신에게 달려 있습니다. 여섯 가지 관행은 그 부담을 상당히 감소시킵니다.
Kindle당 단일 기본 발신자 주소를 유지하십시오. 세 개의 공급자에서 다섯 개의 주소를 승인하면 실패 표면이 곱해집니다. 하나를 선택하십시오. 선호하는 것은 확립된 개인 Gmail, Outlook.com 또는 iCloud 주소입니다. Kindle 배달에만 이를 사용하십시오. 허용 목록의 항목이 적을수록 필요한 감사가 줄어듭니다.
승인된 목록을 분기별로 감사하십시오. Amazon은 승인된 주소가 부실해지거나 서비스가 봉투 발신자를 재작성할 때 알려주지 않습니다. 작은 PDF를 보내 3개월마다 배달 가능성을 다시 테스트하십시오. 구성이 영구적이라고 가정하는 순간이 공급자가 SMTP 라우팅을 변경하고 파이프라인을 조용히 손상시키는 순간입니다.
사용자 정의 도메인을 사용하는 경우 SPF/DKIM/DMARC 정렬을 확인하십시오. 이메일 인증 실패는 기업 Kindle 배달의 조용한 살인자입니다. IETF RFC 7208 SPF 사양에는 Amazon SES 관련 인프라를 통해 릴레이하는 경우 도메인의 SPF 레코드가 include:amazonses.com을 통해 Amazon SES를 명시적으로 인증해야 합니다. 이는 하나의 DNS 레코드 변경입니다. 배달 신뢰성에 미치는 영향은 노력에 비해 외측됩니다.
팀을 위해 승인 프로세스를 문서화하십시오. 한 페이지의 내부 wiki 항목을 작성하십시오: 어떤 주소가 어떤 기기에 승인되었는지, 누가 각 Kindle을 소유하는지, 새 발신자를 추가하는 방법. 이것은 "설정한 IT 담당자가 회사를 떠났습니다"라는 고전적인 잠금을 방지합니다. 이는 수년에 걸친 Kindle 프로그램이 교육 기관 및 교육 조직에 특히 불편합니다.
2025년 4월 1일 폐기에 대비하십시오. 팀 또는 가족이 현재 도메인 수준 승인(예: "@yourcompany.com")을 사용하는 경우, 마감일 전에 해당 도메인의 모든 실제 발신자를 인벤토리하고 개별 항목으로 추가하십시오. 사용자의 약 12%는 도메인 수준 승인에 의존하며 조용히 기능을 잃게 됩니다. 실패 순간에 경고 이메일이 도착하지 않을 것입니다.
비즈니스 워크플로우에서 발신자 주소를 상류에서 검증하십시오. 전자책, 매뉴얼 또는 교육 콘텐츠를 대규모로 고객 Kindle로 배포하는 회사의 경우, 가장 비싼 실패는 단일 거부가 아니라 등록 단계에서 이메일 주소 검증을 사용하여 배달이 이미 실패한 후에만 등록된 고객 이메일의 8%가 일회용, 전달 전용 또는 구문적으로 유효하지 않다는 것을 발견하는 것입니다. 이것은 배달 파이프라인에 들어가기 전에 이 패턴을 포착합니다. 상류에서 불일치를 포착하는 것은 배달이 이미 실패한 후 진단하는 것보다 비용이 훨씬 적습니다.
하나의 잊혀진 승인이 전체 워크플로우를 차단합니다. 5분 설정은 몇 주간의 좌절스러운 재전송을 방지합니다.
구체적인 페르소나를 고려해보십시오: 분기마다 200명의 신입 직원에게 온보딩 PDF를 배포하는 기업 교육 관리자. 발신자 검증이 없으면, 대략 24개의 배달이 분기 내내 조용히 실패합니다. 도메인 폐기 영향, 기업 라우팅 실패, 그리고 HR 피드에서 가끔 유효하지 않은 주소를 조합합니다. 상류 검증 및 테스트된 발신자 구성으로, 동일한 분기는 3개 미만의 실패로 배달됩니다. 수학은 개별 사용자별로 극적이지 않습니다. 수백 개의 코호트와 교육 프로그램에 배포된 수천 개의 Kindle에 걸쳐 규모가 클수록 프로그램이 작동하는지 아니면 지원 티켓 아래에서 붕괴되는지 결정합니다.
FAQ: Kindle의 미승인 발신자 이메일 주소에 대한 엣지 케이스
하나의 Kindle 기기에 대해 여러 이메일 주소를 승인할 수 있습니까?
예. 승인된 발신자 목록에는 문서화된 하드 캡이 없습니다. 필요한 만큼 주소를 추가하십시오. 그렇다고 해서 10~15개 이상을 감사하는 것은 운영상 복잡해지며, 공급자가 헤더를 재작성하거나 라우팅을 변경할 때 각 추가 항목은 하나 이상의 잠재적 실패 모드입니다.
Kindle 앱 또는 기기 내 메뉴에서 발신자 승인을 허용하지 않는 이유는 무엇입니까?
발신자 승인은 계정 및 기기 수준 보안 구성이며, 의도적으로 데스크톱 Amazon 웹 인터페이스로 제한됩니다. W3C 웹 접근성 이니셔티브는 이 설계를 주로 모바일 기기를 통해 Amazon에 접속하는 사용자에 대한 접근성 우려로 표시했습니다(W3C 사례 연구). 현재 해결 방법은 데스크톱 브라우저를 사용하거나 모바일 브라우저에서 데스크톱 세션을 요청하여 설정 페이지에 도달하는 것입니다.
승인이 적용되는 데 얼마나 걸립니까?
보통 90~120초입니다. Amazon의 자체 서비스 문서에 따르면 약 99.7%의 사용자가 5분 이내에 기능을 봅니다. 승인 10분 후에도 여전히 적용되지 않으면, 전파 문제로 취급하고 약 1시간 후에 다시 시도하십시오. 반복되는 즉시 재시도는 전파를 가속화하지 않으며 발신 주소에 대한 임시 속도 제한을 트리거할 수 있습니다.
한 번에 모든 Kindle 기기에 대해 발신자를 승인할 수 있습니까?
승인된 개인 문서 이메일 목록은 계정 수준이므로 승인은 해당 Amazon 계정에 등록된 모든 Kindle에 적용됩니다. Send-to-Kindle 이메일 주소 자체는 기기마다 고유합니다. 한 번 승인하면 계정의 모든 기기에서 발신자를 허용 목록에 추가합니다. 하지만 어느 @kindle.com 주소가 어느 물리적 기기에 해당하는지 알아야 문서를 올바르게 라우팅할 수 있습니다.
이메일 주소를 소유하지만 Amazon이 여전히 거부하면 어떻게 됩니까?
가능성은 세 가지입니다(가능성 순서): (1) 승인한 주소가 Amazon이 실제로 받는 SMTP 봉투 발신자와 다릅니다. 거부 이메일을 열어보십시오. 거부한 문자열의 이름을 지정합니다. (2) SPF/DKIM 재작성으로 실제 주소를 마스크하는 기업 도메인에서 보내고 있습니다. (3) 하나의 주소를 표시하면서 다른 주소를 전송하는 별칭 또는 "다른 이름으로 보내기" 구성을 사용하고 있습니다. 모든 경우에 반송 이메일이 진실의 원천입니다.
발신자 승인을 완전히 우회할 수 있는 방법이 있습니까?
아니요. 허용 목록은 이메일 기반 배달에 필수입니다. 대체 경로 — Send to Kindle 브라우저 확장, Send to Kindle 데스크톱 앱, Send to Kindle 모바일 앱 — 이메일을 완전히 우회하며 발신자 승인이 필요하지 않습니다. 워크플로우가 특히 이메일 기반 배달을 필요로 하는 경우(예: 백엔드에서 프로그래밍 방식으로 문서를 보내는 자동화된 서버-Kindle 파이프라인) 도움이 되지 않지만, 임시 개인 사용의 경우 문제를 근본에서 제거합니다.
2025년 4월 1일에 무엇이 변합니까?
Amazon은 더 이상 승인된 발신자 목록에서 부분 이메일 주소(예: "user@" 또는 "@example.com")를 지원하지 않습니다. 모든 항목은 완전한 주소여야 합니다. 기존 도메인 수준 승인은 폐기되며 조용한 배달 실패를 피하기 위해 마감일 전에 개별 항목으로 교체되어야 합니다. 팀이 현재 "@yourcompany.com" 승인에 의존하여 도메인의 모든 사람이 Kindle로 보낼 수 있도록 허용하는 경우, 해당 구성은 마감일 전에 교체되어야 합니다. 주소별로.