Email Routing

Email Routing nedir?

“Cloudflare Email Routing is a free, private service for creating custom email addresses and forwarding messages to any inbox, protecting your primary email from spam.”

Çözdüğü problem basit: bir alan adın var ama posta sunucun yok. Email Routing, alan adının MX’ini Cloudflare’e yönlendirip bilgi@sirketim.com.tr adresini zaten sahip olduğun bir kutuya (Gmail, Outlook, Yandex) iletiyor. Posta sunucusu yok, kutu barındırma yok, kullanıcı başına lisans yok.

Nasıl çalışır?

Ön koşul

“You must be using Cloudflare DNS to use Email Service.”

Kayıt kuruluşunun kim olduğu önemsiz. .com.tr alan adın TRABIS akredite bir operatörde kalabilir; yeter ki nameserver’ları Cloudflare’e çevirmiş ol (full setup).

Kurallar ve hedef adresler

Bir kural, bir e-posta desenini tek bir hedefe bağlıyor.

Üç aksiyon:

“Send to an email: Emails will be routed to your destination address.” “Send to a Worker: Emails will be processed by the logic in your Worker.” “Drop: Deletes emails matching the rule without routing them. This can be useful if you want to make an email address appear valid for privacy reasons.”

Hedef adres doğrulaması:

“Destination addresses are shared at the account level and can be reused with any other domain in your account.”

“Until a destination address is verified, any routing rule that points to it stays disabled.”

“Deleting a destination address automatically disables all routing rules that use that address as a destination.”

API’de verified alanı bir boolean değil, zaman damgası: “The date and time the destination address has been verified. Null means not verified yet.”

Belgelenmiş eşleşme sırası: kural eşleşmesi → (subaddressing açıksa alt adresler temel kurala düşüyor) → hiçbiri eşleşmezse ve catch-all açıksa catch-all.

Subaddressing (RFC 5233) varsayılan kapalı: “If a routing rule for user+detail@example.com already exists, it takes precedence over the rule for user@example.com.”

Oluşturulan DNS kayıtları

MX  sirketim.com.tr                      route1.mx.cloudflare.net
MX  sirketim.com.tr                      route2.mx.cloudflare.net
MX  sirketim.com.tr                      route3.mx.cloudflare.net
TXT sirketim.com.tr                      "v=spf1 include:_spf.mx.cloudflare.net ~all"
TXT cf2024-1._domainkey.sirketim.com.tr  "v=DKIM1; h=sha256; k=rsa; p=..."

Kayıtlar kilitleniyor:

“When Email Service onboarding succeeds, the DNS records it manages are locked to prevent accidental changes that would break mail flow.”

“Only Email Routing records on the root domain (MX, SPF, and DKIM) support unlocking. Email Sending records on the cf-bounce subdomain stay managed by Email Service for the lifetime of the domain configuration.”

Subdomain desteği var: zone başına toplam 30 alan adı (routing + sending, apex dahil).

Gelen e-posta hattı

Aşamalar: SMTP alımı → kimlik doğrulama kontrolü → kural eşleşmesi → aksiyon → ARC imzası ve SRS yeniden yazımı → giden teslimat → son durum.

SRS ve ARC: Cloudflare yönlendirmenin SPF’i bozma sorununu SRS ile çözüyor — zarf MAIL FROM adresini yeniden yazıyor ama From: başlığına dokunmuyor. ARC ile de zincirdeki doğrulama sonucunu imzalıyor.

Email Workers

export default {
  async email(message, env, ctx): Promise<void> {
    await message.forward("hedef@ornek.com");
  },
} satisfies ExportedHandler<Env>;

Python de destekleniyor (class Default(WorkerEntrypoint) içinde async def email).

ForwardableEmailMessage arayüzü:

interface ForwardableEmailMessage {
  readonly from: string;        // zarf MAIL FROM
  readonly to: string;          // zarf RCPT TO
  readonly headers: Headers;
  readonly raw: ReadableStream;
  readonly rawSize: number;
  readonly canBeForwarded: boolean;
  setReject(reason: string): void;
  forward(rcptTo: string, headers?: Headers): Promise<EmailSendResult>;
  reply(message: EmailMessage): Promise<EmailSendResult>;
}

