Resend ve SendGrid ile Transactional E-posta Kurulumu

Mobil uygulamanın backend'i kayıt doğrulama kodunu, şifre sıfırlama linkini ya da sipariş bildirimini göndermek zorunda kaldığı anda transactional email resend sendgrid kurulum sorusuyla karşılaşırsın: hangi servis, hangi DNS kaydı, hangi kod. Bu yazı iki servisin resmi dokümantasyonuna birebir dayanarak domain doğrulamadan webhook'a kadar tüm kurulumu, aynı doğrulama-kodu e-postasının iki serviste nasıl gönderildiğini ve teslimat kalitesini gerçek kaynaklarla anlatıyor.

💡 Pro Tip: Domain doğrulaması için kullandığın CNAME kaydını Cloudflare'de "DNS only" (gri bulut) bırak — turuncu proxy açıkken doğrulama tamamlanmaz.

İçindekiler

• Transactional vs Marketing E-posta ve Mobil Backend Akışları
• Domain Doğrulama: SPF, DKIM, DMARC
• Resend Kurulumu
• SendGrid Kurulumu
• Aynı Doğrulama Kodu E-postasının İki Serviste Kodu
• Teslimat Kalitesi: Bounce, Complaint ve Açılma Oranının Gerçek Anlamı
• Karar Çerçevesi: Hacim, Bölge, Takım, Fiyat Modeli
• Test ve İzleme
• SSS
• Resend ile transactional e-posta nasıl gönderilir?
• SPF, DKIM ve DMARC kayıtları neden zorunludur?
• Resend mi SendGrid mi hangi durumda tercih edilmeli?
• Doğrulama kodu e-postası spam'e düşerse ne yapmalıyım?
• Açılma oranı (open rate) neden güvenilmez?
• Webhook'ta hangi event'leri mutlaka dinlemeliyim?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

Transactional vs Marketing E-posta ve Mobil Backend Akışları

Resend'in kendi dokümantasyonu iki gönderim türünü net ayırır: transactional e-posta "kişiselleştirilmiş, olay-tetiklemeli iletişim" (personalized, event-driven communication), marketing kampanyası ise "bir kişi listesine dağıtılan toplu Broadcast" olarak tanımlanır. Mobil backend'inde göreceğin tipik akış şu şekilde işler:

• Kayıt doğrulama: kullanıcı e-posta/telefon ile kayıt olur → backend doğrulama kodu üretir → transactional API çağrısı → kod e-postayla gider.
• Şifre sıfırlama: kullanıcı "şifremi unuttum" der → backend tek kullanımlık token üretir → e-posta gider → link/kod ile doğrulanır.
• Sipariş/olay bildirimi: ödeme veya durum değişikliği backend'de tetiklenir → şablonlu e-posta anında gider.

Bu üç akışın ortak noktası: kullanıcı e-postayı hemen bekliyor, gecikme veya spam klasörüne düşme kullanıcı deneyimini doğrudan kırıyor. Bu yüzden transactional gönderim, marketing bültenlerinden ayrı bir itibar (reputation) ve altyapı ile ele alınır.

Domain Doğrulama: SPF, DKIM, DMARC

Bu üç DNS kaydı, alıcı sunucusuna "bu domain'i gerçekten ben yönetiyorum ve bu postayı ben gönderdim" garantisini verir. Twilio SendGrid'in resmi dokümanı domain authentication'ın dört şeyi kanıtladığını yazıyor: "You own the domain... You permitted the sending email server... You verified the identity of the email sender... You validated that no one tampered with the email message in transit." Yani domain sahipliği, gönderim izni, gönderici kimliği ve mesajın yolda değiştirilmediği garantisi — dört ayrı ispat.

Otomatik güvenlik açıksa Twilio bu kayıtları kendisi oluşturup yönetir: "If you turn on automated security, Twilio creates and maintains SPF, DKIM, and DMARC records on your behalf." Resend tarafında doğrulama süresi resmi dokümana göre genelde hızlı: "your domain will often verify within 15 minutes of adding the DNS records. However, DNS changes can occasionally take up to 72 hours to propagate globally."

