# Gönderim öncesi e-posta kalite kontrol listesi: 8 kontrol

Kanonik URL: https://brew.new/tr/blog/pre-send-email-qa-checklist
Yazar: Thomas Park
Yayımlandı: 2026-10-11
Güncellendi: 2026-10-11

Gönderim öncesi kalite kontrol listesi, her e-postayı göndermeden önce yaptığınız kısa kontrollerin listesidir. Sorunlu kampanyalar genellikle hâlâ `#` adresine giden bir butonla, saat 18:00’de 4 MB’lık bir PNG ile değiştirilmiş bir ana görselle ya da klasik Outlook’un yok saydığı iki sütunlu bir düzenle gönderilir. Bunların her birini gönderimden önce yakalamak bir dakika sürer; gönderimden sonra ise düzeltmenin yolu yoktur.

Bu ay Brew e-posta denetimini, her biri kesin bir eşiğe sahip bu kontroller üzerine yeniden kurduk. Bu kontrolleri Brew ile ya da Brew olmadan, elle de yapabilirsiniz.

![Puanı, hazır olma durumunu ve önem derecesine göre gruplanmış bulguları gösteren bir e-posta denetimi sonucu.](/images/blog/email-audit-findings.png)

*Önem derecesine göre gruplanmış bulgular ve tek bir hazır olma kararı.*

## Öne çıkan noktalar

- Sekiz alanı kontrol edin: bağlantılar, boyut, görseller, istemci desteği, erişilebilirlik, metin, yasal uyumluluk ve HTML kodu.
- Gmail, HTML boyutu yaklaşık 102 KB’ı aşan e-postaları kırpar; bu da alt bilgiyi ve abonelikten çıkma bağlantısını gizler. Tıklama izleme boyutu artırdığı için Brew 80 KB’ta uyarı verir.
- Teslim edilmiş bir test e-postasındaki her bağlantıya tıklayın; ancak abonelikten çıkma ya da tercih bağlantılarını asla otomatik bir kontrol aracına açtırmayın.
- Brew denetimi 0 ile 100 arasında puan verir: Her kritik bulgu için 20, her hata için 10, her uyarı için 3 puan düşülür. Tek bir kritik bulgu ya da hata bile “hazır değil” anlamına gelir.
- Denetim hiçbir gönderimi engellemez; gelen kutusu yerleşimini, görüntüleme ekran görüntülerini ya da karanlık modu da test etmez.

## 1. Bağlantılar

Bozuk bir bağlantı gönderimi boşa harcar. Kontrol edilecekler:

- Her butonun gerçek bir hedefi olmalı; `#`, `example.com` ya da doldurulmamış bir `{{url}}` değil.
- Hiçbir bağlantı 404 ya da 410 döndürmemeli, çözümlenemeyen bir alan adına gitmemeli, geçersiz bir sertifikaya sahip olmamalı, bağlantıyı reddetmemeli ya da yönlendirme döngüsüne girmemeli.
- Her bağlantı `https` kullanmalı.
- Görünen bağlantı metni hedefle eşleşmeli. Başka bir yere giden bir `brew.new/pricing` bağlantısı oltalama (phishing) gibi görünür.
- Herkese açık URL kısaltıcılardan uzak durulmalı; bu servisler, onları kullanan tüm spam göndericileriyle aynı itibarı paylaşır.

Her bağlantıya editörde değil, teslim edilmiş bir test e-postasında tıklayın. ESP’niz tıklama izleme için bağlantıları gönderim anında yeniden yazar; bu yüzden yönlendirme zincirleri ve bozuk izleme parametreleri yalnızca orada ortaya çıkar.

Abonelikten çıkma ya da tercih bağlantılarına otomatik bir kontrol aracının istek göndermesine asla izin vermeyin. Bazı sağlayıcılar bu URL’ye gelen her isteği abonelikten çıkma olarak değerlendirir. Ayrıca bir kontrol aracının karşısına çıkan bot koruması, bağlantının çalışmadığını kanıtlamaz. Bağlantıya kendiniz tıklayın.

## 2. Boyut

Gmail, HTML boyutu yaklaşık **102 KB**’ı aşan mesajları kırpar ve devamını “View entire message” (mesajın tamamını görüntüle) bağlantısının arkasına saklar. Bu da alt bilgiyi, abonelikten çıkma bağlantısını ve posta adresini gizler; yani kırpılan bir pazarlama e-postası sessizce yasal bir soruna dönüşür.

Bizim eşiklerimiz:

