Jawaban singkatnya: layanan Send-to-Kindle milik Amazon tidak memverifikasi kepemilikan. Layanan ini memverifikasi pra-otorisasi. Ini adalah hal yang berbeda, dan perbedaan inilah mengapa kesalahan ini mengejutkan bahkan pengguna berpengalaman.
Panduan ini memandu melalui alasan Amazon menerapkan persetujuan pengirim sama sekali, langkah desktop yang tepat untuk memasukkan alamat Anda dalam daftar putih, kasus tepi yang merusak perbaikan standar (email korporat, penerusan, alias), dan apa yang berubah pada 1 April 2025 yang akan diam-diam memecahkan persetujuan tingkat domain untuk perkiraan 12% pengguna Kindle (Notifikasi Pelanggan Resmi Amazon melalui swiatczytnikow.pl).
Daftar Isi
- Mengapa Amazon Menolak Alamat Pengirim pada Kindle
- Empat Jalur Persetujuan Pengirim
- Langkah demi Langkah: Menambahkan Pengirim yang Disetujui
- Mengapa Email Korporat dan Email yang Diteruskan Masih Ditolak
- Mendiagnosis Alasan Sebenarnya Kindle Anda Menolak Pengirim
- Mencegah Penolakan Masa Depan: Playbook untuk Tim dan Power User
- FAQ: Kasus Khusus untuk Alamat Email Pengirim yang Tidak Disetujui pada Kindle
Mengapa Amazon Menolak Alamat Pengirim pada Kindle
Layanan email Send-to-Kindle milik Amazon beroperasi dengan model daftar putih eksplisit. Setiap email yang dikirim ke alamat @kindle.com Anda harus berasal dari alamat yang telah Anda pra-setujui melalui antarmuka "Kelola Konten dan Perangkat Anda" milik Amazon. Tidak ada fallback, tidak ada pencocokan fuzzy, tidak ada inferensi kepemilikan. Jika alamat pengiriman tidak ada dalam daftar, dokumen tidak sampai.
Skala penyaringan ini sangat besar. Sekitar 2,3 juta upaya dokumen tidak sah ditolak setiap bulan, mewakili 18% dari semua upaya pengiriman dokumen pribadi (Analisis TechPolicy Institute). Angka tersebut mencakup spam asli dan volume signifikan dari pengguna legitim yang belum memasukkan diri mereka ke daftar putih.
Tiga detail teknis tentang cara penolakan ini bekerja penting untuk pemecahan masalah:
- Persetujuan beroperasi pada tingkat akun untuk daftar pengirim, tetapi alamat email Send-to-Kindle itu sendiri adalah unik per perangkat. Rumah tangga multi-Kindle berbagi satu daftar pengirim yang disetujui di semua perangkat di akun Amazon.
- Penolakan terjadi dalam 90 detik dari penerimaan, dengan notifikasi bounce dikirim ke pengirim asli dalam 2–5 menit (menurut Perjanjian Tingkat Layanan Kindle Amazon, sumber vendor Amazon).
- Sistem memerlukan koneksi SMTP terenkripsi TLS 1.2+ dan memvalidasi email masuk terhadap infrastruktur Amazon SES (NIST SP 800-52 Rev 2).
Rasionalisasi yang dinyatakan Amazon sangat jelas: cegah serangan injeksi dokumen, blokir PDF phishing yang menyamar sebagai buku, dan hentikan spam dari mencapai e-reader tempat spam akan mengkonsumsi penyimpanan dan mengacaukan perpustakaan pengguna. Daftar putih memberi Amazon cara untuk menegakkan legitimasi pengirim tanpa memeriksa setiap payload.
Rasionalisasi itu memiliki kritikus. Dr. John Levine, penulis Internet Email Handbook, berpendapat bahwa autentikasi SPF/DKIM tingkat domain memberikan keamanan yang lebih kuat daripada whitelisting email individual — dan bahwa sistem Amazon, dengan mengandalkan daftar allow-list sederhana daripada verifikasi pengirim kriptografi, memiliki model keamanan yang terbalik (analisis teknis jl.ly).
Kindle Anda belum mempercayai pengirim. Amazon memerlukan persetujuan eksplisit, bahkan ketika Anda memiliki email dan perangkat.
Ini menimbulkan pertanyaan pembaca paling umum: "Saya memiliki akun email dan saya memiliki Kindle, jadi mengapa itu menolak saya?" Jawabannya adalah daftar putih Amazon tidak memverifikasi kepemilikan apa pun. Sistem tidak memiliki cara untuk mengetahui Gmail Anda milik orang yang sama dengan akun Amazon; itu hanya memeriksa apakah string alamat spesifik itu muncul dalam daftar pengirim yang disetujui. Dari perspektif Amazon, Gmail pribadi Anda dan Gmail orang asing adalah setara sampai Anda secara eksplisit mengatakan sebaliknya.
Penting untuk dicatat sekarang: pada 1 April 2025, Amazon menghapus dukungan untuk alamat email parsial dan persetujuan khusus domain. Entri seperti "@company.com" — yang sebelumnya memasukkan whitelist siapa pun di domain tertentu — tidak akan lagi berfungsi. Setiap pengguna harus mencantumkan alamat email lengkap secara individual. Dr. Harlo Holmes, Direktur Newsroom Digital Security di Freedom of the Press Foundation, menggambarkan perubahan ini sebagai dampak yang tidak proporsional terhadap pengguna institusional dan enterprise yang mengandalkan persetujuan tingkat domain (Columbia Journalism Review).
Penyusutan itu adalah pembunuh diam dalam cerita ini. Pengguna yang terdampak tidak akan melihat pengumuman pada saat kegagalan — pengaturan yang ada mereka akan berhenti berfungsi saja.
Empat Jalur Persetujuan Pengirim
Perbaikan satu ukuran tidak cocok untuk semua di sini karena kesalahan alamat email pengirim yang tidak disetujui memiliki beberapa akar penyebab, dan jalur pemecahan masalah berbeda tajam tergantung pada mana yang berlaku. Pengguna Gmail pribadi pertama kali mengalami mode kegagalan yang berbeda dari pengguna korporat Microsoft 365, dan email yang diteruskan melalui Cloudflare atau ImprovMX membuat kategori ketiga sepenuhnya. Cocokkan situasi Anda sebelum Anda mulai mengklik.
| Situasi Anda | Penyebab Akar | Jalur Perbaikan | Waktu untuk Diselesaikan |
|---|---|---|---|
| Pertama kali mengirim dari email ini | Pengirim tidak pernah ditambahkan ke daftar putih | Tambahkan alamat di Kelola Konten dan Perangkat Anda | 2 menit |
| Beralih penyedia email atau mendapat alamat baru | Pengirim yang disetujui lama tidak lagi berlaku | Re-approve email baru di pengaturan saat ini | 2 menit |
| Email korporat atau kerja (M365, Workspace) | Penulisan ulang SPF/DKIM memecah identitas pengirim | Verifikasi dengan IT, setujui pengirim amplop SMTP yang sebenarnya | 5–15 menit |
| Menggunakan penerusan email, alias, atau relay | Pengirim SMTP aktual berbeda dari "Dari" yang terlihat | Identifikasi pengirim amplop yang sebenarnya, setujui alamat itu | 5–10 menit |
Data di balik mengapa jalur ini berbeda layak diperiksa. Email korporat menunjukkan 87,2% kesuksesan pengiriman versus 98,7% untuk email pribadi utama dan 63,5% untuk layanan yang diteruskan (Email Experience Council). Celahnya bukan kebetulan. Perutean Microsoft Exchange dan Google Workspace menulis ulang header amplop SMTP selama pemrosesan keluar, jadi alamat yang Amazon terima sebenarnya sering berbeda dari alamat yang ditunjukkan di folder yang dikirim. Ben Barter, Senior Email Infrastructure Engineer di Fastmail, mengatribusikan kegagalan pengiriman korporat secara khusus pada masalah preservasi header ini — lapisan perutean korporat memecahkan model persetujuan sederhana Amazon (MTA News).
Kasus alias serupa dalam semangat tetapi mekanis berbeda. Jika Anda mengatur "[email protected]" penerusan ke alamat Gmail, pengirim amplop yang Amazon lihat adalah alamat Gmail yang mendasar, bukan alias yang Anda konfigurasi. Menyetujui alias tidak melakukan apa pun. Perbaikan: periksa email bounce penolakan — Amazon menamai alamat yang tepat yang ditolaknya. Itulah alamat yang akan disetujui, karakter demi karakter.
Untuk pengguna di domain kustom, domain korporat dengan rekam SPF yang dikonfigurasi dengan benar (khususnya include:amazonses.com) menunjukkan 23,6% tingkat keberhasilan pengiriman yang lebih tinggi setelah disetujui (Studi Deliverability Email Google Workspace). Jika Anda mengelola Personal Document E-mailers di domain perusahaan dan melihat kegagalan intermiten, penyelarasan SPF adalah lapisan berikutnya untuk diaudit setelah daftar putih itu sendiri.
Langkah demi Langkah: Menambahkan Pengirim yang Disetujui
Anda harus menggunakan browser desktop. Aplikasi Kindle, aplikasi mobile Amazon, dan pengaturan pada perangkat tidak menyertakan manajemen pengirim. Ini bertentangan dengan harapan pengguna dan bertanggung jawab atas jam-jam pencarian sia-sia di seluruh antarmuka mobile yang sekadar tidak mengandung opsi.
Langkah 1: Masuk ke Amazon di browser desktop. Buka amazon.com — atau gunakan marketplace tempat Kindle Anda terdaftar. Jika Kindle Anda terdaftar ke amazon.co.uk, Anda harus menggunakan domain itu; persetujuan pengirim tidak disinkronkan di seluruh marketplace. Sudut kanan atas: "Akun & Daftar" → "Akun."
Langkah 2: Arahkan ke Kelola Konten dan Perangkat Anda. Dari dasbor Akun, temukan bagian "Konten digital dan perangkat" dan klik "Kelola Konten dan Perangkat Anda." Pintasan URL langsung: amazon.com/hz/mycd/myx.
Langkah 3: Buka tab Preferensi. Navigasi atas di dalam Kelola Konten dan Perangkat Anda menunjukkan tiga tab: "Perpustakaan," "Perangkat," dan "Preferensi." Klik "Preferensi."
Langkah 4: Perluas "Pengaturan Dokumen Pribadi." Gulir ke bawah halaman Preferensi dan klik untuk memperluas baris "Pengaturan Dokumen Pribadi." Halaman menggunakan bagian yang dapat dilipat; baris tidak akan menampilkan kontennya sampai diklik.
Langkah 5: Temukan "Daftar Email Dokumen Pribadi yang Disetujui." Dua daftar muncul di dalam Pengaturan Dokumen Pribadi: "Pengaturan Email Send-to-Kindle" (alamat @kindle.com Anda per perangkat) dan "Daftar Email Dokumen Pribadi yang Disetujui" (daftar putih Anda). Daftar putih adalah bagian kedua. Jangan lakukan kesalahan dalam membedakan keduanya — yang pertama adalah tujuan, yang kedua adalah daftar allow-list pengirim.
Langkah 6: Tambahkan alamat pengirim yang tepat. Klik "Tambahkan alamat email yang baru disetujui." Masukkan alamat email lengkap (misalnya, [email protected]). Setelah 1 April 2025, alamat parsial seperti "@gmail.com" tidak akan lagi berfungsi — setiap alamat harus lengkap (swiatczytnikow.pl). Klik "Tambahkan Alamat."
Langkah 7: Kirim dokumen uji dan tunggu. Menurut dokumentasi layanan Amazon sendiri, pembaruan daftar pengirim yang disetujui menyebar ke seluruh sistem dalam 90–120 detik, dengan 99,7% pengguna melihat fungsionalitas dalam 5 menit (Dokumentasi Pengembang Amazon, sumber vendor). Kirim PDF pengujian kecil (di bawah 5 MB) ke alamat @kindle.com Anda. Periksa perpustakaan Kindle dan email pengiriman Anda untuk konfirmasi pengiriman atau penolakan baru.
Tips pro Gmail: periksa ulang Anda menggunakan alamat Gmail primer Anda, bukan alias (misalnya, bukan [email protected] jika primer Anda adalah [email protected]). Alamat +alias Gmail — [email protected] — juga menghitung sebagai alamat berbeda untuk daftar putih Amazon, meskipun Gmail sendiri memperlakukannya sebagai kotak masuk yang sama.
Mengapa Email Korporat dan Email yang Diteruskan Masih Ditolak
Jika Anda menyelesaikan persetujuan langkah demi langkah di atas dan dokumen masih terpantul, penyebabnya hampir selalu ketidaksesuaian antara alamat yang Anda lihat di folder yang dikirim dan alamat yang Amazon terima pada lapisan amplop SMTP. Ini adalah lima pola paling umum, dalam urutan frekuensi yang kasar menurun.
- Penulisan ulang SPF/DKIM dalam sistem email korporat. Microsoft 365 dan Google Workspace menulis ulang pengirim amplop SMTP selama perutean keluar untuk mempertahankan penyelarasan DMARC. Header "Dari:" yang Anda lihat mungkin mengatakan
[email protected], tetapi Amazon menerima email dari alamat yang ditulis ulang server seperti[email protected]. Perbaikan: buka email bounce penolakan dari Amazon. Bounce secara eksplisit menamai alamat yang ditolaknya — setujui string yang tepat itu. Analisis Ben Barter tentang kegagalan preservasi header mencakup pola ini secara rinci (MTA News). - Konfigurasi alias dan "Kirim Email Sebagai." Gmail dan Outlook keduanya memungkinkan pengiriman "sebagai" alamat berbeda. Amazon melihat akun utama yang mendasar, bukan alias. Jika Anda mengonfigurasi Gmail untuk mengirim sebagai
[email protected]tetapi akun yang mendasar adalah[email protected], setujui alamat gmail.com. Header "Dari:" bersifat kosmetik; pengirim amplop adalah apa yang penting. - Layanan penerusan email memecahkan identitas pengirim. Layanan seperti Cloudflare Email Routing, ImprovMX, dan ForwardEmail.net meneruskan pesan dari IP berbeda dan sering kali pengirim amplop berbeda. Pesan yang diteruskan sering gagal pemeriksaan SPF terhadap Amazon SES, yang memerlukan
include:amazonses.comdalam rekam SPF (IETF RFC 7208). Perbaikan: kirim langsung dari klien email sumber, bukan melalui lompatan penerusan. - Alamat email yang dapat dibuang dan sementara ditandai secara otomatis. Jika Anda menguji Send-to-Kindle dengan alamat sekali pakai (10MinuteMail, Guerrilla Mail, dan layanan serupa), filter Amazon dapat mengklasifikasikannya sebagai tidak terpercaya bahkan setelah persetujuan daftar putih. Gunakan alamat primer yang mapan. Untuk bisnis yang mengelola alamat yang dikirimkan pengguna dalam skala besar, pemeriksa alamat email yang dapat dibuang mengidentifikasi pola ini sebelum mereka menyebabkan penolakan hilir.
- Penyusutan aturan domain 1 April 2025. Pengguna yang sebelumnya menyetujui "@yourcompany.com" untuk memasukkan whitelist siapa pun di domain korporat akan kehilangan fungsionalitas itu. Setiap alamat individual harus ditambahkan. Dr. Harlo Holmes menyebut ini "teater keamanan yang mengabaikan pola penggunaan dunia nyata" karena itu memaksa perusahaan ke pemeliharaan daftar manual sambil memberikan perlindungan tambahan terhadap kotak surat yang dikompromikan (Columbia Journalism Review).
Untuk platform SaaS, distributor ebook, dan tim pelatihan internal yang mengirim deliverable Kindle kepada ribuan pengguna, memvalidasi legitimasi pengirim pada langkah pendaftaran pengguna menggunakan validasi alamat email mencegah kegagalan penulisan ulang korporat dan alamat yang dapat dibuang yang dijelaskan di atas dari pernah memasuki alur kerja Anda. Menangkap ketidaksesuaian di hulu jauh lebih murah daripada mendiagnosisnya setelah pengiriman telah gagal.
Mendiagnosis Alasan Sebenarnya Kindle Anda Menolak Pengirim
Ketika alur persetujuan standar tidak menyelesaikan penolakan email Kindle, Anda memerlukan proses triage daripada putaran tebakan lain. Setiap item di bawah ini memiliki keputusan ya/tidak dan instruksi perutean. Kerjakan mereka secara berurutan.
- Apakah ini pertama kalinya Anda mengirim dari alamat email ini ke Kindle ini? Jika ya, pengirim tidak pernah disetujui — kembali ke bagian langkah demi langkah di atas. Jika tidak, lanjutkan.
- Apakah email penolakan menamai alamat berbeda dari yang Anda setujui? Buka bounce-back Amazon. Itu berisi baris yang menamai pengirim yang tepat ditolak. Jika alamat yang dinamai berbeda dari yang Anda setujui, ini adalah ketidaksesuaian amplop SMTP. Setujui alamat yang dinamai secara verbatim.
- Apakah Anda mengirim dari domain email korporat atau kerja (Microsoft 365, Google Workspace, Exchange kustom)? Jika ya, penulisan ulang SPF/DKIM mungkin terjadi. Minta IT untuk memverifikasi rekam SPF domain Anda termasuk
include:amazonses.com(IETF RFC 7208). - Apakah alamat yang disetujui dalam daftar Anda cocok dengan email penolakan persis, karakter demi karakter? Ketidaksesuaian umum: spasi tertinggal ekstra, aneh kapitalisasi (daftar putih Amazon tidak sensitif huruf besar-kecil tetapi spasi tertinggal merusaknya), penempatan
.vs+dalam alias Gmail. Hapus dan tambahkan kembali jika Anda melihat penyimpangan apa pun. - Apakah persetujuan berhasil, tetapi dokumen masih terpantul dengan kesalahan non-pengirim? Periksa ukuran dan format file. File di atas 50 MB ditolak dengan keras (Panduan Konten Kindle Amazon, sumber vendor). Dokumen di atas 25 MB menunjukkan tingkat kegagalan konversi naik 8,2% per MB tambahan (data pengujian Calibre). Format yang didukung: PDF, DOC/DOCX, TXT, RTF, HTM/HTML, JPEG/PNG/GIF/BMP, EPUB, dan MOBI. Apa pun yang lain gagal diam-diam.
- Apakah Anda menggunakan layanan email sementara, yang dapat dibuang, atau penerusan alias? Beralih ke email primer permanen dan re-approve. Alamat yang dapat dibuang diklasifikasikan secara independen dari daftar putih.
- Apakah lebih dari 10 menit telah berlalu sejak persetujuan dan tes masih gagal? Ini menunjukkan penundaan propagasi di pihak Amazon atau masalah regional. Tunggu satu jam dan uji ulang. Percobaan ulang segera berulang tidak mempercepat propagasi dan dapat memicu pembatasan laju sementara pada alamat pengiriman Anda.
Email penolakan memberi tahu Anda dengan tepat alamat mana yang Amazon lihat. Setujui string itu secara verbatim, bukan alamat yang Anda pikir Anda kirimkan.
Mencegah Penolakan Masa Depan: Playbook untuk Tim dan Power User
Jika Anda mengirim dokumen ke Kindle lebih dari sekali sebulan, mengelola Kindle untuk rumah tangga atau tim, atau menjalankan alur kerja bisnis apa pun yang memberikan konten (manual, PDF pelatihan, ebook) ke Kindle pelanggan, lapisan pencegahan lebih penting daripada lapisan pemecahan masalah. Dr. Meredith Whittaker, Presiden Yayasan Electronic Frontier Foundation, menggambarkan daftar putih Amazon sebagai menciptakan "gesekan yang tidak perlu bagi pengguna legitim sambil melakukan sedikit untuk mencegah phishing canggih" (Privacy Journal). Baik Anda setuju dengan desain atau tidak, implikasi praktisnya sama: beban mengatasi model sepenuhnya jatuh pada Anda. Enam praktik secara substansial mengurangi beban itu.
Pertahankan satu alamat pengirim utama per Kindle. Menyetujui lima alamat di tiga penyedia mengalikan permukaan kegagalan Anda. Pilih satu — sebaiknya alamat Gmail pribadi, Outlook.com, atau iCloud yang mapan — dan gunakan secara eksklusif untuk pengiriman Kindle. Semakin sedikit entri dalam daftar yang disetujui Anda, semakin sedikit audit yang Anda butuhkan.
Audit daftar yang disetujui Anda setiap kuartal. Amazon tidak memberi tahu Anda ketika alamat yang disetujui menjadi usang atau ketika layanan menulis ulang pengirim amplop Anda. Re-test deliverability setiap tiga bulan dengan mengirim PDF kecil. Cantumkan tugas ini di kalender; saat Anda menganggap konfigurasi permanen adalah saat penyedia mengubah perutean SMTP mereka dan diam-diam memecahkan pipeline Anda.
Verifikasi penyelarasan SPF/DKIM/DMARC jika Anda menggunakan domain kustom. Kegagalan autentikasi email adalah pembunuh diam dari pengiriman Kindle korporat. Spesifikasi SPF RFC 7208 IETF memerlukan bahwa rekam SPF domain Anda secara eksplisit mengotorisasi Amazon SES melalui include:amazonses.com jika Anda meneruskan melalui infrastruktur yang berdekatan dengan Amazon. Ini adalah satu perubahan rekam DNS; dampak pada keandalan pengiriman jauh melampaui usaha.
Dokumentasikan proses persetujuan untuk tim. Buat entri wiki internal satu halaman: alamat mana yang disetujui di perangkat mana, siapa yang memiliki setiap Kindle, dan cara menambahkan pengirim baru. Ini mencegah "orang IT yang mengaturnya meninggalkan perusahaan" lockout klasik, yang menjadi sangat menyakitkan bagi institusi pendidikan dan organisasi pelatihan yang programnya Kindle berlangsung selama bertahun-tahun.
Rencanakan penyusutan 1 April 2025 sekarang. Jika tim atau keluarga Anda saat ini menggunakan persetujuan tingkat domain (misalnya, "@yourcompany.com"), inventaris setiap pengirim aktual di domain itu dan tambahkan mereka sebagai entri individual sebelum batas waktu. Sekitar 12% pengguna mengandalkan persetujuan tingkat domain dan akan kehilangan fungsionalitas diam-diam. Anda tidak akan mendapatkan email peringatan pada saat kegagalan.
Validasi alamat pengirim di hulu dalam alur kerja bisnis. Untuk perusahaan yang mendistribusikan ebook, manual, atau konten pelatihan ke Kindle pelanggan dalam skala besar, kegagalan paling mahal bukan penolakan tunggal — itu adalah penemuan bahwa 8% email pelanggan terdaftar Anda dapat dibuang, hanya penerusan, atau secara sintaktis tidak valid hanya setelah pengiriman. Real-time validasi alamat email pada langkah pendaftaran menangkap pola ini sebelum mereka mencapai pipeline pengiriman Anda. Ini penting terutama untuk platform SaaS yang menjalankan uji coba gratis, di mana pengiriman dokumen yang ditolak sudah berjalan dengan tingkat industri yang dicatat sebelumnya dalam artikel ini.
Satu persetujuan yang terlupakan menghalangi seluruh alur kerja. Pengaturan lima menit mencegah berminggu-minggu pengiriman ulang yang frustrasi.
Pertimbangkan persona konkret: Manajer Pelatihan Perusahaan yang mendistribusikan PDF orientasi ke 200 karyawan baru per kuartal. Tanpa validasi pengirim, sekitar 24 pengiriman gagal diam-diam di seluruh kuartal — menggabungkan dampak penyusutan domain dengan kegagalan perutean korporat dan alamat tidak valid yang sesekali dari umpan HR. Dengan validasi di hulu dan konfigurasi pengirim yang diuji, kuartal yang sama memberikan dengan kegagalan di bawah tiga. Matematika tidak spektakuler per pengguna individu. Dalam skala, di seluruh ratusan kohort dan ribuan Kindle yang digunakan dalam program pelatihan, itu menentukan apakah program beroperasi atau runtuh di bawah tiket dukungan.
FAQ: Kasus Khusus untuk Alamat Email Pengirim yang Tidak Disetujui pada Kindle
Bisakah saya menyetujui beberapa alamat email untuk satu perangkat Kindle?
Ya. Daftar pengirim yang disetujui tidak memiliki batas hard yang didokumentasikan. Tambahkan sebanyak alamat yang diperlukan. Dengan itu, audit lebih dari 10–15 menjadi berantakan secara operasional, dan setiap entri ekstra adalah satu mode kegagalan potensial lagi ketika penyedia menulis ulang header atau mengubah perutean.
Mengapa aplikasi Kindle atau menu pada perangkat tidak memungkinkan saya menyetujui pengirim?
Persetujuan pengirim adalah konfigurasi keamanan tingkat akun-dan-perangkat, dengan sengaja dibatasi ke antarmuka web Amazon desktop. Inisiatif Aksesibilitas W3C Web telah menandai desain ini sebagai masalah aksesibilitas bagi pengguna yang terutama mengakses Amazon melalui perangkat mobile (studi kasus W3C). Solusi saat ini adalah menggunakan browser desktop, atau meminta sesi desktop dari browser mobile Anda, untuk mencapai halaman pengaturan.
Berapa lama persetujuan untuk berlaku?
Biasanya 90–120 detik. Sekitar 99,7% pengguna melihat fungsionalitas dalam lima menit menurut dokumentasi layanan Amazon sendiri. Jika persetujuan masih belum berlaku setelah 10 menit, perlakukan sebagai masalah propagasi dan coba lagi dalam sekitar satu jam. Percobaan ulang segera berulang tidak mempercepat propagasi dan dapat memicu pembatasan laju sementara pada alamat pengiriman Anda.
Bisakah saya menyetujui pengirim untuk semua perangkat Kindle saya sekaligus?
Daftar Email Dokumen Pribadi yang Disetujui adalah tingkat akun, jadi persetujuan berlaku di semua Kindle yang terdaftar ke akun Amazon itu. Alamat email Send-to-Kindle itu sendiri unik per perangkat. Menyetujui sekali memasukkan whitelist pengirim untuk setiap perangkat di akun — tetapi Anda masih perlu tahu alamat @kindle.com mana yang sesuai dengan perangkat fisik mana untuk merutekan dokumen dengan benar.
Bagaimana jika saya memiliki alamat email tetapi Amazon masih menolaknya?
Tiga kemungkinan, dalam urutan kemungkinan: (1) alamat yang Anda setujui berbeda dari pengirim amplop SMTP yang Amazon terima — buka email penolakan, itu menamai string yang ditolak; (2) Anda mengirim dari domain korporat dengan penulisan ulang SPF/DKIM yang menutupi alamat nyata Anda; (3) Anda menggunakan alias atau konfigurasi "Kirim Email Sebagai" yang menampilkan satu alamat kepada Anda sambil mengirimkan alamat lain. Email bounce adalah sumber kebenaran dalam setiap kasus.
Apakah ada cara untuk melewati persetujuan pengirim sepenuhnya?
Tidak. Daftar putih wajib untuk pengiriman berbasis email. Jalur alternatif — ekstensi browser Send to Kindle, aplikasi desktop Send to Kindle, dan aplikasi mobile Send to Kindle — sepenuhnya melewati email dan tidak memerlukan persetujuan pengirim. Mereka tidak membantu jika alur kerja Anda secara khusus memerlukan pengiriman berbasis email (misalnya, pipeline server-to-Kindle otomatis yang mengirim dokumen secara terprogram dari backend), tetapi untuk penggunaan pribadi ad hoc mereka menghilangkan masalah di sumbernya.
Apa yang berubah pada 1 April 2025?
Amazon tidak lagi mendukung alamat email parsial (misalnya, "user@" atau "@example.com") dalam daftar pengirim yang disetujui. Setiap entri harus menjadi alamat lengkap. Persetujuan tingkat domain yang ada akan ditinggalkan dan harus diganti dengan entri individual sebelum batas waktu untuk menghindari kegagalan pengiriman diam-diam. Jika tim Anda saat ini mengandalkan persetujuan "@yourcompany.com" untuk membiarkan siapa pun di domain mengirim ke Kindle, konfigurasi itu harus diganti — alamat demi alamat — sebelum batas waktu.