Hızlı Başlangıç

Hesap açmaktan ilk kampanyanızın gelen kutusuna düşmesine kadar 7 adımlık eksiksiz başlangıç rehberi. Her adımı tamamladığınızda bir sonrakine geçin; sıralamayı atlamamanız teslim edilebilirliğinizi doğrudan etkiler.

Onboarding — 7 adım

1. Hesabınızı oluşturun ve doğrulayın. app.sendertr.com/register üzerinden kaydolun. Kayıt sırasında KVKK aydınlatma metni onayı zorunludur. Ardından e-posta adresinize gönderilen doğrulama linki veya 6 haneli kod ile hesabınızı doğrulayın. Doğrulanmamış hesaplar kampanya gönderemez; giriş yaparken doğrulama maili otomatik (5 dk'da bir) yeniden gönderilir.
2. Şirket bilgilerinizi tamamlayın. Ayarlar → Şirket Bilgileri'nden firma tipinizi seçin (tacir veya esnaf). 6563 Sayılı Kanun gereği tacirler için MERSİS numarası + ticaret unvanı, esnaflar için T.C. Kimlik No + ad soyad zorunludur. Ayrıca en az bir iletişim kanalı (e-posta veya telefon) girilmelidir. Esnaflarda T.C. Kimlik No yerine vergi kimlik numarası da kabul edilir. Bu bilgiler (gönderen künyesi) ticari iletilerin altbilgisine otomatik eklenir ve zorunludur: eksikse pazarlama kampanyası onaya gönderilemez ("Önce gönderen künyesini tamamlayın") ve ticari otomasyon etkinleşmez. Eksikleri kampanya formundaki künye kartından da tamamlayabilirsiniz.
3. Gönderim domaininizi ekleyip doğrulayın. Domainler → "Alan adı ekle". Sistem size DKIM (2048-bit) ve DMARC kayıtlarını üretir; SPF isteğe bağlıdır (Return-Path SenderTR alan adında olduğu için gönderim buna bağlı değildir). DKIM ve DMARC TXT kayıtlarını alan adınızın DNS panelinde oluşturun, sonra "DNS Kontrol Et"e basın. İki kayıt da doğrulandığında (sağlık skoru 100) alan adınız gönderime hazır olur; skor 100'ün altındaysa gönderim yapılamaz. Hesabınızın ilk alan adı doğrulandığında 1.000 kredilik hoş geldin kredisi tanımlanır (90 gün geçerli; aynı kayıt IP'sinden 30 günde bir hesaba).
4. Kredinizi kontrol edin. Gönderilen her e-posta 1 kredi düşer. Bakiyeniz alıcı sayısından azsa kampanya otomatik olarak paused (duraklatılmış) duruma geçer. Krediler → "Kredi Satın Al" ile PayTR üzerinden kredi ekleyebilirsiniz.
5. Kişilerinizi yükleyin. Kişiler → İçe Aktar ile CSV/Excel dosyanızı yükleyin (e-posta kolonu eşlemesi zorunlu) veya tek tek ekleyin. İçe aktarma yalnızca adres biçimini denetler; adreslerin gerçekten var olup olmadığını (MX + SMTP + tek kullanımlık/rol tespiti) E-posta Doğrulama ile ayrıca kontrol edin — büyük ve eski listelerde ilk gönderimden önce mutlaka önerilir.
6. Şablonunuzu hazırlayın. Şablonlar → Yeni Şablon ile sürükle-bırak editörde (EmailBuilder.js) tasarımınızı yapın veya HTML modunda kendi kodunuzu kullanın. {{first_name}} gibi merge tag'lerle kişiselleştirin.
7. Kampanyanızı oluşturup onaya gönderin. Kampanyalar → Yeni Kampanya: gönderici, alıcı, konu, içerik ve zamanlamayı belirleyin. "Onaya Gönder" dediğinizde Sender Contract ön kontrolü (preflight) çalışır; tüm zorunlu maddeler geçerse kampanya otomatik risk değerlendirmesinden geçer (alan adı doğrulaması, kredi, spam ve güvenlik puanı, liste ve hesap geçmişi). Sorun yoksa otomatik onaylanır ve hemen ya da zamanlanmışsa belirlediğiniz saatte gönderilir. Riskli görülen kampanyalar (yüksek güvenlik puanı, yeni hesabın büyük ilk gönderimi, son 30 günde eşik aşmış hesap, yeni kayıtlı alan adı) SenderTR ekibinin incelemesine alınır (hafta içi 09:00–18:00); kampanya sayfasında nedenleri görürsünüz. Henüz güvenilir olmayan hesapların 2.000 ve üzeri alıcılı kampanyaları kademeli başlar: önce alıcıların yaklaşık %5'ine (200–1.000 alıcı) gönderilir, sonuçlar 30 dakika izlenir, sorun yoksa kalanı otomatik gider. Güvenilir hesap: son 90 günde en az 3 sorunsuz tamamlanmış kampanya (otomatik izlemede durdurulan yok, kalıcı bounce %2'nin altında) ya da SenderTR'nin işaretlemesi.

İlk gönderimde nelere dikkat edin?

Kampanyalar

Bir liste veya segmente tek seferlik toplu e-posta gönderimi. Her kampanya, gönderim öncesi otomatik bir kalite ve uyum denetiminden (Sender Contract) geçer. Bu bölümde formun her alanını, durum makinesini, AI yardımcılarını, preflight kontrollerini, spam analizini ve dinamik içerik bloklarını ayrıntısıyla bulacaksınız.

Adım adım kampanya oluşturma

Kampanya formu 6 mantıksal bölümden oluşur. Aşağıda her alanın ne işe yaradığı ve hangi kuralların geçerli olduğu açıklanmıştır.

Bölüm 1 — Gönderici Bilgileri

Bölüm 2 — Alıcılar

• Liste: Önceden oluşturulmuş statik kişi grubu. Seçtiğinizde segment seçimi temizlenir. Alıcı sayısı listenin member_count değerinden gelir.
• Segment: Kurallara göre dinamik kişi grubu (alternatif). Seçtiğinizde liste seçimi temizlenir. Tahmini sayı segmentin estimated_count değeridir.
• Mesaj Türü: marketing (Pazarlama) veya transactional (İşlemsel). Bu seçim suppression kurallarını belirler — aşağıdaki tabloya bakın.

Bölüm 3 — Konu

• Konu Satırı: Zorunlu, maks. 255 karakter. Yanındaki AI Öner butonu yapay zeka ile alternatif konu satırları üretir (aşağıda detay).
• Ön İzleme Metni (preview text): Opsiyonel. Gelen kutusunda konu satırının yanında/altında görünen kısa açıklama. Karakter sayacı 0/255 olarak gösterilir. Teknik olarak kampanyanın settings.preview_text alanında saklanır.

Bölüm 4 — İçerik

• Şablon Seçin: Daha önce oluşturduğunuz bir şablonu kampanyaya bağlar. "Yeni şablon oluştur" linki yeni sekmede açılır, böylece doldurduğunuz kampanya formu kaybolmaz.
• AI ile İçerik Oluştur: Bir brief ve ton (Profesyonel / Rahat-Gündelik / Samimi-Arkadaşça / Acil-Heyecanlı) girerek e-posta gövdesi ürettirebilirsiniz. Çıktıyı pencerede düzenler, yeni bir şablon olarak kaydedersiniz; şablon kampanyaya otomatik seçilir. Yapay zekâ yardımcısı varsayılan olarak kapalıdır (Ayarlar → Yapay Zekâ).

Bölüm 5 — Zamanlama

"Onay sonrası hemen gönder" veya "İleri tarih" seçeneği. Akıllı Gönderim Zamanı (STO) ve "En İyi Zaman" AI önerisi de bu bölümdedir — detaylar Gönderim & Zamanlama bölümünde.

Bölüm 6 — Dinamik İçerik Blokları

Aynı kampanyada farklı segmentlere farklı içerik göstermenizi sağlar (aşağıda ayrı başlık).

Gönderim öncesi test

Kampanya detay sayfasındaki Test Gönder kutusundan kampanyayı en fazla 5 kendi adresinize gönderebilirsiniz (taslakta seçili şablonun içeriği kullanılır). Test iletisi gerçek gönderim hattından geçer: aynı sunucu, aynı DKIM anahtarı, aynı gönderen adresi — böylece görünen göndereni ve SPF/DKIM/DMARC sonucunu "Orijinali göster" ile doğrulayabilirsiniz. Gerçek gönderimle aynı kapılardan geçer: gönderim alan adı doğrulanmış olmalı, gönderen adresi o alan adına ait olmalı ve içerik güvenlik denetiminden geçmelidir.

• Konu satırının başına [TEST] eklenir; birleştirme etiketleri örnek değerlerle dolar.
• Kampanya raporlarına ve teslim oranlarına yazılmaz; bağlantı takibi uygulanmaz.
• Her test adresi 1 kredi harcar. Günde en fazla 20 test adresi (başarısız denemeler dahil); dakikada en fazla 6 test isteği.
• Abonelikten çıkma bağlantısı test iletisinde etkisizdir.

Kaydetme ve gönderim

Formun altında üç eylem vardır:

• Spam Skor Kontrol: Gönderim yapmadan seçili şablonun içeriğini, konuyu ve göndereni analiz eder (konu ve şablon seçili olmalı).
• Taslak Olarak Kaydet: Kampanyayı draft durumunda kaydeder, istediğiniz zaman düzenlersiniz.
• Onaya Gönder: Sender Contract preflight kontrolü ve risk değerlendirmesi çalışır; sorun yoksa kampanya otomatik onaylanır, riskli görülürse submitted (İncelemede) durumunda SenderTR incelemesini bekler.

Durum makinesi (state machine)

Kampanya yaşam döngüsü katı bir durum makinesiyle yönetilir. Geçersiz geçiş denenirse sistem hata fırlatır.

AI konu satırı önerisi

Konu alanının yanındaki AI Öner butonu, kampanya adı ve ön izleme metnini bağlam olarak kullanarak Türkçe alternatif konu satırları üretir. Öneriler spam puanından geçirilir; puanı 60'ın altında kalanlar gösterilmez (bu yüzden 5'ten az öneri görebilirsiniz). Bir öneriye tıklayarak konu alanını doldurursunuz.

Sender Contract — gönderim öncesi preflight kontrolü

Kampanya formundaki Gönderim ön kontrolü paneli bu kontrolleri siz yazarken canlı gösterir: başarısız madde varsa "Onaya Gönder" kilitlidir; yalnız uyarı varsa onaya göndermeden önce uyarıları açıkça onaylamanız istenir. "Onaya Gönder" dediğinizde SenderContractService aynı kontrolleri yeniden çalıştırır. Sonuçlar üç seviyede döner: pass (geçti), warning (uyarı, gönderimi engellemez) ve fail (başarısız, gönderimi engeller). Tek bir "fail" bile varsa kampanya onaya gönderilemez.

Her kontrolün sonucu kaydedilir. Başarısız madde varsa hata mesajı "…; ancak onaya gönderilemez:" ile başlayıp geçemeyen maddeleri listeler.

Spam skoru analizi

