# Daftar periksa QA sebelum mengirim email: 8 pemeriksaan

URL kanonis: https://brew.new/id/blog/pre-send-email-qa-checklist
Penulis: Thomas Park
Dipublikasikan: 2026-10-11
Diperbarui: 2026-10-11

Daftar periksa QA sebelum mengirim adalah daftar singkat pemeriksaan yang Anda jalankan pada setiap email sebelum dikirim. Kampanye yang rusak biasanya terkirim dengan tombol yang masih mengarah ke `#`, gambar hero yang diganti dengan PNG 4 MB pada pukul 18.00, atau tata letak dua kolom yang diabaikan Outlook klasik. Masing-masing hanya butuh satu menit untuk ditemukan sebelum pengiriman, dan tidak bisa diperbaiki setelahnya.

Bulan ini kami membangun ulang audit email Brew berdasarkan pemeriksaan-pemeriksaan ini, masing-masing dengan ambang batas yang pasti. Anda bisa menjalankannya secara manual, dengan atau tanpa Brew.

![Hasil audit email yang menampilkan skor, status kesiapan, dan temuan yang dikelompokkan berdasarkan tingkat keparahan.](/images/blog/email-audit-findings.png)

*Temuan dikelompokkan berdasarkan tingkat keparahan, dengan satu kesimpulan kesiapan.*

## Poin penting

- Periksa delapan area: tautan, ukuran, gambar, dukungan klien email, aksesibilitas, teks, kepatuhan, dan markup.
- Gmail memotong HTML yang lebih besar dari sekitar 102 KB, sehingga footer dan tautan berhenti berlangganan ikut tersembunyi. Brew memberi peringatan pada 80 KB karena pelacakan klik menambah ukuran.
- Klik setiap tautan di email uji yang sudah diterima, tetapi jangan pernah biarkan pemeriksa otomatis membuka tautan berhenti berlangganan atau tautan preferensi.
- Audit Brew memberi skor 0 hingga 100: dikurangi 20 untuk setiap temuan kritis, 10 untuk setiap kesalahan, dan 3 untuk setiap peringatan. Satu saja temuan kritis atau kesalahan berarti email belum siap.
- Audit tidak pernah memblokir pengiriman, dan tidak menguji penempatan kotak masuk, tangkapan layar tampilan, atau mode gelap.

## 1. Tautan

Tautan yang rusak membuat pengiriman sia-sia. Pastikan:

- setiap tombol memiliki tujuan sungguhan, bukan `#`, `example.com`, atau `{{url}}` yang belum diisi
- tidak ada tautan yang mengembalikan 404 atau 410, mengarah ke domain yang tidak dapat di-resolve, memiliki sertifikat yang bermasalah, menolak koneksi, atau berputar-putar dalam pengalihan
- setiap tautan memakai `https`
- teks tautan yang terlihat sesuai dengan tujuannya. `brew.new/pricing` yang mengarah ke tempat lain terlihat seperti phishing
- Anda tidak memakai pemendek URL publik, yang berbagi reputasi dengan setiap spammer yang memakainya

Klik setiap tautan di email uji yang sudah diterima, bukan di editor. ESP Anda menulis ulang tautan untuk pelacakan klik saat pengiriman, sehingga rantai pengalihan dan parameter pelacakan yang rusak baru terlihat di sana.

Jangan pernah biarkan pemeriksa otomatis membuka tautan berhenti berlangganan atau tautan preferensi. Sebagian penyedia menganggap setiap permintaan ke URL tersebut sebagai permintaan berhenti berlangganan. Selain itu, halaman penghalang bot yang ditampilkan kepada pemeriksa tidak membuktikan bahwa tautannya mati. Klik sendiri tautan itu.

## 2. Ukuran

Gmail memotong pesan dengan HTML lebih dari sekitar **102 KB** dan menyembunyikan sisanya di balik tautan “Lihat seluruh pesan”. Akibatnya, footer, tautan berhenti berlangganan, dan alamat surat-menyurat ikut tersembunyi, sehingga email pemasaran yang terpotong diam-diam berubah menjadi masalah kepatuhan.