- **80 KB** HTML: uyarı
- **102 KB** HTML: hata, çünkü Gmail e-postayı kırpar
- HTML ve görseller dâhil **3 MB** toplam yükleme boyutu: uyarı
- **5 MB** toplam yükleme boyutu: hata

80 KB’ta uyarı veriyoruz, çünkü tıklama izleme kısa bağlantıları daha uzun yönlendirme URL’leriyle değiştirir ve bazı ESP’ler koda ek işaretleme ekler. Editörünüzde 98 KB olan bir e-posta, alıcıya 105 KB olarak ulaşabilir.

Boyutu genellikle şunlar şişirir: her öğede tekrarlanan satır içi stiller, oluşturucudan kalan yorum satırları, gizlenmiş mükerrer mobil ve masaüstü bölümleri ve gömülü base64 görseller.

## 3. Görseller

Her görsel:

- `alt` metnine sahip olmalı; tamamen dekoratifse `alt=""` kullanılmalı
- `width` ve `height` değerlerine sahip olmalı ki görseller yüklenirken ya da engellendiğinde düzen bozulmasın
- yüklenmeli ve bir HTML hata sayfası değil, gerçekten bir görsel olmalı
- **1 MB**’tan, GIF’lerde ise **3 MB**’tan küçük olmalı

Tek bir büyük görsel ve altındaki bir satır metinden oluşan bir e-posta, görseller kapalıyken okunamaz, ekran okuyucular için anlamsızdır ve bazı filtreler için bir spam sinyalidir. Başlığı ve teklifi gerçek metin olarak yazın.

## 4. İstemci desteği