Siteni Cloudflare'de yönetiyorsan dikkat etmen gereken tek pratik nokta şu: Resend'in dokümanı açıkça uyarıyor — "make sure not to use proxying features (e.g., Cloudflare's orange cloud) for that record, as it will prevent verification from completing." Yani doğrulama CNAME kaydını eklerken o kaydı DNS only (gri bulut) bırakman gerekiyor, aksi halde doğrulama asla tamamlanmıyor. Bu, sitenin kendi Cloudflare tabanlı altyapısında da doğrudan karşılaşılan bir adım.

Resend ayrıca kök domain yerine alt-domain kullanmanı öneriyor: "We strongly recommend sending emails from a subdomain (e.g., notifications.example.com) instead of your root domain." Böylece transactional trafiğinin itibarı, kurumsal domain'inin genel itibarından ayrışır.

Resend Kurulumu

Resend dokümantasyonuna göre başlamadan önce iki ön koşul var: "Your own domain, verified with Resend" ve "A Resend API key." Kurulum adımları:

1. Domain ekle. Resend domain eklemeyi dört farklı yoldan destekler: Dashboard, Resend API, Resend CLI, Resend MCP server.
2. Alt-domain seç (notifications.example.com gibi) ve önerilen DNS kayıtlarını gir.
3. DNS'i doğrula — proxy'siz (gri bulut) bırakarak, genelde 15 dakika içinde tamamlanır.
4. API key oluştur ve backend ortam değişkenine ekle.
5. Node SDK ile gönder. Güncel resend paketi Node ≥20 gerektiriyor (npm registry: "engines": {"node": ">=20"}, MIT lisanslı).

Resmi örneğin sadeleştirilmiş hali (async/await sarmalayıcı ve konsol logu çıkarıldı, dilin genel değişken adlandırmasına uyacak şekilde apiKey kullanıldı):

1import { Resend } from "resend";
2 
3const resend = new Resend(apiKey);
4 
5const { data, error } = await resend.emails.send({
6  from: "Acme <[email protected]>",
7  to: ["[email protected]"],
8  subject: "Hello World",
9  html: "<strong>It works!</strong>",
10});

API referansına göre emails.send çağrısında dikkat etmen gereken sınırlar var: to alanı en fazla 50 adres kabul ediyor, ekler "Base64 encoding sonrası e-posta başına maksimum 40MB", tag değeri ise 256 karakteri geçemiyor.

SendGrid Kurulumu

SendGrid tarafında akış biraz daha kurumsal: hesap açılır, Sender Identity ya da Domain Authentication tamamlanır, API key üretilir, @sendgrid/mail paketi kurulur. Resmi dokümana göre "recommended for testing only" notuyla Single Sender Verification de kabul ediliyor, ama üretim için Domain Authentication şart.

API'nin çalışma şekli sabit: "The host for Web API v3 requests is always https://api.sendgrid.com/v3/" ve "An API Key must be included in the Authorization header." Toplam mesaj boyutu için de net bir sınır var: "The total message size should not exceed 20MB. This includes the message itself, headers, and the combined size of any attachments."

