Uygulamanızdan E-posta Nasıl Gönderilir (ve Gelen Kutusuna Nasıl Ulaşılır)

Uygulamanızdan e-postaları güvenilir biçimde göndermek için kendi posta kutunuz yerine bir e-posta gönderim sağlayıcısı kullanın, kendi alan adınızdaki bir adresten gönderin ve sağlayıcının verdiği DNS kayıtlarını ekleyerek SPF, DKIM ve DMARC'ın hepsinin geçmesini sağlayın. İşlemsel e-postaları (şifre sıfırlamalar, makbuzlar, onaylar) pazarlama e-postalarından ayrı tutun, her birini yalnızca bunu bekleyen kişilere gönderin ve geri dönen mesajları ile abonelikten çıkmaları yönetin. Önce kimlik doğrulamayı doğru kurun; uygulama e-postalarının spam’e düşmesinin en yaygın nedeni budur.

İşlemsel e-posta ile pazarlama e-postası

Bu iki e-posta türü koda bakıldığında benzer görünür ancak gelen kutusu sağlayıcıları ve yasalar tarafından çok farklı ele alınır.

Bunları birbirinden ayırın. Bir pazarlama kampanyası spam şikâyeti alırsa, aynı akıştaki şifre sıfırlamaların bundan zarar görmesini istemezsiniz. Yaygın yaklaşım ayrı alt alan adları kullanmaktır; örneğin hesap e-postaları için mail.example.com, bültenler için news.example.com. Bazı sağlayıcılar ikisini kendi içlerinde de ayırır. Örneğin Postmark, Eylül 2026 itibarıyla işlemsel ve yayın “mesaj akışlarını” ayrı gönderim altyapılarında çalıştırdığını belirtiyor.

Sağlayıcı seçimi

Uygulamanız e-postayı kendi sunucusundan doğrudan göndermemelidir. Gönderim sağlayıcıları altyapıyı, IP itibarını, yeniden denemeleri ve geri dönen mesajların işlenmesini üstlenir. Bilinen seçenekler arasında Postmark, Resend, SendGrid, Amazon SES ve Mailgun bulunur; her birinin bir HTTP API’si ve SMTP erişimi vardır. Fiyatlar ve planlar değişir, bu yüzden karşılaştırmayı kendi sitelerinden yapın.

Karşılaştırırken bakılacaklar:

• Odak. Bazı sağlayıcılar yalnızca işlemsel e-postaya odaklanır; bazıları işlemsel ve pazarlamayı birlikte sunar.
• Geliştirici deneyimi. Net bir API, kullandığınız dil için resmi kütüphaneler, her mesajın teslim edilip edilmediğini, geri dönüp dönmediğini ya da spam olarak işaretlenip işaretlenmediğini gösteren kullanışlı kayıtlar.
• Webhook’lar: geri dönen mesajlar, şikâyetler ve teslimatlar için; böylece uygulamanız tepki verebilir.
• Şablonlar: sağlayıcıda mı yoksa kendi kodunuzda mı saklanacakları. Şablonları kodda tutmak onların sürümlenmesini ve test edilebilmesini sağlar.
• Bölge ve veri işleme, verilerin nerede işlendiğiyle ilgili gereksinimleriniz varsa.
• Hacminizdeki maliyet, ücretsiz katmanı aştığınızda ne olacağı dahil.

Bir listeye bülten göndereceksiniz ise, kampanya özelliklerini uygulamanıza eklemekten çok, özel bir bülten ya da e-posta pazarlama aracı genellikle daha uygun olur.

Gönderim alan adınızı kurun

Kendi alan adınızdan gönderin: hello@example.com, Gmail ya da Outlook adresinden değil. Üçüncü taraf bir hizmet üzerinden ücretsiz bir posta kutusu adresiyle gönderilen e-postalar kimlik doğrulama kontrollerinden geçemez ve büyük ihtimalle filtrelenir.

Sadece gönderim için bir alt alan adı kullanmayı düşünün. Örneğin Resend, gönderim itibarını izole etmek için updates.example.com gibi alt alan adlarından gönderim yapılmasını önerir (Eylül 2026 itibarıyla). Bu, e-posta DNS kayıtlarınızı ana sitenizin kayıtlarından da ayrı tutar.

Sağlayıcı, alan adınızın DNS’inin yönetildiği yere eklemeniz için DNS kayıtları verir. DNS sizin için yeniyse, alan adları ve DNS nasıl çalışır önce kayıt türlerini açıklar.

SPF

SPF (Sender Policy Framework), alan adınız adına hangi sunucuların e-posta gönderebileceğini listeleyen bir TXT kaydıdır. Alıcılar gönderen sunucunun listede olup olmadığını kontrol eder.