Ambang batas kami:

- HTML sebesar **80 KB** menghasilkan peringatan
- HTML sebesar **102 KB** menghasilkan kesalahan, karena Gmail akan memotongnya
- Total ukuran yang dimuat sebesar **3 MB**, yaitu HTML ditambah gambar, menghasilkan peringatan
- Total ukuran yang dimuat sebesar **5 MB** menghasilkan kesalahan

Kami memberi peringatan pada 80 KB karena pelacakan klik mengganti tautan pendek dengan URL pengalihan yang lebih panjang, dan sebagian ESP menambahkan markup. Email berukuran 98 KB di editor Anda bisa tiba sebagai 105 KB.

Penyebab pembengkakan yang umum: gaya inline yang diulang di setiap elemen, sisa komentar dari pembuat email, bagian seluler dan desktop duplikat yang disembunyikan, serta gambar base64 yang disematkan.

## 3. Gambar

Setiap gambar harus:

- memiliki teks `alt`, atau `alt=""` jika hanya dekoratif
- memiliki `width` dan `height`, agar tata letak tetap terjaga saat gambar dimuat atau saat gambar diblokir
- bisa dimuat, dan benar-benar berupa gambar, bukan halaman error HTML
- berukuran di bawah **1 MB**, atau **3 MB** untuk GIF

Satu gambar besar di atas sebaris teks tidak terbaca saat gambar dinonaktifkan, tidak dapat dipahami pembaca layar, dan menjadi sinyal spam bagi sebagian filter. Tulis judul dan penawaran sebagai teks asli, bukan di dalam gambar.

## 4. Dukungan klien email