İki uyarı: canBeForwarded yalnızca bu tek yorumda geçiyor, anlamı belgelenmemiş. Ve eski runtime API sayfası forward() ile reply()’ı Promise<void> olarak tipliyordu; güncel doküman Promise<EmailSendResult> diyor — gerçek bir imza değişikliği.

forward(): hedef önceden doğrulanmış olmalı. “Only headers with an X- prefix can be added through forward(). Other headers are removed.”

reply() gereksinimleri:

“The incoming email must have a valid DMARC result. · An email can only be replied to once per EmailMessage event. · The recipient in the reply must match the sender of the incoming email. · The outgoing sender domain must match the domain that received the email. · The reply is rejected if the incoming email has more than 100 entries in its References header, to prevent reply loops and abuse.”

send_email binding’i dört modda: kısıtsız (doğrulanmış hedeflere), destination_address, allowed_destination_addresses, allowed_sender_addresses.

Gönderim yapabiliyor mu?

Ne zaman kullanılır, ne zaman kullanılmaz

Kullanılır

• Alan adında adres istiyorsan ama posta sunucusu istemiyorsan. Ürünün tam hedefi bu.
• Rol adreslerini tek kutuda topluyorsan — bilgi@, destek@, fatura@ hepsi tek yere.
• Gizlilik için tek kullanımlık adresler üretiyorsan. drop aksiyonu bir adresi “geçerli görünen ama hiçbir yere gitmeyen” hâle getiriyor.
• Gelen e-postayı programatik işlemek istiyorsan. Email Workers, destek talebi açma, otomatik yanıt ve arşivleme için gerçekten güçlü.

Kullanılmaz

Posta kutusuna ihtiyacın varsa. Depolama yok, IMAP yok, POP yok, webmail yok. Dokümanın tamamında “IMAP” ve “POP3” sıfır kez geçiyor.

Normal bir posta istemcisinden alan adın olarak göndermek istiyorsan. Yanıtların Gmail adresinden çıkıyor.

Başka bir MX ile birlikte çalıştırmak istiyorsan. “Cannot use Email Routing with external mail servers.” Bir apex’in tek MX sahibi olabiliyor.

Katı DMARC politikası olan gönderenlerden e-posta bekliyorsan. SRS ve ARC yardımcı oluyor ama “restrictive DMARC policies might make forwarded emails fail to be delivered.”

Kimlik doğrulaması yapmayan eski gönderenlerin var. 3 Temmuz 2025’ten beri SPF veya DKIM zorunlu; ikisi de başarısızsa reddediliyor ve senin haberin olmuyor.

Teslimat hatalarını izlemen kritikse. “Email Routing does not forward non-delivery reports to the original sender.” Bazı başarısızlıklar kimseye görünmüyor.

Spam filtresi bekliyorsan. Geliştirici dokümanları spam filtrelemeyi yalnızca senin bir Worker’da yazacağın bir şey olarak anlatıyor. Pazarlama sayfasındaki “phishing detection” iddiası dokümanlarda hiçbir yerde desteklenmiyor.

Pazarlama e-postası göndereceksen. “Email Service is intended only for transactional emails.”

Yerel kısmında Türkçe karakter kullanacaksan. piñata@piñata.es desteklenmiyor.

Somut örnekler

Kurulum

AUTH=(-H "Authorization: Bearer $CF_API_TOKEN" -H "Content-Type: application/json")

# 1) Hedef adresi ekle (hesap seviyesinde) — doğrulama e-postası gidiyor
curl -sS "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/email/routing/addresses" \
  --request POST "${AUTH[@]}" --data '{"email":"benim@gmail.com"}' | jq '.result'

# 2) DNS kayıtlarını oluştur ve routing'i aç
curl -sS "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/email/routing/dns" \
  --request POST "${AUTH[@]}" | jq '.result'

# 3) Kural oluştur
curl -sS "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/email/routing/rules" \
  --request POST "${AUTH[@]}" --data '{
    "name":"bilgi-adresi","enabled":true,
    "matchers":[{"type":"literal","field":"to","value":"bilgi@sirketim.com.tr"}],
    "actions":[{"type":"forward","value":["benim@gmail.com"]}]
  }' | jq '.result'

Catch-all

curl -sS ".../zones/$ZONE_ID/email/routing/rules/catch_all" --request PUT "${AUTH[@]}" \
  --data '{"enabled":true,
           "matchers":[{"type":"all"}],
           "actions":[{"type":"forward","value":["benim@gmail.com"]}]}'