• Bir alan adının yalnızca bir SPF kaydı olmalıdır. Bir sağlayıcı eklerseniz, ikinci bir kayıt eklemek yerine mevcut kayda birleştirin.
• SPF değerlendirilirken en fazla 10 DNS sorgusuna izin verir; uzun include: zincirleri bu sınırı aşıp hatalara yol açabilir.
• Birçok sağlayıcı SPF’yi, sizden oluşturmanızı istediği bir return-path alt alan adında ayarlar; bu yüzden ana SPF kaydınıza hiç dokunmanız gerekmeyebilir.

DKIM

DKIM (DomainKeys Identified Mail), her mesaja kriptografik bir imza ekler. Sağlayıcı özel bir anahtarla imzalar; siz karşılık gelen genel anahtarı bir DNS kaydı olarak yayınlarsınız (sağlayıcıya bağlı olarak TXT ya da CNAME). Alıcılar imzayı kontrol ederek mesajın yetkili bir gönderenden geldiğini ve yolda değiştirilmediğini doğrular.

Sağlayıcınızın “alan adını doğrula” adımı büyük ölçüde DKIM ile ilgilidir. Bunu atlamayın.

DMARC

DMARC diğer ikisini birbirine bağlar. _dmarc.alanadiniz.com adresinde bir TXT kaydıdır ve alıcılara şunları söyler:

• Hizalama: görünen Gönderen adresindeki alan adı, SPF veya DKIM’i geçen alan adıyla eşleşmelidir.
• Politika: başarısız olan postayla ne yapılacağı — p=none (yalnızca raporla), p=quarantine (şüpheli say, çoğunlukla spam) ya da p=reject.
• Raporlar: toplu raporların nereye gönderileceği (rua=); böylece alan adınız adına kimin gönderim yaptığını görebilirsiniz.

Mantıklı yol, p=none ve bir rapor adresiyle başlamak, meşru postalarınızın geçtiğini doğrulamak, sonra quarantine’a ve en sonunda reject’e geçmektir. Sıkı bir politika, başkalarının alan adınızı taklit etmesini de çok daha zorlaştırır.

Gmail’in istedikleri

Eylül 2026 itibarıyla Google’ın gönderen yönergeleri şunları söylüyor:

• Tüm gönderenler kişisel Gmail hesaplarına gönderirken SPF veya DKIM’e, gönderen sunucular için geçerli ileri ve geri DNS kayıtlarına, TLS’e ve Postmaster Tools’ta 0,3%’in altındaki bir spam oranına ihtiyaç duyar.
• Toplu gönderenler (Gmail’e günde 5.000’den fazla mesaj) SPF ve DKIM’e, bir DMARC kaydına (p=none politikasına izin verilir), Gönderen alan adı hizalamasına ve pazarlama ile abonelik mesajlarında tek tıkla abonelikten çıkma ile görünür bir abonelikten çıkma bağlantısına ihtiyaç duyar.

Sunucu tarafındaki kısımları sağlayıcınız üstlenir. DNS kayıtları ve abonelikten çıkma yönetimi ise sizin sorumluluğunuzdadır. Günde 5.000’e yaklaşmış olmasanız bile, toplu gönderen kurallarını karşılamak güvende olmanın en basit yoludur.

Gönderimi uygulamanıza ekleyin

Alan adı doğrulandıktan sonra:

1. API anahtarını sunucu tarafı bir gizli bilgi olarak saklayın; asla ön yüz kodunda değil. Bkz. ortam değişkenleri ve gizli bilgiler nedir.
2. Sunucudan gönderin; e-postayı tetikleyen eylem başarıyla tamamlandıktan sonra.
3. Kullanıcıyı e-postayı beklemeye zorlamayın. En basit uygulamalar dışında, gönderimi bir kuyruğa alın ve geçici hatalarda yeniden deneyin; böylece yavaş bir sağlayıcı yanıtı kayıt olmayı yavaşlatmaz.
4. Sonucu kaydedin: sağlayıcının mesaj kimliğini ve durumunu; anahtarı ya da kişisel veri içeren tam mesaj gövdelerini kaydetmeden.
5. Geri dönen mesajlar ve şikâyetler için webhook’ları yönetin: kalıcı olarak geri dönen ya da sizi spam olarak işaretleyen adreslere göndermeyi durdurun.

Temelleri kapsayan bir istem:

[PROVIDER] ile işlemsel e-posta gönder; sunucu gizli bilgisi [ENV_NAME] kullanılarak, "Acme hello@mail.acme.com" adresinden. Kayıt olduktan sonra bir hoş geldin e-postası, bir rezervasyon kaydedildikten sonra bir rezervasyon onayı gönder. Şablonları kodda tut; HTML ile birlikte düz metin sürümünü de ekle. Gönderimleri kuyruğa al ve geçici hataları en fazla üç kez yeniden dene. Hataları sağlayıcının hata mesajıyla kaydet ama API anahtarını asla kaydetme. Kalıcı geri dönüşlerde ve şikâyetlerde adresleri teslim edilemez olarak işaretleyen bir webhook uç noktası ekle ve bu adresleri ileride atla.