Spam skoru içeriğinizi 100 puandan başlatıp her riskli bulgu için puan düşer (sonuç en az 0'da tutulur). Yüksek puan = iyi. Aşağıdaki teslimat kontrollerine ek olarak üç denetim daha uygulanır: içerik güvenlik denetimi (kimlik avı, yasadışı bahis, sahte gönderen adı; en çok −40), bağlantılardaki alan adlarının kara liste kontrolü (DBL/SURBL/URIBL; her biri −15, en çok −30) ve 30 günden genç gönderim alan adı (−10). Güvenlik puanı yeni hesaplarda 50, yerleşik hesaplarda 80 ve üzerindeyse ileti gönderilmez; analiz bunu ayrıca belirtir. Konu, HTML içerik, From adresi, Reply-To ve düz metin alternatifi analiz edilir. Aşağıda kontrol edilen tüm maddeler ve maksimum ceza puanları yer alır:

Her kontrol için panelde mesaj ve (başarısızsa) bir öneri görüntülenir. Skor renk kodludur: 80+ yeşil, 60–79 amber, < 60 kırmızı.

Dinamik içerik blokları

Aynı kampanyada farklı segmentlere farklı içerik göstermenizi sağlar. Her blok bir blok adı, bir koşul türü (varsayılan / segmente göre) ve HTML içerik taşır.

1. "Dinamik Blok Ekle" ile yeni blok oluşturun ve bir ad verin (ör. hero, promo, footer).
2. Koşul türünü seçin: Varsayılan (herkese) veya Segmente göre (yalnızca seçili segmente).
3. Bloğun HTML içeriğini girin.
4. Şablonunuza yer tutucuyu ekleyin. Blok adı girildiğinde panel size kopyalanabilir bir etiket gösterir, ör: {{block:hero}}.

Açmayanlara tekrar gönderim (Resend to non-openers)

Tamamlanmış bir kampanyada e-postayı açmamış kişilere yeni bir kampanya oluşturabilirsiniz (düğme yalnızca tamamlanmış kampanyada görünür).

1. Kampanya detayında "Açmayanlara Tekrar Gönder" eylemini seçin.
2. Sistem gönderilmiş/teslim edilmiş ancak açılmamış alıcıları bulur. Apple Mail ön yüklemesi ve güvenlik tarayıcısı açılmaları açılma sayılmaz; bu kişiler de "açmayan" kabul edilir.
3. [Tekrar] Kampanya Adı şeklinde, yalnızca bu kişileri hedefleyen yeni bir taslak kampanya oluşturulur.
4. Düzenleme sayfası açılır; genellikle konu satırını değiştirip onaya gönderirsiniz.

Kampanya kopyalama ve audit

• Kopyala: Mevcut bir kampanyanın ayarlarını ve dinamik bloklarını "(Kopya)" adıyla yeni bir taslağa aktarır; A/B testi ayarları kopyalanmaz, durum ve zamanlama sıfırlanır.
• Gönderim Karar Logu (Audit): /campaigns/{id}/audit — her alıcı için verilen gönderim kararını ve sebebini gösterir (gönderildi, suppression, vb.). CSV olarak dışa aktarılabilir. 6563 s. Kanun kapsamında ispatlanabilir iz sağlar.

Sık karşılaşılan sorunlar

Şablonlar

Tekrar kullanılabilir e-posta tasarımları. Kod bilmeden sürükle-bırak editörle (EmailBuilder.js) profesyonel maillere ulaşır, dilerseniz HTML çıktısını inceler ve şablonu kampanyalarınıza bağlarsınız.

Şablon oluşturma

1. Şablonlar → Yeni Şablon ile editörü açın.
2. Üstteki araç çubuğundan şablon adı (zorunlu) ve isteğe bağlı bir klasör girin. Klasörler şablonları gruplamak için kullanılır.
3. Görsel editörde blokları (metin, görsel, buton, ayraç vb.) tuvale sürükleyin.
4. İçeriği merge tag'lerle kişiselleştirin (aşağıda).
5. Kaydet'e basın. Editör tasarımı hem yapısal JSON (design_json) hem render edilmiş HTML (html_content) olarak saklar.

EmailBuilder.js sürükle-bırak editörü

Editör, panelin içine güvenli bir iframe olarak gömülen, self-hosted (kendi sunucumuzda barındırılan) bir React mini-uygulamasıdır (/email-editor/). Vue paneli ile editör arasında postMessage ile haberleşilir ve her mesaj window.location.origin ile doğrulanır (güvenlik). Editör yüklendiğinde "Editör yükleniyor..." göstergesi kaybolur ve tasarıma başlayabilirsiniz.

Görsel ve HTML modu

Merge tag'ler (kişiselleştirme)

Araç çubuğundaki Değişken menüsünden bir etiket seçtiğinizde görsel editörde yeni bir metin bloğu olarak eklenir (HTML modunda içeriğin sonuna eklenir ve panoya kopyalanır). Gönderim sırasında her etiket ilgili kişinin verisiyle değiştirilir; kişide değer yoksa boş kalır. Yalnızca aşağıdaki etiketler doldurulur; başka bir etiket (ör. {{AD_SOYAD}}) alıcıya olduğu gibi gider ve gönderim ön kontrolü bunu uyarı olarak gösterir.

Görsel kütüphanesi

1. Araç çubuğunda Görsel butonuna basın.
2. "Görsel Yükle" ile dosya seçin (dosya başına en fazla 10 MB · jpg, png, gif, webp; hesap başına toplam 500 MB). Görseller hesabınıza ayrılmış klasörde saklanır ve tam adresle (https://app.sendertr.com/storage/…) sunulur.
3. Yüklediğiniz görsele tıklayınca editöre görsel bloğu olarak eklenir. Dosyalar sayfasından (Dosyalar menüsü) görselleri yönetebilir, kullanmadıklarınızı silebilirsiniz.

Şablonu kampanyaya bağlama

Kampanya oluşturma formunda Bölüm 4 — İçerik → Şablon Seçin menüsünden şablonunuzu seçin. Aynı bölümdeki "yeni şablon oluştur" linki yeni sekmede açılır; böylece kampanya formunuz kaybolmadan şablon hazırlayıp geri dönebilirsiniz.

A/B Testi

İki farklı konu satırını gerçek alıcılar üzerinde test edin; sistem istatistiksel olarak kazanan varyantı belirleyip kalan alıcılara otomatik göndersin.

Ne test edilir?

SenderTR A/B testi konu satırını test eder. Varyant A, kampanyada girdiğiniz ana konu satırıdır; Varyant B ise alternatif konu satırıdır. Varyant B, A/B testini açtığınız andaki gönderici ve şablonla oluşturulur; sonradan kampanyada gönderici ya da şablonu değiştirirseniz Varyant B'de yalnızca konu, test yüzdesi ve kriter güncellenir. Farkın yalnızca konu satırından gelmesi için gönderici ve şablonu A/B testini açmadan önce kesinleştirin.

Kurulum

1. Kampanya formunda A/B Testi bölümündeki anahtarı açın.
2. Varyant B — Konu Satırı alanına alternatif konuyu girin (zorunlu). Varyant A salt okunur olarak ana konu satırını gösterir.
3. Test Yüzdesi kaydırıcısıyla test grubunun büyüklüğünü seçin (%10–%50, varsayılan %20). Bu yüzdenin yarısı A, yarısı B alır.
4. Kazanan Kriteri seçin: Açılma Oranı (open_rate) veya Tıklama Oranı (click_rate).

Kazanan nasıl belirlenir?

ABTestService her iki varyantın seçtiğiniz kritere göre skorunu hesaplar (açılma veya tıklama oranı) ve yüksek olanı kazanan ilan eder. Eşitlikte Varyant A öncelik kazanır. Kazanan kampanya, henüz mail almamış kalan alıcılar için kuyruğa alınır.

İstatistiksel anlamlılık (z-test)

Detaylı A/B raporunda iki oran arasındaki fark, iki oranlı z-testi ile değerlendirilir. Sistem standart normal dağılımdan (tek yönlü) bir güven düzeyi (confidence) yüzdesi hesaplar ve bu değer %95'e ulaşırsa sonucu "istatistiksel olarak anlamlı" (significant: true) işaretler. Kazanan, anlamlılıktan bağımsız olarak yüksek orana göre seçilir; anlamlılık yalnızca sonuca ne kadar güvenebileceğinizi gösterir.

z → güven düzeyi örnekleri:

Detaylı rapor her varyant için şu metrikleri içerir: gönderilen, teslim edilen, açılma, tıklama, bounce sayıları ile açılma/tıklama/bounce oranları.

Düzenleme davranışı

• A/B testini açıp düzenlerseniz, mevcut Varyant B güncellenir; yoksa yeni oluşturulur.
• A/B testini kapatırsanız, henüz gönderilmemiş (taslak) Varyant B silinir ve kampanya tekli gönderime döner.

Gönderim & Zamanlama

Kampanyanızı onay sonrası hemen, ileri bir tarihte veya her kişiye en uygun saatte (STO) gönderebilirsiniz. Bu bölüm üç gönderim modunu ve yapay zeka destekli saat önerisini açıklar.

Gönderim modları

Etkileşimsiz alıcılar (180 gün kuralı)

Pazarlama kampanyalarında, son 180 gündür aldığı hiçbir iletiyi açmamış ve tıklamamış alıcılar (bu sürede en az bir ileti teslim edilmiş olanlar) gönderen itibarınızı korumak için otomatik olarak atlanır; bu alıcılar için kredi düşülmez. Uzun süredir etkileşimsiz adresler alıcı sağlayıcılar nezdinde "istenmeyen" sinyali verir ve zamanla spam tuzağına dönüşebilir. Kampanya oluştururken ön kontrol, kaç alıcının bu nedenle atlanacağını gösterir.

• Yeni eklenen (180 günden genç) ve hiç ileti almamış alıcılar bu kuraldan etkilenmez.
• İşlemsel kampanyalar etkilenmez.
• Bu alıcılara "hâlâ bizden haber almak ister misiniz?" türü bir yeniden kazanım iletisi göndermek için kampanya formunda Etkileşimsizlere de gönder seçeneğini işaretleyin. Etkileşim verenler bir sonraki kampanyadan itibaren yeniden normal gönderime dahil olur.

Gönderim öncesi kontroller ve iade

Onaya gönderdiğiniz her kampanya otomatik kontrolden geçer. Ön kontrol kutusunda listenizle ilgili notlar görürsünüz: tek kullanımlık (geçici) e-posta alan adları, rol adresleri (info@, admin@ gibi) ve doğrulamada geçersiz çıkan adresler; bunlar geri dönme ve şikâyet riski taşır, Listeler → Temizleme ile ayırmanızı öneririz. İçerik spam filtrelerine takılacak görünüyorsa ya da listede riskli adres payı yüksekse kampanya ekibimizin kısa incelemesine düşer; nedenini kampanya sayfasında görürsünüz. Bağlantılarınız da denetlenir: yanıt vermeyen bağlantılar ve URL kısaltıcılar (bit.ly gibi) onay mesajında bildirilir — kısaltıcılara alıcı sağlayıcılar güvenmez, tam adresi kullanın.

İade: Gönderim başlamadan önce bir yapılandırma sorunu çıkarsa (alan adı silinmiş ya da doğrulanmamış, gönderen adresi uyumsuz, alıcı yok, kredi yetersiz) kampanya taslağa iade edilir; size panel bildirimi ve e-posta gelir, kampanya sayfasında nedeni görürsünüz. Düzeltip yeniden onaya gönderirsiniz; kredi düşülmez. Ekibimiz incelemede bir düzeltme isterse aynı yolla notuyla birlikte iade eder.

Send Time Optimization (STO) — Akıllı Gönderim Zamanı

Zamanlama bölümündeki Akıllı Gönderim Zamanı (STO) kutusunu işaretlerseniz, her alıcının iletisi gönderim başladıktan sonraki 24 saat içinde o kişinin en aktif olduğu saate ertelenir. STO açık kampanyalarda kademeli başlangıç uygulanmaz; A/B testli kampanyalarda STO kullanılmaz (test ve kazanan gönderimi hemen yapılır).

STO en iyi saati nasıl bulur?

SendTimeOptimizationService her kişi için şu hesaplamayı yapar:

1. Son 90 günlük açılmaları toplar. Kişinin geçmiş e-posta açılma kayıtları (opened_at) incelenir.
2. En çok açılan saati seçer. Kişinin en yüksek açılma sayısına sahip saati contacts.best_send_hour alanına yazılır.
3. Veri yoksa atlar. Hiç açılma kaydı olmayan kişiler için değer boş bırakılır ve genel kampanya saati kullanılır.

Önce etkileşimli alıcılar

Zamanlama bölümündeki Önce etkileşimli alıcılar kutusu işaretliyse, 12 aydır hiçbir e-postanızı açmayan ya da tıklamayan ve 30 günden eski kişiler 2 saat sonra gönderilir; etkileşimli kişiler ilk dalgada gider. Alıcı sağlayıcılar ilk dalgada açılma ve tıklama görünce kampanyanın geri kalanına daha iyi davranır. Kademeli başlangıç ve STO ile birlikte kullanılabilir.

Kampanya sağlık puanı

Kampanya formundaki ön kontrol kutusu artık tek bir puan gösterir (0–100): 100'den başlar, her engel −30, her uyarı −10; kitlede 12 aydır etkileşimsiz pay yüksekse −15'e kadar, ticari ileti izni bilinmeyen pay yüksekse −15'e kadar düşer. 85+ Gönderime hazır, 60–84 Uyarı, altı Riskli; engel varsa her durumda "Engelli" ve onaya gönderilemez. Puanın altındaki notlar ne yapmanız gerektiğini söyler (liste temizleme, İYS izin listesi yükleme, DNS kaydı).

"En İyi Zaman" AI önerisi

Zamanlama bölümündeki En İyi Zaman butonu, hesabınızın genel açılma davranışına bakarak en iyi gönderim saatlerini önerir (kişi bazlı STO'dan farklı olarak, tüm hesap için toplu öneri).

• Son 90 günlük açılmalar saat bazında gruplanır ve en çok açılma alan ilk 3 saat önerilir (açılma sayısıyla birlikte).
• Hiç açılma verisi yoksa genel öneri olarak 10:00, 14:00 ve 20:00 sunulur ("Genel öneri" notuyla).
• Bir saate tıklayınca kampanya, bugünün tarihiyle o saate zamanlanır ve mod otomatik "İleri tarih"e geçer.

Hangisini seçmeliyim?

Kişiler (Contacts)

Kişi, gönderim yaptığınız her bir e-posta adresinin platformdaki kaydıdır. Tek tek ekleyebilir, dosyadan içe aktarabilir, listelere bağlayabilir ve her birinin etkileşim geçmişini zaman çizelgesiyle takip edebilirsiniz. Kişiler tenant bazında izoledir — başka bir hesabın kişilerine erişilemez.

Kişi sayısı sınırı

Her hesabın planına göre kişi sınırı vardır: Ücretsiz 5.000, Başlangıç 25.000, Profesyonel 100.000, İşletme 250.000. Hesabınızdaki tüm kişi kayıtları sayılır — hiçbir listede olmayanlar, abonelikten çıkanlar, geri dönenler ve engellenenler dahil (bunları silerek yer açabilirsiniz). Sınır yalnızca yeni kişi eklerken uygulanır; mevcut kayıtları her zaman güncelleyebilirsiniz. Toplu içe aktarmada sınır dolarsa sığan kadarı aktarılır ve kaç kişinin aktarılamadığı bildirilir. Daha büyük bir kredi paketi aldığınızda planınız ve bu sınır otomatik yükselir; ihtiyacınız olursa Limitler sayfasından kredinizle 30 günlüğüne ek kişi limiti de alabilirsiniz.

Kişi Alanları

Bir kişide tutulan alanlar ve doğrulama kuralları aşağıdadır. Yalnızca e-posta zorunludur; diğer tüm alanlar isteğe bağlıdır.

Tek Tek Kişi Ekleme

1. Kişiler → Yeni Kişi sayfasını açın.
2. E-posta adresini girin (zorunlu). İsterseniz ad, soyad, telefon ve şehir ekleyin.
3. İsterseniz özel alanlar tanımlayın (anahtar/değer).
4. Kişiyi bir veya birden fazla listeye bağlayın (yalnızca kendi listeleriniz görünür).
5. Kaydet'e basın. E-posta daha önce kayıtlıysa yeni kayıt oluşturulmaz; mevcut kişinin bilgileri güncellenir ve "Bu e-posta zaten kayıtlıydı, bilgiler güncellendi." mesajı görünür.

Kişi Durumu (status)

Her kişinin gönderilebilirliğini belirleyen bir durumu vardır:

Etkileşim Puanı (0–100)

Her aktif kişi için son 90 günlük davranışa göre otomatik bir etkileşim puanı hesaplanır. Hesaplama her Pazar 03:00'te çalışır ve puan kişinin kendi kaydına (engagement_score) yazılır; segmentlerde "Etkileşim Puanı" ile kullanılır. Yalnızca kampanya iletileri sayılır.

Ham puan şu formülle hesaplanır, ardından 0–100 aralığına sıkıştırılır:

rawScore = (açılma_90g × 3) + (tıklama_90g × 5)
         - (bounce × 10) - (şikayet × 20)

score = max(0, min(100, rawScore))

Ayrıca her kişi için son açılma/tıklama tarihleri, alınan kampanya sayısı ve 90 günlük toplam açılma/tıklama değerleri saklanır. Bu veriler segmentleme ve liste temizlemede kullanılır.

Kişi Zaman Çizelgesi (Customer Journey Timeline)

Bir kişinin detay sayfasında, o kişiyle ilgili tüm olaylar tek bir dikey zaman çizelgesinde, en yeniden eskiye doğru sıralanır. Kaynaklar:

• Eklenme: Kişinin sisteme giriş tarihi ve kaynağı (Manuel, import vb.).
• Doğrulama: verified_at + sonucu (geçerli, geçersiz, riskli, tek kullanımlık, spam tuzağı, catch-all, rol) ve skoru.
• Mesaj olayları (son 100): gönderildi, teslim edildi, açıldı, link tıklandı, hard/soft bounce, spam şikâyeti — her biri ilgili kampanya adıyla.
• Denetim (audit) olayları: eklendi, listeye eklendi, suppression eklendi, abonelikten çıkış, suppression sonrası yeniden ekleme, yönetici ile engel kaldırma.
• Suppression kaydı: Engelleme varsa oluşma anı ve sebebi.

Kişileri Silme ve Dışa Aktarma

• Tekli/Toplu silme: Bir veya birden fazla kişiyi silebilirsiniz. Toplu silme yalnızca kendi tenant'ınızın kişilerini hedefler.
• CSV dışa aktarma: Tüm kişileri (e-posta, ad, soyad, telefon, şehir, durum, kaynak, kayıt tarihi) kisiler.csv olarak indirebilirsiniz.

Listeler (Lists)

Liste, kişileri gruplamanın en temel yoludur. Bir kişi aynı anda birden fazla listede olabilir. Kampanyalar listelere veya segmentlere gönderilir. Listeler ayrıca temizleme, Tacir istisnası ve zorunlu liste (whitelist) gibi gelişmiş özellikleri destekler.

Liste Oluşturma

1. Listeler → Yeni Liste'yi açın.
2. Liste adını girin. Ad yalnızca harf, rakam, boşluk ve - _ . , ( ) içerebilir; % & / ^ gibi özel karakterler kullanılamaz.
3. İsterseniz bir açıklama ekleyin (max 1000 karakter).
4. Gerekiyorsa Tacir Listesi kutusunu işaretleyin (aşağıya bakın).
5. Kaydet'e basın.

Listeye Kişi Ekleme

Listeye iki şekilde kişi eklersiniz:

• Mevcut kişilerden ekleme: Liste detayında arama yaparak (en fazla 80 sonuç gösterilir) listede olmayan aktif kişileri seçip ekleyebilirsiniz. Tek seferde en fazla 500 kişi eklenebilir. Sadece kendi tenant'ınızın aktif kişileri eklenir; zaten listede olanlar tekrar eklenmez.
• İçe aktararak (import): CSV/Excel dosyasını yüklerken hedef liste seçilebilir veya yeni liste oluşturulabilir (Import bölümüne bakın).

Liste Temizleme

Liste temizleme, gönderim itibarınızı korumak için sorunlu kişileri tespit edip baskılar (suppress) — yani durumlarını suppressed yapar. Temizleme ekranı her kategori için adet, yüzde ve örnek e-postalar gösterir. Yüzdeler, tenant'ın toplam aktif kişi sayısına göre hesaplanır.

Her kategoriyi tek tek temizleyebilir veya "Tümünü Temizle" ile tüm kategorileri tek seferde baskılayabilirsiniz. Temizleme, ilgili kişilerin durumunu suppressed yapar (kişi silinmez). Dikkat: temizleme belirli bir listeye değil, hesabınızdaki tüm aktif kişilere uygulanır; "Abonelikten çıkanlar" kategorisini temizlemek bu kişilerin işlemsel kampanyaları da almamasına yol açar.

Tacir Listesi (Tacir İstisnası)

Bir listeyi "Tacir Listesi" olarak işaretlemek, 6563 sayılı Kanun'un tacir/esnaf istisnası kapsamında kurumsal rol adreslerine ayrıca ticari elektronik ileti onayı aranmadan gönderim yapılabilmesini sağlar. Bir adresin tacir sayılması için iki koşul birden gerekir:

1. Local part kurumsal rol adı olmalı: @ öncesi, bilinen ~120 Türkçe/İngilizce kurumsal rol önekinden biri olmalı (ör. bilgi, info, satis, sales, muhasebe, billing, ik, hr, destek, support, kvkk, legal …). Nokta, tire ve alt çizgi yok sayılır (halkla.iliskiler → halklailiskiler).
2. Domain kurumsal olmalı: Domain, ücretsiz/kişisel bir servis olmamalı. Gmail, Hotmail, Outlook, Yahoo, iCloud, Yandex, Mail.ru, GMX, ProtonMail gibi ~50 ücretsiz sağlayıcı tacir istisnasından yararlanamaz.

isTacirAddress(email) = isRoleAddress(localPart) AND isCorporateDomain(domain)

// Örnek:
info@firma.com.tr   → TACİR (rol + kurumsal domain)
satis@sirket.com    → TACİR
info@gmail.com       → tacir DEĞİL (ücretsiz domain)
ahmet@firma.com.tr   → tacir DEĞİL (rol adresi değil)

Zorunlu Liste / Whitelist

Zorunlu liste tek bir muafiyet tanır: buradaki kişiler abonelikten çıkmış olsalar bile işlemsel (transactional) kampanyaları alır. Kalıcı bounce, şikâyet, elle engelleme ve süreli "posta kutusu dolu" engeli muafiyet dışıdır; pazarlama kampanyalarına hiçbir etkisi yoktur. Yalnızca alıcının almak zorunda olduğu bildirimler için kullanın (ör. fatura, güvenlik uyarısı, sözleşme bildirimi).

1. Zorunlu Liste sayfasını açın.
2. Eklemek istediğiniz e-posta adresini ve isteğe bağlı bir gerekçe girin.
3. Kişi tenant'ınızda yoksa otomatik oluşturulur (kaynak: whitelist). Ekle'ye basın.
4. Gerektiğinde kişiyi zorunlu listeden çıkarabilirsiniz.

Segmentler (Segments)

Segment, kişilerinizi kurallara göre dinamik biçimde filtreleyen kayıtlı bir sorgudur. Listeden farkı: liste sabit bir üye kümesidir, segment ise her çalıştığında kuralları yeniden değerlendirir. Böylece "son 30 günde tıklayan ve etkileşim puanı 50+ olan kişiler" gibi gruplar otomatik güncel kalır.

Dinamik vs Statik

Segment Alanları

Güvenlik için segment kuralları yalnızca izin verilen (allow-list) alanlar üzerinde çalışır. İzin dışı bir alan sessizce yok sayılır. Panelde aşağıdaki alanlardan ilk 12'si seçilebilir; opt_in_status, best_send_hour ve updated_at yalnızca kural tanımında (API) kullanılabilir:

Operatörler

Panel, alanın türüne uygun operatörleri gösterir: metin alanlarında eşitlik/içerme/başlama-bitme ve boş/dolu; sayılarda equals, greater_than, less_than; tarihlerde in_last_days, not_in_last_days, boş/dolu.

Örnek Segment Kuralları

Örnek 1 — Sıcak (engaged) kişiler: Etkileşim puanı 50+ ve son 30 günde tıklamış.

Grup 1 (AND):
  engagement_score  greater_than     50
  last_click_at     in_last_days     30

Örnek 2 — İstanbul VEYA Ankara'daki geçerli adresler: Gruplar OR, grup içi AND.

Grup 1 (AND):  city = "İstanbul"   AND  verification_status = "valid"
   VEYA
Grup 2 (AND):  city = "Ankara"     AND  verification_status = "valid"

Örnek 3 — Yeniden etkileşim (re-engagement) hedefi: 90 günden uzun süredir açmamış veya hiç açmamış kurumsal kişiler. "Son 90 günden eski" koşulu hiç açmamış (tarihi boş) kişileri kapsamadığı için ikinci bir grup gerekir:

Grup 1 (AND):
  last_open_at  not_in_last_days  90
  email         ends_with         ".com.tr"
   VEYA
Grup 2 (AND):
  last_open_at  is_empty
  email         ends_with         ".com.tr"

Segment Oluşturma ve Önizleme

1. Segmentler → Yeni Segment'i açın ve bir ad verin.
2. Kural grupları ekleyin: her grupta bir veya birden çok koşul (AND), gruplar arasında OR.
3. Önizleme ile kaç aktif kişinin eşleştiğini ve tüm kişileriniz içindeki yüzdesini anlık görün.
4. Kaydet'e basın. Tahmini kişi sayısı (estimated_count) segmentle birlikte saklanır.

İçe Aktarma (CSV / Excel Import)

Büyük kişi listelerini dosyadan yükleyebilirsiniz. Ekranda üç adım vardır: Dosya Yükle → Alan Eşleme → Onay & İçe Aktar. İşlem arka planda kuyrukta yürür ve tamamlanınca size bildirim gönderilir. İçe aktarma hiçbir otomasyonu başlatmaz ve adresleri yalnızca biçim olarak denetler (gerçek doğrulama için E-posta Doğrulama).

Desteklenen Formatlar

Adım Adım İçe Aktarma

1. Dosyayı yükleyin. Sistem dosyayı analiz eder; başlıkları, ilk 5 satırın önizlemesini, tespit edilen ayraç bilgisini ve otomatik kolon eşlemesini döndürür.
2. Kolonları eşleyin. Sistem başlıkları otomatik tanır (büyük/küçük harf, Türkçe karakter, boşluk, tire ve alt çizgi farkları yok sayılır; 3+ karakterli başlıklar kısmi eşleşmeyle de tanınır). email, e-posta, mail → e-posta; ad, isim, name → ad; soyad, surname → soyad; telefon, tel, gsm → telefon; sehir, il → şehir. Eşlemeyi elle düzeltebilirsiniz. En az bir kolon e-postaya eşlenmelidir. Yalnızca e-posta, ad, soyad, telefon ve şehir içe aktarılabilir; diğer sütunlar (özel alanlar dahil) yok sayılır.
3. Hedef liste seçin. Mevcut bir listeyi seçin veya yeni liste adı girerek oluşturun. Liste seçmeden de import yapılabilir.
4. İşlemi başlatın. Import arka plan kuyruğuna alınır. Sayfada "Import başlatıldı… tamamlandığında bildirim alacaksınız." mesajı görünür.
5. Bildirim alın. İş bitince uygulama içi bildirim gelir: kaç kişi eklendi, kaç kişi güncellendi, kaç satır geçersizdi (ve double opt-in açıksa kaç onay e-postası gönderildi).

Arka Plan İşleme Mantığı

İçe aktarma ProcessContactImportJob kuyruğunda, 500'erlik chunk'lar hâlinde ve veritabanı transaction'ı içinde toplu (bulk) upsert ile işlenir:

• Her satır kolon eşlemesine göre alanlara dönüştürülür; e-postası boş veya geçersiz satırlar "geçersiz" sayılıp atlanır.
• Aynı chunk içinde tekrar eden e-postada son kayıt geçerli olur.
• E-posta tenant içinde benzersizdir; var olan kişi güncellenir (duplicate), yoksa oluşturulur (imported). Kaynak import olarak işaretlenir. Güncellemede yalnızca dosyada eşlenmiş sütunlar değişir; eşlenmiş sütunda boş bırakılan hücre mevcut değeri silmez. Mevcut kişinin durumu (ör. abonelikten çıkmış) değişmez.
• Sütun sayısı başlık satırından az olan satırlar eksik hücreler boş sayılarak alınır; fazla olan satırlar (ör. tırnaklanmamış virgül) alanlar kayabileceği için alınmaz ve "geçersiz" sayılır.
• Plan kişi sınırı dolarsa sığan kadarı aktarılır; bildirimde sınır nedeniyle aktarılamayan sayısı yazar.
• Liste seçildiyse tüm kişiler listeye çift kayıt olmadan eklenir; liste üye sayısı güncellenir.
• İşlem bitince yüklenen dosya sunucudan silinir.

Double Opt-in (Çift Onay)

Tenant ayarlarında double opt-in açıksa, import sırasında yalnızca o import'ta yeni oluşturulan ve opt_in_status = single olan kişilere onay e-postası gönderilir. Bu, mevcut kişilere gereksiz onay maili gitmesini önler. Her onay e-postası 1 kredi harcar (bakiye yoksa gönderilmez); aynı adrese günde en fazla bir onay e-postası gider. Onay bekleyen kişi (pending) onaylayana kadar pazarlama kampanyası ve ticari otomasyon almaz. Onay e-postası gönderilemezse hata loglanır ama import durmaz.

Hata Durumları

E-posta Doğrulama (Verification)

Doğrulama, bir e-posta adresinin gerçekten teslim edilebilir olup olmadığını gönderim yapmadan denetler. Hatalı, tek kullanımlık veya tuzak adresleri ayıklayarak bounce oranınızı düşürür ve itibarınızı korur. Tüm işlem yerel yapılır — dış API'ye veri gönderilmez (KVKK uyumlu).

Doğrulama Aşamaları

Her adres sırayla şu kontrollerden geçer:

1. Sözdizimi (RFC 5321/5322): Uzunluk, @ sayısı, local part (max 64) ve domain (max 253) kuralları, ardışık/baştaki/sondaki nokta, geçersiz karakter, en az iki harfli TLD denetimi. Türkçe karakter veya boşluk içeren domain reddedilir.
2. Spam tuzağı tespiti: spamtrap, honeypot, blackhole gibi local part'lar; 10+ ardışık rakam; 20+ karakterlik rastgele hex desenler tuzak sayılır.
3. Tek kullanımlık (disposable): Adres, 57.000+ domainlik disposable listesinde mi diye bakılır (ör. mailinator, yopmail, 10minutemail). Liste önbelleğe alınır.
4. Rol adresi: info, admin, support, noreply, sales gibi kişisel olmayan kurumsal adresler işaretlenir (sonuç risky + is_role_based: true).
5. KEP adresi: Kayıtlı elektronik posta adresleri kep sonucu alır; bu adreslere kampanya gönderilmez.
6. MX kontrolü: Domain'in MX kaydı dig ile, sistem resolver önbelleği atlanarak otoriter NS üzerinden sorgulanır (bulunamazsa 8.8.8.8 fallback). MX yoksa adres invalid'tir; DNS sorgusu zaman aşımına uğrarsa sonuç unknown olur.
7. SMTP el sıkışması: MX sunucusuna bağlanılır (port 25 → 587 → 465 sırasıyla denenir; 587'de STARTTLS), EHLO → MAIL FROM → RCPT TO akışı yürütülür. 250 → kabul; 550/5.1.1 → geçersiz; 4xx → geçici ret (greylisting olabilir, "riskli").
8. Catch-all tespiti: İki farklı rastgele adres denenir. İkisi de kabul edilirse, sunucunun gerçek catch-all mı yoksa arka planda filtreleyen bir gateway mi olduğu dinamik sinyallerle (MX farklı kurumda mı, yanıtlar aynı mı, generik mi, gateway adı var mı) puanlanır. Yüksek gateway ihtimali → unknown; aksi halde gerçek catch_all.

Sonuç Kategorileri

Her sonuçla birlikte 0–100 güven skoru ve ek bayraklar döner: mx_found, smtp_check, is_disposable, is_role_based, is_catch_all, is_spam_trap ve açıklayıcı bir SMTP mesajı.

Tek Adres Doğrulama

1. Doğrulama sayfasını açın; mevcut kredi bakiyeniz ve birim maliyet görünür.
2. Adresi girip Doğrula'ya basın.
3. Sonuç (kategori + skor + sinyaller) anında gösterilir ve doğrulama geçmişine kaydedilir. Bu ekran kişi kaydındaki doğrulama durumunu değiştirmez; kişileri güncellemek için toplu doğrulamayı kullanın.

Toplu Doğrulama

1. Kişiler ekranında seçili kişileri ya da tüm kişileri doğrulamayı seçin. Yalnızca aktif kişiler doğrulanır ve ücretlendirilir; engelli, abonelikten çıkmış ve şikâyetçi kişilere zaten gönderim yapılmaz. Bir listeyi doğrulamak için liste sayfasındaki liste doğrulamasını kullanabilirsiniz (maliyet önizlemesi, yazım hatası düzeltme, geçersizleri listeden çıkarma, CSV dışa aktarma).
2. Sistem maliyeti önceden hesaplar (kişi sayısı, gerekli kredi, mevcut bakiye, karşılanabilir mi).
3. Onaylayınca kredi atomik olarak düşülür, bir doğrulama seansı (session) oluşturulur ve arka planda işlenir.
4. İlerlemeyi canlı izleyebilir, biten seansların özetini ve adres bazlı sonuçlarını görebilirsiniz.

Kredi Maliyeti

Maliyet, sonuç olumlu ya da olumsuz olsun, yapılan iş sayısına göre hesaplanır. Yetersiz kredi varsa işlem başlamaz; gerekli ve mevcut kredi miktarı bildirilir. Her doğrulama bir kredi hareketi (email_verification) olarak loglanır.

API ile Doğrulama

Doğrulama, REST API üzerinden de yapılabilir ve panelle birebir aynı motoru kullanır (aynı disposable listesi, catch-all analizi, spam-trap ve sözdizimi tespiti). Tek adres ve en fazla 100 adreslik toplu uçlar mevcuttur; sonuçlar yine hesabınıza kaydedilir ve fiyat paneldekiyle aynıdır (tekli ve toplu, 1 adres = 1 kredi).

Suppression (Kalıcı Engelleme)

Suppression listesi, e-posta gönderilmemesi gereken adreslerin listesidir (gönderim tipine göre istisnalar ve süreli "posta kutusu dolu" engeli dışında kalıcıdır). Bir adres suppression'a girdiğinde, kişi silinip yeniden eklense bile koruma devam eder. Bu, abonelikten çıkmış veya şikâyet etmiş birine yanlışlıkla tekrar gönderim yapılmasını engeller.

Engel listesini görme ve kaldırma talebi

Tüm engelli adresleri (kalıcı geri dönme, şikâyet, elle eklenen, posta kutusu dolu, abonelikten çıkma) Engel Listesi menüsünden görebilir, adrese ya da nedene göre süzebilirsiniz. Her satırda engelin işlemsel gönderimi de durdurup durdurmadığı yazar. Bir adresin gerçekten kullanılabilir olduğunu düşünüyorsanız satırdaki Kaldırma talebi düğmesiyle kısa bir açıklama yazarak talep gönderin. Abonelikten çıkanlar için talep gönderilemez; bu kişinin kendi kararıdır ve yalnızca kişi formunuz üzerinden yeniden abone olup onay bağlantısına tıklarsa kendiliğinden kalkar. Talep ekibimizin onayına düşer; karar hesabınızın e-posta adresine bildirilir ve aynı sayfadaki Kaldırma taleplerim bölümünde görünür. Talep göndermek için hesap sahibi, yönetici ya da pazarlamacı rolü gerekir. Aynı işlemler API ile de yapılabilir.

Başka platformdan baskılama listesi taşıma

Eski sisteminizdeki abonelikten çıkanları, kalıcı geri dönenleri ve şikâyet edenleri ilk kampanyanızdan önce aktarın: Listeler → Abonelikten Çıkanlar → İçe Aktar. CSV, XLSX, XLS, TXT veya JSON kabul edilir (50 MB'a kadar). E-posta sütununu seçersiniz; sebep sütunu varsa unsubscribed, hard bounce, complaint, geçersiz gibi yazımlar otomatik tanınır, tanınmayanlar seçtiğiniz varsayılan sebeple işlenir.

Seçilebilen varsayılan sebepler: abonelikten çıkma (sebep sütunu yoksa varsayılan), şikâyet, kalıcı bounce. Var olan kayıtlar korunur (aynı dosyayı iki kez yüklemek veriyi bozmaz). Dosyadaki adres hesabınızda kişi olarak varsa, sebep ne olursa olsun kişinin durumu suppressed yapılır ve hiçbir gönderim (işlemsel kampanya dahil) almaz. Eski sistemde çıkmış bir adrese yeniden göndermek 6563 sayılı Kanun ihlalidir ve şikâyet üretir; bu aktarım o riski kapatır.

Suppression Nedenleri

Gönderim Tipine Göre Davranış

Suppression'ın etkisi, gönderimin tipine göre değişir. hard_bounce, complaint, manual ve süreli mailbox_full her zaman bloke eder; unsubscribe ise ticari iletileri bloke eder:

Abonelikten Çıkanlar Listesi (Salt Okunur)

Abonelikten çıkanlar (unsubscribe nedenli suppression kayıtları) ayrı bir ekranda listelenir; kişinin belirttiği çıkış nedeni ve yorumu, hangi kampanyadan çıktığı ve son 90 günün neden dağılımı da gösterilir. Bu liste tasarım gereği salt okunurdur: arama ve sayfalama yapabilirsiniz ama kişiyi buradan elle çıkaramazsınız.

• Tenant, kişiyi sistemden silebilir ama onu abonelikten çıkanlar korumasından çıkaramaz.
• Bu koruma kasıtlıdır: bir kullanıcı abonelikten çıktıktan sonra elle yeniden listeye eklenerek tekrar pazarlama maili almaya zorlanamaz.

Kalıcılık Garantisi

Suppression kaydı kişiden bağımsız olarak e-posta bazında tutulur. Bu nedenle:

• Kişi silinse bile suppression kalır (süreli mailbox_full engeli süresi dolunca kalkar).
• Platform geneli süreli engel: bir adres SenderTR'deki herhangi bir hesapta "alıcı yok", "hesap kapatılmış", "alan adı yok" ya da "alan adı e-posta kabul etmiyor" kalıcı yanıtını aldıysa, ortak gönderim altyapısının itibarını korumak için 30 gün boyunca hiçbir hesaptan gönderilmez (Amazon SES'in genel engel listesine benzer). Bu engel sizin listenizde görünmez ve kredi düşülmez; API suppression_reason: "platform_invalid" döner, kampanya ve otomasyonda alıcı atlanır. Kutu dolu, spam şüphesi, IP itibarı gibi retler bu kapsama girmez. Adresin gerçekten çalıştığından eminseniz destek ekibimize yazın.
• Aynı e-posta yeni bir kişi olarak tekrar eklenirse, gönderim aşamasında suppression yeniden uygulanır.
• Suppression varken panelden, listeye ekleme ile ya da API ile yeniden ekleme girişimi readded_after_suppression olarak denetim kaydına yazılır (uyum/ispat için).

Otomasyonlar

Otomasyonlar; bir olay (tetikleyici) gerçekleştiğinde kişileri otomatik bir e-posta akışına dahil eden, kampanyalardan farklı olarak tek seferlik değil sürekli çalışan akışlardır. Hoş geldin serileri, doğum günü kutlamaları, satın alma sonrası takip ve yeniden etkileşim gibi senaryoları bir kez kurarsınız; sistem her yeni kişi için ayrı ayrı çalıştırır.

Otomasyon nasıl çalışır?

1. Tetikleyici (trigger). Akışı başlatan olay: kişi eklendi, etiketlendi, form gönderdi, belirli bir tarih geldi, sipariş tamamlandı vb.
2. Adımlar (steps). Sırayla işleyen kutular: e-posta gönder, bekle (gecikme), koşul kontrol et (dallanma), aksiyon yürüt (etiket/liste/alan değişikliği).
3. Kayıt (enrollment). Tetikleyici eşleşen her kişi için bir kayıt açılır; kişi adım adım ilerletilir, akış bitince kayıt completed olur.

Akış motoru her dakika çalışır: zamanı gelen aktif kayıtlar ilerletilir (bir turda en fazla 500 kayıt). Aynı kayıt hiçbir zaman iki kez aynı anda işlenmez ve bir kişiye aynı e-posta adımı yalnızca bir kez gönderilir.

Adım adım otomasyon oluşturma

1. Otomasyonlar → Yeni Otomasyon. Boş başlayın ya da galeriden hazır bir şablon seçin. Otomasyon adı zorunludur.
2. Tetikleyiciyi seçin. Türe göre ek alanlar açılır (liste, etiket, tarih alanı + ofset). "Kişi Listeye Eklendiğinde" için ayrıca Kimler bu otomasyona girsin? seçimini yaparsınız (giriş kaynakları).
3. Gönderici bilgilerini girin. Gönderim alan adını seçin, gönderici adını ve adresin yerel kısmını yazın (bilgi + sirket.com → bilgi@sirket.com). Başka bir alan adının adresi kabul edilmez.
4. Adımları ekleyin ve e-postaların içeriğini yazın. Her e-posta adımında konu ve içerik (ya da bir şablon) gerekir.
5. Etkinleştirin. Otomasyon sayfasındaki kontrol paneli eksik bir şey varsa listeler; eksikler tamamlanmadan "Aktifleştir" düğmesi çalışmaz.

Etkinleştirme kontrolleri

Taslak ya da duraklatılmış bir otomasyonun sayfasında, etkinleştirmeden önce neyin eksik olduğu gösterilir. Kurallar kampanyalarla aynıdır:

Kimler bu otomasyona girer? (giriş kaynakları)

"Kişi Listeye Eklendiğinde" (contact_added) tetikleyicisi, kişinin nereden geldiğine göre çalışır. Hoş geldin e-postası bir ticari iletidir; bu yüzden varsayılan olarak yalnızca kendi isteğiyle abone olan kişiler otomasyona girer:

CSV/Excel içe aktarma hiçbir otomasyonu başlatmaz.

Panelden eklenenler için günlük sınır

Hesabınız güvenilir duruma geçene kadar, panelden eklenen kişilerden (tek tek, toplu liste ve otomasyon sayfasındaki "Manuel Kişi Ekle") ticari otomasyonlara günde en fazla 2.000 kişi alınır. Sınır hesap başınadır (tüm otomasyonlar toplamı) ve her gün yenilenir.

• Sınır dolunca sonraki kişiler otomasyona alınmaz (sonradan da eklenmez); hesap sahibine ve yöneticilere günde bir kez e-posta ve uygulama içi bildirim gider.
• Otomasyon sayfasında bugünkü kullanım ("bugün X / 2.000 kişi") ve sınır nedeniyle alınmayan kişi sayısı görünür.
• Kayıt formu, çift onay ve API ile gelenler bu sınıra dahil değildir.
• Güvenilir hesap: son 90 günde en az 3 sorunsuz tamamlanmış kampanya (otomatik izlemede durdurulan yok, kalıcı bounce %2'nin altında) ya da SenderTR'nin hesabı güvenilir olarak işaretlemesi. Bu tanım kampanyalardaki kademeli başlangıçla aynıdır. Güvenilir hesapta sınır uygulanmaz.

Tetikleyiciler

Tarih alanı tetikleyicisi nasıl çalışır?

Her sabah ilgili tarih alanının ay-gün kısmı bugünle karşılaştırılır (yıl önemsizdir). offset_days ile tetiklemeyi öne çekebilirsiniz: offset = 3 ile "3 gün sonraki olayları bugünden" yakalarsınız. Aynı kişi aynı yıl içinde tekrar kaydedilmez.

Adım türleri

Şablon seçilen e-posta adımında içerik gönderim anında şablondan okunur: şablonu sonradan düzenlerseniz otomasyon yeni hali gönderir (kampanyalardan farkı budur). Düzenlenen şablon içerik güvenlik denetimine takılırsa o adım gönderilmez ve size bildirilir.

Koşul (condition) türleri

• opened_email — Kişi, bu akışa girdikten sonra bir e-posta açtı mı? (Apple Mail ön yüklemesi ve güvenlik tarayıcıları açılma sayılmaz.)
• clicked_link — Kişi, akışa girdikten sonra bir bağlantıya tıkladı mı?
• in_segment — Kişi belirtilen segmentin kurallarına uyuyor mu? (Yalnızca kendi hesabınızın segmentleri.)
• has_tag — Kişide belirli bir etiket var mı?
• field_equals — Kişinin bir alanı belirtilen değere eşit mi?

Sonuç evet ise yes, hayır ise no dalı işlenir. İlgili dal tanımlı değilse akış sıradaki adımdan devam eder.

Aksiyon (action) türleri

• add_to_list — Kişiyi belirtilen listeye ekler.
• remove_from_list — Kişiyi listeden çıkarır.
• update_field — Kişinin bir alanını günceller (yalnızca first_name, last_name, phone, city, status).
• add_tag — Kişiye etiket ekler (mükerrer eklemez). Etiket ilk kez eklendiyse "Kişi Etiketlendiğinde" otomasyonları başlar; böylece otomasyonları birbirine bağlayabilirsiniz.

Örnek: gecikmeli koşullu akış

1) email      → "Hoş geldiniz" gönder
2) delay      → 5 gün bekle
3) condition  → opened_email?
      ├─ yes → action: add_tag "etkilesim_yuksek"
      └─ no  → email: "Bize bir şans daha verir misiniz?"

Hazır şablonlar (6 adet)

Galeri 6 hazır akış sunar. Şablon seçildiğinde tüm adımlarıyla yeni bir draft otomasyon oluşur. Her e-posta adımı düzenlenebilir bir başlangıç içeriğiyle gelir: [köşeli parantez] içindeki yerler sizin dolduracağınız kısımlardır. Bu adımlar sayfada "Hazır içerik — düzenlenmeli" rozetiyle görünür; içerik düzenlenmeden otomasyon etkinleşmez. Abonelikten çıkma bağlantısı ve künye gönderimde otomatik eklenir.

Gönderim, kredi ve gönderilemeyen e-postalar

Her otomasyon e-postası 1 kredi harcar; kredi yalnızca e-posta gerçekten gönderilince düşer. Gönderim anında şu durumlarda e-posta gönderilmez (kredi düşmez) ve otomasyon sayfasında "gönderilemedi" olarak nedeniyle görünür:

"Bildirim gider" işaretli sorunlarda hesap sahibine ve yöneticilere e-posta ve uygulama içi bildirim gönderilir — aynı otomasyon ve neden için günde en fazla bir kez. Bu bildirim Ayarlar → Bildirimler'de "Otomasyon Uyarısı" ile kapatılabilir. Sorun düzelince otomasyon kendiliğinden göndermeye devam eder; arada gelen aboneler ilgili e-postayı almamış olur.

SenderTR incelemesi

Otomasyonu etkinleştirmenin önündeki tek engel içerik güvenlik denetimiyse, içeriğinizin meşru olduğunu düşünüyorsanız otomasyon sayfasındaki "SenderTR incelemesine gönder" düğmesini kullanabilirsiniz (isteğe bağlı olarak ekibe bir not ekleyin).

• İnceleme sürerken otomasyon pending_review (İncelemede) durumundadır: düzenlenemez, gönderim yapmaz. "İncelemeyi geri çek" ile taslağa döndürebilirsiniz.
• Onaylanırsa başka eksik yoksa otomasyon etkinleşir. Onay, içeriğin o anki haline verilir: konu, içerik ya da gönderici değişirse onay düşer ve yeniden inceleme gerekir.
• Reddedilirse otomasyon önceki durumuna döner; gerekçe otomasyon sayfasında görünür.
• Sonuç her durumda e-posta ve uygulama içi bildirimle iletilir.

Sonuçlar ve istatistikler

Otomasyon e-postaları istatistiklerde işlemsel ve kampanya gönderimlerinden ayrı bir akış olarak gösterilir: Pano ve Raporlar'daki "Otomasyon" şeridi (son 30 gün) ve her otomasyonun kendi sayfası.

• Gönderildi: alıcı sunucusuna gönderilen otomasyon e-postaları.
• Geri döndü: gönderilenlerden kalıcı olarak reddedilenler (bounce).
• Açılma / Tıklama: teslim edilen (gönderildi − geri döndü) e-postalara oranla, ilk açılma ve ilk tıklama. Tıklama açılmayı da gösterir. Apple Mail ön yüklemesi ve güvenlik tarayıcıları sayılmaz.
• Gönderilemedi: yukarıdaki nedenlerle gönderilmeyen e-postalar — kişi ve adım başına bir kez sayılır, sonradan gönderilenler düşülür. Sizin düzeltmeniz gereken nedenler kırmızı gösterilir.
• Otomasyon sayfasında her e-posta adımının altında o adımın kendi sonucu yazar (gönderildi · açılma · tıklama).

Kayıt (enrollment) mantığı

• Çift akış engeli: Kişinin aynı otomasyonda active veya paused bir kaydı varsa tetikleyici tekrar gerçekleşse bile yeniden kaydedilmez.
• Akışı tamamlamış (ya da iptal edilmiş) kişi için tetikleyici yeniden gerçekleşirse akış baştan başlar. Tarih alanı tetikleyicisinde aynı yıl içinde tekrar kayıt yapılmaz.
• Tek bir form gönderimi birden fazla otomasyonu başlatabilir: önce form_submitted, kişi yeniyse ayrıca contact_added.
• Abonelikten çıkan kişinin ticari akıştaki kaydı iptal edilir; sonraki adımlar gönderilmez.

Manuel kayıt (Manuel Kişi Ekle)

Aktif bir otomasyonun sayfasından kişileri tek tek ekleyebilirsiniz. Koşullar: otomasyon active, en az bir adım var, kişi hesabınıza ait ve akışta zaten aktif kaydı yok. Manuel kayıt panel günlük sınırına tabidir.

Durumlar ve silme kuralı

Formlar

Formlar; web sitenize gömebileceğiniz abone kayıt formlarıdır. Ziyaretçiler formu doldurduğunda kişi otomatik oluşturulur, seçtiğiniz listeye eklenir ve (etkinse) onay e-postası süreci başlar — ayrıca ilgili otomasyon tetikleyicileri çalışır.

Form oluşturma

1. Formlar → Yeni Form. Form adı girin (zorunlu).
2. Bağlı listeyi seçin. Form üzerinden kaydolan kişiler bu listeye eklenir. (İsteğe bağlıdır; seçilmezse kişi yine oluşturulur ama listeye bağlanmaz.)
3. Alanları tanımlayın. Her alan için Alan Adı (name), Etiket, Tür ve Zorunlu seçeneklerini belirleyin.
4. Oluşturun. Kaydedince sistem otomatik olarak gömme (embed) kodunu üretir.

Desteklenen alan türleri

Gömme (embed) kodu kullanımı

Form kaydedildiğinde, tanımladığınız alanlardan otomatik bir HTML <form> bloğu üretilir. Bu kod, formu SenderTR'nin gönderim adresine (/f/{form_token} — forma özel, tahmin edilemeyen 40 karakterlik kod) POST eder. Eski sayısal adresli (/f/123) gömme kodları çalışmaya devam eder. Düzenleme ekranında "Embed Kodu" kartından tek tıkla kopyalayıp sitenize yapıştırın.

<form action="https://app.sendertr.com/f/aB3k…(40 karakter)" method="POST" style="max-width:400px;font-family:sans-serif">
  <div style="margin-bottom:12px">
    <label style="display:block;margin-bottom:4px;font-weight:600">E-posta Adresi</label>
    <input type="email" name="email" required ... />
  </div>
  <button type="submit" ...>Kayıt Ol</button>
</form>

Üretilen kod satır içi (inline) stillerle gelir; dış bağımlılık gerektirmez, doğrudan herhangi bir sayfaya yapıştırılabilir. Alan etiketleri ve adları HTML-escape edilerek güvenli biçimde basılır.

Form gönderiminde ne olur?

1. Doğrulama. Form alanları tanımınıza göre sunucuda doğrulanır (zorunlu alanlar, e-posta formatı, telefon uzunluğu, metin uzunluğu). E-posta yoksa istek reddedilir.
2. Kişi oluşturma/güncelleme. E-posta küçük harfe çevrilir; aynı tenant + e-posta için kişi yoksa yeni kayıt açılır (source=form), varsa mevcut kişi kullanılır. Standart alanlar profile, diğerleri custom_fields'a yazılır.
3. Listeye ekleme. Forma bir liste bağlıysa kişi o listeye eklenir (mükerrer eklemez).
4. Çift onay (açıksa). Kişi henüz onaylı değilse önce onay e-postası gönderilir (aşağıya bakın). Onay e-postası 1 kredi harcar.
5. Otomasyon tetikleme. form_submitted, kişi yeni oluşturulduysa ayrıca contact_added tetiklenir. Kişi çift onay bekliyorsa tetikleyiciler onaya ertelenir: hoş geldin e-postası onay bağlantısına tıklanmadan gitmez (bkz. Otomasyonlar → giriş kaynakları).
6. Teşekkür sayfası. Ziyaretçiye başarı sayfası gösterilir.

Double Opt-in (çift onay)

İzinli ve KVKK uyumlu liste oluşturmanın en güvenli yolu çift onaydır. Formdan gelen kişi henüz onaylanmamışsa:

1. Sisteme rastgele güvenli bir onay token'ı üretilir ve kişi opt_in_status = pending olarak işaretlenir.
2. Kişiye "E-posta Adresinizi Onaylayın" konulu bir onay e-postası gönderilir; içinde /confirm/{token} bağlantısı bulunur.
3. Kişi bağlantıya tıkladığında opt_in_status = confirmed olur, token silinir ve onay zamanı (opted_in_at) kaydedilir.
4. Onayla birlikte, form gönderiminde ertelenen otomasyonlar (hoş geldin serisi vb.) başlar. Onay 14 gün içinde verilmezse ertelenen tetikleyiciler düşer.

Onay bekleyen kişiye ticari kampanya ve ticari otomasyon e-postası gönderilmez. Aynı adrese günde en fazla bir onay e-postası gider.

Spam koruması

Halka açık form gönderim ucu, otomatik bot/spam gönderimlerine karşı sınırlandırılmıştır: IP başına dakikada 10, saatte 60 gönderim; ayrıca günde form başına en fazla 500, IP başına en fazla 20 yeni adres (aşılırsa form "günlük yeni kayıt sınırı" yanıtı verir). Plan kişi sınırınız dolduysa form yeni kayıt kabul etmez ("Bu form şu anda yeni kayıt kabul etmiyor"). Pasif bir form ya da askıdaki hesabın formu bulunamadı (404) yanıtı verir. Ayrıca tüm alanlar sunucu tarafında tipine göre doğrulanır ve metin uzunlukları sınırlandırılarak kötüye kullanım önlenir.

Domain & DNS Doğrulama

E-postalarınızı kendi alan adınızdan göndermek ve gelen kutusuna ulaşmak için, gönderen domaininizi ekleyip DKIM ve DMARC DNS kayıtlarını doğrulamanız gerekir. Bu, hem teslim edilebilirlik hem de 6563 sayılı Kanun gereği yasal gönderen kimliği için zorunludur. SPF isteğe bağlıdır: geri dönme adresi (Return-Path) SenderTR alan adında olduğu için alıcılar SPF'i bizim alan adımızda denetler; ana alan adınızdaki SPF kaydı gönderimi etkilemez (bkz. Return-Path ve geri dönmeler).

1. Domain Ekleme

1. Domainler → "Alan adı ekle" düğmesine basın.
2. Alan adınızı girin (ör. sirketiniz.com). Sistem girdiğinizi otomatik temizler: https:// ve www. ön eklerini, sondaki / işaretini ve boşlukları kaldırır, küçük harfe çevirir.
3. Yalnızca ASCII (Türkçe karaktersiz, punycode olmayan) bir alan adı kabul edilir; aynı alan adı hesabınızda bir kez eklenebilir. Ana alan adı başka bir SenderTR hesabında doğrulanmışsa eklenemez/doğrulanamaz. Planınızın alan adı sınırı eklerken uygulanır (Limitler sayfasından ek limit alınabilir).
4. Kaydederken sistem sizin için arka planda 2048-bit RSA DKIM anahtar çifti üretir ve özel anahtarı şifreli olarak saklar. Açık (public) anahtar DNS kaydında kullanılır.
5. DKIM seçici (selector) sabittir: sendertr. Kaydınız her zaman sendertr._domainkey.alanadiniz.com adındadır ve aylık değişmez. Anahtar değişimi gerektiğinde panel yeni bir seçici verir; eski kayıt yayılma tamamlanana kadar silinmez.

Domain eklendiğinde üç kaydın durumu pending (beklemede), sağlık skoru 0 olarak başlar. Detay sayfasında size eklemeniz gereken tam DNS kayıtları gösterilir.

Önerilen yapı: gönderim türüne göre alt alan adı

Alıcı sağlayıcılar (Gmail, Outlook) itibarı gönderen alan adına göre tutar. Kampanyalara gelen şikâyetler ve düşük etkileşim, aynı alan adından giden şifre sıfırlama veya fatura iletilerinizi de etkileyebilir. Bu yüzden şu yapıyı öneririz (zorunlu değildir):

• Ayda 10.000'in altında gönderimde tek alan adı da yeterlidir. Gereğinden fazla alt alan adı açmayın; çok sayıda alt alan adı spam tekniği gibi görünür.
• Alt alan adı, ana alan adınızın yaşını ve DMARC kaydını kullanır; DKIM kaydı alt alan adına özel üretilir.
• Alan adı hakkı: doğrulanmış bir alan adınızın 2 alt alan adı ek alan adı hakkı harcamaz (ör. ornek.com + bulten.ornek.com + bildirim.ornek.com tek hak sayılır).
• Pazarlama kampanyasında ana alan adınızı seçerseniz kampanya formunda bu öneri hatırlatılır; gönderim engellenmez.

2. Eklenecek DNS Kayıtları

Domain detay sayfasında üç adet TXT kaydı gösterilir: DKIM ve DMARC zorunlu, SPF isteğe bağlı. Zorunlu kayıtları alan adınızın DNS yönetim panelinde (Cloudflare, GoDaddy, Natro, İsimtescil, alan adı sağlayıcınız vb.) oluşturmanız gerekir.

SPF — Sender Policy Framework (isteğe bağlı)

SPF, hangi sunucuların sizin adınıza e-posta göndermeye yetkili olduğunu tanımlar ve zarf gönderen (Return-Path) alan adında denetlenir. SenderTR'de Return-Path bounce.sendertr.com alan adında olduğu için ana alan adınızın SPF kaydı gönderimlerinizi etkilemez; panel durumu yalnızca bilgi amaçlı gösterir ve sağlık skoruna katmaz. Kendi posta sisteminizi (Google Workspace, Exchange vb.) de SenderTR üzerinden kullanacaksanız veya tek kayıtta tüm gönderenlerinizi listelemek istiyorsanız aşağıdaki include'u ekleyebilirsiniz.

DKIM — DomainKeys Identified Mail

DKIM, gönderilen her e-postaya dijital imza ekler. Alıcı sunucu, DNS'teki açık anahtarınızla imzayı doğrulayarak e-postanın yolda değiştirilmediğini ve gerçekten sizden geldiğini teyit eder. SenderTR 2048-bit RSA anahtar kullanır.

DMARC — Domain-based Message Authentication

DMARC, SPF ve DKIM başarısız olduğunda alıcı sunucunun ne yapacağını belirler ve size geri bildirim (rapor) gönderilmesini sağlar. Marka korumasının (spoofing/phishing engelleme) temel taşıdır.

Politika (p=) seçenekleri:

3. Doğrulama

1. DNS kayıtlarını sağlayıcınızın panelinde oluşturduktan sonra, SenderTR domain detay sayfasında "DNS Kontrol Et" butonuna basın. Tablodaki her kaydın hem tam adını hem de panelinizin istediği kısa adını (ör. @, _dmarc) tıklayarak kopyalayabilirsiniz.
2. Sistem her kaydı domaininizin otoriter nameserver'ı üzerinden doğrudan sorgular (ISP/sistem cache'ini atlar). Otoriter NS yanıt vermezse genel DNS çözücüsüyle yeniden kontrol eder.
3. SPF, DKIM ve DMARC ayrı ayrı kontrol edilir; her birinin durumu pass veya fail olarak güncellenir. SPF sonucu yalnızca bilgi amaçlıdır; skoru ve gönderim iznini etkilemez.
4. Sağlık skoru yeniden hesaplanır ve son kontrol zamanı (last_checked_at) kaydedilir.
5. Skor 100 olduğunda domain "doğrulanmış" (verified_at) olarak işaretlenir ve kampanya, otomasyon, API ve SMTP gönderimlerinde kullanılabilir hale gelir. Hesabınızın ilk doğrulanan alan adında hoş geldin kredisi tanımlanır.
6. Genç alan adı: 30 günden kısa süre önce kayıt edilmiş bir alan adından günde en fazla 200 işlemsel (API/SMTP) ileti gönderilebilir ve bu alan adından gönderilen her kampanya SenderTR incelemesine alınır. Alan adı 30 günü doldurunca sınır kendiliğinden kalkar.
7. Sürekli denetim: Doğrulanmış alan adlarınız her gün yeniden kontrol edilir. Bir kayıt DNS'ten kaybolursa (sık neden: DNS sağlayıcısını değiştirip kayıtları taşımamak) size e-posta ile bildirilir ve kayıt geri gelene kadar o alan adından gönderim durdurulur — çünkü bu durumda e-postalar alıcılar tarafından reddedilir. Kaydı ekleyip "DNS Kontrol Et"e bastığınızda gönderim hemen yeniden başlar.

Sağlık Skoru (health_score) Nasıl Hesaplanır?

Skor 0–100 arasındadır ve iki zorunlu kaydın toplamından oluşur (30 Eyl 2026'dan itibaren; öncesinde SPF 30 puan taşıyordu):

4. DNS Yayılma Süresi

DNS değişiklikleri anında yayılmaz. Kayıtların tüm dünyaya yayılması birkaç dakikadan birkaç saate (nadiren TTL ayarınıza bağlı olarak 24–48 saat) kadar sürebilir. Doğrulama başarısızsa:

• Bir süre bekleyin (15–30 dakika) ve "DNS Kontrol Et"i tekrar deneyin.
• SenderTR cache kullanmadan otoriter sunucuyu sorguladığı için, sağlayıcınızda kayıt görünür hale geldiği anda doğrulama da başarılı olur.

5. Sık Karşılaşılan Sorunlar

6. Return-Path ve geri dönmeler

Return-Path (zarf gönderen, MAIL FROM), alıcı sunucunun teslim edilemeyen iletiyi geri göndereceği adrestir; görünen From adresinden bağımsızdır ve SPF tam olarak bu adresin alan adında denetlenir. SenderTR her ileti için benzersiz bir Return-Path üretir (VERP):

b+<tür><kayıt-id>.<imza>@bounce.sendertr.com

• Varsayılan alan adı: bounce.sendertr.com. Alıcı sunucunun sonradan ürettiği geri dönme bildirimleri (DSN) buraya gelir; SenderTR bildirimi ayrıştırır, ilgili iletiyi bounced yapar ve kalıcı hatalarda adresi engelleme listesine alır. Böylece geri dönmeler sizin posta kutunuza düşmez ve raporlarınız eksiksiz olur.
• İmza: Adres içindeki imza SenderTR'ye özeldir; sahte veya yanlış yönlendirilmiş bildirimler daha kapıda reddedilir.
• DMARC hizalaması: Return-Path bizim alan adımızda olduğu için SPF hizalanmaz; DMARC, alan adınızla atılan DKIM imzasıyla geçer. Gmail, Yahoo ve Microsoft'un gönderici kuralları için bu yeterlidir (SPF veya DKIM hizalaması). Amazon SES ve Postmark de aynı modeli kullanır.
• Özel Return-Path (isteğe bağlı): Return-Path'in kendi alan adınızda görünmesini ve SPF hizalamasını da istiyorsanız, domain detay sayfasındaki Gelişmiş: Özel Return-Path bölümünden şu CNAME'i ekleyip "Doğrula"ya basın:

  Alan	Değer
  Tip	CNAME
  Host / Ad	bounce.sirketiniz.com (kısa ad: bounce)
  Hedef	bounce.sendertr.com.

  Doğrulanınca zarf gönderen b+…@bounce.sirketiniz.com olur; bildirimler CNAME üzerinden yine SenderTR'ye ulaşır. DMARC kaydınızda aspf=s (katı SPF hizalaması) varsa panel bu seçeneği öne çıkararak önerir. Hedef birebir bounce.sendertr.com olmalıdır; Cloudflare'da proxy kapalı tutulmalıdır.
• Kayıt bozulursa: Günlük denetim CNAME'i de kontrol eder. Çözülmüyorsa özel Return-Path devre dışı kalır, gönderim durmaz, varsayılan alan adıyla sürer ve size kısa bir e-posta gider. Kayıt geri gelince kendiliğinden yeniden etkinleşir.

Özel takip alan adı

Açılma pikseli ve tıklama yönlendirmeleri varsayılan olarak t.sendertr.com üzerinden gider. Alan adı sayfasından kendi alt alan adınızı tanımlarsınız (ör. link.markaniz.com): DNS'inize link.markaniz.com CNAME t.sendertr.com ekleyin, "Kaydet ve doğrula" deyin. CNAME doğrulanınca SenderTR takip sunucusunda sertifikayı 1–2 dakikada kurar ve o alan adının yeni iletilerindeki bağlantılar https://link.markaniz.com/… olur. Eski iletilerdeki bağlantılar çalışmaya devam eder; abonelikten çıkma bağlantıları u.sendertr.com'da kalır (RFC 8058 tek tık çıkış için sabit alan adı). Kaldırırsanız bağlantılar yeniden t.sendertr.com üzerinden gider.

Alan adı sağlığı sayfası

Her alan adının sayfasında dört alt puan görürsünüz: Kimlik doğrulama (DKIM + DMARC), İtibar (son 30 gün geri dönme ve şikâyet), Liste kalitesi (gönderim öncesi ret payı) ve Gönderim kalitesi (ertelenme). 30 günde 50'den az ileti varsa oran puanları "—" kalır. Aynı sayfada son 7/30 gün teslim tablosu, alıcı sağlayıcıya göre (Gmail, Microsoft, Yahoo, Yandex) teslim kırılımı ve derecelendirmesi, DMARC yol haritası (p=none → quarantine → reject önerisi, rapor hizalama oranıyla) ve yapılacaklar listesi vardır. Yalnız bu alan adından çıkan iletiler sayılır.

Hizalanmayan ileti oranı 7 günde %5'i geçen alan adı sahibine haftada bir uyarı e-postası gider: SenderTR'den çıkan iletiler DKIM ile hizalıdır, bu iletiler büyük olasılıkla alan adınız adına gönderim yapan başka bir servis ya da sahte gönderimdir.

Deliverability — Gelen Kutusuna Ulaşmak

Teslim edilebilirlik (deliverability), e-postalarınızın spam klasörüne değil gelen kutusuna ulaşma yeteneğidir. SenderTR'nin temel odağı budur. Teslimat; kimlik doğrulama, gönderici itibarı, liste kalitesi ve içerik kalitesinin bir bileşkesidir.

IP Warmup (IP Isınması)

Yeni bir gönderim IP'si itibar geçmişine sahip değildir. Sağlayıcılar (Gmail, Outlook) yeni IP'lerden gelen yüksek hacimli gönderime şüpheyle yaklaşır. Bu yüzden SenderTR'nin yeni gönderim sunucularında hacim yaklaşık 30 gün boyunca kademeli olarak artırılır — buna "ısınma" denir. Bu süreç SenderTR tarafından yönetilir; sizin hesabınızda bir ayar gerektirmez.

Tipik plan: Gün 1'de 50 e-posta/gün ile başlanır ve limit gün gün artar; 30. güne gelindiğinde sunucu stable aşamasına geçer ve limit 50.000/gün olur. Bir gün ancak önceki gün sağlıklı (bounce < %5, şikayet < %0,3) ve limitin en az yarısı kullanılmışsa ilerler; hacim yetersizse en fazla 3 gün aynı günde beklenir, sağlık eşiği aşılırsa gün sabit tutulur. SenderTR'nin yük dengeleyicisi warmup-aware'dir: günlük limitini doldurmuş sunucuları otomatik dışlar ve stable > warming > paused önceliğiyle sunucu seçer. Bu süreç platform tarafından otomatik yönetilir — tenant olarak ekstra bir işlem yapmanıza gerek yoktur.

Kara liste izleme

SenderTR'nin tüm gönderim IP'leri 12 büyük DNS kara listesinde (DNSBL) 30 dakikada bir kontrol edilir; itibar sinyalleri ayrıca 15 dakikada bir değerlendirilir. Listelerin ağırlığı farklıdır: Spamhaus, Barracuda, SpamCop, Invaluement, CBL ve Mailspike teslimatı etkiler ve IP'yi havuzdan çıkarır; gürültülü listeler (UCEPROTECT, SORBS vb.) tek başına IP düşürmez, yalnız kaydedilir. Alıcı sağlayıcının bloğu (ör. Microsoft 5.7.1) nedeniyle havuzdan çıkarılan IP, 12 saat boyunca yeni blok sinyali gelmezse otomatik geri alınır. Trafik bu sürede sağlıklı sunuculara yönlendirilir. Bu izleme SenderTR ekibi tarafından yürütülür; sizin bir işlem yapmanız gerekmez. Sizin itibarınızı belirleyen asıl etkenler aşağıdaki eşikler ve liste kalitenizdir.

Gönderim Kalitesi Eşikleri

Eşikler sektör standardına (büyük e-posta sağlayıcılarının toplu gönderici kuralları ve yaygın ESP uygulamaları) göre belirlenmiştir. Bounce oranına yalnız alıcı tarafındaki kalıcı geri dönüşler (adres yok, alan adı yok) sayılır; "posta kutusu dolu", geçici hatalar ve alıcı sunucunun engellemesi bounce oranına sayılmaz.

İşlemsel gönderim (API ve SMTP)

Her gönderim kimliği (SMTP kullanıcısı / API anahtarı) için son 24 saat değerlendirilir:

Değerlendirme için son 24 saatte en az 20 ileti gerekir; bounce uyarısı ve askısı için ayrıca en az 10 kalıcı bounce olmalıdır.

Hesap (son 30 gün)

Son 30 günde en az 1.000 ileti denemesi olan bir hesapta kalıcı bounce oranı %5'e veya şikâyet oranı %0,3'e ulaşırsa yeni kampanyalar otomatik onay yerine SenderTR incelemesine alınır. Bunun dışında incelemeye düşüren durumlar: hiç kampanyası tamamlanmamış hesabın 5.000+ alıcılı ilk kampanyası, geçmişteki en büyük kampanyanın 10 katı ve en az 20.000 alıcılı ani hacim artışı, son 14 günde otomatik izlemede kilitlenen kampanya, 30 günden genç gönderim alan adı ve içerik güvenlik puanı. Hesap askısı otomatik verilmez; yalnız SenderTR incelemesiyle verilir.

Kampanya Anlık İzleme (Devre Kesici)

Hesap düzeyindeki eşiklerden bağımsız olarak, gönderimdeki her kampanya gönderim sürerken anlık izlenir. Eşik aşılırsa kampanya otomatik olarak paused durumuna alınır; böylece kötü bir liste tüm hesabın ve gönderim IP'lerinin itibarını bozmadan durdurulur.

Duraklatılan kampanyanın ayarlarına pause_reason = auto_monitor ve gerekçe (pause_detail: hangi eşik, kaç deneme) yazılır; gerekçe kampanya sayfasındaki duraklama bandında görünür ve hesap sahibine bildirim gider. Listeyi temizledikten (doğrulama, suppression) sonra kampanyayı panelden sürdürebilirsiniz. Bir kampanya ikinci kez otomatik duraklarsa panelden sürdürülemez; destek ekibimiz (destek@sendertr.com) inceledikten sonra devam eder.

Gelen Kutusu Yerleşim Tahmini (Inbox Placement)

Kampanya göndermeden önce, SenderTR gelen kutusuna ulaşma olasılığınızı 0–100 arası bir skorla tahmin eder. Beş kontrol değerlendirilir:

Sonuç, başlıca sağlayıcılar için tahmin üretir:

Teslimatı Artırmak İçin İpuçları

Gönderim Altyapısı

İşlemsel ve kampanya trafiği SenderTR'de yalnız kuyrukta değil, sunucu ve IP düzeyinde ayrıdır. Bu bölüm iletinizin hangi yoldan çıktığını, önceliğin ve ömrün nasıl çalıştığını ve ne zaman hangi havuza düştüğünüzü anlatır.

İki akış, ayrı havuzlar

Bir akışta gönderilebilir sunucu kalmazsa (hepsi bakımda, sağlıksız ya da günlük sınırda) ileti diğer akışın IP'lerine düşmez; ömrü içinde kuyrukta bekler ve operasyon ekibine kritik uyarı gider. Yani bir kampanya kaynaklı itibar sorunu şifre sıfırlama e-postanızı hiçbir koşulda etkilemez.

Hangi havuza düşersiniz?

• Yeni hesap (30 günden genç ya da 1.000'den az teslim) işlemselde tx-new, kampanyada mkt-warmup havuzundan gönderir. Hesap olgunlaşınca kendiliğinden paylaşımlı havuza geçer.
• Güvenilir hesap (son 90 günde 3 sorunsuz kampanya ya da yönetici onayı) tx-shared ve mkt-good.
• SMTP relay üzerinden toplu gönderim: aynı içerik bir saat içinde 200'den çok farklı alıcıya gider ve iletide List-Unsubscribe başlığı yoksa hesap tx-new havuzuna alınır ve size bildirilir. Bülten ve kampanya için panelin Kampanya özelliğini kullanın; SMTP ve API işlemsel iletiler içindir.
• Dedike IP: size ayrılmış IP'si olan hesap yalnız o IP'den gönderir; IP'nin günlük kapasitesi dolduysa paylaşımlı havuza düşmez, ileti kapasite açılınca gider. İşlemsel ve kampanya için ayrı IP ayrılır (akışlar aynı IP'yi paylaşmaz). Ayrıntı: Dedike IP'ler.

Dedike IP'ler

Ayarlar → Dedike IP'ler. Her hesap talep edebilir; günde 1.000+ düzenli ileti anlamlıdır, daha düşük hacimde paylaşımlı havuz daha iyi sonuç verir. Talep bir destek talebi olarak açılır; ekibimiz IP'yi 1 iş günü içinde atar.

Ücret: IP başına aylık 15.000 kredi (yaklaşık 1.490 TL + KDV karşılığı), kredi bakiyenizden 30 günde bir düşer; kurulum, PTR ve ısınma ücretsizdir. Bakiye yetmezse e-posta ile uyarılırsınız; 7 gün içinde yükleme yapılmazsa IP serbest bırakılır ve gönderimleriniz paylaşımlı havuza döner. Isınma 3–4 hafta sürdüğü için kısa süreli kullanım için uygun değildir.

• Kurulum: IP, SenderTR'nin gönderim sunucularından birine eklenir; PTR kaydı ve HELO adı tanımlanır (isterseniz mail.markaniz.com gibi kendi adınız), SPF kaydımıza dahil edilir. Alan adınızın DKIM/DMARC ayarları değişmez.
• Isınma: yeni IP gün 1'de 50 iletiyle başlar ve ısınma planına göre büyür; limitin üstündeki iletiler bekler, paylaşımlı havuza düşmez. Isınma günü ve günlük limit panelde görünür.
• İzleme: IP'nin sağlığı (SMTP erişimi, geri dönme/erteleme oranı) ve kara liste durumu (Spamhaus, Barracuda vb.) sürekli izlenir; listelenme durumunda çıkış sürecini ekibimiz yürütür ve panelde görürsünüz.
• Bırakma: IP'yi bıraktığınızda hesabınız paylaşımlı havuza döner; IP 7 gün karantinada bekler, başka bir hesaba ancak sıfırdan ısınarak verilir.

Plan özellikleri

Limitler sayfasında hesabınızın özellikleri listelenir. Paketler arasında özellik farkı yoktur; büyük paket yalnızca limitleri büyütür. Aşağıdaki özellikler her hesapta açıktır:

Öncelik ve ömür (işlemsel)

API'de priority: "critical" ile gönderilen ileti ayrı bir kuyruktan, normal işlemsel iletilerden önce işlenir; OTP, giriş kodu ve şifre sıfırlama için düşünülmüştür. Critical izni gönderim hesabı bazında verilir (ücretli planlarda açık) ve günlük limitin en çok %30'u critical olabilir; aşan istekler normal olarak kabul edilir. Her iletinin bir ömrü vardır (expires_in): critical 15 dakika, normal 24 saat. Ömrü içinde gönderilemeyen ileti expired olur, kredisi düşmez ve expired webhook'u ile bildirilir. SMTP relay iletileri her zaman normal önceliklidir.

Kampanyada sıra ve adalet

Kampanya işleri kuyruğa bir anda basılmaz: her kampanya için kuyrukta en çok 500 iş bekler, eksilen her dakika tamamlanır. Böylece bir hesabın 1 milyonluk kampanyası başka bir hesabın 200 kişilik kampanyasını ya da hoş geldin otomasyonunu arkada bekletmez. Otomasyon e-postaları kampanyalardan önce işlenen ayrı bir kuyruktadır.

Acil durdurma

Operasyon ekibi gerektiğinde tüm gönderimi tek anahtarla durdurabilir; bu sürede iletiler kuyrukta bekler, ömrü dolanlar expired olur. Durum sayfasında (sendertr.com/status) tüm gönderim sunucularının anlık durumu görünür.

Gönderen İtibarı

SenderTR her hesap için günlük bir gönderen puanı (0–100) hesaplar. Puan hangi havuzdan gönderdiğinizi, kademeli başlangıç uygulanıp uygulanmadığını ve otomatik onayı etkiler. Hesap sahibi puanı ve bileşenlerini panelde görür (yönetici gözlem dönemi sonrasında müşteri ekranına açılır).

Bileşenler

30 günde 50'den az gönderimi olan hesapta oran bileşenleri "veri yok" sayılır ve nötr puan alır; yeni hesap bu yüzden ne cezalandırılır ne de ödüllendirilir.

Kademeler

Puan her gece 01:30'da yenilenir. Kademe değişikliği aynı gün havuz seçimine yansır; hesap 30 günden gençken kademe puandan değil "yeni hesap" kuralından gelir.

Kayıt riski ve anomali

• Kayıt anı: kayıt IP'sinin kara listede olması, aynı IP'den kısa sürede birden çok kayıt, şüpheli hesap adı ve riskli alan adı uzantısı puanlanır. Yüksek risk hesabı kapatmaz; hesap yeni/riskli havuzlardan başlar ve ekibimiz inceler.
• Hacim sıçraması: bir SMTP/API hesabı bir saatte 200'den çok ileti gönderir ve bu, son 7 günün saatlik ortalamasının 10 katıysa hesap sahibine ve ekibimize uyarı gider. Gönderim durdurulmaz; anahtar sızmış olabilir diye anahtarı yenilemeniz önerilir.
• Yeni kaynak adresi: hesap daha önce görülmemiş bir IP'den gönderim yaptığında bilgi e-postası gönderilir (yeni sunucuya taşındıysanız yok sayın).
• Sağlayıcı yavaşlatması: Gmail, Microsoft, Yahoo ve Yandex için gönderici başına ayrı bağlantı ve hız sınırı uygulanır; bir sağlayıcı bir IP'yi geçici olarak yavaşlattığında (4.7.x) sistem bunu 10 dakika içinde fark eder ve o IP'de hacmi artırmaz.

Raporlar & Analitik

Gönderim performansınızı kampanya, link, cihaz, coğrafi konum ve zaman bazında detaylı izleyin. Tüm metrikler tek bir merkezi tanımdan gelir; pano, raporlar ve yönetici ekranları her zaman aynı sayıyı gösterir.

Metrik Tanımları (Tüm Raporlarda Ortak)

Gönderimleriniz üç ayrı akışta raporlanır ve hiçbir ekranda birbirine karıştırılmaz: İşlemsel (API ve SMTP ile giden bildirimler), Kampanya (pazarlama gönderimleri) ve Otomasyon. Her akışın eşikleri ayrıdır (bkz. Deliverability); birleşik bir oran, yüksek işlemsel hacmin içinde sorunlu bir kampanyayı gizleyebileceği için gösterilmez. Tüm ekranlar aynı tanımları kullanır:

Otomasyon akışında ayrı teslim bildirimi olmadığından açılma ve tıklama oranlarının paydası "gönderilen − geri dönen"dir (bkz. Otomasyon sonuçları). 20'den az gönderimde oranlar renklendirilmez.

1. Kampanya Raporu

Raporlar → Kampanyalar. Tamamlanmış ve gönderilmekte olan kampanyaların özet tablosu: kampanya başına gönderilen, açılma %, tıklama %, bounce %, şikayet % ve tarih. Üstte tüm kampanyaların ortalamaları (özet) gösterilir. CSV olarak dışa aktarılabilir.

Kampanya Detay Raporu

Tek bir kampanyaya tıklayınca açılan derin analiz. İçeriği:

• Dönüşüm hunisi (funnel): Gönderilen → Teslim → Açıldı → Tıklandı → Bounce → Şikayet → Abonelik iptali (sayılar ve oranlar).
• Saatlik açılma grafiği: Günün 0–23 saatlerine göre açılma dağılımı.
• Günlük açılma trendi: Son 14 günün açılma eğrisi.
• Cihaz dağılımı: Masaüstü / mobil / tablet.
• E-posta istemcisi: Gmail, Outlook, Apple Mail vb. (ilk 10).
• Ülke dağılımı: Açılma + tıklamaların ülke koduna göre dağılımı (ilk 15).
• En çok tıklanan linkler: Link bazlı toplam/benzersiz tıklama ve yüzde (ilk 10).
• Açılma ve tıklama detayları: Adres, IP, ülke, şehir, cihaz, istemci, zaman (ilk 100).
• Durum dağılımı & SMTP özeti: 250/221 başarı, fail, DSN (delivered/bounced/deferred) sayıları ve örnek mesaj logları.
• Gelir: e-ticaret entegrasyonu varsa kampanyaya bağlanan siparişler, ortalama sipariş tutarı, alıcı başına gelir ve dönüşüm oranı (son tıklama/açılma ilişkilendirmesi).
• Makine açılmaları: Apple Mail ön yüklemesi ve güvenlik tarayıcısı açılmaları ayrı gösterilir; açılma oranına katılmaz.
• Abonelikten çıkma nedenleri: çıkan kişilerin belirttiği nedenler.

2. Link Tıklama Raporu (Heatmap)

Raporlar → Tıklamalar ve kampanya bazında Click Heatmap. Hangi linkin kaç kez tıklandığı, kaç benzersiz kişi tıkladığı ve toplam içindeki yüzdesi (CTR). En çok tıklanan linkler sıralanır — içeriğinizin hangi bölümünün ilgi çektiğini görürsünüz.

3. Cihaz & E-posta İstemcisi Raporu

Raporlar → Cihazlar. Tıklama verilerinden (User-Agent ayrıştırılarak; açılmalar bu rapora katılmaz):

• Cihaz tipi dağılımı: Masaüstü, mobil, tablet (pasta/çubuk grafik).
• E-posta istemcisi dağılımı: En çok kullanılan 15 istemci (Gmail, Apple Mail, Outlook vb.).

Bu, içeriğinizi hangi cihaz/istemci için optimize etmeniz gerektiğini gösterir (ör. çoğunluk mobilse mobil uyumlu tasarım önceliklidir).

4. Coğrafi Rapor

Raporlar → Coğrafi. Tıklamaların GeoIP (yerel MaxMind GeoLite2 veritabanı, KVKK uyumlu) ile çözümlenmiş ülke ve şehir dağılımı. Ülke bazında toplam ve benzersiz kişi sayısı, şehir bazında ilk 20 — harita ve tablo olarak.

5. Zaman Analizi (Saatlik / Günlük)

Raporlar → Zaman Analizi. Açılmaların günün saatlerine (0–23) ve haftanın günlerine (Pzt–Paz) göre dağılımı. Bu, kampanyalarınızı en yüksek etkileşim aldığı zaman diliminde göndermenize yardımcı olur.

6. Teslimat (Deliverability) Raporu

Raporlar → Deliverability. Hesap geneli teslimat sağlığı:

• İşlemsel ve kampanya akışları için ayrı ayrı teslim, bounce ve şikâyet oranları (her akış kendi eşiğiyle renklenir).
• Sağlayıcı bazında (Gmail, Outlook, Yahoo…) dağılım; 7/30/90/180 gün seçilebilir, akış seçilebilir.
• Domain bazında DKIM/DMARC/SPF doğrulama durumu ve akış başına gönderim/bounce.
• PDF olarak dışa aktarılabilir.

Şikayet Raporu

Son 30 günün günlük şikayet sayısı ve oranı (şikâyet / teslim, binde hassasiyetle; işlemsel ya da kampanya akışı seçilir) ve son tamamlanan/gönderilen 20 kampanyanın şikâyet durumu. Şikayet oranınızı %0,3 kritik eşiğinin altında tutmanız için izleme aracıdır.

DMARC Aggregate Raporu

Alıcı sağlayıcılardan gelen DMARC (RUA) raporlarının özeti (son 30 gün):

• SPF / DKIM geçme oranları ve hizalama (alignment) oranı (en az biri pass).
• Disposition dağılımı: none / quarantine / reject.
• Hizalanmayan kaynak IP'ler: Potansiyel spoofing/phishing tespiti için, sizin adınıza yetkisiz gönderim yapan en yüksek hacimli IP'ler listelenir.

Krediler & Faturalandırma

SenderTR kullandıkça-öde modeliyle çalışır: gönderime kabul edilen her ileti 1 kredi düşer; her kredi paketi kendi alım tarihinden itibaren 12 ay geçerlidir; yeni paket eski paketin süresini uzatmaz, gönderimler önce süresi en yakın paketten düşer (aylık abonelik zorunluluğu yoktur). Hoş geldin kredisi 90 gün geçerlidir; süre dolmadan 30 ve 7 gün önce e-postayla hatırlatılır. Alıcı sunucu tarafından reddedilen veya geri dönen (bounce) iletiler için kredi iadesi yapılmaz — listenizi temiz tutmak doğrudan tasarruftur. E-posta adresinizi doğruladığınızda hesabınıza 1.000 kredi hediye yüklenir.

Kredi Nedir?

Bakiye & Kullanım Görüntüleme

Krediler sayfasında:

• Güncel bakiye ve toplam satın alınan kredi.
• İşlem geçmişi: Satın alma, kullanım (charge/debit), iade (refund), transactional/doğrulama kullanımı.
• Kampanya bazında kullanım: En çok kredi harcayan ilk 10 kampanya.
• Aylık trend: Son 6 ayın kredi kullanımı.
• Bu ay kullanılan ve kullanım türü dağılımı (kampanya / transactional / doğrulama).
• Günlük gönderim trendi (son 30 gün).
• Günlük ortalama kullanım ve buna dayalı kalan gün tahmini (bakiye / günlük ortalama).

Paket Satın Alma (PayTR)

Krediler PayTR altyapısıyla güvenli (3D Secure / iframe) şekilde alınır. Adımlar:

1. Krediler → "Kredi Satın Al". Aktif paketler listelenir (kredi miktarı, bonus kredi, KDV'li/KDV'siz fiyat, 1.000 e-posta başına birim fiyat).
2. Bir paket seçip "Satın Al"e basın. (Aynı paket için son 20 dakikada bekleyen bir isteğiniz varsa o yeniden kullanılır.)
3. PayTR ödeme ekranına yönlendirilirsiniz. Kart bilgilerinizi doğrudan PayTR'ye girersiniz — SenderTR kart verisi saklamaz.
4. Ödeme tamamlanınca PayTR sunucudan-sunucuya (callback) bildirim gönderir. İmza (HMAC-SHA256) ve tutar doğrulandıktan sonra krediler hesabınıza yüklenir.
5. Başarı sayfasına dönersiniz. Callback birkaç saniye gecikirse "kredileriniz kısa süre içinde yüklenecek" mesajı görünür ve kısa süre sonra bakiye güncellenir.

Kredi Paketleri

Fiyatlara KDV dahil değildir; ödeme sırasında %20 KDV eklenir. Güncel katalog her zaman fiyatlandırma sayfasında ve panelde Krediler → "Kredi Satın Al" ekranında gösterilir. Büyük paket aldığınızda planınız ve tüm limitleriniz kendiliğinden yükselir (10.000+ kredi: Başlangıç, 50.000+: Profesyonel, 250.000+: İşletme).

Limitler ve Ek Limitler

Panelde Limitler sayfası her limitin ne kadarını kullandığınızı ve ne kadarının kaldığını gösterir: kişi sayısı, gönderim alan adı, ekip üyesi, günlük ve aylık işlemsel gönderim, SMTP kullanıcısı. %80'i geçen limit sarı, dolan limit kırmızı görünür.

Planınızın limiti yetmezse Artır düğmesiyle kredinizden ek limit alabilirsiniz. Ekler 30 gün geçerlidir ve süresi dolunca bakiyenizden otomatik yenilenir; yenilemeyi istediğiniz zaman kapatabilirsiniz. Bakiyeniz yenilemeye yetmeyecekse 3 gün önceden e-postayla uyarılırsınız. Ek sona erdiğinde hiçbir veriniz silinmez; yalnızca o kaynağa yeni ekleme yapamazsınız. Ek ücretleri iade edilmez. Planınızın içerdiğinden fazla SMTP kullanıcısı için her ay krediden ücret alınır (Limitler sayfasında gösterilir).

Kota Uyarıları (%80 / %95 / %100)

Kredilerinizin bitmesiyle gönderimlerinizin aniden durmasını önlemek için, kullanım belirli eşiklere ulaştığında otomatik uyarı alırsınız. Uyarılar hem e-posta hem uygulama içi bildirim hem de dashboard banner'ı olarak Owner ve Admin'lere gönderilir.

İade Politikası

Kredi iadesi şu durumlarda gerçekleşir:

• Paket iadesi: Satın aldığınız paket, ödemeden itibaren 14 gün içinde ve hiç kullanılmamışsa (bakiyeniz paketin kredisi + bonusu kadar ya da üzerindeyse) destek üzerinden iade edilir. Kısmi paket iadesi yapılmaz.
• PayTR chargeback / iptal: Ödenmiş bir sipariş için PayTR iptal sinyali gönderirse, ilgili kredi otomatik geri alınır ve sipariş refunded işaretlenir.

Ekip & Roller

Hesabınıza ekip üyeleri davet ederek farklı yetki seviyeleriyle birlikte çalışın. Davetler e-posta ile gönderilir ve 7 gün geçerlidir. Davet, iptal ve üye çıkarma işlemlerini yalnızca Owner ve Admin yapabilir; hesap başına günde en fazla 20 davet gönderilebilir. Ekip üyesi sayısı planınıza göre sınırlıdır (Ücretsiz: 2, bekleyen davetler dahil); daha fazlası için panelde Limitler sayfasından ek alabilirsiniz.

Üye Davet Akışı

1. Ayarlar → Ekip sayfasını açın. Mevcut üyeler ve bekleyen davetler listelenir.
2. "Üye Davet Et": davet edilecek kişinin e-posta adresini girin ve bir rol seçin (Admin, Marketer, Uploader, Viewer).
3. Sistem benzersiz bir davet token'ı (64 karakter) üretir ve 7 gün geçerli bir davet bağlantısı oluşturur.
4. Davet edilen kişiye otomatik bir davet e-postası gider. (E-posta gönderilemezse davet bağlantısı ekranda gösterilir; manuel paylaşabilirsiniz.)
5. Kişi bağlantıya tıklar → davet kabul ekranı açılır. Yeni kullanıcıysa ad ve şifre belirleyerek hesap oluşturur ve otomatik giriş yapar; ekibinize katılır.

Davet Yönetimi

• Davet iptali: Bekleyen bir daveti istediğiniz an iptal edebilirsiniz.
• Üye kaldırma: Bir üyeyi ekipten çıkarabilirsiniz. Owner kaldırılamaz (hesap sahibi korunur); bir Admin'i yalnızca Owner çıkarabilir.
• Son giriş: Her üyenin son giriş zamanı listede gösterilir.

Roller ve Yetkiler

SenderTR'de 5 tenant rolü vardır. Her rolün yetki kapsamı:

Webhook'lar (Panel Üzerinden)

Webhook, e-posta olaylarınızı (teslim, bounce, açılma vb.) kendi sisteminize anlık iletmenin yoludur. Bir olay gerçekleştiğinde SenderTR, belirttiğiniz URL'ye imzalı bir HTTP POST isteği gönderir — böylece CRM, ERP veya kendi uygulamanız gerçek zamanlı güncellenir.

Webhook Ekleme

1. Ayarlar → Webhook'lar → "Yeni Webhook".
2. Webhook URL'ini girin (geçerli bir https:// adresi, max 500 karakter). Bildirimler buraya POST edilir.
3. Dinlemek istediğiniz olayları seçin (en az bir tane zorunlu).
4. Kaydedin. Sistem size tek seferlik bir secret gösterir — bunu güvenli bir yere kaydedin (aşağıya bakın).
5. İsterseniz "Test" butonu ile endpoint'inize örnek bir bildirim göndererek entegrasyonu doğrulayın.

Olay (Event) Türleri

İstek Formatı

Her webhook isteği JSON gövde ile gelir ve aşağıdaki başlıkları taşır:

Örnek gövde:

{
  "event": "clicked",
  "id": "evt_01K6PZ3Q9E8W2V7XJ4N0B5C8RD",
  "timestamp": "2026-06-01T17:30:00+03:00",
  "data": {
    "email": "musteri@example.com",
    "campaign_id": 123,
    "url": "https://sirketiniz.com/kampanya"
  }
}

İmza Doğrulama (HMAC-SHA256)

İsteğin gerçekten SenderTR'den geldiğini, değiştirilmediğini ve yeniden oynatılmadığını doğrulamak için X-SenderTR-Signature başlığını kullanın. Başlık t=<unix zaman>,v1=<imza> biçimindedir; imza, t değeri + nokta + ham gövde dizisinin secret'ınızla HMAC-SHA256'sıdır. t şu andan 5 dakikadan eskiyse isteği reddedin. Eski X-Webhook-Signature (yalnız gövdenin imzası) geçiş dönemi boyunca gönderilmeye devam eder; mevcut entegrasyonlar çalışmaya devam eder.

# PHP — zaman damgalı imza (önerilen)
$payload = file_get_contents('php://input');
[$t, $v1] = array_map(fn ($p) => explode('=', $p, 2)[1], explode(',', $_SERVER['HTTP_X_SENDERTR_SIGNATURE']));
$expected = hash_hmac('sha256', $t.'.'.$payload, $secret);

if (abs(time() - (int) $t) > 300 || !hash_equals($expected, $v1)) {
    http_response_code(401); exit('Geçersiz imza');
}

Eski biçim (yalnız gövde):

# PHP örneği
$payload   = file_get_contents('php://input');
$signature = hash_hmac('sha256', $payload, $secret);

if (hash_equals($signature, $_SERVER['HTTP_X_WEBHOOK_SIGNATURE'])) {
    // Geçerli istek — işle
} else {
    http_response_code(401); // Sahte / değiştirilmiş istek
}

# Node.js örneği
const crypto = require('crypto');
const signature = crypto
  .createHmac('sha256', secret)
  .update(rawBody)
  .digest('hex');

if (signature === req.headers['x-webhook-signature']) {
  // Geçerli
}

Secret Yönetimi

• Secret Yenile: Secret'ı kaybettiyseniz veya sızdığından şüpheleniyorsanız "Secret Yenile" ile yeni bir tane üretin. Eski secret anında geçersiz olur — entegrasyonunuzu güncellemeyi unutmayın.

Yeniden Deneme (Retry) ve Otomatik Devre Dışı Bırakma

Endpoint'iniz geçici olarak ulaşılamaz olursa SenderTR teslimatı yeniden dener:

Ölü mektuplar ve yeniden gönderme

Tüm denemeleri tükenen ya da kalıcı hata alan teslimler ölü mektup olarak saklanır (7 gün). Panelde webhook kartında son 7 günün başarı oranı (teslim / toplam) ve ölü mektup listesi görünür; her birini ya da tümünü Yeniden gönder ile tekrar kuyruğa alabilirsiniz. Yeniden gönderimde aynı olay kimliği (X-Event-Id, gövdedeki id) ve aynı gövde kullanılır; sunucunuz bu kimlikle tekilleştirme yapmalıdır. Pasife düşmüş webhook yeniden gönderimle birlikte yeniden etkinleştirilir.

Ayarlar

Hesabınızı dört kategoride yönetin: Hesap & Şirket, Entegrasyon & API, Güvenlik ve E-posta & Teslimat. Bu bölüm şirket bilgileri (yasal footer), API anahtarları ve güvenlik ayarlarını kapsar.

Şirket Bilgileri (Yasal Footer)

Ayarlar → Şirket Bilgileri. 6563 sayılı Kanun gereği her kampanyaya otomatik eklenen yasal footer için gereken bilgiler buradan girilir. Şirket tipinize göre footer içeriği değişir:

Girilebilen alanlar:

API Anahtarı Oluşturma

Ayarlar → API Anahtarları. REST API ve entegrasyonlar için anahtar üretin.

1. Anahtara açıklayıcı bir ad verin (ör. "Üretim sunucusu", "CRM entegrasyonu").
2. Yetkileri seçin. Varsayılan: gönderim ve doğrulama. Kişi, liste, segment ve kampanya API'leri için ilgili okuma/yazma yetkisini işaretleyin; anahtara yalnızca ihtiyaç duyduğu yetkileri verin. Yetkiler ve IP listesi sonradan değiştirilemez — gerekirse yeni anahtar oluşturup eskisini silin. Anahtarın gönderebileceği alan adları ise sonradan düzenlenebilir.
3. İsteğe bağlı olarak izinli IP listesi (allowed IPs) girin — her satıra bir IPv4/IPv6 adresi ya da CIDR bloğu (ör. 203.0.113.0/24). Belirtilirse anahtar yalnızca bu adreslerden çalışır (ek güvenlik).
4. İsteğe bağlı son kullanma seçin (30/90/180 gün, 1 yıl). Süresi dolan anahtar 401 expired_api_key döner.
5. Oluşturun. Anahtar str_ ön ekiyle üretilir (ör. str_xxxxxxxx...).

Listede her anahtar için: ad, ön ek, oluşturma tarihi, son kullanım zamanı, geçerlilik (son kullanma; 14 gün kala uyarı) ve izinli IP sayısı gösterilir. Bir anahtarı istediğiniz an silebilirsiniz (anında devre dışı kalır) ya da Döndür ile aynı ayarlarla yeni gizli değer alırsınız; eski değer 24 saat daha çalışır, bu sürede entegrasyonunuzu güncellersiniz. Hesabınızın API istekleri Ayarlar → API Günlüğü sayfasında izlenir.

Yetki Kapsamları (Scope)

API anahtarları belirli yetkilerle sınırlanabilir: send, verify, contacts:read, contacts:write, lists:read, lists:write, segments:read, campaigns:read, campaigns:write, webhooks (webhook aboneliklerini API ile yönetme; Zapier/Make/n8n tetikleyicileri), templates (işlemsel şablon API'si). Yetki dışı bir istek 403 insufficient_scope döner. Rate limit (hesap başına): transactional API 300/dk, genel API 60/dk.

Güvenlik

• Şifre değiştirme: Hesap Bilgilerim sayfasından mevcut şifrenizi doğrulayarak yeni şifre belirleyin: en az 10 karakter, büyük ve küçük harf, rakam ve sembol içermeli.
• İki adımlı doğrulama (2FA): Ayarlar → Güvenlik'ten bir doğrulayıcı uygulamayla (Google Authenticator, Authy vb.) QR kodunu okutarak açın. Size 8 adet kurtarma kodu verilir; yeni kurtarma kodu üretmek için şifreniz istenir. Telefonunuzu kaybederseniz kurtarma koduyla giriş yapabilirsiniz.
• Giriş geçmişi (Login History): Son 50 girişiniz — IP adresi, kaynak port, tarayıcı (User-Agent) ve zaman bilgisiyle. Başarılı, başarısız ve kayıt (register) girişleri 5651 sayılı Kanun uyumu için 24 ay saklanır. Tanımadığınız bir giriş görürseniz hemen şifrenizi değiştirin.
• Tema: Açık / koyu (light/dark) tema tercihi.

Entegrasyon & Diğer

Bildirim Tercihleri

Ayarlar → Bildirimler. Hangi olaylarda e-posta/uygulama içi bildirim alacağınızı seçin:

• Kampanya tamamlandı, kampanya reddedildi
• Günlük rapor, haftalık rapor
• Bounce uyarısı, şikayet uyarısı
• Düşük kredi uyarısı, yeni ekip üyesi
• Otomasyon uyarısı — bir otomasyon içerik, künye ya da alan adı sorunu yüzünden e-posta gönderemediğinde ya da panelden eklenenlerin günlük sınırı dolduğunda (aynı otomasyon ve neden için günde en fazla bir kez)

API Genel Bakış

SenderTR REST API ile transactional e-posta gönderebilir, e-posta adreslerini doğrulayabilir, e-ticaret olaylarını otomasyonlara aktarabilir ve pazarlama verilerinizi (kişi, liste, segment, kampanya) programatik olarak yönetebilirsiniz.

Temel URL

Tüm endpoint'ler v1 öneki altındadır:

https://api.sendertr.com/v1

İçerik tipi

İstek ve yanıt gövdeleri her zaman JSON'dır. Gövdeli isteklerde (POST/PUT) aşağıdaki başlığı gönderin:

Content-Type: application/json
Accept: application/json

API tüm yanıtları ve hataları (422 doğrulama, 404, 429 dahil) her zaman JSON olarak döner; Accept: application/json başlığını göndermeniz yine de önerilir.

Her yanıt bir X-Request-Id başlığı taşır (req_…). Bir sorunu bildirirken bu kimliği yazın; aynı kimlik panelde Ayarlar → API Günlüğü sayfasında ve destek tarafında görünür. Kendi kimliğinizi X-Request-Id başlığıyla gönderirseniz (8–64 karakter) o korunur.

Makinece okunabilir şema: openapi.json (OpenAPI 3.0). Resmî istemciler: PHP ve Node.js SDK.

Kimlik doğrulama özeti

Her istek bir API anahtarı ile yetkilendirilir. Önerilen yol panelin de gösterdiği X-Api-Key başlığıdır; Authorization: Bearer biçimi de aynı şekilde kabul edilir:

# Önerilen
X-Api-Key: YOUR_API_KEY

# Alternatif (aynı anahtar)
Authorization: Bearer YOUR_API_KEY

Detaylar ve yetki kapsamları (scope) için Kimlik Doğrulama bölümüne bakın.

Rate limit (hız sınırı)

Limitler dakika başına, hesap (tenant) başına uygulanır: aynı hesabın tüm API anahtarları ve tüm sunucuları tek kovayı paylaşır; anahtar sayısını artırmak limiti artırmaz. Aşımda 429 Too Many Requests döner (gövde: { "error": "rate_limited", "message": "…", "retry_after": 23 }; Retry-After başlığı da gelir, bkz. Hatalar).

Versiyonlama

API sürümü URL yolundadır: /v1/.... Geriye dönük uyumu bozan değişiklikler yeni bir sürüm öneki (/v2) ile yayınlanır; v1 yaşam döngüsü boyunca desteklenir.

Geriye dönük uyum & yetkiler

İzolasyon

Her API anahtarı yalnızca kendi hesabınıza (tenant) ait verilere erişir. Tüm sorgular hesap kimliğiyle açıkça filtrelenir; başka bir hesabın kayıt ID'si istenirse 404 döner (IDOR koruması).

Kimlik Doğrulama

SenderTR API, hesabınıza bağlı bir API anahtarı (SMTP/API credential) ile yetkilendirilir. Anahtar bir SMTP kimliğine ve bir gönderim alan adına (sending domain) bağlıdır.

API anahtarı nasıl alınır?

1. Panele girin: app.sendertr.com.
2. Önce Domainler bölümünden gönderim alan adınızı ekleyip doğrulayın ve Transactional sayfasından SMTP bilgilerinizi oluşturun (gönderim bu kimlik üzerinden yapılır).
3. Ayarlar → API Anahtarları sayfasında anahtara bir ad verin.
4. Yetkileri seçin: varsayılan olarak gönderim (send) ve doğrulama (verify) işaretlidir. Kişi, liste, segment veya kampanya API'sini kullanacaksanız ilgili yetkiyi de işaretleyin.
5. İsteğe bağlı: izinli IP listesi girin.
6. Oluşan anahtarı (str_ ile başlar) kopyalayın. Bu değer yalnızca bir kez gösterilir. (İşlemsel E-posta → SMTP Bilgileri sayfasındaki anahtar ön eksiz 40 karakterdir; o da gönderim API'sinde geçerlidir.)

Anahtarı gönderme

Aşağıdaki iki başlıktan biri kullanılabilir (ikisi de aynı anahtarı taşır):

# Önerilen (panelde gösterilen biçim)
X-Api-Key: str_xxxxxxxxxxxxxxxxxxxxxxxx

# Alternatif — aynı anahtar, Bearer biçiminde
Authorization: Bearer str_xxxxxxxxxxxxxxxxxxxxxxxx

Yetki kapsamları (abilities / scope)

Her endpoint belirli bir yetkiye sahip anahtar gerektirir. Yetkileri anahtarı oluştururken Ayarlar → API Anahtarları ekranında seçersiniz; yetkiyi değiştirmek için yeni bir anahtar oluşturun. Transactional sayfasındaki SMTP kimliğine bağlı anahtar yalnızca send ve verify yetkisine sahiptir. Tanınan yetkiler:

Alan adı kapsamı

Her anahtar yalnızca izin verilen gönderim alan adlarından gönderebilir. Ayarlar → API Anahtarları ekranında anahtarı oluştururken (ya da sonradan "Düzenle" ile) bir veya birkaç alan adı seçersiniz; "Hesaptaki tüm alan adları" seçeneği de vardır ancak önerilmez. SMTP kullanıcıları ve onların API anahtarı varsayılan olarak yalnızca bağlı oldukları alan adından gönderir (İşlemsel E-posta sayfasından değiştirilebilir).

Birden çok müşteri ya da marka adına gönderim yapıyorsanız (ajans, SaaS) her alan adı için ayrı anahtar oluşturun: bir anahtar sızarsa yalnızca o alan adı etkilenir. İzin verilmeyen alan adından gelen istek 403 domain_not_allowed döner, ileti gönderilmez ve hesap sahibine bildirim gider. from_email verilmezse anahtarın izinli alan adlarından biri kullanılır.

{ "error": "domain_not_allowed", "message": "Bu API anahtarı musteri-b.com alan adından gönderim yetkisine sahip değil. İzinli alan adları: musteri-a.com. …", "allowed_domains": ["musteri-a.com"] }

IP kısıtlaması (opsiyonel)

Anahtara izinli IP listesi tanımlarsanız, listede olmayan bir IP'den gelen istek 403 ip_not_allowed döner. Üretim sunucularınızın çıkış IP'lerini eklemeniz önerilir. Liste IPv4, IPv6 ve CIDR bloğu kabul eder (ör. 203.0.113.10, 203.0.113.0/24, 2a01:db8::/32).

Son kullanma ve anahtar döndürme

Anahtar oluştururken son kullanma süresi (30/90/180 gün, 1 yıl) seçebilirsiniz; süresi dolan anahtar 401 expired_api_key döner ve panelde "yakında doluyor" uyarısıyla görünür. Kesintisiz geçiş için anahtarı Döndür: aynı ad, yetki, IP ve alan adı kapsamıyla yeni bir gizli değer üretilir, eski değer 24 saat daha çalışır. Bu sürede entegrasyonunuzu yeni anahtara geçirin; 24 saat sonra eski değer kendiliğinden geçersiz olur.

Güvenlik — anahtar saklama

• API anahtarını asla istemci tarafı (tarayıcı/JS, mobil uygulama) koduna gömmeyin. Anahtar yalnızca sunucu tarafında kullanılmalıdır.
• Anahtarı ortam değişkeninde (.env) veya gizli yönetim servisinde saklayın; sürüm kontrolüne (git) eklemeyin.
• Sızıntı şüphesinde panelden anahtarı silin (anında geçersiz olur) ve yenisini oluşturun; planlı değişimde Döndür kullanın (eski değer 24 saat çalışır). SMTP Bilgileri sayfasındaki anahtarı "Yenile" ile değiştirebilirsiniz.
• Anahtarlarınıza son kullanma süresi verin ve sürenin bitmesine yakın döndürün.
• Mümkünse anahtara yalnızca ihtiyaç duyduğu yetkileri ve izinli IP listesini atayın (en az ayrıcalık ilkesi).

Doğrulama hatası örnekleri

// Anahtar eksik
HTTP/1.1 401 Unauthorized
{ "error": "unauthorized", "message": "API key gerekli. X-Api-Key header veya Bearer token kullanın." }

// Geçersiz/pasif anahtar
HTTP/1.1 401 Unauthorized
{ "error": "invalid_api_key", "message": "Geçersiz veya deaktif API anahtarı." }

// Hesap pasif
HTTP/1.1 403 Forbidden
{ "error": "tenant_inactive", "message": "Hesabınız aktif değil." }

// IP izinli değil
HTTP/1.1 403 Forbidden
{ "error": "ip_not_allowed", "message": "Bu IP adresinden erişim izniniz yok." }

// Süresi dolmuş anahtar
HTTP/1.1 401 Unauthorized
{ "error": "expired_api_key", "message": "API anahtarının süresi dolmuş. Panelden yeni bir anahtar oluşturun." }

// Yetki yetersiz
HTTP/1.1 403 Forbidden
{ "error": "insufficient_scope", "message": "Bu API anahtarı 'contacts:write' yetkisine sahip değil.", "required_ability": "contacts:write" }

Transactional E-posta Gönderimi

Sipariş onayı, şifre sıfırlama, OTP gibi işlemsel e-postaları tek istekte gönderin. Gönderim asenkron kuyruğa alınır; yanıt anında döner.

POST /send

Tek bir alıcıya transactional e-posta gönderir. Yetki: send. Rate limit: 300/dk.

İstek alanları

cURL örneği

curl -X POST https://api.sendertr.com/v1/send \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{
    "to": "musteri@example.com",
    "from_email": "siparis@sirketiniz.com",
    "from_name": "Sirketiniz",
    "subject": "Siparisiniz alindi (#10234)",
    "html": "<h1>Tesekkurler!</h1><p>Siparisiniz hazirlaniyor.</p>",
    "text": "Tesekkurler! Siparisiniz hazirlaniyor.",
    "reply_to": "destek@sirketiniz.com",
    "tags": ["order", "confirmation"],
    "metadata": { "order_id": "10234" }
  }'

Dosya eki, cc ve bcc

cc, bcc ve attachments yalnızca tekli uçta (/v1/send ve /v1/email/send) kullanılabilir.

• Görünen başlıklar: Her alıcı aynı To (isteğinizdeki to) ve aynı Cc satırını görür. bcc adresleri hiçbir iletinin başlığında yer almaz; headers içinde gönderilen Cc/Bcc başlıkları bu isteklerde yok sayılır.
• Tekrarlanan adres: to, cc ve bcc içinde aynı adres (büyük/küçük harf fark etmez) birden çok kez geçerse tek ileti gider; öncelik to > cc > bcc.
• Engelli alıcı: to adresi engel listesindeyse istek eskisi gibi recipient_suppressed ile reddedilir. Engelli bir cc/bcc adresi ise atlanır, diğerleri gönderilir; yanıtta "status": "skipped" olarak döner ve kredi düşülmez.
• Ek sınırları: en fazla 10 dosya; base64 çözülmüş toplam boyut en fazla 10 MB (base64 metin yaklaşık üçte bir daha büyüktür). filename zorunlu, en fazla 255 karakter, yol ayırıcı (/, \) ve kontrol karakteri içeremez. content_type verilmezse dosya içeriğinden belirlenir.
• Yasaklı uzantılar (büyük/küçük harf fark etmez; dosyanın açılış biçimini belirleyen son uzantı denetlenir — çift uzantı hilesi fatura.pdf.exe reddedilir, firma.com.pdf gibi PDF'ler kabul edilir): exe, bat, cmd, com, scr, pif, js, jse, vbs, vbe, wsf, wsh, msi, msp, jar, ps1, psm1, sh, apk, dll, hta, lnk, reg, cpl, iso, img → 422 attachment_type_not_allowed.
• Saklama: Ekler yalnızca gönderim için tutulur; tüm kopyalar gönderilince silinir, her durumda en fazla 48 saat saklanır.
• İzleme: Her kopyanın metadata'sına ortak group_id ve role (to | cc | bcc) eklenir; webhook olaylarında ve GET /messages listesinde bu alanlarla kopyaları eşleştirebilirsiniz. Kendi metadata'nızda aynı adlı anahtar varsa bu değerlerle ezilir.

curl -X POST https://api.sendertr.com/v1/send \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{
    "to": "musteri@example.com",
    "cc": ["muhasebe@example.com"],
    "bcc": "arsiv@sirketiniz.com",
    "from_email": "fatura@sirketiniz.com",
    "subject": "Faturaniz (#10234)",
    "html": "<p>Faturaniz ektedir.</p>",
    "attachments": [
      {
        "filename": "fatura-10234.pdf",
        "content_type": "application/pdf",
        "content": "JVBERi0xLjQKJ..."
      }
    ]
  }'

Yanıtta tekli gönderimin alanları (id, message_id, priority, expires_at; hepsi to kopyasına ait) aynen döner; cc, bcc veya attachments gönderdiğinizde ek olarak her kopyanın kendi id ve message_id'sini taşıyan recipients listesi gelir:

HTTP/1.1 202 Accepted
{
  "success": true,
  "id": "msg_01K6Q0A3ZK8Y1C2D3E4F5G6H7J",
  "message_id": "8f3c0c1e-...-9a2b@sirketiniz.com",
  "status": "queued",
  "priority": "normal",
  "expires_at": "2026-10-05T14:05:10+03:00",
  "recipients": [
    { "email": "musteri@example.com",  "role": "to",  "id": "msg_01K6Q0A3ZK8Y1C2D3E4F5G6H7J", "message_id": "8f3c0c1e-...-9a2b@sirketiniz.com", "status": "queued" },
    { "email": "muhasebe@example.com", "role": "cc",  "id": "msg_01K6Q0A3ZM1P9R8S7T6U5V4W3X", "message_id": "1d7e2a90-...-44c1@sirketiniz.com", "status": "queued" },
    { "email": "arsiv@sirketiniz.com", "role": "bcc", "id": null, "message_id": null, "status": "skipped", "reason": "recipient_suppressed" }
  ]
}

Ek, cc ve bcc'ye özgü hatalar (hepsi 422, isteğin tamamı reddedilir):

{ "error": "attachment_type_not_allowed", "message": "Bu dosya türü ek olarak gönderilemez: fatura.pdf.exe. …", "index": 0, "filename": "fatura.pdf.exe" }
{ "error": "attachments_too_large", "message": "Eklerin toplam boyutu en fazla 10 MB olabilir (base64 çözülmüş hâliyle).", "limit_bytes": 10485760 }
{ "error": "attachment_invalid_base64", "message": "attachments.0.content geçerli bir base64 değil.", "index": 0 }
{ "error": "attachment_invalid_filename", "message": "attachments.0.filename geçersiz: yol ayırıcı (/ \) veya kontrol karakteri içeremez.", "index": 0 }
{ "error": "attachment_infected", "message": "Ek zararlı içerik taşıdığı için reddedildi: fatura.pdf (Sanesecurity.Foxhole.Mail_pdf.UNOFFICIAL). Dosyayı üreten sistemi kontrol edin.", "index": 0, "filename": "fatura.pdf", "signature": "Sanesecurity.Foxhole.Mail_pdf.UNOFFICIAL" }
{ "error": "too_many_recipients", "message": "cc ve bcc toplamı en fazla 10 adres olabilir." }

11 veya daha fazla ek ve geçersiz bir cc/bcc adresi standart alan doğrulama hatası (errors) olarak döner.

Başarılı yanıt

E-posta kuyruğa alınır ve 202 Accepted döner:

HTTP/1.1 202 Accepted
X-Request-Id: req_01K6Q0A3ZJ6R0B9W5XK2M4N7PD
{
  "success": true,
  "id": "msg_01K6Q0A3ZK8Y1C2D3E4F5G6H7J",
  "message_id": "8f3c0c1e-...-9a2b@sirketiniz.com",
  "status": "queued",
  "priority": "normal",
  "expires_at": "2026-10-05T14:05:10+03:00"
}

id (msg_…) ya da message_id değerini saklayın; durum sorgulama ve iptal için ikisi de kullanılır. send_at verdiyseniz yanıt send_at alanını da taşır.

Hata yanıtları

// Doğrulama hatası (eksik/yanlış alan)
HTTP/1.1 422 Unprocessable Content
{ "error": "validation_failed", "message": "Alıcı zorunludur.", "errors": { "to": ["Alıcı zorunludur."] } }

// Günlük gönderim limiti doldu
HTTP/1.1 429 Too Many Requests
{ "error": "daily_limit_exceeded", "message": "Günlük gönderim limitiniz doldu. Hesabınızın limiti günde 5.000 işlemsel e-posta. …", "limit": 5000, "used": 5000 }

// Alıcı suppression listesinde
HTTP/1.1 422 Unprocessable Content
{ "error": "recipient_suppressed", "message": "Bu alıcı suppression listesinde (hard_bounce).", "suppression_reason": "hard_bounce" }
{ "error": "recipient_suppressed", "message": "Alıcının posta kutusu dolu olduğu için adres geçici olarak engellendi; 07.10.2026 19:00 tarihinden sonra yeniden gönderilebilir.", "suppression_reason": "mailbox_full", "suppressed_until": "2026-10-07T19:00:00+03:00" }
{ "error": "recipient_suppressed", "message": "Bu adres son 30 gün içinde platformumuzda kalıcı olarak geri döndü (Alıcı adresi yok); …", "suppression_reason": "platform_invalid", "suppressed_until": "2026-11-10T14:00:00+03:00" }

// Yetersiz kredi
HTTP/1.1 402 Payment Required
{ "error": "insufficient_credit", "message": "Yetersiz kredi." }

// Hesap/kimlik pasif
HTTP/1.1 403 Forbidden
{ "error": "tenant_inactive", "message": "Hesabınız aktif değil." }

Gönderim ön kontrolleri (validator)

Her /send isteği sırayla şu kontrollerden geçer; ilk başarısızlıkta yukarıdaki ilgili hata döner:

1. Ek, cc ve bcc alanları geçerli mi? (ek ve adres hataları, aşağıya bakın)
2. Anahtara bağlı bir gönderim alan adı var mı? (no_sending_domain → 422)
3. Gönderen alan adı anahtarın izinli alan adlarından biri mi? (domain_not_allowed → 403)
4. Gönderen adresinin alan adı doğrulanmış mı (DKIM + DMARC; SPF isteğe bağlı)? (domain_not_verified → 422) — alan adları her gün yeniden denetlenir; bir kayıt DNS'ten kaybolursa gönderim kayıt geri gelene kadar durur.
5. İçerik güvenlik denetimi (content_rejected → 422) — aşağıya bakın.
6. Hesap aktif mi? (tenant_inactive → 403)
7. Alıcı bir KEP adresi mi? (kep_address → 422; KEP adreslerine gönderim yapılmaz)
8. API/SMTP kimliği aktif mi? (credential_inactive → 403)
9. Günlük deneme tavanı: engelli adreslere tekrar tekrar gönderim denemeleri dahil, gönderim kimliği başına günlük limitin 3 katı (en az 50) deneme. (rate_limit_exceeded → 429)
10. Günlük ve aylık gönderim limiti (hesap geneli; SenderTR bir SMTP kimliğine ayrıca tavan tanımladıysa o da uygulanır); 30 günden yeni alan adlarında günde 200 ileti tavanı. (daily_limit_exceeded / monthly_limit_exceeded → 429)
11. Alıcı suppression listesinde mi? (recipient_suppressed → 422; posta kutusu dolu engeli süreli, suppressed_until ile döner)
12. Kredi bakiyesi yeterli mi? (insufficient_credit → 402) — kuyrukta henüz gönderilmemiş iletileriniz de bakiyeden düşülerek hesaplanır: 10 krediniz ve kuyrukta 10 iletiniz varsa 11. istek reddedilir.

İçerik sınırları

html en fazla 2.000.000, text en fazla 1.000.000 karakter olabilir. variables ile {{etiket}} değiştirme hem tekli /send'de hem /send/batch'te çalışır. cc/bcc adresleri ASCII olmalı (en fazla 254 karakter).

Günlük limit

Günlük ve aylık gönderim limiti hesap geneline uygulanır: tüm API anahtarlarınız ve SMTP kullanıcılarınız aynı limitten düşer. Limit planınıza göre belirlenir (ör. ücretsiz planda günde 100, ayda 3.000) ve daha büyük bir kredi paketi aldığınızda plan ile birlikte kendiliğinden yükselir. İhtiyacınız olursa panelde Limitler sayfasından kredinizle 30 günlüğüne +1.000/gün ek alabilirsiniz (aylık limit de 30 katı artar).

Günlük sayaç her gün 00:00'da, aylık sayaç her ayın 1'inde (Europe/Istanbul) sıfırlanır. Limit aşımında HTTP 429 ve daily_limit_exceeded veya monthly_limit_exceeded döner; yanıt limit ve used alanlarını içerir.

HTTP/1.1 429 Too Many Requests
{ "error": "daily_limit_exceeded", "message": "… alan adınız yeni kayıtlı …", "limit": 200, "used": 200, "young_domain_until": "2026-10-25" }

POST /send/batch

Tek istekte 500 iletiye kadar gönderim. /v1/email/batch adıyla da çağrılabilir. Her ileti tek gönderimle aynı kurallardan geçer ve bağımsız değerlendirilir: biri reddedilirse diğerleri yine gönderilir. Hız sınırı: dakikada 60 istek (yani dakikada 30.000 iletiye kadar).

İstek

• messages (zorunlu, 1–500): her eleman /send ile aynı alanları alır; attachments, cc ve bcc hariç.
• defaults (isteğe bağlı): her iletiye uygulanacak ortak alanlar. İletideki alan bunu ezer.
• variables (ileti başına, isteğe bağlı): konu, HTML ve metindeki {{anahtar}} etiketlerine yerleşir. HTML'de değerler otomatik kaçışlanır; tanımlamadığınız etiketlere (ör. {{unsubscribe_url}}) dokunulmaz.

curl -X POST https://api.sendertr.com/v1/send/batch \
  -H "X-Api-Key: ANAHTARINIZ" -H "Content-Type: application/json" \
  -d '{
    "defaults": {
      "from_email": "siparis@alanadiniz.com",
      "subject": "Siparişiniz {{no}} kargoya verildi",
      "html": "<p>Merhaba {{ad}}, siparişiniz yolda.</p>"
    },
    "messages": [
      { "to": "ayse@ornek.com", "variables": { "ad": "Ayşe", "no": "1001" } },
      { "to": "ali@ornek.com",  "variables": { "ad": "Ali",  "no": "1002" } }
    ]
  }'

Yanıt (her zaman 200)

{
  "accepted": 1,
  "rejected": 1,
  "results": [
    { "index": 0, "success": true,  "message_id": "…@alanadiniz.com", "status": "queued" },
    { "index": 1, "success": false, "error": "recipient_suppressed", "message": "Bu alıcı suppression listesinde (hard_bounce)." }
  ]
}

results istekteki sırayla döner; index alanıyla kendi kaydınızla eşleştirin. Kredi yetmezse bakiyeyi aşan iletiler insufficient_credit ile reddedilir, öncekiler gönderilir.

HTTP/1.1 422 Unprocessable Content
{ "error": "unsupported_in_batch",
  "message": "Toplu gönderimde attachments desteklenmez. Ek, cc veya bcc içeren iletileri tek tek POST /v1/send ile gönderin.",
  "fields": ["attachments"] }

İçerik güvenlik denetimi

API ve SMTP ile gönderilen iletiler kimlik avı (phishing) ve kötüye kullanım işaretleri için taranır: parola giriş formu, doğrudan IP adresine bağlantı, görünen metni başka alan adına götüren bağlantı, bir banka veya platform adına ama o kurumun alan adından olmayan gönderim, aciliyet kalıpları. Normal sipariş, şifre sıfırlama ve bildirim iletileri etkilenmez.

• Bağlantı alan adı itibarı: iletideki bağlantıların alan adları Spamhaus DBL, SURBL ve URIBL kara listelerinde sorgulanır. Phishing, zararlı yazılım veya spam kaynağı olarak listelenmiş bir alan adına bağlantı yeni hesaplarda iletiyi tek başına durdurur; yerleşik hesaplarda başka bir işaretle birleşince durdurur, tek başına işaretler. Yanıttaki reasons listesi hangi alan adının hangi listede olduğunu söyler.
• Ek taraması: ekler ClamAV ve Sanesecurity imzalarıyla taranır; zararlı ek attachment_infected ile reddedilir.
• Yeni hesaplarda (ilk 30 gün veya ilk 1.000 teslim) denetim daha sıkıdır.
• Engellenen ileti gönderilmez, kredi düşülmez ve yanıtta gerekçesi döner:

HTTP/1.1 422 Unprocessable Entity
{ "error": "content_rejected",
  "message": "İleti güvenlik denetiminden geçmedi ve gönderilmedi. …",
  "reasons": ["bağlantı doğrudan IP adresine gidiyor: 185.22.33.44"] }

Yanlış bir engelleme olduğunu düşünüyorsanız destek@sendertr.com adresine yazın; ekibimiz inceleyip hesabınızı güvenilir olarak işaretleyebilir.

POST /check/content

Gönderim öncesi kontrol: iletinizi, gönderim anında uygulanan aynı kural setiyle sınar. Hiçbir ileti gönderilmez, kredi düşülmez. Yetki: send. Rate limit: 60/dk.

curl -X POST https://api.sendertr.com/v1/check/content \
  -H "X-Api-Key: YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{ "subject": "Hesabınız askıya alınacak", "from_email": "bildirim@sirketiniz.com", "from_name": "Garanti",
        "html": "<p>24 saat içinde <a href=\"http://185.22.33.44/dogrula\">doğrulayın</a></p>" }'

Yanıt score (0–100 teslimat puanı), checks[] (her kontrol: name, passed, score_impact, message, suggestion), warnings[], suggestions[], security (güvenlik puanı ve gerekçeleri), sender_domain (kayıt tarihi, genç mi) ve would_block (new_account, established_account, this_account: bu ileti gönderilse engellenir miydi) alanlarını taşır. Kontroller: spam kelimeler, büyük harf, görsel/metin oranı, çoklu parça, kimlik avı kalıbı, yasadışı bahis, sahte gönderen adı, HTML smuggling, punycode, bağlantı alan adı kara listeleri (Spamhaus DBL / SURBL / URIBL), gönderen alan adı yaşı.

GET /messages/{id}

Tek bir transactional iletinin güncel durumunu ve olay zaman çizelgesini döndürür. {id} olarak msg_… kimliği ya da Message-ID verilebilir. Yetki: send. Rate limit: 60/dk. Alan adıyla sınırlı bir anahtar yalnızca izinli alan adlarından gönderilmiş iletileri görür, listeler ve iptal eder.

cURL

curl https://api.sendertr.com/v1/messages/msg_01K6Q0A3ZK8Y1C2D3E4F5G6H7J \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Accept: application/json"

Başarılı yanıt

HTTP/1.1 200 OK
{
  "id": "msg_01K6Q0A3ZK8Y1C2D3E4F5G6H7J",
  "message_id": "8f3c0c1e-...-9a2b@sirketiniz.com",
  "to": "musteri@example.com",
  "from": "bildirim@sirketiniz.com",
  "subject": "Siparisiniz alindi (#10234)",
  "status": "delivered",
  "priority": "normal",
  "smtp_code": 250,
  "smtp_response": null,
  "error": null,
  "bounce_side": null, "bounce_reason": null, "bounce_label": null,
  "tags": ["siparis"], "metadata": { "order_id": "10234" },
  "send_at": null,
  "expires_at": "2026-06-02T14:05:10+03:00",
  "sent_at": "2026-06-01T14:05:12+03:00",
  "opened_at": "2026-06-01T14:09:40+03:00",
  "clicked_at": null,
  "created_at": "2026-06-01T14:05:10+03:00",
  "events": [
    { "event": "queued",    "at": "2026-06-01T14:05:10+03:00", "detail": null, "dsn_code": null, "server": null },
    { "event": "sent",      "at": "2026-06-01T14:05:12+03:00", "detail": null, "dsn_code": null, "server": "5.2.84.5" },
    { "event": "delivered", "at": "2026-06-01T14:05:13+03:00", "detail": null, "dsn_code": "2.0.0", "server": null },
    { "event": "opened",    "at": "2026-06-01T14:09:40+03:00", "detail": null, "dsn_code": null, "server": null }
  ]
}

Tüm API yanıtlarındaki zaman alanları Türkiye saatiyle (Europe/Istanbul, +03:00) ISO 8601 biçiminde döner. Aynı zaman çizelgesi panelde İşlemsel E-posta → ileti satırı tıklanınca görünür. 4 Eki 2026'dan önceki iletilerde events boş döner.

Olası status değerleri: queued (kuyrukta ya da send_at bekliyor), sending, sent (sunucumuz iletiyi alıcı sunucuya iletmek üzere kabul etti; alıcı onayı bekleniyor), delivered (alıcı sunucu kabul etti), deferred (alıcı geçici olarak erteledi, yeniden denenir; işlemsel iletilerde en fazla 24 saat, sonra bounced), bounced (alıcı sunucu reddetti), failed (gönderilmeden reddedildi: kredi, limit, engelli alıcı), expired (ömrü, expires_in, kuyrukta beklerken doldu; gönderilmedi, kredi düşmedi), cancelled (siz iptal ettiniz), complained (alıcı spam bildirdi). sent genellikle saniyeler içinde alıcı sunucunun yanıtıyla delivered, deferred ya da bounced olur; bu olayların her biri webhook'la da bildirilir. Mesaj bulunamazsa 404 { "error": "not_found" }.

events[].event değerleri: queued, scheduled, sending, sent, delivered, deferred, bounced, failed, expired, cancelled, complained, opened, clicked.

DELETE /messages/{id}

Kuyrukta bekleyen (queued, ileri tarihli dahil) iletiyi iptal eder; ileti gönderilmez, kredi düşmez. Sunucuya verilmiş ileti (sending ve sonrası) iptal edilemez: 409 not_cancellable ve mevcut status döner. Yetki: send.

curl -X DELETE https://api.sendertr.com/v1/messages/msg_01K6Q0A3ZK8Y1C2D3E4F5G6H7J -H "X-Api-Key: YOUR_API_KEY"

HTTP/1.1 200 OK
{ "success": true, "id": "msg_01K6Q0A3ZK8Y1C2D3E4F5G6H7J", "message_id": "8f3c…@sirketiniz.com", "status": "cancelled" }

GET /messages

Hesabınızın transactional mesajlarını sayfalı listeler. Yetki: send.

Sorgu parametreleri

curl "https://api.sendertr.com/v1/messages?status=delivered&from=2026-06-01&per_page=50" \
  -H "X-Api-Key: YOUR_API_KEY" -H "Accept: application/json"

Yanıt { "data": [ …ileti… ], "meta": { "current_page", "per_page", "total", "last_page", "from", "to", "retention_months" } } biçimindedir; liste geçmiş penceresiyle sınırlıdır (retention_months, 6 ay; bkz. plan özellikleri); her ileti GET /messages/{id} ile aynı alanları taşır (events hariç). Eski üst düzey sayfalama alanları (current_page, total, last_page) geriye dönük uyum için korunmuştur.

İşlemsel Şablonlar, Idempotency ve SDK'lar

Uygulamanızda e-posta içeriği taşımak yerine şablonu bir kez kaydedin, gönderimde yalnızca anahtar ve değişkenleri geçin. Ağ kesintilerinde çift gönderimi Idempotency-Key önler. Resmî PHP ve Node.js istemcileri ve OpenAPI şeması entegrasyonu kısaltır.

Idempotency-Key — çift gönderimi önleme

POST /send ve POST /send/batch isteklerine Idempotency-Key başlığı ekleyin (en çok 128 karakter; sipariş numarası, UUID vb.). Aynı anahtarla 24 saat içinde gelen yinelenen istek ikinci bir ileti oluşturmaz; ilk yanıt aynen döner ve yanıtta Idempotent-Replayed: true başlığı bulunur. Anahtar hesabınıza özeldir.

curl -X POST https://api.sendertr.com/v1/send \
  -H "X-Api-Key: YOUR_API_KEY" -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-48215-confirmation" \
  -d '{ "to": "musteri@example.com", "template": "order-created", "variables": { "no": "48215" } }'

İşlemsel şablonlar (API)

Yetki: templates (Ayarlar → API Anahtarları → "İşlemsel şablonları yönet"). Şablonlar sürümlüdür: her PUT yeni bir sürüm açar ve etkinleştirir; sorun olursa eski sürümü tek çağrıyla geri alırsınız. Hesap başına 200 şablon, şablon başına 50 sürüm.

# Oluştur
curl -X POST https://api.sendertr.com/v1/templates -H "X-Api-Key: YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{ "key": "order-created", "name": "Sipariş onayı", "subject": "Siparişiniz alındı (#{{no}})",
        "html": "<p>Merhaba {{ad}}, {{no}} numaralı siparişiniz hazırlanıyor.</p>", "from_name": "Mağazam" }'