“When you enable this feature, Email Routing forwards every email sent to your domain, including misspelled local parts, to a single destination.”

Bir adresi iki kutuya yönlendiren Worker

export default {
  async email(message, env, ctx) {
    await message.forward("birinci@ornek.com");
    await message.forward("ikinci@ornek.com");   // her hedef için ayrı çağrı
  },
} satisfies ExportedHandler<Env>;

Her iki hedefin de önceden doğrulanmış olması gerekiyor.

Gizlilik için “geçerli görünen” adres

curl -sS ".../zones/$ZONE_ID/email/routing/rules" --request POST "${AUTH[@]}" \
  --data '{"name":"tek-kullanimlik","enabled":true,
           "matchers":[{"type":"literal","field":"to","value":"kayit-2026@sirketim.com.tr"}],
           "actions":[{"type":"drop","value":[]}]}'

Analitik (GraphQL)

curl -sS https://api.cloudflare.com/client/v4/graphql "${AUTH[@]}" --data '{
  "query":"query($z:String!,$b:Date!,$s:Date!){viewer{zones(filter:{zoneTag:$z}){
    emailRoutingAdaptiveGroups(filter:{date_geq:$b,date_leq:$s},limit:100,orderBy:[date_DESC]){
      count dimensions{date status action ruleMatched dmarc spf} }}}}",
  "variables":{"z":"'"$ZONE_ID"'","b":"2026-08-25","s":"2026-09-01"}}' \
  | jq '.data.viewer.zones[0].emailRoutingAdaptiveGroups'

Görebileceğin durumlar: Forwarded · Handled · Dropped · Rejected · Delivery failed · Error. Saklama 31 gün. Token’ın Analytics Read yetkisi gerekiyor.

Demo 1: Kimlik doğrulama zorunluluğunu on-prem sunucudan test etmek

Bu demo, Türkiye’de kendi posta sunucusunu çalıştıran ekipler için doğrudan uygulanabilir: 3 Temmuz 2025’ten beri yürürlükte olan kuralın ne yaptığını gösteriyor.

Adım 1 — Kurulumu doğrula

dig +short MX sirketim.com.tr
dig +short TXT sirketim.com.tr | grep spf
dig +short TXT cf2024-1._domainkey.sirketim.com.tr

route1/2/3.mx.cloudflare.net MX kayıtları, _spf.mx.cloudflare.net içeren SPF ve DKIM TXT kaydı

Adım 2 — Kimlik doğrulamasız gönder

On-prem Ubuntu sunucundan, SPF ve DKIM olmadan:

sudo apt-get install -y swaks
swaks --to bilgi@sirketim.com.tr \
      --from test@dogrulamasiz.ornek \
      --server route1.mx.cloudflare.net \
      --h-Subject "Kimlik dogrulamasiz test" \
      --body "Bu mesaj SPF ve DKIM olmadan gonderildi."

swaks oturum çıktısında SMTP reddi ve hata mesajı

Adım 3 — SPF kur ve tekrar dene

Gönderen alan adına SPF kaydı ekle, yayılmasını bekle, aynı komutu tekrarla.

swaks çıktısında 250 kabul yanıtı ve mesajın gelen kutusuna düşmesi

Adım 4 — RBL kontrolünü göster

Konut IP’si veya küçük bir ISP bloğundan gönderim yap.

554 <IP> found on one or more RBLs hata mesajı

Adım 5 — Yönlendirmenin SPF’i nasıl koruduğunu göster

Gelen kutusundaki mesajın ham kaynağını aç ve zarf başlıklarına bak.

Return-Path başlığında SRS ile yeniden yazılmış adres, From başlığının değişmemiş hâli

ARC-Seal, ARC-Message-Signature ve ARC-Authentication-Results başlıkları

Adım 6 — Katı DMARC ile gönder

Gönderen alan adına p=reject DMARC politikası koy ve tekrar dene.

Mesajın hedef kutuya ulaşıp ulaşmadığı ve varsa spam klasörüne düşme durumu

Adım 7 — Analitikten doğrula

emailRoutingAdaptiveGroups çıktısında Forwarded, Rejected ve dmarc/spf boyutları

Bu demoda ölçülenler:

Demo 2: Email Worker’ı yerel olarak, DNS riski almadan test etmek