Hesap e-postaları (doğrulama bağlantıları, sihirli bağlantılar ve şifre sıfırlamalar) giriş sürecinin bir parçasıdır. Uygulamanıza giriş nasıl eklenir bu akışların nasıl birbirine oturduğunu anlatır; bu bağlantıları tek kullanımlık ve kısa ömürlü yapın.

Teslimat alışkanlıkları

Kimlik doğrulama sizi dikkate alınır hale getirir. Davranışınız ise sizi gelen kutusunda tutar.

• Yalnızca insanların beklediği şeyleri gönderin. Onaylanmış kayıtlar, pazarlama için açık onay, satın alınmış listeler yok.
• Abonelikten çıkmayı kolaylaştırın; kesinlikle işlemsel olmayan her şeyde ve bunu hemen uygulayın.
• Yeni alan adlarını ısıtın. Yepyeni bir alan adının ilk gün binlerce mesaj göndermesi şüpheli görünür. İşlemsel postalarla başlayın ve hacmi kademeli olarak artırın.
• Listeleri temiz tutun. Kalıcı geri dönüşleri hemen kaldırın ve uzun süredir hiçbir şeyi açmamış kişileri çıkarmayı düşünün.
• İnsan gibi yazın. Net bir konu satırı, tanınabilir bir Gönderen adı, düz metin bölümü, az görsel ve kendi alan adınıza giden bağlantılar. Bağlantı kısaltıcılarından kaçının.
• İzleyin. Alan adınızı Google Postmaster Tools’a ekleyin ve ara sıra DMARC raporlarını okuyun.
• Gerçek bir yanıt adresi kullanın, birinin okuduğu bir adres. Yanıtlar iyi bir sinyal ve faydalı geri bildirimdir.

Kimseyi spamlamadan test etmek

• Sağlayıcınızda varsa test modunu ya da sandbox’ını kullanın ya da kendinize ait adreslere gönderin.
• Geliştirme sırasında gerçek kullanıcılar yerine tüm gelen postaları yakalayan bir test gelen kutusuna gönderin; gerçek görünümlü adreslerle dolu bir veritabanı, yanlışlıkla yabancılara e-posta göndermenin kolay bir yoludur.
• Her şablonu birkaç istemcide kontrol edin — web’de Gmail, bir telefondaki posta uygulaması, Outlook — ve karanlık modda.
• Bir test e-postasının mesaj başlıklarına bakın: SPF, DKIM ve DMARC’ın geçip geçmediğini gösterirler.

Yasal temeller

Kurallar ülkeden ülkeye değişir. Genel olarak pazarlama e-postası birçok yerde onay gerektirir, göndereni tanımlamalı ve çalışan bir abonelikten çıkma seçeneği sunmalıdır; işlemsel e-posta farklı ele alınır ama pazarlama içeriğini gizlice eklemek için kullanılmamalıdır. Bekleme listesi sayfasından adres topluyorsanız, hangi kişilere neyi, ne zaman ve nasıl göndereceğinizi ve kaydı nasıl aldığınızı belirtin. Emin değilseniz, kullanıcılarınızın bulunduğu ülkedeki kuralları kontrol edin.

E-posta kontrol listesi

• Gönderim sağlayıcısı seçildi; API anahtarı sunucu gizli bilgisi olarak saklanıyor
• Kendi alan adınızdan ya da alt alan adınızdan gönderiliyor, ücretsiz bir posta kutusundan değil
• SPF, DKIM ve DMARC kayıtları eklendi ve geçiyor
• İşlemsel ve pazarlama postaları ayrıldı
• Gönderimler kuyruğa alındı ve yeniden deneniyor; sonuçlar kaydediliyor
• Geri dönüş ve şikâyet webhook’ları yönetiliyor
• İşlemsel olmayan postalarda abonelikten çıkma var ve hemen uygulanıyor
• Şablonlar birkaç istemcide test edildi; test postaları gerçek kullanıcılara ulaşmıyor

Bir Mythex uygulamasından e-posta göndermek

Mythex, oluşturduğunuz uygulamalar için yerleşik bir e-posta gönderim hizmeti içermez; bu yüzden Resend, SendGrid ya da Postmark gibi bir sağlayıcıyı kendiniz getirirsiniz. API anahtarını bir proje gizli bilgisi olarak saklayın — ajan sohbette bir gizli bilgi kartıyla bunu isteyebilir — ve ihtiyacınız olan e-postaları düz sözlerle isteyin. Dokümanlarda uygulamanızdan e-posta gönderme bölümünde bir başlangıç istemi var. Alan adınızı Pro’da Mythex üzerinden satın aldıysanız, sağlayıcının TXT ve CNAME kayıtlarını alan adının DNS ayarlarına ekleyebilirsiniz; bkz. özel alan adları.

Sorular