# Şablonla gönder — subject/html şablondan, {{ad}} ve {{no}} doldurulur
curl -X POST https://api.sendertr.com/v1/send -H "X-Api-Key: YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{ "to": "musteri@example.com", "template": "order-created", "variables": { "ad": "Ayşe", "no": "48215" } }'

# Yeni sürüm (yalnız html değişti) ve gerekirse geri al
curl -X PUT  https://api.sendertr.com/v1/templates/order-created -H "X-Api-Key: YOUR_API_KEY" -H "Content-Type: application/json" -d '{ "html": "<p>v2…</p>" }'
curl -X POST https://api.sendertr.com/v1/templates/order-created/activate/1 -H "X-Api-Key: YOUR_API_KEY"

Şablonla gönderilen iletinin metadata alanına template ve template_version yazılır; raporlarda hangi sürümün gittiğini görürsünüz. İstekte verilen subject, html, text, from_email, from_name, reply_to şablondaki değeri ezer. Toplu gönderimde defaults.template ile tüm iletilere, ileti bazında template ile tek iletiye uygulanır.

Resmî SDK'lar ve OpenAPI

// PHP
$st = new SenderTR\SenderTR('str_...');
$r = $st->send(['to' => 'musteri@example.com', 'template' => 'order-created', 'variables' => ['no' => '48215']], idempotencyKey: 'order-48215');
echo $r['id'];                       // msg_…
$st->getMessage($r['id']);           // durum + events[]

