Alan adınızdan hem kendi sunucunuzdan, hem CRM sisteminizden, hem de pazarlama araçlarınızdan e‑posta gönderiyorsanız, SPF kaydındaki iç içe DNS başvuruları lookup sınırını aşabilir. Test araçlarında gördüğünüz ‘Too many DNS lookups’ veya ‘PermError: DNS lookup limit exceeded’ uyarıları, bir yandan teslim edilebilirliği düşürürken diğer yandan da nereden başlayacağınızı bilemediğiniz karmaşık bir tablo yaratır.
Bu yazıda, birden fazla gönderim kaynağı bulunan alan adlarında oluşabilecek problemler üzerinden gideceğiz ve ’10 DNS lookup limitine takılmadan’ birden fazla e‑posta servisini aynı alan adında nasıl doğru tanımlayabileceğinizi adım adım anlatacağız. SPF’in temel mantığından çok, örnek senaryolara, tipik yanlış konfigürasyonlara, delegasyon ve ayrı alan adı kullanma stratejilerine, SPF flattening mimarisine ve IPv6 ile birlikte planlama detaylarına odaklanacağız. Eğer elinizde şu anda çalıştığından emin olamadığınız, birden fazla ‘include’ içeren karmaşık bir SPF kaydı varsa, yazının sonunda onu sade, okunabilir ve RFC’ye uygun hale getirebilecek net bir yol haritanız olacak.
SPF ve 10 DNS Lookup Sınırı Gerçekte Ne Anlama Geliyor?
SPF (Sender Policy Framework), alıcı mail sunucularına ‘SMTP MAIL FROM veya HELO kimliğindeki alan adı için hangi gönderici IP adreslerinin yetkili olduğunu’ DNS üzerinden ilan etmenin standart yoludur. TXT kaydı olarak tanımlanan SPF kaydı, gelen e‑postanın kaynağını kontrol etmek için çeşitli mekanizmalar kullanır: ip4, ip6, a, mx, include, exists ve ptr gibi. redirect ise bir mekanizma değil, başka bir SPF politikasına yönlendiren değiştiricidir.
RFC 7208’e göre SPF değerlendirmesinde DNS sorgusu gerektiren en fazla 10 terim işlenebilir; iç içe include ve redirect değerlendirmeleri de bu ortak sınıra dahildir. Bu, toplam DNS paketlerinin sayısı değildir. Sınır aşılırsa SPF sonucu PermError olur; politika değerlendirilemez. Bu sonuç SPF pass sağlamaz, ancak hizalı bir DKIM doğrulaması başarılıysa DMARC yine geçebilir. İletinin kabulü veya reddi alıcının politikasına da bağlıdır.
Lookup sınırı, değerlendirme sırasında işlenen DNS sorgusu gerektiren terimler için geçerlidir. Sayılanlar:
- include: Başka bir alan adının SPF politikasını değerlendirir (kendisi 1 terim; iç değerlendirmedeki DNS gerektiren terimler de sayılır)
- a: Alan adının A/AAAA kaydını çözer (10 terimlik sınırda 1 terim)
- mx: MX kaydını ve ardından hedeflerin A/AAAA kayıtlarını çözer (birden fazla DNS sorgusu gerekse de 10 terimlik sınırda 1 terim; ayrıca MX’e özgü çözümleme sınırları vardır)
- exists: Belirtilen alan adı için DNS sorgusu yapar (10 terimlik sınırda 1 terim)
- ptr: Reverse DNS ve doğrulama sorguları yapar (10 terimlik sınırda 1 terim; kullanımı önerilmez)
- redirect= Başka bir alanın SPF politikasına yönlendirir (işlenirse kendisi 1 terim; hedefteki DNS gerektiren terimler de sayılır)
ip4, ip6, all gibi mekanizmalar ek DNS sorgusu üretmez, dolayısıyla lookup limitini etkilemez. Sınırı aşmanıza sebep olan genellikle çok sayıda include ve iç içe include zincirleridir. Bir servis sizden ‘include:spf.servisadi.com’ eklemenizi ister, o SPF kaydının içinde de 6–7 farklı include daha çıkar ve toplam sayıyı kolayca 10’un üzerine taşırsınız.
Birden Fazla E‑Posta Servisi Kullanan Şirketlerin Tipik SPF Sorunları
Paylaşımlı hosting, VPS veya bağımsız bir MTA kullanılan yapılarda SPF kaydını karmaşıklaştırabilecek durumları özetleyelim:
- Kendi mail sunucusu + bir CRM + bir pazarlama aracı + bir yardım masası yazılımı gibi 3–5 farklı kaynaktan e‑posta gönderimi
- Her servisin dökümantasyonundaki ‘Şu include’u ekleyin’ önerilerine körü körüne uyup 8–10 farklı include kullanmak
- Her include içindeki SPF kaydının da birden fazla include içermesi ve iç içe zincirler oluşması
- Subdomain yerine her şeyi kök alan adında toplamak; hem gönderim domaini, hem Return‑Path, hem SPF için tek domain kullanmak
- Eski, artık kullanılmayan servislerin SPF’te unutulması; yani teknik borç birikmesi
Limit aşıldığında şu belirtiler görülebilir:
- SPF test araçlarında ‘PermError: too many DNS lookups’ veya ‘Maximum hops exceeded’ uyarıları
- DMARC raporlarındaki SPF doğrulama sonuçlarında ‘permerror’ görülmesi; ‘temperror’ ise geçici hataları belirtir, bu limitin aşılması değildir
- Alıcı politikalarına ve diğer doğrulama sonuçlarına bağlı olarak iletilerin kabul edilmesi, spam’e ayrılması veya reddedilmesi nedeniyle tutarsız teslim edilebilirlik
Temel SPF mantığını öğrenmek için önce SPF, DKIM ve DMARC doğrulamasını sıfırdan kurma rehberimizi okumanız iyi bir başlangıç olur. Bu yazıda ise ileri seviye konfigürasyona ve optimizasyona odaklanacağız.
10 Lookup Limitine Takılmadan SPF Kaydı Tasarlama Adımları
1. Tüm Gönderim Kaynaklarını Envanterleyin
Önce hangi sistemlerin hangi alan adı adına e‑posta gönderdiğini netleştirmeniz gerekiyor. Sıklıkla atlanan kaynaklar şunlar:
- Web sitenizin iletişim formları (PHP mail, SMTP eklentileri)
- E‑ticaret sitenizin sipariş, fatura ve bildirim mailleri
- CRM ve pazarlama otomasyonu araçları
- Destek/ticket sistemleri
- Sunucu izleme araçları, backup bildirimleri, cron raporları
Her biri için şu bilgileri toplayın:
- Gönderen domain (From: alanındaki alan adı)
- Return‑Path / MAIL FROM alan adı (çoğu zaman farklıdır)
- Hizmet tarafından önerilen SPF include veya IP listesi
- Kendi kontrolünüzde olan IP’ler (örneğin DCHost üzerindeki VPS veya mail sunucunuz)
2. Doğrudan IP Kullanımını Değerlendirin; A/MX Maliyetini Hesaplayın
SPF lookup sayısını düşürmenin bir yolu, kendi kontrolünüzdeki sabit gönderim IP adreslerini doğrudan SPF’e yazmaktır. Örneğin alan adınızın mail.sunucu.com gibi bir alt alanından, DCHost üzerindeki bir VPS’ten e‑posta gönderiyorsanız, çoğu zaman şu seçenekleriniz vardır. Aşağıdaki kayıtlar şematiktir; 1.2.3.4 ve örnek alan adlarını aynen yayımlamayın. IP’yi gerçek çıkış IP’nizle, alan adlarını kontrolünüzdeki adlarla veya hizmetin belgelediği SPF hedefleriyle değiştirin. Bu iki alternatiften yalnızca birini, değerlendirilen MAIL FROM alan adının tek SPF TXT politikasına uyarlayın; -all öncesinde diğer meşru gönderim kaynaklarını da kapsayın:
v=spf1 ip4:1.2.3.4 -all
veya
v=spf1 a:mail.sunucu.com -all
Burada:
- ip4 mekanizması ek DNS lookup üretmez.
- a:mail.sunucu.com, 10 terimlik sınırdan birini kullanır; yalnızca bu adın A/AAAA kayıtları gerçek gönderim IP’lerinizi gösteriyorsa uygundur.
MX, A ve include aynı gönderim IP kümesini yetkilendiriyorsa gereksiz tekrar oluşabilir. Aşağıdaki şematik kayıtta böyle bir tekrar olup olmadığını hedef kayıtları inceleyerek belirleyin:
v=spf1 mx include:mail.dchost-musteri.com a -all
Bunun yerine, hangi IP’lerden gerçekten gönderim yapıldığını tespit edip SPF’i sadeleştirmek genellikle hem lookup sayısını hem de karışıklığı azaltır.
3. Gereksiz Include’ları Temizleyin
Envanter sırasında aşağıdaki gibi çok sayıda include içeren şematik bir kayıtla karşılaşabilirsiniz:
v=spf1 include:_spf1.servis.com include:_spf2.servis.com include:mail1.example.net include:mail2.example.net include:eu.mailhost.com ~all
Burada işlenen her include, 10 terimlik sınıra bir ekler; hedefindeki DNS gerektiren terimler de aynı toplama eklenir. Servislerin dökümantasyonunu dikkatle inceleyin:
- Aynı servis için birden çok include gerekiyormuş gibi görünen ama aslında eski sürümler için bırakılmış kayıtlar olabilir.
- Bölgesel include’ları (eu, us, asia) ancak hizmetin güncel belgeleri hesabınızın gönderim ve yedek geçiş yolları için gereksiz olduklarını doğruluyorsa kaldırın.
- Servis hem include hem IP aralıkları yayımlıyorsa, doğrudan ip4/ip6 kullanmayı yalnızca bu listenin hesabınız için tüm olası gönderim kaynaklarını kapsadığı belgelenmişse değerlendirin. IP değişikliklerini izleyip kaydı güncelleme sorumluluğunu da üstlenmeniz gerekir.
Hedefiniz, bütün servislere rağmen toplam 4–6 lookup civarında kalmak olsun. Bu bir RFC eşiği değil, ilerideki değişiklikler için pay bırakan tasarım hedefidir. Gerekirse flattening veya ayrı gönderim alan adlarını değerlendirebilirsiniz.
4. ‘redirect’ Değiştiricisini ve ‘exists’ Mekanizmasını Dikkatli Kullanın
Aşağıdaki yalnızca ‘redirect=’ içeren politika, değerlendirmeyi _spf.example.com alanındaki SPF politikasına yönlendirir. Alan adı ile TXT içeriği şematik olarak şöyle gösterilebilir:
example.com: v=spf1 redirect=_spf.example.com
_spf.example.com: v=spf1 ip4:1.2.3.4 include:servis.com -all
Bu, yönetimi kolaylaştırabilir ama lookup sayısını azaltmaz; redirect işlendiğinde kendisi de sınıra bir terim ekler. Benzer şekilde ‘exists’ de bu bütçeyi kullanır. Limite yakınsanız, bu terimleri otomatik olarak kaldırmak yerine hangi yetkilendirme işlevini sağladıklarını ve toplam değerlendirme maliyetini inceleyin.
Delegasyon, Ayrı Alan Adları ve Subdomain Stratejileri
Gelişmiş SPF yönetiminde en güçlü araçlardan biri, aynı marka için birden fazla domain veya subdomain kullanmaktır. Burada kritik nokta, DMARC hizalamasını (alignment) bozmadan SPF’i sadeleştirmektir.
Transactional, Pazarlama ve Operasyonel Mailleri Ayırın
Genel bir iyi uygulama:
- Transactional mailler (şifre sıfırlama, sipariş onayı) için: mail.example.com veya notify.example.com
- Pazarlama/bülten mailleri için: news.example.com veya email.example.com
- Destek ve ticket mailleri için: support.example.com
Her bir subdomain için ayrı bir SPF kaydı tanımlayabilir ve ilgili servisi sadece oraya bağlayabilirsiniz. Örneğin:
example.com. TXT "v=spf1 ip4:203.0.113.10 -all"
mail.example.com. TXT "v=spf1 include:spf.transactionalservis.com -all"
news.example.com. TXT "v=spf1 include:spf.marketingservis.com -all"
Burada önemli olan, kullandığınız servislerin Return‑Path / MAIL FROM domainini bu subdomain’lere göre ayarlayabilmenizdir. Yukarıdaki IP ve servis alan adları temsili örneklerdir; gerçek gönderici IP’leri ve sağlayıcının bildirdiği SPF hedefleriyle değiştirilmelidir. Bu tasarım için seçtiğiniz servisin özel envelope‑from domain tanımını desteklediğini doğrulayın.
DMARC Hizalamasını Korumak
DMARC, SPF veya DKIM sonucunu değerlendirirken ‘alignment’ kavramını kullanır. SPF alignment, From başlığındaki alan adı ile SPF doğrulamasından geçen MAIL FROM alan adını karşılaştırır. Relaxed hizalamada organizasyon alan adlarının aynı olması yeterlidir; strict hizalamada alan adları birebir aynı olmalıdır. Örneğin:
- From: bilgi@example.com
- SPF doğrulaması: mail.example.com
Bu örnekte relaxed alignment sağlanır, çünkü iki adresin organizasyon alan adı example.com’dur. MAIL FROM için mail.example.com veya news.example.com kullanmak SPF yönetimini ayırabilir; ancak strict SPF hizalamasında bu alan adları From alan adı example.com ile hizalanmaz. DMARC geçişi için hizalı SPF veya hizalı DKIM doğrulamalarından en az birinin başarılı olması gerekir.
DMARC ve SPF hizalamasını daha derin anlamak için transactional ve pazarlama e‑postaları için ayrı gönderim alanı kullanma rehberimizi da mutlaka okumanızı öneririz.
Alt Domainleri Merkezi Bir SPF Politikasına Yönlendirmek
Eğer çok sayıda alt alan adınız varsa ve hepsinin aynı SPF politikasını kullanmasını istiyorsanız, redirect kullanarak merkezi bir alan tanımlayabilirsiniz. Aşağıdaki IP ve servis alan adı temsili değerlerdir:
_spf.example.com. TXT "v=spf1 ip4:203.0.113.10 include:spf.servis.com -all"
mail.example.com. TXT "v=spf1 redirect=_spf.example.com"
news.example.com. TXT "v=spf1 redirect=_spf.example.com"
Bu yaklaşım yönetimi kolaylaştırır; ama lookup sayısını düşürmez. Yine de çok sayıda subdomain’i tek bir merkezden yönetmek istiyorsanız işe yarar. Lookup optimizasyonunu, merkez kayıt olan _spf.example.com üzerinde yapmanız gerekir.
SPF Flattening: Lookup Sayısını Azaltmak ve Güncelliği Korumak
Delegasyon ve sadeleştirme sonrasında hâlâ 10 lookup sınırına yakınsanız, SPF flattening değerlendirilebilecek bir seçenektir. Temel fikir, ‘include:spf.servis.com’ gibi kayıtların arkasındaki IP ve IP bloklarını önceden çözüp SPF kaydınıza doğrudan ip4/ip6 olarak yazmaktır.
Statik Flattening Ne Zaman Tehlikeli?
En basit ama riskli yöntem, include hedeflerini bir kez çözerek elde edilen yetkili IP aralıklarını kendi SPF kaydınıza yazmaktır. Yalnızca görünen ip4/ip6 değerlerini kopyalamak, kaydın tamamının aynı yetkilendirme sonucunu verdiğini kanıtlamaz. Aşağıdaki varsayımsal örnekte, include hedefinin yalnızca gösterilen iki aralığı yetkilendirdiği varsayılmıştır; IP’ler ve servis alan adı temsili değerlerdir:
orijinal:
v=spf1 ip4:203.0.113.10 include:spf.marketingservis.com -all
flatten edilmiş:
v=spf1 ip4:203.0.113.10 ip4:198.51.100.0/24 ip4:192.0.2.0/25 -all
Bunun iki önemli riski var:
- Servis, zaman içinde IP aralıklarını değiştirirse SPF kaydınız güncel kalmaz.
- Özellikle büyük sağlayıcıların IP aralıkları çok geniştir; SPF kaydınız gereksiz şişebilir.
Bu nedenle statik flattening, yalnızca yetkili IP listesinin doğruluğunu ve değişikliklerini takip edebildiğiniz koşullarda değerlendirilmelidir. Sağlayıcının küçük veya kurumsal olması, IP aralıklarının değişmeyeceğini garanti etmez. Otomasyon güncellik takibini kolaylaştırabilir; ancak üretilen kaydın doğruluğunun denetlenmesi yine gerekir.
Otomatik / Dinamik SPF Flattening Mimarisinin Mantığı
Güncellik riskini azaltmak için SPF flattening’i doğrulama adımları içeren bir otomasyon süreci haline getirebilirsiniz. Örneğin:
- Bir betik (Python, Bash vb.) belirli aralıklarla (cron, CI/CD pipeline) çalışır.
- Betik, include ettiğiniz alanların SPF kayıtlarını çözer.
- Ortaya çıkan yetkili ip4/ip6 listelerini konsolide eder, gereksiz tekrarları atar; çözülemeyen veya eşdeğerliği doğrulanamayan politikaları otomatik olarak yayımlamaz.
- Aday kaydın sözdizimini, DNS boyut sınırlarını ve beklenen göndericileri yetkilendirdiğini kontrol eder. Kontroller başarılıysa DNS sağlayıcınızın API’si üzerinden yayımlar; hata halinde mevcut kaydı koruyup uyarı üretir ve geri dönüş için önceki sürümü saklar.
Bu süreç, SPF kaydının periyodik olarak güncellenmesini sağlar; ancak servis değişikliği ile kaydın yenilenmesi arasında gecikme olabilir. Güncelleme sıklığı ve DNS önbelleklerindeki TTL süreleri birlikte planlanmalı, başarısız güncellemeler izlenmelidir.
Bu konuyu ayrıntılı okuma ve örnek bash/CI pipeline şablonları görmek isterseniz, SPF flattening ile 10 lookup duvarını aşma rehberimizi özellikle tavsiye ederim.
E‑Posta Yönlendirme, SRS/ARC ve SPF İlişkisi
SPF ile ilgili bir başka tuzak da e‑posta yönlendirme senaryolarıdır. Kullanıcı ‘info@example.com’ adresine gelen mailleri kişisel hesabına yönlendirdiğinde, yönlendiren sunucu orijinal gönderen adına maili tekrar gönderir. SPF, kaynak IP’ye baktığı için çoğu zaman bu yeniden gönderilen maili yetkisiz olarak görür.
SRS (Sender Rewriting Scheme), yönlendirmede MAIL FROM adresini yeniden yazmak için kullanılır; bu, görünür From alan adıyla SPF hizalamasını korumayı garanti etmez. ARC (Authenticated Received Chain) ise aracıların doğrulama değerlendirmelerini taşır; SPF sonucunu düzeltmez ve otomatik DMARC geçişi sağlamaz. Kendi mail sunucunuzda bu yöntemleri değerlendirirken DMARC için başarılı ve hizalı SPF veya DKIM gerektiğini, ARC bilgisinin kullanımının ise alıcının değerlendirmesine bağlı olduğunu dikkate alın.
Detaylı senaryolar ve pratik kurulum adımları için e‑posta yönlendirmede SPF/DMARC neden kırılıyor, SRS ve ARC ile nasıl düzeltilir rehberimize göz atabilirsiniz. SPF’i optimize ederken yönlendirme trafiğinizi de hesaba katmayı unutmayın.
IPv6 ile SPF ve Reverse DNS
Mail sunucunuz IPv6 üzerinden teslimat yapıyorsa SPF kaydında bu gönderim adresini de yetkilendirin. ip6 mekanizması kullanılan aşağıdaki örnekte adresler temsilidir; kendi gönderici IP’lerinizle değiştirilmelidir:
v=spf1 ip4:203.0.113.10 ip6:2001:db8::1234 -all
Doğrudan ip6 mekanizması DNS lookup bütçesini tüketmez; ancak a gibi DNS sorgusu gerektiren terimler IPv6 için de bu sınıra dahildir. Yalnızca yetkili gönderici adreslerini tanımlayın. Reverse DNS (PTR) doğruluğu ise SPF geçişinden ayrı bir teslim edilebilirlik kontrolüdür. Bir VPS veya dedicated sunucu üzerinde çift yığınlı gönderim tasarlarken, seçilen planda IPv4/IPv6 erişimini, SMTP çıkış koşullarını ve PTR yönetim yetkisini doğrulayın; ardından şu adımları kontrol edin:
- IPv6 PTR kaydı: ‘mail.example.com’ gibi tutarlı bir hostname’e işaret etmeli
- Bu hostname’in AAAA kaydı gönderen IPv6 adresine geri çözülmeli; IPv4 gönderimi için de ilgili PTR adı A kaydıyla gönderen IPv4 adresine geri çözülmeli
- SPF kaydınızda ip6: veya a:mail.example.com üzerinden IPv6 da yetkilendirilmiş olmalı
IPv6 ile e‑posta gönderimi ve SPF/Reverse DNS detaylarını adım adım ele aldığımız IPv6 ile e‑posta gönderimi ve teslim edilebilirlik rehberimizi özellikle teknik ekipler için öneriyoruz.
Gelişmiş SPF Yönetimi Altyapıya Göre Nasıl Kurgulanabilir?
SPF tasarımını uygularken DNS yönetim yetkisi, gönderici IP’lerinin kontrolü ve kullanılan servisler belirleyicidir. Altyapı türüne göre şu yaklaşımlar değerlendirilebilir:
- Paylaşımlı hosting için: Yetkili DNS panelinde, sağlayıcının bildirdiği gönderim kaynaklarını esas alarak kullanılmayan include’ları kaldırın. ip4/ip6 tanımlarını yalnızca doğru ve güncel gönderici adresleri biliniyorsa kullanın.
- VPS ve dedicated sunucular için: Kendi MTA’nızı yönetiyorsanız mail.example.com gibi ayrı subdomain’ler ve kontrolünüzdeki sabit gönderici IP’leri için doğrudan yetkilendirme kullanabilirsiniz.
- Çoklu servis kullanan kurumsal yapılar için: Transactional / pazarlama / operasyonel mailleri farklı subdomain’lere dağıtabilir; gerekiyorsa doğrulama ve hata takibi içeren otomatik SPF flattening pipeline’ı değerlendirebilirsiniz.
- DMARC ve raporlama tarafında: RUA toplu raporlarındaki kaynak IP’leri ve hizalama sonuçlarını gönderici envanteriyle karşılaştırın. RUF hata raporları sınırlı gelebilir ve hassas veri içerebilir; rutin takipte toplu raporları esas alın.
Bu çalışmayı alan adı, DNS ve e‑posta yöneticilerinin sorumluluklarını netleştirerek planlayın. Dışarıdan destek alınacaksa SPF incelemesi, subdomain tasarımı ve flattening otomasyonunun hizmet kapsamına dahil olup olmadığını önceden belirleyin.
Özet ve Sonraki Adımlar
Gelişmiş SPF yönetimi, sadece TXT kaydına birkaç include eklemekten çok daha fazlası. Bir yandan RFC 7208’in, iç içe değerlendirmeler dahil DNS sorgusu gerektiren include/a/mx/ptr/exists/redirect terimleri için koyduğu toplam 10 sınırına uymak zorundasınız; diğer yandan DMARC hizalamasını bozmadan birden fazla e‑posta servisini aynı marka çatısı altında yönetmeniz gerekiyor. Doğru strateji genellikle şu bileşenlerin birleşiminden oluşuyor:
- Tüm gönderim kaynaklarını envanterleyip gereksiz include’ları temizlemek
- Kendi kontrolünüzdeki gönderici IP’lerini doğrudan ip4/ip6 ile veya DNS lookup bütçesini de hesaba katarak a/mx üzerinden yetkilendirmek
- Transactional, pazarlama ve operasyonel mailleri ayrı subdomain’lere taşımak
- Gerekiyorsa otomatik SPF flattening pipeline’ı kurmak
- Yönlendirme, SRS/ARC ve IPv6 gibi detayları SPF ile uyumlu hale getirmek
Bir sonraki adımda, mevcut SPF kaydınızı test araçlarıyla kontrol edip ‘DNS lookups’ sayısını not alın. Ardından bu yazıdaki adımları izleyerek sadeleştirme ve delegasyon denemeleri yapın. Daha sonra, DMARC raporlarında görünen kaynak IP’leri gönderim envanterinizle karşılaştırın; tanımadığınız kaynakları yetkili kabul etmeden önce araştırın. Bu süreçte rehbere ihtiyaç duyarsanız, e‑posta teslim edilebilirliğini SPF, DKIM, DMARC ve rDNS ile adım adım yükseltme yazımız da yol gösterici olacaktır.
Alan adı, DNS veya mail altyapısı taşıması planlıyorsanız, SPF/DMARC tasarımından ve DNS değişikliklerinden kimin sorumlu olacağını önceden belirleyin. VPS, dedicated veya colocation seçeneklerini değerlendirirken e‑posta mimarisi için gereken yönetim ve destek kapsamını seçtiğiniz planın koşullarıyla karşılaştırın.