Flexbox, grid, `position`, gambar latar, dan SVG inline masing-masing rusak di setidaknya satu klien email utama. [Can I email](https://www.caniemail.com/) melacak dukungan untuk setiap fitur dan klien, dan merupakan referensi tunggal terbaik.

Paling waspadai Outlook. Di Gmail dan Apple Mail, tampilan biasanya hanya menurun sedikit tanpa terlihat rusak. Outlook klasik di Windows merender dengan mesin tata letak Word, mengabaikan banyak pengaturan lebar CSS, membuang gambar latar, dan menghapus padding dari tombol yang dibuat sebagai tautan bergaya.

Kami menandai sebuah fitur untuk satu keluarga klien, seperti Gmail atau Outlook, hanya jika setidaknya dua klien dalam keluarga itu tidak mendukungnya. Temuan itu menjadi peringatan hanya jika Outlook merusaknya tanpa cadangan. Selebihnya berstatus info. Jika tidak begitu, setiap email akan mendapat dua puluh peringatan klien, dan orang akan mengabaikan semuanya.

## 5. Aksesibilitas

Pemeriksaan yang murah dan cepat:

- `lang` pada `<html>`, agar pembaca layar melafalkan teks dengan benar
- elemen `<title>`
- tingkat heading yang berurutan, tanpa lompatan dari `h1` ke `h4`
- teks alt yang menjelaskan pesan yang disampaikan gambar. “Diagram batang yang menunjukkan pendaftaran naik dua kali lipat pada bulan Maret” membantu. “image1.png” tidak
- kontras pada teks isi, tombol, dan teks footer abu-abu muda, tempat sebagian besar kegagalan tersembunyi

[WCAG 2.2](https://www.w3.org/TR/WCAG22/) adalah acuannya. Sebagian besar masalah email berkaitan dengan kriteria WCAG tentang alternatif teks, kontras, bahasa halaman, dan heading.

## 6. Teks, subjek, dan teks pratinjau

Buat subjek kurang dari sekitar **60 karakter** dan **9 kata**, atau ponsel akan memotongnya. Hindari penulisan SEMUA HURUF KAPITAL, “RE:” atau “FWD:” pada email yang bukan balasan, serta tanda seru beruntun.

Buat teks pratinjau kurang dari sekitar **90 karakter**, tanpa mengulang subjek. Jika dibiarkan kosong, banyak klien email akan menampilkan “Lihat di browser” sebagai gantinya.

Merge tag tanpa nilai cadangan akan mengirim “Halo ,” kepada setiap orang yang tidak memiliki nama depan. Pembaca akan mengingatnya.

Setiap angka harus punya sumber yang bisa Anda tunjukkan, terutama di draf pertama buatan AI, yang mudah menghasilkan angka dengan penuh percaya diri. [Cara menulis email marketing](/id/blog/how-to-write-marketing-emails) dan [panduan subjek email](/id/blog/email-subject-lines) membahas pemilihan kata lebih dalam.

## 7. Kepatuhan

Email komersial memerlukan tautan berhenti berlangganan yang berfungsi dan alamat surat-menyurat yang valid sesuai ketentuan [CAN-SPAM](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business). Pengirim massal ke Gmail dan Yahoo juga memerlukan header berhenti berlangganan sekali klik, yang dibahas dalam [Aturan yang tetap berlaku saat agen mengirim email Anda](/id/blog/agent-email-deliverability).

Email transaksional dikecualikan dari sebagian aturan pemasaran, tetapi tidak dari daftar periksa ini. Bukti pembayaran dengan tautan mati tetap akan berujung menjadi tiket dukungan.

## 8. Markup

Hapus elemen yang dibuang atau diblokir klien email:

- elemen `<script>`, `<form>`, dan `<iframe>`
- SVG yang disematkan dan URI `data:`
- gambar latar tanpa cadangan `background-color`, agar teks tetap terbaca jika gambar gagal dimuat

Awali dengan doctype. Tanpa doctype, sebagian klien merender dalam quirks mode dan jarak antarelemen bergeser.

## Menjalankan daftar periksa ini di Brew

Audit email Brew menjalankan daftar ini dari:

- tab **Audit** di dialog kirim, di samping Pratinjau dan Audiens
- tombol **Audit** pada langkah email di kanvas otomatisasi
- API dan MCP, dengan `POST /v1/emails/audit` atau alat `audit_email`

Lihat [dokumentasi audit](https://docs.brew.new/create-emails/audit-email) dan [referensi API](https://docs.brew.new/api-reference/public-v1/emails/audit-an-email) untuk semua field.

**Pemeriksaan instan** yang gratis berjalan otomatis untuk setiap aturan yang hanya membutuhkan HTML: placeholder, ukuran, teks alt dan dimensi gambar yang hilang, urutan heading, `lang` dan `<title>`, panjang subjek dan teks pratinjau, merge tag tanpa nilai cadangan, serta markup yang diblokir.

**Jalankan audit** menambahkan pemeriksaan yang memerlukan akses jaringan atau penilaian:

- permintaan langsung ke setiap tautan, hingga 100 tautan per email, kecuali tautan berhenti berlangganan dan tautan preferensi. Halaman penghalang bot dilaporkan sebagai “tidak terverifikasi”, bukan mati
- permintaan ke setiap gambar, untuk menangkap aset yang mati atau terlalu besar
- dukungan di 15 klien email dari empat keluarga, yaitu Gmail, Apple Mail, Outlook, dan Yahoo, dengan aturan dari bagian 4
- kontras dan aturan aksesibilitas lainnya, lengkap dengan rujukan WCAG 2.2
- peninjauan AI tentang apakah subjeknya menyesatkan, apakah teks tautan dan teks alt bermakna, apakah ada alamat surat-menyurat dalam format negara mana pun, dan apakah email tersebut termasuk email pemasaran atau transaksional

Setiap penilaian AI disetel agar setidaknya 95% temuan yang dimunculkannya benar pada email milik kami sendiri. Peninjau AI yang sering membunyikan alarm palsu lebih buruk daripada tidak ada sama sekali.

Audit lengkap membutuhkan 5 kredit. Jika ada pemeriksaan wajib yang tidak tersedia, Anda mendapatkan audit parsial gratis tanpa skor, karena skor yang melewatkan sebagian pemeriksaan akan menyesatkan.

## Cara kerja skor

Setiap audit menghasilkan skor 0 hingga 100 dan sebuah status: siap, perlu ditinjau, atau belum siap (di aplikasi ditampilkan sebagai Siap dikirim, Perlu ditinjau, dan Ada masalah). Setiap temuan memiliki tingkat keparahan, yaitu Kritis, Kesalahan, Peringatan, atau Info, ditambah bukti seperti status HTTP dari tautan yang mati.

Skor dimulai dari 100. Setiap temuan kritis mengurangi 20 poin, setiap kesalahan 10 poin, setiap peringatan 3 poin, dan info tidak mengurangi apa pun. Hanya tiga temuan pertama per aturan yang dihitung.

Contoh: tombol yang ditautkan ke `#`, tautan footer yang mengembalikan 404, dua gambar tanpa teks alt, subjek sepanjang 68 karakter, dan flexbox yang diabaikan dua klien Yahoo.

| Temuan | Tingkat keparahan | Poin |
| --- | --- | --- |
| Tautan tombol berupa placeholder | Kritis | −20 |
| Tautan footer mengembalikan 404 | Kesalahan | −10 |
| Gambar tanpa teks alt (×2) | Peringatan | −6 |
| Subjek lebih dari 60 karakter | Peringatan | −3 |
| Flexbox diabaikan 2 klien Yahoo | Info | 0 |
| **Skor** | | **61** |

Satu saja temuan kritis atau kesalahan berarti “belum siap”; jika hanya ada peringatan, statusnya “perlu ditinjau”. Perbaiki dua tautan tersebut, dan email ini mendapat skor 91 dengan status perlu ditinjau. Penilaian yang jujur: email ini sebenarnya aman dikirim, dan sisanya layak mendapat waktu satu menit.

**Perbaiki di chat** menyerahkan temuan berstatus peringatan dan yang lebih parah kepada agen Brew, lalu menjalankan ulang pemeriksaan instan gratis pada hasil perbaikannya.

## Yang tidak dilakukan audit

Audit tidak memblokir pengiriman. Jika ada temuan kritis, dialog kirim meminta Anda memilih **Tetap kirim** dan mencatat keputusan untuk mengabaikan temuan tersebut. Pengiriman lewat API, MCP, dan otomatisasi melaporkan temuannya, lalu tetap berjalan. Itulah default yang tepat. Sebagian email yang tidak disukai audit tetap perlu dikirim, dan alat QA yang menyandera pengiriman pada akhirnya akan dimatikan.

Audit tidak menulis ulang HTML Anda. Perbaikan adalah langkah terpisah yang Anda mulai sendiri.

Audit tidak menguji penempatan kotak masuk, membuat tangkapan layar tampilan, atau memeriksa mode gelap. Untuk mode gelap, buka email uji di ponsel Anda dengan mode gelap aktif. Cara ini akan menangkap logo yang menghilang di latar hitam.

## Pertanyaan yang sering diajukan

### Berapa lama hasil audit berlaku?

Di dialog kirim, 15 menit. Setelah itu, atau jika emailnya berubah, panel akan meminta Anda menjalankannya ulang. Lewat MCP, Anda bisa membaca ulang laporan yang tersimpan selama 7 hari tanpa biaya.

### Apakah skor tinggi berarti email akan masuk ke kotak masuk?

Tidak. Audit memeriksa email itu sendiri. Penempatan juga bergantung pada reputasi domain, autentikasi, dan tingkat keluhan, yang dibahas dalam [panduan keterkiriman](/id/blog/email-deliverability).

### Bisakah saya mengaudit email yang dibuat dengan alat lain?

Bisa, lewat API atau MCP. Kirim `emailHtml` atau `emailJsx` sebagai pengganti ID email Brew, dan dapatkan laporan yang sama sebelum email itu masuk ke ESP Anda. Jika Anda [me-remix templat dari galeri dan mengekspornya ke ESP Anda](/id/blog/how-to-remix-a-real-brand-email-template-and-export-it-to-your-esp), audit email tersebut di Brew sebelum mengekspornya.

### Siapa di tim saya yang bisa menjalankannya?

Siapa pun yang memiliki akses ke merek tersebut bisa menjalankannya: admin organisasi dan anggota yang ditambahkan ke merek itu. Brew tidak memiliki peran yang hanya bisa melihat.