// Node.js
const { SenderTR } = require('@sendertr/sdk');
const st = new SenderTR('str_...');
const r = await st.send({ to: 'musteri@example.com', template: 'order-created', variables: { no: '48215' } }, { idempotencyKey: 'order-48215' });
await st.cancelMessage(r.id);        // kuyruktaysa iptal

Her iki SDK de hataları error kodu, HTTP durumu ve X-Request-Id ile fırlatır (SenderTRException / SenderTRError).

API Günlüğü (panel)

Ayarlar → API Günlüğü: hesabınızın son 30 günlük API istekleri — zaman, yol, HTTP durumu, hata kodu, süre, anahtar adı, IP ve X-Request-Id. İstek gövdesi ve başlıkları saklanmaz. Son 24 saatin istek, 4xx, 429 ve 5xx sayıları ile ortalama süresi özetlenir; duruma, yola ve istek kimliğine göre filtrelenir.

E-posta Doğrulama API

Adresleri gönderim öncesi doğrulayın: söz dizimi, MX kaydı, SMTP el sıkışması, geçici (disposable) servis, rol adresi, catch-all ve spam-trap tespiti. Tüm kontroller lokal yapılır — dış servise veri gitmez (KVKK uyumlu).

POST /verify

Tek bir adresi doğrular. Yetki: verify. Rate limit: 60/dk. POST /email/verify aynı uca eşdeğer bir takma addır (aynı istek/yanıt).