Bu demonun en güçlü yanı: hiçbir DNS değişikliği yapmadan tam bir e-posta işleme akışını test edebiliyorsun.

Adım 1 — Worker’ı yaz

import PostalMime from "postal-mime";
import { EmailMessage } from "cloudflare:email";
import { createMimeMessage } from "mimetext";

export default {
  async email(message, env, ctx) {
    const t0 = Date.now();
    const parsed = await PostalMime.parse(message.raw);

    // Arşivle
    await env.MAILBOX.put(`${Date.now()}-${message.to}`, JSON.stringify({
      from: message.from, to: message.to, konu: parsed.subject,
      ekler: (parsed.attachments ?? []).map(a => ({ ad: a.filename, tip: a.mimeType })),
      spf: message.headers.get("authentication-results"),
    }));

    // Destek adresine otomatik yanıt
    if (message.to.startsWith("destek@")) {
      const mid = message.headers.get("Message-ID");
      const r = createMimeMessage();
      if (mid) { r.setHeader("In-Reply-To", mid); r.setHeader("References", mid); }
      r.setSender(message.to);        // gelen alan adı OLMALI
      r.setRecipient(message.from);   // orijinal gönderen OLMALI
      r.setSubject(`Re: ${parsed.subject ?? ""}`);
      r.addMessage({ contentType: "text/plain", data: `Talebiniz alındı.` });
      await message.reply(new EmailMessage(message.to, message.from, r.asRaw()));
    }

    const h = new Headers();
    h.set("X-Triyaj-Ms", String(Date.now() - t0));
    h.set("X-Orijinal-Alici", message.to);   // yalnızca X-* başlıkları hayatta kalıyor
    await message.forward("benim@gmail.com", h);
  },
} satisfies ExportedHandler<Env>;

Adım 2 — Yerel olarak test et

npx wrangler dev

Başka bir terminalde — mesaj Message-ID başlığı taşımak zorunda:

curl --request POST 'http://localhost:8787/cdn-cgi/handler/email' \
  --url-query 'from=musteri@ornek.net' \
  --url-query 'to=destek@sirketim.com.tr' \
  --data-raw 'From: "Musteri" <musteri@ornek.net>
To: destek@sirketim.com.tr
Subject: Fatura sorunu
Date: Tue, 01 Sep 2026 08:00:00 +0300
Message-ID: <demo-001@onprem>
Content-Type: text/plain; charset="utf-8"

Merhaba, faturamda hata var.'

Ayrıştırılmış mesaj nesnesi, forward ve reply çağrılarının simülasyon logları

Adım 3 — Reddetme yolunu test et

curl --request POST 'http://localhost:8787/cdn-cgi/handler/email' \
  --url-query 'from=bot@spam.ornek' --url-query 'to=destek@sirketim.com.tr' \
  --data-raw 'From: bot@spam.ornek
To: destek@sirketim.com.tr
Subject: spam
Message-ID: <spam-001@x>

...'

Worker'ın setReject çağrısı ve kalıcı SMTP hata mesajı

Adım 4 — Yayına al ve kuralı bağla

npx wrangler deploy

curl -sS ".../zones/$ZONE_ID/email/routing/rules" --request POST "${AUTH[@]}" --data '{
  "name":"destek-worker","enabled":true,
  "matchers":[{"type":"literal","field":"to","value":"destek@sirketim.com.tr"}],
  "actions":[{"type":"worker","value":["email-triyaj"]}]
}' | jq '.result'

Kural API yanıtı ve panelde Worker aksiyonlu kuralın görünmesi

Adım 5 — Gerçek e-posta gönder ve otomatik yanıtı gör

In-Reply-To başlığıyla iş parçacığına bağlanmış otomatik yanıt

X-Triyaj-Ms ve X-Orijinal-Alici başlıklarının ham kaynakta bulunması

Aynı anda X- öneki olmayan bir başlık eklemeyi dene — silindiğini göster.

Adım 6 — Arşivi ve analitiği doğrula

npx wrangler kv key list --binding MAILBOX | jq length

Anahtar listesi ve bir kaydın içeriğinde ek dosya adları ile MIME tipleri

Worker devreye girdikten sonra status alanında Handled değerinin görünmesi ve ruleMatched UUID'si

Bu demoda ölçülenler:

Fiyatlandırma

