{"id":137,"date":"2026-10-11T09:01:11","date_gmt":"2026-10-11T06:01:11","guid":{"rendered":"https:\/\/mx1mail.com\/blog\/e-posta-yonlendirme-spfi-neden-bozar-srs-sender-rewriting-scheme\/"},"modified":"2026-10-11T09:01:11","modified_gmt":"2026-10-11T06:01:11","slug":"e-posta-yonlendirme-spfi-neden-bozar-srs-sender-rewriting-scheme","status":"publish","type":"post","link":"https:\/\/mx1mail.com\/blog\/tr\/e-posta-yonlendirme-spfi-neden-bozar-srs-sender-rewriting-scheme\/","title":{"rendered":"E-Posta Y\u00f6nlendirme SPF\u2019i Neden Bozar? SRS (Sender Rewriting Scheme) Mant\u0131\u011f\u0131, Riskler ve Do\u011fru Yakla\u015f\u0131m"},"content":{"rendered":"<h2>Y\u00f6nlendirme neden \u201cbasit\u201d g\u00f6r\u00fcn\u00fcr ama pratikte sorun \u00e7\u0131kar\u0131r?<\/h2>\n<p>E-posta y\u00f6nlendirme (forwarding), ilk bak\u0131\u015fta \u00e7ok basit bir i\u015flem gibi g\u00f6r\u00fcn\u00fcr: Gelen bir mesaj\u0131n bir kopyas\u0131 ba\u015fka bir adrese iletilir. Ancak kurumsal e-posta altyap\u0131s\u0131nda g\u00fcvenlik ve kimlik do\u011frulama kontrolleri devreye girdi\u011finde y\u00f6nlendirme; SPF, DMARC ve genel teslim edilebilirlik a\u00e7\u0131s\u0131ndan beklenmedik hatalara yol a\u00e7abilir. Bunun nedeni, y\u00f6nlendirme yapan sunucunun \u00e7o\u011fu zaman mesaj\u0131n \u201cg\u00f6ndereni\u201d gibi davranmas\u0131 ve al\u0131c\u0131 taraf\u0131n bu yeni ba\u011flant\u0131y\u0131 kimlik do\u011frulama a\u00e7\u0131s\u0131ndan de\u011ferlendirmesidir.<\/p>\n<p>Bu yaz\u0131da, y\u00f6nlendirme s\u0131ras\u0131nda SPF\u2019in neden bozuldu\u011funu, SRS (Sender Rewriting Scheme) yakla\u015f\u0131m\u0131n\u0131n ne yapt\u0131\u011f\u0131n\u0131, hangi senaryolarda gerekli hale geldi\u011fini ve \u015firketlerin y\u00f6nlendirme politikas\u0131n\u0131 nas\u0131l tasarlamas\u0131 gerekti\u011fini pratik \u015fekilde ele alaca\u011f\u0131z.<\/p>\n<h2>SPF\u2019in kontrol etti\u011fi \u015fey nedir?<\/h2>\n<p>SPF (Sender Policy Framework), bir alan ad\u0131n\u0131n \u201cbu domain ad\u0131na mail g\u00f6ndermeye hangi IP\u2019ler\/servisler yetkilidir?\u201d sorusuna DNS \u00fczerinden yan\u0131t vermesini sa\u011flar. Al\u0131c\u0131 sunucu, SMTP ba\u011flant\u0131s\u0131n\u0131 yapan IP\u2019yi al\u0131r, zarf g\u00f6nderen (envelope-from) adresindeki domain i\u00e7in SPF kayd\u0131n\u0131 sorgular ve bu IP yetkili mi diye kontrol eder.<\/p>\n<p>Burada kritik nokta \u015fudur: SPF, mesaj\u0131n i\u00e7erik k\u0131sm\u0131ndaki g\u00f6r\u00fcnen From alan\u0131ndan de\u011fil, \u00e7o\u011funlukla zarf g\u00f6nderen bilgisinden (Return-Path ile ili\u015fkilidir) ve ba\u011flant\u0131y\u0131 kuran IP\u2019den hareket eder. Bu, SPF\u2019i y\u00f6nlendirme senaryolar\u0131nda k\u0131r\u0131lgan yapar.<\/p>\n<h2>E-posta y\u00f6nlendirme SPF\u2019i neden ba\u015far\u0131s\u0131z yapar?<\/h2>\n<p>Bir kullan\u0131c\u0131ya gelen mesaj\u0131 ba\u015fka bir adrese y\u00f6nlendirdi\u011finizde, y\u00f6nlendirme sunucusu genellikle yeni bir SMTP oturumu ba\u015flat\u0131r ve mesaj\u0131 hedef sunucuya iletir. Bu yeni SMTP oturumunda ba\u011flant\u0131y\u0131 kuran IP art\u0131k \u201cy\u00f6nlendiren sunucunun IP\u2019sidir\u201d. Ancak zarf g\u00f6nderen adresi \u00e7o\u011fu zaman orijinal g\u00f6nderen olarak kal\u0131r.<\/p>\n<p>Sonu\u00e7: Hedef sunucu, \u201corijinal g\u00f6nderen domain\u201din SPF kayd\u0131na bakar ama ba\u011flanan IP \u201cy\u00f6nlendiren sunucu\u201d oldu\u011fu i\u00e7in bu IP genellikle yetkili de\u011fildir. SPF bu y\u00fczden fail (veya softfail) olur.<\/p>\n<h3>\u00d6rnek senaryo<\/h3>\n<ul>\n<li><strong>Orijinal g\u00f6nderici:<\/strong> kullanici@ornek.com<\/li>\n<li><strong>\u0130lk al\u0131c\u0131:<\/strong> info@sirket.com<\/li>\n<li><strong>Y\u00f6nlendirme hedefi:<\/strong> ad.soyad@baskadomain.com<\/li>\n<li><strong>Y\u00f6nlendiren sunucu:<\/strong> sirket.com\u2019un mail sunucusu<\/li>\n<\/ul>\n<p>baskadomain.com taraf\u0131, ornek.com\u2019un SPF kayd\u0131na bak\u0131p \u201csirket.com sunucusu ornek.com ad\u0131na mail g\u00f6nderebilir mi?\u201d diye kontrol eder. \u00c7o\u011fu durumda cevap hay\u0131rd\u0131r; SPF ba\u015far\u0131s\u0131z olur.<\/p>\n<h2>SPF fail her zaman sorun mu? DMARC devreye girince b\u00fcy\u00fcr<\/h2>\n<p>Tek ba\u015f\u0131na SPF fail bazen tolere edilebilir gibi g\u00f6r\u00fcnse de, DMARC politikas\u0131 olan domainlerde durum ciddi hale gelebilir. DMARC, SPF ve\/veya DKIM sonu\u00e7lar\u0131na bakar ve bunlar\u0131n g\u00f6r\u00fcnen From domainiyle \u201cuyumlu\u201d (alignment) olmas\u0131n\u0131 ister. Y\u00f6nlendirme SPF\u2019i bozdu\u011funda, DKIM de mesaj \u00fczerinde bozulmu\u015fsa (\u00f6rne\u011fin mailing list modifikasyonu, baz\u0131 ge\u00e7itler, baz\u0131 otomatik eklemeler), DMARC ba\u015far\u0131s\u0131z olabilir.<\/p>\n<p>Orijinal g\u00f6nderen domain p=quarantine veya p=reject gibi s\u0131k\u0131 bir DMARC politikas\u0131 kullan\u0131yorsa, y\u00f6nlendirdi\u011finiz mesajlar hedefte spam\/karantina klas\u00f6r\u00fcne d\u00fc\u015febilir veya tamamen reddedilebilir. Bu, \u00f6zellikle rol bazl\u0131 adresleri (info@, muhasebe@ gibi) ki\u015fisel kutulara y\u00f6nlendiren \u015firketlerde yayg\u0131n bir problemdir.<\/p>\n<h2>SRS (Sender Rewriting Scheme) nedir ve neyi de\u011fi\u015ftirir?<\/h2>\n<p>SRS, y\u00f6nlendirme s\u0131ras\u0131nda SPF k\u0131r\u0131lmas\u0131n\u0131 azaltmak i\u00e7in geli\u015ftirilmi\u015f bir y\u00f6ntemdir. Temel fikir \u015fudur: Y\u00f6nlendiren sunucu, mesaj\u0131 iletirken zarf g\u00f6nderen adresini (envelope-from) kendi domainine ait bir adrese \u201cyeniden yazar\u201d. B\u00f6ylece hedef sunucu SPF kontrol\u00fcn\u00fc art\u0131k orijinal domain i\u00e7in de\u011fil, y\u00f6nlendiren sunucunun domaini i\u00e7in yapar.<\/p>\n<p>Bu, y\u00f6nlendirme sunucusunun ba\u011flant\u0131y\u0131 kuran IP oldu\u011fu ger\u00e7e\u011fiyle uyumludur. Yani SPF a\u00e7\u0131s\u0131ndan \u201cba\u011flanan IP, kontrol edilen domainin SPF kayd\u0131nda yetkili mi?\u201d sorusu olumluya d\u00f6nebilir.<\/p>\n<h3>SRS nas\u0131l \u00e7al\u0131\u015f\u0131r (kavramsal)?<\/h3>\n<p>Orijinal envelope-from: bounce@ornek.com<\/p>\n<p>Y\u00f6nlendirme sonras\u0131 envelope-from \u00f6rne\u011fi: SRS0=HASH=ZAMAN=ornek.com=bounce@sirket.com<\/p>\n<p>Mesaj\u0131n g\u00f6r\u00fcnen From alan\u0131 genellikle de\u011fi\u015fmez; de\u011fi\u015fen k\u0131s\u0131m \u00e7o\u011fu zaman Return-Path\/envelope-from\u2019dur. Bu, SPF do\u011frulamas\u0131n\u0131 hedef tarafta \u201csirket.com ad\u0131na g\u00f6nderim\u201d gibi g\u00f6sterir. Ayr\u0131ca bounce (geri d\u00f6n\u00fc\u015f) trafi\u011finin de do\u011fru \u015fekilde y\u00f6nlendiren sunucuya geri gelmesini sa\u011flar.<\/p>\n<h2>SRS ne zaman gereklidir, ne zaman \u015fart de\u011fildir?<\/h2>\n<h3>SRS\u2019nin \u00f6zellikle gerekli oldu\u011fu durumlar<\/h3>\n<ul>\n<li>\u015eirketiniz bir alan ad\u0131ndan gelen mailleri ba\u015fka bir sa\u011flay\u0131c\u0131ya veya farkl\u0131 bir domain\u2019e otomatik y\u00f6nlendiriyorsa<\/li>\n<li>Rol bazl\u0131 adresler yo\u011fun \u015fekilde y\u00f6nlendirme kullan\u0131yorsa (info@ ekip da\u011f\u0131t\u0131m\u0131 yerine y\u00f6nlendirme gibi)<\/li>\n<li>DMARC politikas\u0131 s\u0131k\u0131 (quarantine\/reject) domainlerden yo\u011fun mail al\u0131yorsan\u0131z<\/li>\n<li>Y\u00f6nlendirme hedefi b\u00fcy\u00fck posta sistemleri ve s\u0131k\u0131 anti-spam kontrolleri uygulayan kurumsal al\u0131c\u0131larsa<\/li>\n<\/ul>\n<h3>SRS\u2019ye daha az ihtiya\u00e7 duyulan durumlar<\/h3>\n<ul>\n<li>Ayn\u0131 e-posta sistemi i\u00e7inde sunucu taraf\u0131 \u201cdeliver to mailbox\u201d yap\u0131l\u0131yor, farkl\u0131 bir d\u0131\u015f hedefe SMTP ile yeniden g\u00f6nderim yap\u0131lm\u0131yorsa<\/li>\n<li>Y\u00f6nlendirme yerine istemci taraf\u0131 kural kullan\u0131l\u0131yor (kullan\u0131c\u0131n\u0131n oturumu i\u00e7inde) ancak bunun da farkl\u0131 riskleri vard\u0131r<\/li>\n<li>Y\u00f6nlendirme hedefi ayn\u0131 domain i\u00e7indeki bir posta kutusuysa<\/li>\n<\/ul>\n<h2>Y\u00f6nlendirme tasar\u0131m\u0131nda pratik alternatifler<\/h2>\n<p>SRS \u00e7o\u011fu zaman do\u011fru \u00e7\u00f6z\u00fcmd\u00fcr; ancak her zaman tek se\u00e7enek de\u011fildir. \u0130\u015fletmeler a\u015fa\u011f\u0131daki se\u00e7enekleri de de\u011ferlendirmelidir.<\/p>\n<h3>1) Y\u00f6nlendirme yerine da\u011f\u0131t\u0131m grubu \/ payla\u015f\u0131lan posta kutusu<\/h3>\n<p>Bir adresin birden fazla ki\u015fiye \u201cda\u011f\u0131t\u0131lmas\u0131\u201d gerekiyorsa, gelen mesaj\u0131n ayn\u0131 sistem i\u00e7inde birden fazla kutuya teslim edilmesi, d\u0131\u015fa y\u00f6nlendirmeye g\u00f6re daha az teslim edilebilirlik riski ta\u015f\u0131r. Ayr\u0131ca denetim, eri\u015fim kontrol\u00fc ve i\u015ften ayr\u0131lan \u00e7al\u0131\u015fan s\u00fcre\u00e7leri daha y\u00f6netilebilir olur.<\/p>\n<h3>2) Y\u00f6nlendirmeyi s\u0131n\u0131rland\u0131rma ve istisna y\u00f6netimi<\/h3>\n<p>Her hesab\u0131n her yere y\u00f6nlendirme yapabilmesi, veri s\u0131z\u0131nt\u0131s\u0131 ve g\u00f6lge IT riskini art\u0131rabilir. Y\u00f6nlendirmeyi yaln\u0131zca onayl\u0131 hedeflere izin vererek veya belirli rol adresleriyle s\u0131n\u0131rlayarak kontrol etmek, hem g\u00fcvenlik hem teslim edilebilirlik a\u00e7\u0131s\u0131ndan faydal\u0131d\u0131r.<\/p>\n<h3>3) DKIM\u2019in korunmas\u0131na dikkat etmek<\/h3>\n<p>Y\u00f6nlendiren sistem, mesaj i\u00e7eri\u011fini veya ba\u015fl\u0131klar\u0131n\u0131 gereksiz yere de\u011fi\u015ftirdi\u011finde DKIM imzas\u0131 bozulabilir. Bu da DMARC ba\u015far\u0131s\u0131zl\u0131\u011f\u0131n\u0131 h\u0131zland\u0131r\u0131r. Y\u00f6nlendirme yapan altyap\u0131da hangi i\u015flemlerin mesaj\u0131 modifiye etti\u011fini anlamak (etiket ekleme, konuya prefix ekleme, baz\u0131 \u015fablonlar) \u00f6nemlidir.<\/p>\n<h2>SRS kullan\u0131rken dikkat edilmesi gereken operasyonel noktalar<\/h2>\n<h3>DNS ve teslim edilebilirlik<\/h3>\n<p>SRS ile yeniden yaz\u0131lan envelope-from adresleri sizin domaininizi kullanaca\u011f\u0131ndan, bu domainin SPF kayd\u0131 y\u00f6nlendiren \u00e7\u0131k\u0131\u015f IP\u2019lerinizi kapsamal\u0131d\u0131r. Aksi halde SPF yine fail olur; sadece sorunu ba\u015fka yere ta\u015f\u0131m\u0131\u015f olursunuz.<\/p>\n<h3>Bounce y\u00f6netimi<\/h3>\n<p>SRS\u2019nin bir amac\u0131 da geri d\u00f6n\u00fc\u015f (bounce) mesajlar\u0131n\u0131n do\u011fru yere ula\u015fmas\u0131d\u0131r. Yanl\u0131\u015f yap\u0131land\u0131r\u0131lm\u0131\u015f SRS, bounce\u2019lar\u0131n kaybolmas\u0131na veya d\u00f6ng\u00fc olu\u015fmas\u0131na neden olabilir. Bu, \u00f6zellikle otomatik yan\u0131tlar ve teslim edilemeyen mail raporlar\u0131 a\u00e7\u0131s\u0131ndan operasyonel k\u00f6rl\u00fck yarat\u0131r.<\/p>\n<h3>Loglama ve sorun giderme<\/h3>\n<p>Y\u00f6nlendirme kaynakl\u0131 teslim sorunlar\u0131n\u0131 \u00e7\u00f6zmek i\u00e7in SMTP loglar\u0131, al\u0131c\u0131 taraf\u0131n verdi\u011fi hata kodlar\u0131 ve m\u00fcmk\u00fcnse mesaj header analizi gerekir. SRS devredeyse, Return-Path gibi alanlarda g\u00f6r\u00fcnen yeniden yaz\u0131m bilgisinin izlenebilir olmas\u0131 \u00f6nemlidir.<\/p>\n<h2>\u015eirketler i\u00e7in \u00f6nerilen kontrol listesi<\/h2>\n<ol>\n<li>Hangi adresler y\u00f6nlendirme yap\u0131yor? Nereye y\u00f6nlendiriyor?<\/li>\n<li>Y\u00f6nlendirme d\u0131\u015f bir domaine mi gidiyor? (risk artar)<\/li>\n<li>Y\u00f6nlendirme nedeniyle SPF fail g\u00f6r\u00fclen \u00f6rnekler var m\u0131?<\/li>\n<li>DMARC\u2019\u0131 s\u0131k\u0131 domainlerden gelen maillerde kay\u0131p ya\u015fan\u0131yor mu?<\/li>\n<li>Y\u00f6nlendirme yerine da\u011f\u0131t\u0131m\/ortak posta kutusu gibi tasar\u0131mlar daha uygun olabilir mi?<\/li>\n<li>Y\u00f6nlendirme zorunluysa, SRS destekli sunucu taraf\u0131 y\u00f6nlendirme planland\u0131 m\u0131?<\/li>\n<li>De\u011fi\u015fiklik sonras\u0131 test: SPF\/DKIM\/DMARC sonu\u00e7lar\u0131 hedef tarafta nas\u0131l g\u00f6r\u00fcn\u00fcyor?<\/li>\n<\/ol>\n<h2>Sonu\u00e7: Y\u00f6nlendirme bir \u201ckolayl\u0131k\u201d de\u011fil, mimari karard\u0131r<\/h2>\n<p>E-posta y\u00f6nlendirme, do\u011fru tasarlanmad\u0131\u011f\u0131nda SPF k\u0131r\u0131lmas\u0131, DMARC ba\u015far\u0131s\u0131zl\u0131\u011f\u0131 ve teslim edilebilirlik kayb\u0131 gibi sonu\u00e7lar do\u011furabilir. SRS, bu problemin temelini hedefleyerek y\u00f6nlendirme s\u0131ras\u0131nda zarf g\u00f6ndereni yeniden yazar ve SPF kontrol\u00fcn\u00fc tutarl\u0131 hale getirir. Bununla birlikte, y\u00f6nlendirme ihtiyac\u0131n\u0131 ba\u015ftan azaltan tasar\u0131mlar (da\u011f\u0131t\u0131m gruplar\u0131, rol adresi y\u00f6netimi) \u00e7o\u011fu \u015firket i\u00e7in daha s\u00fcrd\u00fcr\u00fclebilir olabilir.<\/p>\n<p>MX1Mail \u00fczerinde e-posta ak\u0131\u015flar\u0131n\u0131 planlarken, y\u00f6nlendirme gereksinimlerini teslim edilebilirlik ve kimlik do\u011frulama perspektifiyle ele almak; \u00f6zellikle SPF\/DMARC kaynakl\u0131 s\u00fcrprizleri azaltmak i\u00e7in iyi bir ba\u015flang\u0131\u00e7t\u0131r.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>E-posta y\u00f6nlendirme s\u0131ras\u0131nda SPF\u2019in neden ba\u015far\u0131s\u0131z olabildi\u011fini, SRS\u2019nin bunu nas\u0131l \u00e7\u00f6zd\u00fc\u011f\u00fcn\u00fc ve y\u00f6nlendirme tasar\u0131m\u0131nda teslim edilebilirli\u011fi nas\u0131l koruyaca\u011f\u0131n\u0131z\u0131 \u00f6\u011frenin.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[291],"tags":[197,99,328],"class_list":["post-137","post","type-post","status-publish","format-standard","hentry","category-e-posta-teslim-edilebilirligi","tag-e-posta-yonlendirme","tag-spf","tag-srs"],"_links":{"self":[{"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/posts\/137","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/comments?post=137"}],"version-history":[{"count":0,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/posts\/137\/revisions"}],"wp:attachment":[{"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/media?parent=137"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/categories?post=137"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mx1mail.com\/blog\/wp-json\/wp\/v2\/tags?post=137"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}