İstek alanları

cURL

curl -X POST https://api.sendertr.com/v1/verify \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "email": "test@example.com" }'

Başarılı yanıt

HTTP/1.1 200 OK
{
  "email": "test@example.com",
  "result": "valid",
  "score": 95,
  "mx_found": true,
  "smtp_check": true,
  "smtp_message": "250 OK",
  "is_disposable": false,
  "is_role_based": false,
  "is_catch_all": false,
  "is_spam_trap": false
}

Yanıt alanları

result kategorileri

POST /verify/bulk

Birden çok adresi tek istekte doğrular. Yetki: verify. İstek başına en fazla 100 adres.

İstek alanları

cURL

curl -X POST https://api.sendertr.com/v1/verify/bulk \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "emails": ["a@example.com", "b@example.com"] }'

Başarılı yanıt

HTTP/1.1 200 OK
{
  "results": [
    { "email": "a@example.com", "result": "valid",   "score": 92, "mx_found": true,  "smtp_check": true,  "is_disposable": false, "is_role_based": false, "is_catch_all": false, "is_spam_trap": false },
    { "email": "b@example.com", "result": "invalid", "score": 5,  "mx_found": false, "smtp_check": false, "is_disposable": false, "is_role_based": false, "is_catch_all": false, "is_spam_trap": false }
  ]
}