Güncel @sendgrid/mail paketi (npm registry'de 8.1.6) Node ≥12 gerektiriyor — Resend'in Node ≥20 şartına göre daha eski altyapılarla da uyumlu, bu da eski bir backend'i taşırken pratik bir fark yaratabilir.

Ücretsiz deneme kotası resmi dokümanda net yazıyor (bu yazının yayın tarihi olan 2026-09-16 itibarıyla): "you can start a free trial that allows you to send up to 100 emails per day for 60 days." Bu rakam SendGrid'in kendi planlarına bağlı olarak değişebilir, kurulum öncesi güncel sayfadan teyit et.

1npm install @sendgrid/mail

Kurulum sonrası API key'i ortam değişkeninde saklamalısın; bir sonraki bölümde tam gönderim kodunu göreceksin.

Aynı Doğrulama Kodu E-postasının İki Serviste Kodu

Mobil kayıt akışında en sık ihtiyaç duyduğun e-posta budur: kullanıcıya 6 haneli doğrulama kodu gönderme. İki servisin resmi sözdizimiyle, aynı işi yapan iki kod bloğu:

Resend ile:

1import { Resend } from "resend";
2 
3const resend = new Resend(apiKey);
4 
5const { data, error } = await resend.emails.send({
6  from: "Acme <[email protected]>",
7  to: ["[email protected]"],
8  subject: "Doğrulama Kodun",
9  html: `<strong>Kodun: 482913</strong>`,
10});
11 
12if (error) {
13  console.error(error);
14}

SendGrid ile (resmi Node.js hızlı başlangıç örneğine yakın yapı):

1const sgMail = require("@sendgrid/mail");
2sgMail.setApiKey(apiKey); // process.env üzerinden okunan SendGrid anahtarı
3const msg = {
4  to: "[email protected]",
5  from: "[email protected]",
6  subject: "Sending with SendGrid is Fun",
7  text: "and easy to do anywhere, even with Node.js",
8  html: "<strong>and easy to do anywhere, even with Node.js</strong>",
9};
10sgMail
11  .send(msg)
12  .then(() => {
13    console.log("Email sent");
14  })
15  .catch((error) => {
16    console.error(error);
17  });

İki örnekte de mantık aynı: API key'i ayarla, alıcı/gönderici/konu/gövdeyi tanımla, send çağrısını then/catch ya da try/catch ile sar. Fark, Resend'in { data, error } döndüren tekil obje yaklaşımı, SendGrid'in ise promise tabanlı .then().catch() zinciri kullanması.

Teslimat Kalitesi: Bounce, Complaint ve Açılma Oranının Gerçek Anlamı

Bir e-postayı göndermek yetmiyor; gerçekten ulaştığını, reddedilmediğini ve kullanıcının şikayet etmediğini bilmen lazım. Her iki servis de bunun için webhook zorunlu kılıyor.

SendGrid'in Event Webhook'u üç kategori event üretiyor: "Delivery events that indicate the status of email delivery... Engagement events that indicate how the recipient is interacting... Account change events that indicate changes and impacts to your account." Aynı dokümanda kritik bir gizlilik uyarısı da var: "Never place PII in this field... Twilio employees could see these values. These values get stored long-term even if you leave the Twilio SendGrid platform." Yani webhook payload'ına kullanıcı adı, e-posta içeriği gibi kişisel veri gömmemelisin.

Resend'in webhook event tipleri arasında bounce ve complaint doğrudan var: email.bounced, email.complained, email.delivered, email.delivery_delayed, email.opened, email.clicked, email.failed, email.sent, email.suppressed.

Rate limit aşımında SendGrid 429 döner: "When you reach a rate limit, you can no longer make requests against that endpoint for the remainder of the refresh period, and the API returns a 429 response." Yanıt header'larında X-RateLimit-Limit: 150 ve X-RateLimit-Remaining: 0 gibi bilgiler taşınır — backend'inde retry mantığı kurarken bu header'ları oku.

Açılma oranı (open rate) konusunda dikkat etmen gereken kritik bir nokta var: Apple Mail Privacy Protection. Apple'ın resmi kılavuzu şunu söylüyor: "When this option is selected, your IP address is hidden from senders and remote content is privately downloaded in the background when you receive a message (instead of when you view it)." Yani MPP açık bir cihazda, e-posta okunmasa bile "açıldı" gibi görünebilir çünkü içerik arka planda önceden indiriliyor; gönderici gerçek açılma anını ve IP'yi göremiyor.

Bu, mobil kullanıcı ağırlıklı bir kitlede open-rate metriğini güvenilmez kılıyor. Sitenin kendi Resend entegrasyonunda da bu yüzden click tracking açık, open tracking ise MPP nedeniyle gürültülü kabul ediliyor — karar verirken açılma oranına değil, tıklama oranına güven.

Karar Çerçevesi: Hacim, Bölge, Takım, Fiyat Modeli

Fiyat katmanları zamanla değişiyor, bu yüzden somut $ rakamına karar vermeden önce güncel fiyatlandırma sayfasına bakman daha sağlıklı. Buna karşın nitel olarak karşılaştırabileceğin, dokümanlarla doğrulanmış birkaç eksen var:

• Altyapı yaşı: SendGrid Node SDK gereksinimleri (Node ≥12) daha eski backend'lerle de çalışıyor; Resend Node SDK ise Node ≥20 istiyor — yeni bir backend kuruyorsan bu fark önemsiz, eski bir monolit'e entegre ediyorsan SendGrid'in daha geniş uyumluluğu avantaj olabilir.
• API yüzeyi: Resend, domain eklemeyi Dashboard/API/CLI/MCP server olmak üzere dört yoldan destekliyor — altyapı-as-code yaklaşımı (CLI/MCP) tercih eden takımlar için bu esneklik SendGrid'in dashboard-ağırlıklı akışına göre öne çıkıyor.
• Deneme süresi: SendGrid'in resmi ücretsiz deneme kotası "günde 100 e-posta, 60 gün" — küçük bir mobil MVP'nin doğrulama/şifre-sıfırlama trafiğini test etmek için yeterli bir pencere.
• Ekip büyüklüğü: Domain authentication'ı otomatik SPF/DKIM/DMARC yönetimiyle "arka planda" tutmak isteyen küçük takımlar için Twilio'nun "automated security" özelliği operasyonel yükü azaltıyor.

Aynı eksenleri yan yana koyarsan tablo şöyle görünüyor:

Bu tablo bir "kazanan" ilan etmiyor; iki servis de aynı temel işi (domain doğrulama + API ile gönderim + webhook ile izleme) farklı varsayılanlarla yapıyor. Backend'inin yaşına, takımının altyapı tercihine ve deneme sürecine göre seçim yapman daha sağlıklı.

Somut rakam ya da bölgesel fiyat karşılaştırması istiyorsan, karar öncesi resmi fiyatlandırma sayfasını güncel tarihle kontrol et — buradaki karşılaştırma yalnız doğrulanmış teknik eksenlere dayanıyor.

Test ve İzleme

Kurulumdan sonra en çok atlanan adım izlemedir. Pratik bir kontrol listesi:

• Webhook endpoint'ini erkenden bağla. Bounce ve complaint event'lerini production'a çıkmadan önce görebilmelisin; aksi halde geçersiz bir adrese gönderdiğin her e-posta sessizce kaybolur.
• Log'u backend tarafında tut. Hangi kullanıcıya, hangi template'le, ne zaman e-posta gittiğini kendi veritabanında da tut — servis tarafındaki event geç gelebilir ya da webhook geçici olarak düşebilir.
• Rate limit header'larını izle. SendGrid'in X-RateLimit-Remaining header'ı sıfıra yaklaşınca, kuyruğa alıp yeniden deneme (retry) mantığı devreye girmeli.
• PII'yi webhook payload'ından uzak tut. SendGrid'in kendi dokümanı bu konuda net uyarıyor; kullanıcı e-posta içeriğini ya da adını event meta verisine gömme.

İki servisin webhook payload şekli birbirinden farklı, bu yüzden alıcı kodunu ayrı yazman gerekiyor: Resend her isteğe tek bir JSON event objesi ({ "type": ..., "data": { ... } }) POST ederken, SendGrid bir event dizisi gönderir ve alan adı type değil event'tir ("bounce", "spamreport" gibi). İkisini aynı kod bloğunda for...of ile dolaşmaya çalışmak Resend isteğinde çalışma zamanı hatasına yol açar.

1// Resend webhook alıcısı (Express) — tek bir event objesi POST edilir
2app.post("/webhooks/resend", (req, res) => {
3  const event = req.body;
4  if (event.type === "email.bounced" || event.type === "email.complained") {
5    // kullanıcı kaydını işaretle, tekrar gönderim listesine ekleme
6  }
7  res.status(200).send("ok");
8});

1// SendGrid Event Webhook alıcısı (Express) — bir event DİZİSİ POST edilir
2app.post("/webhooks/sendgrid", (req, res) => {
3  const events = req.body;
4  for (const e of events) {
5    if (e.event === "bounce" || e.event === "spamreport") {
6      // kullanıcı kaydını işaretle, tekrar gönderim listesine ekleme
7    }
8  }
9  res.status(200).send("ok");
10});

Resend tarafında üretime almadan önce webhook imza doğrulamasını da kurman gerekiyor; aksi halde payload'ın gerçekten Resend'den geldiğini garanti edemezsin. 9-11 Eylül 2026'da eklenen rotateSigningSecret() metodu (Node SDK) ve MCP server'daki rotate-webhook-signing-secret aracı, imza sırrını sızdırdığını düşündüğünde panelde tıklamadan rotasyon yapmanı sağlıyor — özellikle CI/CD ya da otomasyon akışlarında panel bağımlılığını ortadan kaldırıyor.

Rate limit tarafında da benzer bir sağlamlık gerekiyor: SendGrid 429 döndüğünde X-RateLimit-Remaining: 0 header'ını görürsün; bu durumda isteği hemen tekrar denemek yerine üstel geri çekilme (exponential backoff) uygulaman ve her gönderim isteğine kendi ürettiğin bir idempotency anahtarı (ör. kullanıcı ID + işlem tipi + zaman damgası) eklemen gerekir. Böylece ağ zaman aşımı ya da retry sırasında aynı doğrulama kodunu kullanıcıya iki kez göndermemiş olursun; e-posta servislerinin kendisi bu tekilleştirmeyi senin için yapmaz.

SSS

Resend ile transactional e-posta nasıl gönderilir?

Önce domain'ini Resend'de doğrularsın (alt-domain önerilir, DNS kaydı proxy'siz bırakılmalı), API key oluşturursun, sonra Node SDK'da resend.emails.send({ from, to, subject, html }) çağrısını yaparsın. Resmi dokümana göre doğrulama "genelde 15 dakika içinde" tamamlanıyor.

SPF, DKIM ve DMARC kayıtları neden zorunludur?

Çünkü alıcı sunucusu bu kayıtlar olmadan senin domain'in adına gönderilen postanın gerçek mi sahte mi olduğunu ayırt edemez. SendGrid'in resmi tanımına göre bu kayıtlar domain sahipliğini, gönderim iznini, gönderici kimliğini ve mesajın yolda değiştirilmediğini kanıtlar.

Resend mi SendGrid mi hangi durumda tercih edilmeli?

Yeni ve modern bir Node backend kuruyorsan (Node ≥20), API/CLI/MCP tabanlı altyapı-as-code akışı istiyorsan Resend daha uygun. Eski bir backend'e (Node ≥12 yeterli) entegre ediyorsan ya da kurumsal automated security (otomatik SPF/DKIM/DMARC yönetimi) istiyorsan SendGrid'in daha köklü Twilio altyapısı avantaj sağlayabilir.

Doğrulama kodu e-postası spam'e düşerse ne yapmalıyım?

Önce domain authentication'ının tamamlandığını (SPF/DKIM/DMARC yeşil) doğrula, sonra kök domain yerine alt-domain kullandığından emin ol, son olarak webhook'tan gelen bounce/complaint oranına bak — yüksekse gönderim listeni ve şablonunu gözden geçir.

Açılma oranı (open rate) neden güvenilmez?

Çünkü Apple Mail Privacy Protection açık cihazlarda içerik, kullanıcı okumadan önce arka planda indiriliyor; bu da gerçek okunmamış postaların bile "açıldı" görünmesine yol açıyor. Bu yüzden tıklama oranı (click rate) daha güvenilir bir sinyal.

Webhook'ta hangi event'leri mutlaka dinlemeliyim?

En azından bounce ve complaint event'lerini (Resend'de email.bounced/email.complained, SendGrid'de delivery/engagement event'leri) — bunlar olmadan geçersiz adreslere göndermeye devam edip itibarını kaybedebilirsin.

Güncelleme (Eylül 2026)

Bu yazı 2026-09-16 itibarıyla güncel; yayın öncesi son üç haftada her iki serviste de takip etmeye değer şu değişiklikler oldu:

• Resend — webhook imza sırrı rotasyonu (9-11 Eylül 2026). Node SDK'ya rotateSigningSecret() metodu ve MCP server'a rotate-webhook-signing-secret aracı eklendi; webhook oluşturma akışı da get-webhook uç noktasına yönlendirildi. Üretimde imza sırrını sızdırdığını düşünüyorsan artık panelde tıklamadan, kod veya MCP aracından rotasyon yapabiliyorsun.
• Resend — Broadcast/Template kırık link kontrolü (3 Eylül 2026). Toplu gönderim öncesi kırık, eksik veya placeholder link kontrolü eklendi — bu, transactional tarafını değil marketing Broadcast akışını ilgilendiriyor ama aynı hesaptan yönetiyorsan bilmen faydalı.
• Resend — takım girişinde SSO (1 Eylül 2026). IdP ile SSO girişi etkinleştirildi; birden fazla kişinin API key/domain yönettiği takımlarda erişim kontrolünü kolaylaştırıyor.
• SendGrid — Link Branding'e otomatik SSL (27 Ağustos 2026). Twilio, branded link'ler için auto_ssl parametresi ve auto_ssl_available alanını duyurdu; bunun gerekçesi Gmail'in HTTPS olmayan linklere 2026 Ekim sonuna kadar uyarı göstermeye başlayacak olması. E-postalarında branded link kullanıyorsan bu ayarı kontrol etmen öneriliyor.

Bu değişikliklerin hiçbiri yukarıdaki temel kurulum adımlarını (domain doğrulama, API key, emails.send/sgMail.send çağrıları) geçersiz kılmıyor; webhook ve link güvenliği tarafında ek sağlamlaştırma sağlıyorlar.

Sonuç

Resend ve SendGrid'in ikisi de mobil backend'inin doğrulama kodu, şifre sıfırlama ve sipariş bildirimi e-postalarını güvenilir şekilde gönderebiliyor; asıl fark kurulum felsefesinde ve ekosistemde. Domain doğrulamasını (SPF/DKIM/DMARC) doğru kurmak, alt-domain kullanmak ve webhook'tan gelen bounce/complaint sinyalini dinlemek, servis seçiminden daha kritik. Backend tarafında ağ katmanını sağlamlaştırmak istiyorsan network layer optimizasyonu rehberine, senkronize veri akışları için CloudKit senkronizasyon yazısına, serverless bir backend değerlendiriyorsan Supabase Edge Functions rehberine veya Hono.js production rehberine bakabilirsin. Genel güvenlik sertleştirmesi için iOS Security Best Practices ve backend tarafında offline-first desenler için Firebase İleri Seviye yazıları da işine yarayabilir. İki servisi tablo halinde yan yana karşılaştırmak istersen /comparisons/resend-vs-sendgrid/ sayfasına göz at.

Kaynaklar

• Resend Introduction — transactional/marketing ayrımı ve ön koşullar.
• Resend — Add a Domain — alt-domain önerisi, doğrulama süresi, Cloudflare proxy uyarısı.
• Resend — Send with Node.js — resmi emails.send kod örneği.
• Resend — Webhook Event Types — bounce/complaint/delivery event listesi.
• Twilio SendGrid — Domain Authentication — dört maddelik doğrulama tanımı, automated security.
• Twilio SendGrid — Node.js Quickstart — resmi sgMail.send kod örneği, ücretsiz deneme kotası.
• Twilio SendGrid — Getting Started with the API — API host ve mesaj boyutu sınırı.
• Twilio SendGrid — Event Webhook — event kategorileri, PII uyarısı.
• Twilio SendGrid — Rate Limits — 429 yanıtı ve rate limit header'ları.
• Apple — Mail Privacy Protection (Mac) — MPP'nin IP gizleme ve arka plan indirme davranışı.
• Twilio — SSL for Branded Links — Eylül 2026 otomatik SSL güncellemesi.
• Resend Node SDK v6.27.0 release — 9 Eylül 2026, rotateSigningSecret() eklendi.
• Resend MCP v2.20.0 release — 10 Eylül 2026, rotate-webhook-signing-secret aracı.
• Resend MCP v2.20.1 release — 11 Eylül 2026, webhook oluşturma get-webhook uç noktasına yönlendirildi.
• Resend Changelog — Broadcast link kontrolü (3 Eylül) ve SSO (1 Eylül) duyuruları.