Email Routing’in ölçümlü hiçbir boyutu yok. Tek dolaylı maliyet: “Email Routing Workers is billed according to Workers pricing” — bir Worker’a yönlendirirsen Worker çağrıları normal Workers faturasına giriyor.

Limitler

Ayrı bir “özel adres” limiti yok — özel adres zaten bir kural, yani tavan 200.

Lisanslama ve hukuki çerçeve

Hizmet tescillidir ve Cloudflare Hizmet Şartları’na tabidir.

E-posta içeriği ve KVKK. Yönlendirilen her e-posta Cloudflare’in altyapısından geçiyor ve gönderen adresi, alıcı adresi ile mesaj gövdesi bu geçiş sırasında işleniyor. Bir kurumsal e-posta akışında bu, kişisel veri işleme faaliyeti. Email Service dokümantasyonunda hiçbir coğrafi ayrım yok — “country”, “region”, “geograph”, “jurisdiction” ve “data localization” terimleri sıfır kez geçiyor. Yani e-postaların nerede işlendiği konusunda ne bir taahhüt ne de bir kontrol var.

Türkiye’de veri yerleşimi gerektiren bir kurumsan bu ürün o şartı karşılamıyor.

Worker’a yönlendirdiğinde. Bir Email Worker yazdığında mesajın tam MIME akışına erişiyorsun — gövde, ekler, tüm başlıklar. Ne sakladığın, nerede sakladığın ve ne kadar sakladığın tamamen senin sorumluluğunda. Demo 2’deki KV arşivleme örneği bunu görünür kılıyor: kolayca yapılabiliyor, ama bir veri saklama politikası gerektiriyor.

drop aksiyonu ve gizlilik. Cloudflare bu aksiyonu açıkça gizlilik için öneriyor: “This can be useful if you want to make an email address appear valid for privacy reasons.” Bir formu doldurmak zorunda kaldığında geçerli görünen ama hiçbir yere gitmeyen bir adres üretebiliyorsun.

Sık yapılan hatalar

Dokümanın kendi "email": [{"name": "…"}] bloğunu kopyalamak. Wrangler şemasında yok; build kırılıyor. Email Worker’lar kural ile bağlanıyor.

Pazarlama sayfasındaki DNS ve API örneklerini kullanmak. Dört noktada yanlış: MX mail.cloudflare.com çözümlenmiyor, SPF _spf.cloudflare.com diye bir kayıt yok, adres API’si zone değil hesap seviyesinde, ve /email_routing/analytics diye bir uç bulunmuyor.

Email Routing’in DMARC kaydı oluşturduğunu sanmak. Yalnızca MX + SPF + DKIM.

İkinci bir SPF kaydı oluşturmak. “Having multiple SPF records on your domain is not allowed.” Birleştir ve 10 lookup sınırına dikkat et.

Aynı desen için iki kural yazmak. Hangisinin kazandığı iki resmî sayfada farklı anlatılıyor.

Doğrulanmamış bir adrese yönlendirmek. Kural doğrulamaya kadar devre dışı kalıyor; hedefi silmek onu kullanan her kuralı sessizce devre dışı bırakıyor.

Worker’ı yeniden adlandırmak. “Renaming a Worker removes the binding between that Worker and any routes that point to it.”

X- öneki olmayan başlıkların forward()’tan sağ çıkmasını beklemek. Siliniyorlar.

reply()’ı birden fazla kez çağırmak ya da gönderen alan adı / alıcı eşleşmeyen bir yanıt denemek, ya da DMARC’ı geçmemiş bir mesaja yanıt vermek. Üçü de hata fırlatıyor.

Worker’ın send_email sonuçlarını routing özetinden okumak. “dropped” görünüyorlar.

Workers Free’de ağır MIME ayrıştırması yapmak. Loglarda EXCEEDED_CPU.

Kullanımdan kaldırılan /enable, /disable, /unlock uçlarını kullanmak.

Kilitli DNS kayıtlarını DNS panelinden düzenlemeye çalışmak. Önce Email Routing → Settings’ten kilidi aç. Başka bir sağlayıcıya geçiyorsan: önce kilidi aç ve yeni kayıtları ekle, sonra devre dışı bırak — tersi posta akışını kesiyor.

Türkçe test e-postasında windows-1252 kullanmak. Cloudflare’in kendi örneği böyle; kopyalarsan Türkçe karakterler bozuluyor.