Flexbox, grid, `position`, arka plan görselleri ve satır içi SVG’nin her biri en az bir büyük e-posta istemcisinde bozulur. [Can I email](https://www.caniemail.com/) desteği özellik ve istemci bazında takip eder; tek bir başvuru kaynağı olarak en iyisi budur.

En çok Outlook’a dikkat edin. Gmail ve Apple Mail desteklemedikleri özelliklerde genellikle sessizce daha sade bir görünüme geçer. Windows’taki klasik Outlook ise Word’ün düzen motoruyla görüntüleme yapar; birçok CSS genişliğini yok sayar, arka plan görsellerini atar ve stillendirilmiş bağlantı olarak kurulan butonların iç boşluklarını (padding) siler.

Bir özelliği Gmail ya da Outlook gibi bir istemci ailesi için ancak o ailedeki en az iki istemci desteklemiyorsa işaretliyoruz. Bunu yalnızca Outlook özelliği bir yedek çözüm olmadan bozuyorsa uyarı olarak gösteriyoruz. Geri kalan her şey bilgi düzeyinde kalıyor. Aksi hâlde her e-posta yirmi istemci uyarısı alır ve insanlar hepsini görmezden gelir.

## 5. Erişilebilirlik

Kolayca yapılabilecek kontroller:

- `<html>` öğesinde `lang` niteliği; böylece ekran okuyucular metni doğru telaffuz eder
- bir `<title>` öğesi
- sıralı başlık seviyeleri: `h1` seviyesinden `h4` seviyesine atlamak yok
- görselin ne anlattığını söyleyen alternatif metin. “Mart ayında kayıtların ikiye katlandığını gösteren çubuk grafik” işe yarar, “image1.png” yaramaz
- gövde metninde, butonlarda ve hataların çoğunun saklandığı açık gri alt bilgi metninde yeterli kontrast

Başvuru kaynağı [WCAG 2.2](https://www.w3.org/TR/WCAG22/). E-postalardaki sorunların çoğu, bu standardın metin alternatifleri, kontrast, sayfa dili ve başlıklarla ilgili kriterlerine karşılık gelir.

## 6. Metin, konu satırı ve önizleme metni

Konu satırlarını yaklaşık **60 karakterin** ve **9 kelimenin** altında tutun; aksi hâlde telefonlar onları keser. Tamamı BÜYÜK HARFLE yazılmış konu satırlarından, yanıt olmayan e-postalarda “RE:” ya da “FWD:” kullanmaktan ve art arda ünlem işaretlerinden kaçının.

Önizleme metnini, konu satırını tekrarlamadan yaklaşık **90 karakterin** altında tutun. Boş bırakırsanız birçok istemci onun yerine “Tarayıcıda görüntüle” gibi bir metin gösterir.

Varsayılan değeri olmayan bir birleştirme etiketi, adı eksik olan herkese “Merhaba ,” gönderir. Okurlar bunu unutmaz.

Her rakamın gösterebileceğiniz bir kaynağı olmalı; özellikle kendinden emin rakamları kolayca üreten yapay zekâ ilk taslaklarında. İfadeler konusunda [pazarlama e-postaları nasıl yazılır](/tr/blog/how-to-write-marketing-emails) yazısı ve [konu satırı rehberi](/tr/blog/email-subject-lines) daha derine iniyor.

## 7. Yasal uyumluluk

[CAN-SPAM](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) kapsamında ticari e-postalarda çalışan bir abonelikten çıkma bağlantısı ve geçerli bir posta adresi bulunmalıdır. Gmail’e ve Yahoo’ya toplu gönderim yapan göndericilerin ayrıca tek tıkla abonelikten çıkma başlıklarına ihtiyacı vardır; bu konuyu [e-postalarınızı bir ajan gönderdiğinde de geçerli olan kurallar](/tr/blog/agent-email-deliverability) yazısında ele aldık.

İşlemsel e-postalar bazı pazarlama kurallarından muaftır, ama bu kontrol listesinden değil. Çalışmayan bir bağlantı içeren makbuz yine de bir destek talebine dönüşür.

## 8. HTML kodu

E-posta istemcilerinin sildiği ya da engellediği öğeleri kaldırın:

- `<script>`, `<form>` ve `<iframe>` öğeleri
- gömülü SVG ve `data:` URI’leri
- yedek bir `background-color` tanımlanmamış arka plan görselleri (yedek renk sayesinde görsel yüklenmezse de metin okunabilir kalır)

E-postaya bir doctype bildirimiyle başlayın. Bu bildirim yoksa bazı istemciler e-postayı quirks modunda görüntüler ve boşluklar kayar.

## Kontrol listesini Brew ile çalıştırmak

Brew e-posta denetimi bu listeyi şu noktalardan çalıştırır:

- gönderim penceresinde, Önizleme ve Hedef kitle sekmelerinin yanındaki **Denetle** sekmesi
- otomasyon tuvalindeki e-posta adımlarında bulunan **Denetle** düğmesi
- `POST /v1/emails/audit` isteği ya da `audit_email` aracıyla API ve MCP

Tüm alanlar için [denetim dokümantasyonuna](https://docs.brew.new/create-emails/audit-email) ve [API referansına](https://docs.brew.new/api-reference/public-v1/emails/audit-an-email) göz atın.

Ücretsiz **anlık kontroller**, yalnızca HTML kodunu gerektiren tüm kurallarda otomatik olarak çalışır: yer tutucular, boyut, eksik alternatif metin ve görsel ölçüleri, başlık sırası, `lang` ve `<title>`, konu satırı ve önizleme metni uzunluğu, varsayılan değeri olmayan birleştirme etiketleri ve engellenen kod öğeleri.

**Denetimi çalıştır**, ağ erişimi ya da değerlendirme gerektiren kontrolleri ekler:

- abonelikten çıkma ve tercih bağlantıları hariç, e-posta başına en fazla 100 bağlantıya canlı istek. Bot korumasına takılan bağlantılar “çalışmıyor” olarak değil, “doğrulanamadı” olarak döner
- çalışmayan ya da fazla büyük görselleri yakalamak için her görsele istek
- Gmail, Apple Mail, Outlook ve Yahoo olmak üzere dört ailedeki 15 istemcide, 4. bölümdeki kuralla istemci desteği
- WCAG 2.2 referanslarıyla kontrast ve diğer erişilebilirlik kuralları
- yapay zekâ incelemesi: Konu satırı yanıltıcı mı, bağlantı ve alternatif metinler bir anlam taşıyor mu, herhangi bir ülkenin formatında posta adresi var mı ve e-posta pazarlama amaçlı mı yoksa işlemsel mi

Her yapay zekâ değerlendirmesi, kendi e-postalarımızda ortaya çıkardığı bulguların en az %95 oranında doğru olacağı şekilde ayarlandı. Yalancı çoban gibi boş yere alarm veren bir yapay zekâ denetçisi, hiç olmamasından daha kötüdür.

Tam bir denetim 5 kredi tutar. Gerekli bir kontrol yapılamazsa puan içermeyen, ücretsiz bir kısmi denetim alırsınız; çünkü bazı kontrolleri atlamış bir puan yanıltıcı olur.

## Puan nasıl hesaplanır?

Her denetim 0 ile 100 arasında bir puan ve bir durum döndürür: “hazır”, “inceleme gerekiyor” ya da “hazır değil” (uygulamada “Gönderime hazır”, “İnceleme gerekiyor” ve “Sorunlar bulundu” olarak görünür). Her bulgunun bir önem derecesi (Kritik, Hata, Uyarı ya da Bilgi) ve çalışmayan bir bağlantının HTTP durum kodu gibi bir kanıtı vardır.

Puan 100’den başlar. Her kritik bulgu 20, her hata 10, her uyarı 3 puan düşürür; bilgi düzeyindeki bulgular puanı etkilemez. Her kural için yalnızca ilk üç bulgu sayılır.

Örnek: `#` adresine bağlanmış bir buton, 404 döndüren bir alt bilgi bağlantısı, alternatif metni olmayan iki görsel, 68 karakterlik bir konu satırı ve iki Yahoo istemcisinin yok saydığı flexbox.

| Bulgu | Önem derecesi | Puan |
| --- | --- | --- |
| Buton bağlantısı bir yer tutucu | Kritik | −20 |
| Alt bilgi bağlantısı 404 döndürüyor | Hata | −10 |
| Alternatif metni olmayan görsel (×2) | Uyarı | −6 |
| 60 karakteri aşan konu satırı | Uyarı | −3 |
| 2 Yahoo istemcisinin desteklemediği flexbox | Bilgi | 0 |
| **Puan** | | **61** |

Tek bir kritik bulgu ya da hata “hazır değil” anlamına gelir; yalnızca uyarılar varsa durum “inceleme gerekiyor” olur. İki bağlantıyı düzeltirseniz bu e-posta 91 puan alır ve durumu “inceleme gerekiyor” olur. Bu dürüst bir değerlendirme: E-posta artık sorunsuz gönderilebilir; geri kalanlar ise bir dakikanızı ayırmaya değer.

**Sohbette düzelt**, uyarı ve daha ciddi bulguları Brew ajanına iletir, ardından düzeltilmiş e-postada ücretsiz anlık kontrolleri yeniden çalıştırır.

## Denetimin yapmadıkları

Gönderimleri engellemez. Kritik bulgular varsa gönderim penceresi **Yine de gönder** onayını ister ve bu tercihi kayda geçirir. API, MCP ve otomasyon gönderimleri bulguları raporlar ve gönderime devam eder. Doğru varsayılan davranış da bu. Denetimin beğenmediği bazı e-postaların yine de gönderilmesi gerekir; gönderimleri rehin tutan bir kalite kontrol aracı ise eninde sonunda kapatılır.

HTML kodunuzu yeniden yazmaz. Düzeltmeler, sizin başlattığınız ayrı bir adımdır.

Gelen kutusu yerleşimini test etmez, görüntüleme ekran görüntüleri almaz ve karanlık modu kontrol etmez. Karanlık mod için telefonunuzda karanlık modu açıp bir test e-postasını açın. Siyah zeminde kaybolan logoyu böyle yakalarsınız.

## Sıkça sorulan sorular

### Bir denetim ne kadar süre geçerlidir?

Gönderim penceresinde 15 dakika. Bu süreden sonra ya da e-posta değişirse panel denetimi yeniden çalıştırmanızı ister. MCP üzerinden kaydedilmiş bir raporu 7 gün boyunca ücretsiz olarak yeniden okuyabilirsiniz.

### Yüksek puan, e-postanın gelen kutusuna düşeceği anlamına mı gelir?

Hayır. Denetim e-postanın kendisini kontrol eder. Yerleşim; alan adı itibarına, kimlik doğrulamaya ve şikâyet oranına da bağlıdır. Bunları [teslim edilebilirlik rehberinde](/tr/blog/email-deliverability) ele aldık.

### Başka bir araçta oluşturulmuş bir e-postayı denetleyebilir miyim?

Evet, API ya da MCP üzerinden. Brew e-posta kimliği yerine `emailHtml` veya `emailJsx` gönderin; e-posta ESP’nize girmeden önce aynı raporu alın. [Galeriden bir şablonu uyarlayıp ESP’nize aktarıyorsanız](/tr/blog/how-to-remix-a-real-brand-email-template-and-export-it-to-your-esp), dışa aktarmadan önce Brew ile denetleyin.

### Ekibimde bunu kimler çalıştırabilir?

Markaya erişimi olan herkes çalıştırabilir: organizasyon yöneticileri ve markaya eklenen üyeler. Brew içinde yalnızca görüntüleme yetkisi veren bir rol yok.