Kredi maliyeti

API doğrulaması panelle aynı fiyattadır ve kredi, doğrulama yapılmadan önce düşer (sonuç ne olursa olsun):

Bakiye yetmezse hiçbir adres doğrulanmaz, kredi düşülmez ve şu yanıt döner:

HTTP/1.1 402 Payment Required
{ "error": "insufficient_credit", "message": "Yetersiz kredi. Gerekli: 4, mevcut: 1.", "required": 4, "balance": 1 }

Her istek, Krediler sayfasındaki işlem geçmişinde email_verification türüyle görünür. Tekli ve toplu doğrulama aynı fiyattır (1 adres = 1 kredi); birden çok adresiniz varsa istek sayısını azaltmak için /verify/bulk kullanın.

Marketing CRUD API

Kişi, liste, segment ve kampanyalarınızı programatik yönetin. Tüm endpoint'ler 60/dk rate limit'e tabidir ve ilgili yetki kapsamını (scope) gerektirir. Her istek yalnızca kendi hesabınızın verisine erişir; başka hesabın ID'si → 404.

Sayfalama ve yanıt zarfı

Listeleme endpoint'leri tutarlı bir zarf döndürür:

{
  "data": [ { ... }, { ... } ],
  "meta": {
    "current_page": 1,
    "per_page": 25,
    "total": 134,
    "last_page": 6,
    "from": 1,
    "to": 25
  }
}

Tekil kayıt endpoint'leri { "data": { ... } } döndürür. per_page parametresi 1–100 aralığında olabilir (varsayılan 25).

Kişiler (Contacts)

GET /contacts

Yetki: contacts:read. Kişileri sayfalı listeler.

curl "https://api.sendertr.com/v1/contacts?status=active&search=ahmet&per_page=50" \
  -H "X-Api-Key: YOUR_API_KEY" -H "Accept: application/json"

HTTP/1.1 200 OK
{
  "data": [
    {
      "id": 4821,
      "email": "ahmet@example.com",
      "first_name": "Ahmet",
      "last_name": "Yılmaz",
      "phone": "+905xxxxxxxxx",
      "city": "İstanbul",
      "status": "active",
      "source": "api",
      "custom_fields": { "plan": "pro" },
      "engagement_score": 72,
      "verification_status": "valid",
      "opt_in_status": "confirmed",
      "created_at": "2026-05-20T10:11:00+03:00",
      "updated_at": "2026-05-28T08:00:00+03:00"
    }
  ],
  "meta": { "current_page": 1, "per_page": 50, "total": 1, "last_page": 1, "from": 1, "to": 1 }
}

GET /contacts/{id}

Yetki: contacts:read. Tek kişiyi, üye olduğu listelerle birlikte döndürür. Bulunamazsa 404.

HTTP/1.1 200 OK
{ "data": { "id": 4821, "email": "ahmet@example.com", "...": "...", "lists": [ { "id": 12, "name": "Bülten" } ] } }

POST /contacts

Yetki: contacts:write. E-posta bazlı upsert: aynı e-posta varsa günceller, yoksa oluşturur. Yeni oluşturulursa 201, güncellenirse 200 döner.

curl -X POST https://api.sendertr.com/v1/contacts \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "email": "yeni@example.com",
    "first_name": "Yeni",
    "last_name": "Kullanıcı",
    "custom_fields": { "plan": "trial" },
    "list_ids": [12, 15]
  }'

HTTP/1.1 201 Created
{ "data": { "id": 5012, "email": "yeni@example.com", "...": "...", "lists": [ { "id": 12, "name": "Bülten" }, { "id": 15, "name": "Kampanya" } ] } }

POST /contacts/bulk

Tek istekte 1.000 kişiye kadar ekleme veya güncelleme (e-posta adresine göre). contacts:write yetkisi gerekir. Her kayıt bağımsız işlenir; hatalı olanlar errors içinde istekteki sırasıyla döner. Plan kişi limitiniz yalnızca yeni kişilere uygulanır; mevcut kişileri her zaman güncelleyebilirsiniz. Üst düzeydeki list_ids tüm kişilere, kişi içindeki list_ids yalnızca o kişiye uygulanır.

POST /v1/contacts/bulk
{
  "list_ids": [3],
  "contacts": [
    { "email": "ayse@ornek.com", "first_name": "Ayşe", "city": "İzmir" },
    { "email": "ali@ornek.com",  "first_name": "Ali", "list_ids": [5] }
  ]
}

→ 200 { "created": 1, "updated": 1, "failed": 0, "errors": [] }

100.000 kişilik bir liste 100 istekte, dakikada 60 istek sınırıyla iki dakikadan kısa sürede yüklenir.

PUT /contacts/{id}

Yetki: contacts:write. Var olan kişiyi günceller. Tüm alanlar opsiyoneldir (gönderilen güncellenir).

curl -X PUT https://api.sendertr.com/v1/contacts/5012 \
  -H "X-Api-Key: YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{ "city": "Ankara", "list_ids": [12] }'

DEL /contacts/{id}

Yetki: contacts:write. Kişiyi siler (liste bağları çözülür).

HTTP/1.1 200 OK
{ "data": { "deleted": true, "id": 5012 } }

Listeler (Lists)

GET /lists

Yetki: lists:read. Parametreler: search, per_page. Her liste üye sayısı (member_count) ile döner.

HTTP/1.1 200 OK
{ "data": [ { "id": 12, "name": "Bülten", "description": null, "is_tacir_list": false, "member_count": 3120, "created_at": "...", "updated_at": "..." } ], "meta": { "...": "..." } }

GET /lists/{id}

Yetki: lists:read. Tek liste. Bulunamazsa 404.

POST /lists

Yetki: lists:write. Yeni liste oluşturur (201).

curl -X POST https://api.sendertr.com/v1/lists \
  -H "X-Api-Key: YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{ "name": "Haziran Kampanyası", "description": "Yaz indirimi listesi" }'

PUT /lists/{id}

Yetki: lists:write. name (opsiyonel ama gönderilirse zorunlu+geçerli), description, is_tacir_list güncellenir.

DEL /lists/{id}

Yetki: lists:write. Listeyi siler (kişi bağları çözülür, kişiler silinmez). Yanıt: { "data": { "deleted": true, "id": 12 } }.

Segmentler (Segments)

Segmentler salt okunurdur (API ile oluşturulamaz/düzenlenemez).

GET /segments

Yetki: segments:read. Parametreler: search, per_page.

HTTP/1.1 200 OK
{ "data": [ { "id": 7, "name": "Aktif İstanbul", "estimated_count": 940, "created_at": "...", "updated_at": "..." } ], "meta": { "...": "..." } }

GET /segments/{id}

Yetki: segments:read. Tek segment + rules (kural tanımları) döner.

Kampanyalar (Campaigns)

GET /campaigns

Yetki: campaigns:read. Parametreler: status, search, per_page.

HTTP/1.1 200 OK
{
  "data": [
    {
      "id": 88, "name": "Yaz İndirimi", "subject": "%30'a varan indirim",
      "from_email": "kampanya@sirketiniz.com", "from_name": "Sirketiniz",
      "message_type": "marketing", "status": "draft", "status_label": "Taslak",
      "total_recipients": 0, "sent_count": 0,
      "scheduled_at": null, "started_at": null, "completed_at": null,
      "created_at": "...", "updated_at": "..."
    }
  ],
  "meta": { "...": "..." }
}

GET /campaigns/{id}

Yetki: campaigns:read. Tek kampanya + detaylı istatistikler (stats) ve settings döner.

HTTP/1.1 200 OK
{
  "data": {
    "id": 88, "name": "Yaz İndirimi", "status": "completed",
    "stats": {
      "sent": 3120, "delivered": 3080, "opens": 1450, "unique_opens": 1190,
      "clicks": 320, "unique_clicks": 270, "bounces_hard": 12, "bounces_soft": 28,
      "complaints": 1, "unsubscribes": 9
    },
    "settings": { "list_ids": [12], "segment_ids": [] }
  }
}

POST /campaigns

Yetki: campaigns:write. Yeni taslak kampanya oluşturur (201, durum draft).

curl -X POST https://api.sendertr.com/v1/campaigns \
  -H "X-Api-Key: YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{
    "name": "Yaz İndirimi",
    "subject": "%30'\''a varan indirim",
    "from_email": "kampanya@sirketiniz.com",
    "from_name": "Sirketiniz",
    "html_content": "<h1>İndirim başladı</h1>",
    "list_ids": [12]
  }'

Oluşan kampanyayı göndermek için panele girip onaya göndermeniz gerekir.

Webhook'lar

İki yönlü webhook desteği: Giden webhook'larla e-posta olaylarını kendi sisteminize anlık iletiriz; gelen e-ticaret webhook'larıyla mağaza olaylarınızı (sipariş/sepet) otomasyonlara aktarırsınız.

Giden Webhook'lar (SenderTR → sizin sunucunuz)

Panelden Ayarlar → Webhook'lar bölümünde bir endpoint URL'i ve dinlenecek olayları tanımlarsınız. Olay gerçekleştiğinde sunucunuza POST isteği gönderilir.

Event türleri

delivered, bounced, opened, clicked, unsubscribed, complained, expired (yalnız işlemsel: ileti ömrü dolduğu için gönderilmedi; data.reason = "ttl_exceeded"), deferred (yalnız işlemsel: alıcı geçici olarak erteledi, yeniden denenecek; data.dsn_code), failed (yalnız işlemsel: tüm denemeler tükendi, gönderilemedi; data.reason)

Gönderilen başlıklar

Payload yapısı

POST https://sizin-sunucunuz.com/webhooks/sendertr
Content-Type: application/json
X-SenderTR-Signature: t=1780308580,v1=4b1f0c7d2e9a8f6b5c3d1e0f9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b
X-Webhook-Signature: 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08
X-Event-Id: evt_01K6PZ3Q9E8W2V7XJ4N0B5C8RD
X-Event-Type: opened
X-Timestamp: 2026-06-01T14:09:40+03:00
User-Agent: SenderTR-Webhook/1.0

{
  "event": "opened",
  "id": "evt_01K6PZ3Q9E8W2V7XJ4N0B5C8RD",
  "timestamp": "2026-06-01T14:09:40+03:00",
  "data": {
    "campaign_id": 88,
    "message_id": 918273,
    "email": "musteri@example.com",
    "timestamp": "2026-06-01 14:09:40"
  }
}

Tüm payload'lar aynı üst yapıyı taşır: event, id (olay kimliği, yeniden denemelerde aynı), timestamp ve olaya özgü alanları içeren data nesnesi. data içindeki alanlar:

İşlemsel iletilerde (delivered, bounced, complained, opened, clicked) data şu alanları taşır: source ("transactional"), message_id (gönderim yanıtında dönen metin kimlik), email, subject, tags, metadata, timestamp; olaya göre ayrıca dsn_code, smtp_code, bounce_type, error_message, feedback_type veya url.

Geri dönmenin tarafı ve nedeni

bounced olayında bounce_side retin kimden kaynaklandığını, bounce_reason kısa nedeni, bounce_label Türkçe açıklamayı taşır. Yalnızca alıcı kaynaklı kalıcı retler (bounce_type: hard) adresi engel listesine alır; gönderen ve sunucu kaynaklı retlerde alıcı engellenmez.

{
  "event": "bounced",
  "timestamp": "2026-09-29T10:12:03+03:00",
  "data": {
    "source": "transactional",
    "message_id": "3f9c2b1e-…@firmaniz.com",
    "email": "musteri@example.com",
    "subject": "Siparişiniz alındı",
    "tags": ["siparis"],
    "metadata": {"order_id": "1001"},
    "dsn_code": "5.1.1",
    "smtp_code": "550",
    "bounce_type": "hard",
    "bounce_side": "recipient",
    "bounce_reason": "user_unknown",
    "bounce_label": "Alıcı adresi yok",
    "error_message": "user unknown",
    "timestamp": "2026-09-29T10:12:03+03:00"
  }
}

Kampanya olaylarında message_id SenderTR içindeki ileti numarasıdır (tamsayı); işlemsel olaylarda gönderim yanıtındaki metin kimliktir. Aynı olay nadiren iki kez gelebilir; işleyicinizi tekrar gelen olaya dayanıklı (idempotent) yazın.

Otomasyon iletileri: otomasyon adımlarından giden bir ileti kalıcı olarak geri dönerse bounced olayı data.source: "automation" ile ve daha az alanla gelir — subject, tags, metadata, smtp_code, bounce_side/bounce_reason/bounce_label bulunmaz. İşleyicinizi eksik alanlara dayanıklı yazın.

{
  "event": "bounced",
  "timestamp": "2026-09-29T10:12:03+03:00",
  "data": {
    "source": "automation",
    "message_id": "a-5812@firmaniz.com",
    "email": "musteri@example.com",
    "bounce_type": "hard",
    "dsn_code": "5.1.1",
    "error_message": "user unknown",
    "timestamp": "2026-09-29T10:12:03+03:00"
  }
}

İmza doğrulama (HMAC-SHA256)

Önerilen: X-SenderTR-Signature: t=<unix>,v1=<hex>. İmza t + "." + ham gövde dizisinin secret'ınızla HMAC-SHA256'sıdır; t 5 dakikadan eskiyse isteği reddedin (yeniden oynatma koruması). Secret webhook oluştururken bir kez gösterilir ve sunucumuzda şifreli saklanır.

// PHP — zaman damgalı imza
$payload = file_get_contents('php://input');
parse_str(str_replace(',', '&', $_SERVER['HTTP_X_SENDERTR_SIGNATURE'] ?? ''), $sig);   // ['t' => ..., 'v1' => ...]
$expected = hash_hmac('sha256', ($sig['t'] ?? '').'.'.$payload, $secret);

if (abs(time() - (int) ($sig['t'] ?? 0)) > 300 || !hash_equals($expected, $sig['v1'] ?? '')) {
    http_response_code(401);
    exit('Geçersiz imza');
}

Eski biçim (X-Webhook-Signature): ham gövdenin tek başına HMAC-SHA256'sı. Geçiş dönemi boyunca gönderilmeye devam eder.

// PHP
$payload   = file_get_contents('php://input');
$signature = hash_hmac('sha256', $payload, $secret);

if (!hash_equals($signature, $_SERVER['HTTP_X_WEBHOOK_SIGNATURE'] ?? '')) {
    http_response_code(401);
    exit('Geçersiz imza');
}

$data = json_decode($payload, true);
// $data['event'], $data['data'] ...

// Node.js (Express, express.raw ile)
const crypto = require('crypto');

app.post('/webhooks/sendertr', express.raw({ type: 'application/json' }), (req, res) => {
  const signature = crypto.createHmac('sha256', SECRET).update(req.body).digest('hex');
  const received  = req.get('X-Webhook-Signature') || '';

  if (!crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(received))) {
    return res.status(401).send('Geçersiz imza');
  }

  const payload = JSON.parse(req.body.toString());
  // payload.event, payload.data ...
  res.sendStatus(200);
});

Yeniden deneme (retry) ve devre dışı bırakma

• Geçici hatalarda — bağlantı hatası, zaman aşımı (10 sn), 5xx, 408, 429 — ilk denemeden sonra 3 kez daha denenir: 10 sn, 60 sn, 300 sn sonra.
• Diğer 4xx yanıtlar kalıcı hata sayılır ve yeniden denenmez.
• Hata sayacı teslimat başına artar: tüm denemeler bittiğinde ya da kalıcı hatada fail_count bir artar; denemeler tek tek sayılmaz.
• 5 ardışık başarısız teslimattan sonra webhook otomatik olarak devre dışı bırakılır ve hesap sahibine e-posta ile bildirilir. Panelden tekrar etkinleştirebilirsiniz; yeniden etkinleştirme ve paneldeki başarılı "Test" sayacı sıfırlar (başarılı test pasif webhook'u da yeniden açar).
• Başarılı teslimat hata sayacını sıfırlar. Sunucunuz 410 Gone dönerse abonelik hata sayılmadan kapatılır.
• Hesap başına en fazla 25 aktif webhook tanımlanabilir (panel ve API'de aynı sınır; API'de 422 limit_reached).

Hızlı yanıt verin: işlemi asenkron yapıp hemen 200 dönmeniz, zaman aşımı kaynaklı gereksiz retry'ları önler.

Gelen E-ticaret Webhook'ları (mağazanız → SenderTR)

POST /webhooks/ecommerce — Mağaza olaylarınızı SenderTR'ye iletin; eşleşen e-ticaret tetikleyicili otomasyonlara kişi otomatik kaydedilir. Yetki: API anahtarı ve contacts:write yetkisi (kişi oluşturur/günceller). Rate limit: 60/dk.

POST https://api.sendertr.com/v1/webhooks/ecommerce/{hesabınıza-özel-anahtar}

Gelir ilişkilendirme

Sipariş olayları (order.*) tutarıyla birlikte kaydedilir ve müşterinin son temas ettiği kampanyaya gelir olarak yazılır: sipariş öncesi 5 gün içinde tıkladığı son kampanya; tıklama yoksa 1 gün içinde açtığı son kampanya. Yalnızca gerçek kişi etkileşimleri sayılır (Apple Mail'in otomatik açılmaları ve güvenlik tarayıcılarının tıklamaları hariç). Sonuç kampanya raporunda gelir, sipariş sayısı, ortalama sepet, alıcı başına gelir ve dönüşüm oranı olarak görünür.

• Aynı sipariş (platform + sipariş numarası) tekrar gelirse yeni kayıt açılmaz; durum ve tutar güncellenir, otomasyon ikinci kez başlamaz.
• İptal (cancelled), iade (refunded), başarısız ve bekleyen siparişler gelirden düşer. WooCommerce'te "Sipariş güncellendi", Shopify'da orders/updated (ve orders/edited) webhook'unu da eklerseniz iadeler otomatik yansır. Aynı olayın tekrar teslimi 2 gün içinde tanınır ve yok sayılır.
• Genel formatta tutar için data.order_id, data.total, data.currency (varsayılan TRY) ve isteğe bağlı data.status, data.ordered_at gönderin.

Dört format desteklenir

1) Generic, 2) WooCommerce, 3) Shopify, 4) ikas. Hangi formatın geldiği başlıklardan veya gövdenin şeklinden anlaşılır. Platformun teslimat kimliğiyle (X-Shopify-Webhook-Id, X-WC-Webhook-Delivery-ID, ikas id) tekrar gelen olay bir kez işlenir ve {"ok": true, "duplicate": true} döner.

1) Generic format

curl -X POST https://api.sendertr.com/v1/webhooks/ecommerce \
  -H "X-Api-Key: YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{
    "event": "order.completed",
    "email": "musteri@example.com",
    "first_name": "Ahmet",
    "data": { "order_id": "10234", "total": 499.90, "currency": "TRY" }
  }'

Desteklenen olaylar ve otomasyon tetikleyici eşlemesi

2) WooCommerce (native)

X-WC-Webhook-Topic başlığı ile gelir; e-posta billing.email alanından okunur. Topic eşlemesi: order.created→sipariş, order.updated→order.completed, customer.created. Webhook oluşturulurken gönderilen ping isteği 200 alır. Panelde WooCommerce kartına webhook "Gizli anahtar"ını girerseniz X-WC-Webhook-Signature (gövdenin HMAC-SHA256'sı, base64) doğrulanır; tutmayan istek 401 invalid_signature alır. WooCommerce sepet terk olayı göndermez; bunun için bir eklentinin webhook'unu veya kendi kodunuzu generic formatta cart.abandoned ile gönderin.

3) Shopify (native)

X-Shopify-Topic başlığı ile gelir; e-posta email veya customer.email alanından okunur. Topic eşlemesi: orders/create→order.created, orders/paid & orders/fulfilled→order.completed, customers/create→customer.created, orders/updated & orders/cancelled→gelir güncellemesi.

Ödeme sayfası ve sepet terk: checkouts/create ve checkouts/update doğrudan sepet terk sayılmaz; ödeme sayfası bekletilir (yanıt: {"ok": true, "tracked": "checkout"}). Paneldeki bekleme süresi (varsayılan 60 dakika, 15 dk – 24 saat) boyunca aynı checkout_token ile sipariş gelmezse cart.abandoned olarak işlenir; müşteri ödeme sayfasında işlem yaptıkça süre yeniden başlar. Kurtarma bağlantısı (abandoned_checkout_url) kişinin cart_recovery_url özel alanına yazılır; otomasyon e-postasında {{cart_recovery_url}} ile kullanılır.

İmza: Panelde Shopify kartına webhook imza anahtarını girerseniz X-Shopify-Hmac-Sha256 doğrulanır; tutmayan istek 401 invalid_signature alır.

4) ikas

Panelde Ayarlar → Entegrasyonlar → ikas kartına özel uygulamanızın Client ID ve Client Secret'ını girdiğinizde webhook'lar (store/order/created, store/order/updated, store/customer/created) hesaba özel adresinize SenderTR tarafından kaydedilir. Gövde {"id", "scope", "merchantId", "data": "<JSON metni>", "signature"} biçimindedir; signature, data metninin Client Secret ile HMAC-SHA256'sıdır (hex) ve zorunlu doğrulanır. Sipariş alanları: orderNumber, customer.email, totalFinalPrice, currencyCode, orderPaymentStatus. ikas sepet terk olayı göndermez.

Başarılı yanıt

HTTP/1.1 200 OK
{
  "ok": true,
  "contact_id": 5012,
  "event": "order.completed",
  "platform": "generic",
  "enrolled": 1,
  "order": {
    "id": "10234",
    "total": 499.9,
    "currency": "TRY",
    "counts_as_revenue": true,
    "attributed_campaign_id": 88,
    "attribution": "click"
  }
}

order yalnızca sipariş olaylarında döner (diğerlerinde null). attributed_campaign_id geliri üstlenen kampanyadır; ilişkilendirilecek kampanya yoksa null, attribution ise click veya open olur.

enrolled = bu olayla kişinin kaydedildiği otomasyon sayısı. Eşleşen tetikleyici yoksa kişi yine oluşturulur/güncellenir ama enrolled: 0 döner.

Diğer 2xx yanıtlar: müşteri e-postası olmayan olay (misafir sipariş vb.) işlenecek kişi olmadığı için { "ok": true, "skipped": "no_email" }; aynı teslimat kimliğiyle tekrar gelen olay { "ok": true, "duplicate": true }; WooCommerce kurulum ping'i { "ok": true, "ping": true }. Planınızın kişi limiti doluysa kişi eklenmez ve 202 { "ok": false, "error": "contact_limit_reached", "message": "…" } döner — 2xx dönmesinin nedeni mağaza platformlarının 4xx/5xx'te webhook'u tekrar deneyip sonunda kapatmasıdır; hesap sahibine ayrıca e-posta bildirimi gider.

Hata yanıtı

HTTP/1.1 422 Unprocessable Content
{ "error": "invalid_payload", "message": "event + email gerekli (generic) veya desteklenen WooCommerce/Shopify/ikas webhook gövdesi." }

HTTP/1.1 422 Unprocessable Content
{ "error": "invalid_email" }

// X-Api-Key ile çağrılan uçta anahtar eksik/geçersiz
HTTP/1.1 401 Unauthorized
{ "error": "invalid_api_key", "message": "Geçersiz veya deaktif API anahtarı." }

// Panelde imza anahtarı tanımlıysa ve WooCommerce/Shopify/ikas imzası tutmuyorsa
HTTP/1.1 401 Unauthorized
{ "error": "invalid_signature", "message": "…" }

// Hesaba özel adresteki anahtar geçersiz
HTTP/1.1 404 Not Found
{ "error": "invalid_token" }

Zapier, Make ve n8n

Otomasyon platformlarından iki yönde bağlanırsınız: akışınız REST API ile e-posta gönderir veya kişi ekler; SenderTR'deki olaylar webhook ile akışınızı başlatır. Hazır Zapier ve Make uygulamaları geliştiriliyor; aşağıdaki yöntemler bugün çalışır.

Bağlantı testi

GET /me (eşdeğeri /account) — Anahtarın ait olduğu hesabı döner; yetki gerektirmez. Platformların "bağlantıyı test et" adımı için.

{
  "data": {
    "account": {"id": 1731, "name": "Firma A.Ş.", "status": "active"},
    "credits": {"balance": 8420, "expires_at": "2027-09-29T23:59:59+03:00"},
    "sending_domains": ["firmaniz.com"],
    "abilities": ["send", "contacts:write", "webhooks"]
  }
}

Webhook aboneliği (REST hook)

Yetki: webhooks. Panelden tanımlanan webhook'larla aynı kayıtlardır; imza, yeniden deneme ve olay kapsamı aynıdır. Hesap başına en fazla 25 aktif abonelik.

Karşı taraf bir teslimata 410 Gone dönerse (akış silinmiş) abonelik kendiliğinden kapatılır.

Platform bazında

• Zapier: Gönderim için Webhooks by Zapier → POST (ücretli planlar) ile /v1/send; tetikleyici için Catch Hook adresini panelde webhook olarak tanımlayın ya da POST /v1/webhooks ile abone olun.
• Make: HTTP → Make a request ile API'yi çağırın; tetikleyici için Custom webhook adresini tanımlayın.
• n8n: HTTP Request düğümü (Header Auth: X-Api-Key); tetikleyici için Webhook düğümünün üretim adresini tanımlayın. İmzayı bir Code düğümünde X-Webhook-Signature ile doğrulayabilirsiniz.

Engel Listesi (API)

Kalıcı geri dönen, şikâyet eden, abonelikten çıkan ve posta kutusu dolu olan adresler hesabınızın engel listesine otomatik eklenir. Listeyi API ile okuyabilir, bir adresin listeden çıkarılmasını talep edebilirsiniz. Çıkarma talepleri ekibimizin onayına düşer. Aynı liste ve talepler panelde Engel Listesi menüsünde de görünür.

Engel gerekçeleri

Listeyi okuma

GET /v1/suppressions?reason=hard_bounce&since=2026-10-01&per_page=100&page=1
X-Api-Key: YOUR_API_KEY

Filtreler isteğe bağlıdır: email, reason, since (bu tarihten sonra eklenenler), per_page (en fazla 500). Yanıt:

{
  "data": [
    {
      "email": "kullanici@ornek.com",
      "reason": "hard_bounce",
      "reason_label": "Kalıcı geri dönme",
      "blocks_transactional": true,
      "created_at": "2026-10-08T14:21:56+03:00",
      "expires_at": null
    }
  ],
  "meta": { "current_page": 1, "per_page": 100, "total": 1, "last_page": 1 }
}

Tek bir adresin durumu: GET /v1/suppressions/{email}. Adres listede değilse 404 ve {"error": "not_suppressed"} döner.

Listeden çıkarma talebi

Adres gerçekten düzeldiyse (ör. kullanıcı posta kutusunu açtı) çıkarma talebi gönderin. Talep ekibimizin onayına düşer; karar hesabınızın kayıtlı e-posta adresine bildirilir ve talebin durumu API'den sorgulanabilir.

POST /v1/suppressions/removal-requests
X-Api-Key: YOUR_API_KEY
Content-Type: application/json

{ "email": "kullanici@ornek.com", "note": "Kullanıcı posta kutusunu düzeltti" }

Talebin durumu: GET /v1/suppressions/removal-requests/{id}. Tüm talepler: GET /v1/suppressions/removal-requests?status=pending. status değerleri: pending (bekliyor), approved (onaylandı, adres listeden çıkarıldı), rejected (reddedildi; gerekçe decision_note alanında).

{
  "data": {
    "id": 42,
    "email": "kullanici@ornek.com",
    "status": "approved",
    "suppression_reason": "hard_bounce",
    "note": "Kullanıcı posta kutusunu düzeltti",
    "decision_note": null,
    "created_at": "2026-10-10T09:00:00+03:00",
    "decided_at": "2026-10-10T10:12:00+03:00"
  }
}

Engel listesindeki bir adrese gönderim denendiğinde API 422 ve {"error": "recipient_suppressed", "suppression_reason": "…"} döner; kredi düşülmez (bkz. Hatalar). Engel listesini güncel tutmanın en kolay yolu webhook ile bounced (bounce_type: "hard") ve complained olaylarını dinlemektir.

SMTP Relay

REST API yerine standart SMTP protokolünü tercih ediyorsanız, transactional e-postalarınızı SenderTR SMTP relay üzerinden gönderebilirsiniz. Mevcut SMTP uyumlu kütüphane/uygulamalarınızla çalışır.

Bağlantı ayarları

Önemli kurallar

• TLS zorunludur — şifresiz (plaintext) kimlik doğrulamaya izin verilmez.
• Gönderim, REST API ile aynı ön kontrollerden geçer: doğrulanmış alan adı, içerik denetimi, hesap ve kimlik aktifliği, günlük/aylık limit, suppression, kredi. SMTP bağlantısı iletiyi kabul eder; bu kontrolde reddedilen ileti gönderilmez ve panelde Transactional → Gönderim Logları'nda nedeniyle görünür.
• Günlük ve aylık limit hesap geneline uygulanır; API ve SMTP gönderimleri aynı limitten düşer.
• Gönderim kimliğiniz askıya alınırsa bağlantı ve giriş çalışmaya devam eder, ancak gönderim 554 5.7.1 SenderTR: SMTP hesabiniz askiya alindi… yanıtıyla reddedilir. Nedeni ve çözümü hesap sahibine e-postayla bildirilir.
• Suppression davranışı transactional kuralıyla aynıdır: unsubscribe serbest, hard_bounce/complaint/manual engellidir.
• Gönderen adresi (From) doğrulanmış gönderim alan adınızda olmalıdır. Başka bir alan adıyla gönderirseniz ileti reddedilmez; From adresi SMTP kimliğinizin (zarf göndereninin) adresiyle değiştirilir, görünen ad korunur. Alıcıda farklı bir gönderen adresi görmek istemiyorsanız kendi alan adınızı kullanın.

Kod örnekleri

PHP (PHPMailer)

use PHPMailer\PHPMailer\PHPMailer;

$mail = new PHPMailer(true);
$mail->isSMTP();
$mail->Host       = 'smtp.sendertr.com';
$mail->Port       = 587;
$mail->SMTPAuth   = true;
$mail->SMTPSecure = PHPMailer::ENCRYPTION_STARTTLS;
$mail->Username   = 'SMTP_KULLANICI_ADINIZ';
$mail->Password   = 'SMTP_SIFRENIZ';

$mail->setFrom('siparis@sirketiniz.com', 'Sirketiniz');
$mail->addAddress('musteri@example.com');
$mail->addReplyTo('destek@sirketiniz.com');
$mail->Subject = 'Siparişiniz alındı';
$mail->isHTML(true);
$mail->Body    = '<h1>Teşekkürler!</h1>';
$mail->AltBody = 'Teşekkürler!';
$mail->send();

Node.js (Nodemailer)

const nodemailer = require('nodemailer');

const transporter = nodemailer.createTransport({
  host: 'smtp.sendertr.com',
  port: 587,
  secure: false,        // 587 + STARTTLS
  requireTLS: true,
  auth: {
    user: 'SMTP_KULLANICI_ADINIZ',
    pass: 'SMTP_SIFRENIZ',
  },
});

await transporter.sendMail({
  from: '"Sirketiniz" <siparis@sirketiniz.com>',
  to: 'musteri@example.com',
  replyTo: 'destek@sirketiniz.com',
  subject: 'Siparişiniz alındı',
  text: 'Teşekkürler!',
  html: '<h1>Teşekkürler!</h1>',
});

Özel başlıklar

İstemcinizin desteklediği standart e-posta başlıklarını (Reply-To, X-* özel başlıklar) ekleyebilirsiniz. SMTP relay iletinizi büyük ölçüde olduğu gibi iletir; DKIM imzasını sistem ekler. İstisnalar: Bcc, Return-Path, Received, X-Originating-IP, DKIM-Signature/DomainKey-Signature, Feedback-ID ve X-SenderTR-* başlıkları atılır (X-SenderTR-Track önce okunur) ve sistem tarafından yeniden yazılır (Bcc alıcılarına zarf üzerinden yine teslim edilir; iç başlıklarımız taklit edilemez). Sender ve Resent-* başlıkları atılır; birden fazla From varsa yalnızca ilki kalır ve From tek bir adres içermelidir (aksi halde zarf göndereniyle değiştirilir). Message-ID tek satır olarak korunur; verdiğiniz kimlik başka bir iletiyle çakışırsa sistem yeni bir kimlik üretir. Yasaklı türde ek (yürütülebilir dosyalar, çift uzantı dahil) taşıyan ileti gönderilmez; panelde failed olarak attachment_type_not_allowed nedeniyle görünür. Ekler gönderimden önce virüs taramasından (ClamAV + Sanesecurity) geçer; zararlı bulunan ek taşıyan ileti gönderilmez, panelde failed görünür ve hesap sahibine bildirim gider. Açılma/tıklama izleme SMTP relay'de isteğe bağlıdır: panelde gönderim hesabı kartındaki SMTP ile gönderilenlere de uygula seçeneği açıksa iletinin HTML bölümüne görünmez piksel eklenir ve bağlantılar takip adresinden geçirilir (düz metin bölümü, ekler ve çok parçalı yapı değişmez; imzalı/şifreli iletilere dokunulmaz). Seçenek açıkken tek bir iletide takibi kapatmak için X-SenderTR-Track: off başlığını ekleyin. Alıcıya giden iletiye Feedback-ID ve X-Report-Abuse başlıkları eklenir. İşlemsel e-postalarda abonelikten çıkma bağlantısı zorunlu değildir; pazarlama içeriği göndermeyin.

Hatalar & Durum Kodları

SenderTR API standart HTTP durum kodlarını kullanır ve tüm hatalarda makinece okunabilir JSON döndürür.

HTTP durum kodları

Hata yanıt yapısı

Her hata aynı zarfla döner: error (makine kodu) + message (Türkçe açıklama) + duruma göre ek alanlar. Doğrulama hatasında errors (alan → mesajlar), hız sınırında retry_after (saniye) eklenir. Yanıtın X-Request-Id başlığını destek talebinize ekleyin.

{
  "error": "daily_limit_exceeded",
  "message": "Günlük gönderim limitiniz doldu.",
  "limit": 5000,
  "used": 5000
}

Bilinen error kodları:

Validation (422) hataları

Alan doğrulama hataları error: "validation_failed", ilk hatayı taşıyan message ve alan→mesaj listesi içeren errors ile döner.

HTTP/1.1 422 Unprocessable Content
{
  "message": "Alıcı zorunludur. (ve 1 hata daha)",
  "errors": {
    "to": ["Alıcı zorunludur."],
    "subject": ["Konu zorunludur."]
  }
}

Rate limit (429) ve Retry-After

Dakikalık HTTP rate limit aşıldığında 429 ile birlikte Retry-After (saniye) ve limit başlıkları döner:

HTTP/1.1 429 Too Many Requests
Retry-After: 38
X-RateLimit-Limit: 300
X-RateLimit-Remaining: 0

{ "message": "Too Many Attempts." }

Bu yanıtta error alanı yoktur; dakikalık limit aşımını HTTP koduna ve Retry-After başlığına bakarak tanıyın.

Günlük gönderim limiti aşımı ise iş kuralı hatasıdır ve farklı gövde döner (yukarıdaki daily_limit_exceeded). İkisini ayırt etmek için yanıt gövdesindeki error alanına bakın.

Yaygın hatalar ve çözümleri

Sıkça Sorulan Sorular

En sık karşılaşılan sorular ve kısa yanıtları. Detay için ilgili bölüme bağlantı verilmiştir.

Hesap & Faturalandırma

Krediler süreli mi, her ay yeniden mi yükleniyor?

Her ay yüklenmez; aylık abonelik yoktur. Her kredi paketi kendi alım tarihinden itibaren 12 ay geçerlidir; yeni paket eski paketin süresini uzatmaz. Hoş geldin kredisi 90 günlük ayrı pakettir. Gönderimler önce süresi en yakın paketten düşer; başarısız gönderim iadesi aynı pakete geri yazılır. Her paket için süre dolmadan 30 ve 7 gün önce e-postayla hatırlatılırsınız; süre dolunca yalnız o paketin kullanılmamış kalanı düşer. Paketlerin kalanı ve son kullanma tarihleri panelde Krediler sayfasında ve API'de GET /v1/me → credits.lots alanında görünür. (Krediler)

Kredim biterse ne olur?

Bakiyeniz alıcı sayısından azsa kampanya otomatik paused olur; kredi yükleyip "Devam Et" ile sürdürürsünüz. API/SMTP işlemsel iletiler kredi yetersizken "Yetersiz kredi" ile başarısız olur ve sonradan otomatik gönderilmez. Kullanım %80/%95/%100 eşiklerinde önceden uyarılırsınız. (Krediler)

Nasıl kredi satın alırım?

Krediler → "Kredi Satın Al" ile PayTR üzerinden (3D Secure) güvenli ödeme yaparsınız. Kart bilgileriniz SenderTR'de saklanmaz. (Krediler)

Gönderim & Teslimat

E-postalarım neden spam'e düşüyor?

En yaygın nedenler: eksik DNS doğrulaması (DKIM/DMARC; SPF isteğe bağlı), kötü liste hijyeni (yüksek bounce/şikayet) ve riskli içerik. Domain sağlık skorunuzu 100'e çıkarın, listenizi doğrulayın ve kampanyada "Spam Skor Kontrol" yapın. (Deliverability)

Kampanyam neden gönderilemiyor / onaya gitmiyor?

Gönderim ön kontrolünde bir "fail" maddesi vardır (DKIM/DMARC geçersiz, içerik/konu boş, alıcı yok, gönderen künyesi eksik veya domain sağlığı düşük; SPF yalnızca uyarıdır). Kampanya formundaki ön kontrol panelinde maddeler canlı listelenir. (Kampanyalar)

Kampanyam neden "İncelemede"?

Kampanyalar otomatik kontrollerden geçer ve sorun yoksa hemen onaylanır. Risk göstergesi taşıyanlar (yüksek güvenlik puanı, yeni hesabın 5.000+ alıcılı ilk gönderimi, ani hacim artışı, son 30 günde eşik aşmış hesap, 30 günden genç alan adı) SenderTR ekibinin incelemesine alınır (hafta içi 09:00–18:00). Nedenler kampanya sayfasında "İncelemede: …" satırında yazar. (Kampanyalar)

Listeye kişi ekledim ama hoş geldin e-postası gitmedi.

Hoş geldin otomasyonu varsayılan olarak yalnızca kayıt formu, çift onay ve API ile kendi isteğiyle abone olanlara gider; panelden eklediğiniz ya da içe aktardığınız kişiler girmez. Panelden eklenenleri de almak için otomasyonu düzenleyip "Kimler bu otomasyona girsin?" altında ilgili kutuyu işaretleyin (izin sorumluluğu sizdedir; günlük sınır uygulanır). Kişi otomasyona girdiği halde e-posta gitmediyse otomasyon sayfasındaki "E-posta sonuçları" kutusunda gönderilemedi nedeni yazar. (Otomasyonlar)

Domainimi doğruladım ama hâlâ "fail" görünüyor.

DNS yayılması birkaç dakika–saat sürebilir. 15–30 dk bekleyip tekrar "DNS Kontrol Et"e basın. Host adında çift domain (ör. _dmarc.domain.com.domain.com) oluşmadığından emin olun: paneliniz alan adını kendisi ekliyorsa domain sayfasında gösterilen kısa adı (ör. _dmarc) kullanın. (Domain & DNS)

En iyi gönderim saati nedir?

Hesabınızın geçmiş açılma verisine göre değişir. "En İyi Zaman" önerisini kullanın veya kişi bazlı optimizasyon için STO'yu açın. Veri yoksa 10:00/14:00/20:00 iyi başlangıçtır. (Gönderim & Zamanlama)

Kişiler & Listeler

Abonelikten çıkan birini tekrar nasıl eklerim?

Suppression koruması kalıcıdır; kişiyi silseniz bile korunur. Tek meşru yol, kişinin kendi isteğiyle (ör. sitenizdeki form üzerinden) yeniden abone olmasıdır. (Suppression)

Hangi dosya formatlarını içe aktarabilirim?

CSV, TXT, Excel (XLSX/XLS) ve JSON. En fazla 50 MB. İçe aktarmada e-posta kolonu eşlemesi zorunludur. (İçe Aktarma)

Liste ile segment arasındaki fark nedir?

Liste sabit (statik) bir kişi grubudur; segment ise kurallara göre her çalıştığında yeniden hesaplanan dinamik bir gruptur. (Segmentler)

Geliştirici / API

API anahtarımı nereden alırım?

Ayarlar → API Anahtarları. Anahtarı oluştururken yetkilerini (gönderim, doğrulama, kişi/liste/kampanya) ve isteğe bağlı izinli IP'leri seçersiniz; anahtar yalnızca bir kez gösterilir. (Kimlik Doğrulama)

API mi SMTP mi kullanmalıyım?

Yüksek hacim ve durum sorgulama için REST API; mevcut SMTP altyapınızı değiştirmeden hızlı entegrasyon için SMTP relay önerilir. İkisi de aynı ön kontrollerden geçer. (SMTP Relay)

Webhook imzasını nasıl doğrularım?

Ham istek gövdesinin secret'ınızla HMAC-SHA256'sını hesaplayıp X-Webhook-Signature ile sabit-zamanlı karşılaştırın. PHP/Node örnekleri için: (Webhook'lar (API))

WooCommerce / Shopify mağazamı bağlayabilir miyim?

Evet. Ayarlar → Entegrasyonlar'dan WooCommerce, Shopify ve ikas mağazanızı bağlayabilir, HubSpot kişilerinizi aktarabilirsiniz. Gelen e-ticaret webhook'u ile sipariş/sepet olaylarını otomasyonlara ve kampanya gelir raporuna aktarırsınız. (Webhook'lar (API))

Gizlilik & Güvenlik

Verilerim güvende mi?

Tüm sunucular Türkiye'dedir; e-posta doğrulaması bile dış servise gönderilmeden yerel yapılır. Yurt dışına çıkan tek veri, kendi isteğinizle açtığınız yapay zekâ yardımcısına yazdığınız metindir (yukarıya bakın). KVKK md.11 kapsamında verilerinizi dışa aktarabilir (/my-data/export) veya silinme/anonimleştirme talep edebilirsiniz. (Ayarlar)

Ekip üyesi davet edebilir miyim?

Evet, Ayarlar → Ekip'ten rol atayarak (Admin/Marketer/Uploader/Viewer) davet edersiniz. Davet 7 gün geçerlidir; davet edebilen yalnızca Owner ve Admin'dir, günde en fazla 20 davet. (Ekip & Roller)

Daha fazla yardım

Aradığınızı bulamadıysanız destek@sendertr.com adresinden veya panel içi destek bölümünden bize ulaşın.