Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
Kurumsal e-postalarınız Gmail, Outlook, Hotmail veya Yahoo'da spam klasörüne düşüyor, hiç ulaşmıyor ya da 550/421/451 gibi SMTP hatalarıyla geri dönüyorsa sorun yalnız içerikten kaynaklanmayabilir. DNS kimlik doğrulaması, gönderici IP itibarı, PTR/rDNS, HELO/EHLO, TLS, SPF kapsamı, DKIM imzası, DMARC hizalaması, toplu gönderim davranışı ve kullanılan SMTP altyapısı birlikte değerlendirilmelidir.
İlk ön analiz için e-posta veya hosting şifresi göndermeyin. Alan adınızı, hangi adrese gönderimde sorun yaşadığınızı, varsa geri dönüş hata metnini ve bir test e-postasının tam header bilgisini iletmeniz yeterlidir.
SPF, DKIM, DMARC, PTR ve SMTP itibar teşhisi
SPF, DKIM ve DMARC geçmesi teslimatı garanti etmez. IP/domain itibarı, PTR, TLS, spam şikayet oranı, ani gönderim artışı, eski liste, bounce oranı, paylaşımlı IP, mesaj içeriği, link domainleri ve alıcı etkileşimi de filtrelemeyi etkiler.
Domain adına hangi kaynakların mail göndermeye yetkili olduğunu belirtir.
Türkiye (Türkçe)
Almanya (German)
Worldwide (English)
v=spf1 ip4:203.0.113.25 include:_spf.ornekservis.com -allMesajı dijital imza ile doğrular.
selector1._domainkey.example.com → v=DKIM1; k=rsa; p=PUBLIC_KEYSPF/DKIM sonuçlarını From domainiyle hizalar ve policy/raporlama sağlar.
_dmarc.example.com → v=DMARC1; p=none; rua=mailto:[email protected]Gönderici IP'yi geriye doğru hostname'e çözer.
203.0.113.25 → mail.example.comDomain'e gelen maili hangi sunucunun kabul edeceğini tanımlar.
example.com → 10 mail.example.comSMTP aktarımını şifreler.
STARTTLS / TLS 1.2+| Hata / Durum | Nerede | Olası anlam | İlk kontrol |
|---|---|---|---|
| 550 5.7.26 | Gmail | Gönderici authentication yetersiz veya başarısız olabilir. | Header içindeki spf=, dkim=, dmarc= ve alignment kontrol edilir. |
| 550 5.7.515 | Outlook / Hotmail | Gönderici domain gereken authentication seviyesini karşılamıyor. | SPF, DKIM, DMARC ve From/MailFrom/DKIM alignment incelenir. |
| 421 4.7.0 | Gmail / çeşitli | Geçici rate limit, PTR veya reputation sorunu olabilir. | PTR, forward DNS, gönderim hızı ve tam hata metni incelenir. |
| 451 / 4.x.x | Çeşitli | Geçici SMTP hata sınıfı; greylist/rate limit/DNS olabilir. | Queue retry ve enhanced status code değerlendirilir. |
| 550 5.1.1 | Çeşitli | Alıcı adresi yok veya geçersiz. | Liste hijyeni ve alıcı adresi doğrulanır. |
| SPF PermError | Authentication | SPF syntax, çoklu kayıt veya 10 lookup sınırı. | SPF ağacı include/redirect dahil çözülür. |
| DKIM Fail | Authentication | Selector/key/imza problemi. | DKIM-Signature d=/s= ve Authentication-Results kontrol edilir. |
| DMARC Fail | Authentication | Aligned SPF veya DKIM pass yok. | From, smtp.mailfrom ve DKIM d= domainleri karşılaştırılır. |
| Spam klasörü | Gmail/Outlook/Yahoo | Authentication geçse bile reputation/complaint/engagement zayıf olabilir. | Postmaster, bounce, complaint ve gönderim davranışı değerlendirilir. |
SPF, DKIM ve DMARC bir e-postanın hangi domain adına gönderildiğini doğrulamaya yardımcı olur. Buna rağmen inbox/spam kararı yalnız authentication sonucuna göre verilmez. Gönderici IP ve domain itibarı, geçmiş gönderim davranışı, kullanıcı şikayetleri, bounce oranı, alıcı etkileşimi, mesaj hacmi ve içerik sinyalleri birlikte değerlendirilir.
Bu yüzden mail-tester gibi araçlardan yüksek puan almak faydalıdır ancak Gmail, Outlook veya Yahoo inbox garantisi değildir. Gerçek teşhis için gönderilmiş mesajın raw header bilgisi ve alıcı sağlayıcının döndürdüğü SMTP sonucu incelenmelidir.
İlk soru sadece “SPF var mı?” olmamalıdır. Mailin hangi altyapıdan çıktığı, hangi IP ile gönderildiği, Return-Path ve From domainlerinin ne olduğu ve DKIM imzasının hangi domainle atıldığı birlikte görülmelidir.
SPF, 5321.MailFrom yani SMTP envelope sender domaini için hangi sunucu ve servislerin mail göndermeye yetkili olduğunu DNS TXT kaydında belirtir. Web sitesi, CRM, fatura sistemi ve newsletter farklı altyapılardan gönderim yapıyorsa tüm meşru kaynakların doğru biçimde kapsanması gerekir.
Aynı domain için iki ayrı v=spf1 kaydı yayınlamak yaygın bir yapılandırma hatasıdır. Yetkili kaynaklar tek SPF politikası altında birleştirilmelidir. include, a, mx, ptr, exists ve redirect gibi DNS sorgusu oluşturan terimlerin evaluation toplamı RFC 7208 gereği 10 lookup sınırını aşmamalıdır; aksi halde SPF PermError oluşabilir.
SPF pass olması DMARC pass garantisi değildir. DMARC için SPF ile doğrulanan MailFrom domaininin görünen 5322.From domainiyle alignment sağlaması gerekir.
DKIM, gönderici mail sisteminin mesaj başlığı ve gövdesinin belirli bölümlerini private key ile imzalamasıdır. Alıcı, DKIM-Signature içindeki d= domaini ve s= selector değerini kullanarak DNS'teki public key kaydını bulur ve imzayı doğrular.
DNS'te DKIM kaydı bulunması tek başına yeterli değildir; SMTP sunucusunun gerçekten mesajı imzalaması gerekir. Header içinde dkim=pass sonucu aranmalı ve DMARC için DKIM d= domaininin From domainiyle hizalı olup olmadığı kontrol edilmelidir.
DKIM Fail yanlış selector, hatalı veya parçalanmış TXT kaydı, kapalı imzalama servisi, anahtar değişimi veya mesajın imzalandıktan sonra değiştirilmesi gibi nedenlerle oluşabilir.
DMARC, SPF ve DKIM sonuçlarına domain alignment katmanı ekler. SPF veya DKIM yollarından en az biri hem pass hem de From domainiyle hizalıysa DMARC geçebilir.
p=none raporlama ve gözlem aşamasında kullanılır. p=quarantine başarısız mesajların spam/karantina işlemine yönlendirilmesini, p=reject ise alıcıdan reddetmesini ister. Policy sıkılaştırmadan önce domain adına mail gönderen tüm gerçek servisler envanterlenmelidir.
DMARC aggregate raporları CRM, web formu, fatura servisi, newsletter ve bilinmeyen göndericileri ayırmaya yardımcı olur. Meşru kaynaklar düzeltilmeden doğrudan reject politikasına geçmek gerçek mailleri kesebilir.
Kullanıcının mail uygulamasında gördüğü gönderen 5322.From alanıdır. SMTP taşımada kullanılan envelope sender / Return-Path 5321.MailFrom olarak düşünülür. DKIM ise kendi d= signing domainini taşır.
Üçüncü taraf SMTP servisi kendi return-path domainiyle SPF pass alabilir; ancak bu domain From ile hizalı değilse SPF, DMARC açısından işe yaramayabilir. Benzer şekilde DKIM pass olsa bile d= domaini From ile hizalı değilse DMARC yine başarısız olabilir.
Custom return-path ve custom DKIM seçenekleri özellikle newsletter, CRM, ticket, fatura ve transactional mail servislerinde bu yüzden önemlidir.
Gönderici IP'nin PTR kaydı IP adresini anlamlı bir hostname'e geri çözmelidir. Google sender guidelines, gönderim domainleri veya IP'ler için geçerli forward ve reverse DNS kayıtlarını şartlar arasında sayar.
Örneğin 203.0.113.25 PTR ile mail.example.com'a gidiyorsa mail.example.com A kaydının da 203.0.113.25'e dönmesi sağlıklı bir forward-confirmed reverse DNS yapısı oluşturur.
PTR çoğu zaman Cloudflare veya normal DNS panelinden değil IP bloğunu yöneten VPS/hosting sağlayıcısı tarafından ayarlanır. DNS paneline PTR isimli TXT kaydı eklemek reverse DNS oluşturmaz.
SMTP bağlantısında gönderici sunucu kendisini HELO/EHLO ile tanıtır. localhost, server.local veya internette çözümlenmeyen bir ad kullanmak kötü yapılandırma sinyali olabilir.
Kendi Postfix/Exim sunucunuzu işletiyorsanız HELO/EHLO adının gerçek bir FQDN olması ve PTR/A ilişkisiyle tutarlı çalışması önerilir. Mail hosting servislerinde bu katmanı sağlayıcı yönetebilir.
Bazı teslimat problemlerinde yalnız domain DNS'ine bakmak yeterli değildir; SMTP banner, hostname ve gerçek bağlantı davranışı da kontrol edilmelidir.
Google, Gmail sender requirements içinde SMTP aktarımında TLS kullanılmasını ister. STARTTLS desteği, güncel protokol sürümleri ve sağlıklı sertifika zinciri modern mail altyapısının temel parçalarıdır.
TLS eksikliği her sağlayıcıda otomatik spam sonucu üretmez fakat güvenlik ve uyumluluk açısından önemli bir sinyaldir. Özellikle eski mail sunucuları, hatalı hostname sertifikaları ve yanlış relay yapılandırmaları incelenmelidir.
Port 25 sunucudan sunucuya SMTP teslimatında; 465 ve 587 ise authenticated submission senaryolarında farklı roller taşır.
Google, Gmail hesaplarına mail gönderen tüm göndericiler için SPF veya DKIM, geçerli forward/reverse DNS, TLS ve RFC uyumlu mesaj formatı ister. Günlük 5.000'den fazla Gmail mesajı gönderen bulk sender'lar için SPF ve DKIM birlikte, DMARC, alignment ve marketing/abonelik mesajlarında one-click unsubscribe gibi ek şartlar vardır.
Google Postmaster Tools spam rate değerinin %0,3 altında tutulmasını belirtir. Operasyonel hedef bu üst sınıra yaklaşmak değil mümkün olduğunca altında kalmak olmalıdır.
550 5.7.26 gibi hatalarda Authentication-Results header'ı, SPF/DKIM/DMARC sonucu ve From alignment kontrol edilmelidir.
Microsoft consumer mail servisleri yüksek hacimli göndericiler için daha sıkı authentication gereksinimleri uygular. 550 5.7.515, 5322.From domaininin gereken authentication seviyesini karşılamadığını bildirir.
Teşhiste SPF yetkili kaynaktan pass mı, DKIM gerçek mesajda pass mı, DMARC yayınlanmış mı ve SPF/DKIM yollarından biri From domainiyle alignment sağlıyor mu soruları kontrol edilir.
Üçüncü taraf gönderim servisi kullanılıyorsa Return-Path, From, DKIM d= ve SPF include değerleri birlikte değerlendirilmelidir.
Yahoo sender guidance tüm göndericilerde en az SPF veya DKIM authentication ve düşük spam complaint oranı bekler. Bulk sender tarafında SPF, DKIM ve DMARC birlikte önem kazanır.
Pazarlama maillerinde kolay abonelikten çıkma, hard bounce adreslerini temizleme ve izinli alıcı listesi teslimat sağlığının temel parçalarıdır.
Bir mesajın Gmail'de inbox, Yahoo veya Outlook'ta spam olması mümkündür; sağlayıcıların reputation ve policy sistemleri aynı değildir.
Authentication göndericinin kimliğini kanıtlamaya çalışır; reputation ise geçmiş gönderim davranışına göre güven düzeyi oluşturur. Yeni domain, daha önce spam için kullanılmış IP veya paylaşımlı IP'deki başka müşterilerin davranışı teslimatı etkileyebilir.
Dedicated IP her zaman daha iyi değildir. Düşük hacimli gönderici yeterli pozitif sinyal üretemeyebilir veya kötü warm-up yapabilir. İyi yönetilen shared IP havuzu bazı hacimlerde daha avantajlı olabilir.
Bu nedenle “IP değiştirince düzelir” genellemesi yerine gönderim tipi, hacim, geçmiş ve alıcı dağılımı birlikte değerlendirilmelidir.
Her public blocklist aynı ağırlıkta değildir ve büyük sağlayıcılar kendi özel reputation sistemlerini kullanır. Bununla birlikte itibarlı blocklist'lerde listelenme doğrudan SMTP gönderen sunucu için ciddi bir sinyal olabilir.
Delist başvurusundan önce root cause çözülmelidir: ele geçirilmiş mailbox, web shell, açık relay, kötü liste veya spam script devam ediyorsa IP tekrar listelenebilir.
Paylaşımlı hosting IP'sindeki problem başka müşteriden kaynaklanıyorsa hosting sağlayıcısının outbound relay politikası ayrıca önem kazanır.
İletişim formunda ziyaretçinin yazdığı Gmail/Outlook adresini doğrudan From yapmak yaygın hatadır. Form kendi domaininizden bir From kullanmalı, ziyaretçi adresi Reply-To alanına yazılmalıdır.
PHP mail() ile yerel Exim/Postfix üzerinden gönderimde envelope sender, DKIM ve Return-Path davranışı hosting ayarına bağlıdır. Doğrulanmış SMTP hesabı veya transactional servis kullanmak header ve log kontrolünü iyileştirebilir.
Ancak yalnız SMTP eklentisi kurmak yanlış DNS, bozuk DMARC alignment veya kötü IP reputation sorununu otomatik çözmez.
PHP mail() mesajı yerel mail transfer agent'a teslim eder. SMTP submission uygulamanın kullanıcı adı/OAuth gibi kimlik doğrulama ile belirli mail servisine bağlanmasını sağlar. API tabanlı transactional servisler de ayrı bir gönderim modelidir.
Amazon SES, Mailgun, Postmark, SendGrid gibi servislerde custom domain authentication, DKIM ve return-path yine doğru kurulmalıdır. Servis kullanmak DMARC alignment ihtiyacını ortadan kaldırmaz.
En doğru model transactional/marketing ayrımı, hacim, log ihtiyacı, veri konumu ve reputation yönetimiyle seçilmelidir.
Bir anda binlerce eski veya doğrulanmamış adrese mail göndermek hard bounce ve spam complaint oranını yükseltir. Yeni domain/IP üzerinde ani hacim artışı reputation açısından risklidir.
Bulk mailde izinli liste, double opt-in, hard bounce temizliği, inactive kullanıcıların azaltılması ve unsubscribe akışı teknik DNS kadar önemlidir.
Sipariş/fatura gibi transactional mailler ile marketing kampanyalarını ayrı stream veya subdomain mimarisiyle yönetmek reputation etkisini ayırmaya yardımcı olabilir.
Google, günlük 5.000'den fazla Gmail alıcısına marketing veya subscribed mesaj gönderen bulk sender'larda one-click unsubscribe ister. Bunun için List-Unsubscribe-Post ve List-Unsubscribe header'larının RFC 8058 yaklaşımıyla kullanılması gerekir.
Mesaj gövdesinde de görünür abonelikten çıkma bağlantısı bulunmalıdır. Kullanıcı çıkışını zorlaştırmak spam complaint oranını artırabilir.
Sipariş onayı, şifre sıfırlama gibi transactional mailler marketing mailleriyle aynı kategori değildir.
Authentication-Results SPF, DKIM ve DMARC sonucunu gösterir. Return-Path envelope sender, From kullanıcının gördüğü gönderen, DKIM-Signature içindeki d= signing domain ve s= selector bilgisidir.
Received zinciri mesajın hangi sunuculardan geçtiğini ve route'u gösterir. Bir ekran görüntüsünden ziyade mümkünse tam raw header teşhis için daha değerlidir.
spf=pass, dkim=pass ve dmarc=pass iyi başlangıçtır. Bu üçü geçip mail spam'e düşüyorsa reputation, complaint, engagement ve içerik tarafına geçilir.
Evet. Test araçları DNS, authentication, içerik ve bazı blocklist sinyallerini yararlı biçimde raporlar; fakat Gmail, Microsoft veya Yahoo'nun tüm özel reputation ve kullanıcı etkileşim verilerine sahip değildir.
10/10 puan temel hijyenin iyi olduğunu gösterebilir ancak gerçek inbox placement garantisi değildir. Gerçek alıcıya test gönderip header ve provider-specific sonuçlar incelenmelidir.
Düşük puan görüldüğünde de sadece puanı yükseltmek için rastgele DNS kaydı eklemek yerine her bulgunun gerçek gönderim mimarisiyle ilişkisi doğrulanmalıdır.
Aynı domain web sitesi üzerinden Exim, fatura servisi üzerinden ayrı SMTP, ticket sistemi üzerinden başka servis ve newsletter üzerinden üçüncü platform kullanabilir. Birinin DKIM'i doğruyken diğerinin Return-Path veya SPF alignment'ı bozuk olabilir.
Bu yüzden “domainimde SPF var” demek yeterli değildir; domain adına mail çıkaran tüm kaynakların envanteri çıkarılmalıdır. DMARC raporları bu envanteri doğrulamada yardımcı olur.
Hosting taşıma sonrası eski SPF include, eski DKIM selector veya yanlış outbound IP kalması sık görülen teslimat sorunlarındandır.
DNS TTL ve resolver cache nedeniyle SPF/DKIM/DMARC değişikliği her yerde aynı anda görünmeyebilir. Ayrıca reputation sorunu TXT kaydı düzeldiği anda sıfırlanmaz.
Önce authoritative nameserver ve public resolver sonuçlarında yeni kaydın görüldüğü doğrulanmalı; sonra yeni bir test maili gönderilip yeni Authentication-Results header'ı kontrol edilmelidir.
DKIM selector cache, yanlış DNS zone veya eski nameserver delegasyonu da beklenmeyen sonuçlar üretebilir.
Domain, sorun yaşanan alıcı sağlayıcı, bounce hata metni ve mümkünse test mailinin raw header bilgisi gönderilir. Public DNS üzerinden MX, SPF ve DMARC; header üzerinden gerçek SPF/DKIM/DMARC, Return-Path, DKIM d= ve gönderici IP değerlendirilir.
PTR/rDNS, HELO ve TLS gibi mail sunucusu sinyalleri mümkün olduğunca dışarıdan kontrol edilir. Derin queue, Exim/Postfix log, mailbox compromise veya outbound spam incelemesi gerekiyorsa yetkili erişim ihtiyacı ayrıca açıklanır.
İlk aşamada parola, hosting paneli veya mailbox şifresi gönderilmemelidir.
Örnekleri körlemesine DNS’e eklemeyin; IP, include, domain ve raporlama adreslerini gerçek altyapınıza göre uyarlayın.
v=spf1 ip4:203.0.113.25 -allv=spf1 ip4:203.0.113.25 include:_spf.ornekservis.com -allv=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=rv=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://example.com/unsubscribe/token>Hosting veya yazılımı bizden satın almış olmanız gerekmez.
SPF, DKIM, PTR, HELO, queue, mail log ve outbound IP
Domain authentication, outbound control ve DNS
SPF/DKIM/DMARC, Postmaster ve third-party sender
SPF/DKIM/DMARC, Exchange Online ve alignment
Form, sipariş, üyelik ve SMTP eklentisi
SMTP/API, queue, Return-Path ve From/Reply-To
Bulk authentication, unsubscribe ve reputation
PTR, hostname, TLS, queue ve HELO/EHLO
Spam klasörü mü, bounce mı, gecikme mi?
Web site, mailbox, CRM veya newsletter hangisi gönderiyor?
SPF, DKIM, DMARC, Return-Path, From, d= ve IP çıkar.
SPF, DKIM, DMARC, MX, A/AAAA ve PTR kontrol et.
HELO/EHLO, hostname ve TLS kontrol et.
IP/domain, shared IP, complaint ve bounce ayrımı yap.
Hacim, liste, unsubscribe ve marketing/transactional ayrımı.
Yeni mail header ve alıcı sonucu ile doğrula.
İlk ön analizde alan adınızı, sorun yaşadığınız alıcı sağlayıcısını ve varsa tam hata mesajını inceleyelim. Mümkünse spam'e düşen veya geri dönen mesajın raw header bilgisini paylaşın. Şifre veya panel erişimi ilk aşamada gerekli değildir.
Gmail tüm göndericiler için en az SPF veya DKIM ister; bulk sender tarafında SPF, DKIM ve DMARC birlikte gereklidir. Pratikte üç yöntemi birlikte doğru kurmak en sağlıklı yaklaşımdır.
SPF'nin doğruladığı 5321.MailFrom domaini görünen 5322.From domainiyle alignment sağlamıyorsa SPF, DMARC'yi geçiremez.
Evet. DKIM d= signing domaini From domainiyle hizalı değilse DKIM pass tek başına DMARC pass sağlamaz.
Aynı domain için birden fazla v=spf1 kaydı yerine tüm meşru kaynaklar tek geçerli SPF politikasında birleştirilmelidir.
RFC 7208, include/a/mx/ptr/exists/redirect gibi DNS sorgusu oluşturan SPF terimlerini toplam 10 evaluation lookup ile sınırlar; aşılması PermError üretebilir.
~all softfail, -all fail sonucunu ifade eder. Tüm gerçek gönderim kaynakları doğrulanmadan rastgele hard fail politikasına geçilmemelidir.
Public key'in DNS'te hangi isim altında bulunduğunu gösteren etikettir; gönderilmiş mailde DKIM-Signature s= alanında görülebilir.
Raporlama/gözlem için kullanılır; başarısız mail için quarantine veya reject talimatı vermez.
Aggregate DMARC raporlarının gönderileceği adrestir ve domain adına mail gönderen kaynakları görmeye yardımcı olur.
Genellikle hayır. Reverse DNS IP bloğunu yöneten hosting/VPS sağlayıcısı tarafından ayarlanır.
Google geçerli forward ve reverse DNS ister. PTR veya forward eşleşme problemi 4.7.0 gibi geçici kısıtlama ve teslimat sorunlarına yol açabilir.
Hayır. Test puanı birçok teknik kontrolü kapsar ancak sağlayıcıların özel reputation ve engagement sistemlerini garanti etmez.
Gmail, Outlook ve Yahoo farklı policy ve reputation sistemleri kullanır. Outlook 550 5.7.515 gibi provider-specific authentication hataları da verebilir.
SPF, DKIM, DMARC, Return-Path/5321.MailFrom, 5322.From ve DKIM d= alignment birlikte kontrol edilmelidir.
Gönderici authentication gereksiniminin karşılanmadığını gösterebilir. Tam header içindeki SPF/DKIM/DMARC ve alignment sonucu incelenmelidir.
4.x.x kodları genellikle geçici sınıftadır. PTR, rate limit, reputation veya alıcı policy sorunu olabilir; tam hata metni önemlidir.
Büyük sağlayıcılar sadece public blacklist kullanmaz; kendi domain/IP reputation, complaint ve engagement verilerini de değerlendirir.
Her zaman değil; fakat shared outbound IP'deki başka kullanıcıların davranışı reputation'ı etkileyebilir.
Hayır. Dedicated IP'nin de doğru warm-up ve reputation oluşturması gerekir.
Önerilmez. Kendi doğrulanmış domain adresinizi From, ziyaretçi adresini Reply-To olarak kullanın.
Hayır. SMTP kimlik doğrulama ve loglamayı iyileştirir fakat yanlış DNS veya kötü reputation'ı otomatik çözmez.
Tek başına kötü değildir; davranışı yerel mail sunucusu ayarlarına bağlıdır. Authenticated SMTP/API çoğu uygulamada daha izlenebilir olur.
Gmail hesaplarına günde 5.000'den fazla mesaj gönderen bulk sender'larda SPF ve DKIM, DMARC, PTR, TLS, alignment ve marketing/subscribed mesajlarında one-click unsubscribe gibi gereksinimler vardır.
Google Postmaster Tools spam rate değerinin %0,3 altında tutulmasını ister; operasyonel hedef bunun belirgin biçimde altında olmalıdır.
Gmail şartı marketing ve subscribed mesajlar içindir. Sipariş onayı ve parola sıfırlama gibi transactional mesajlar aynı sınıfta değildir.
Servis teknik olarak izin verse bile reputation açısından ani hacim artışı risklidir; izinli liste ve kontrollü gönderim artışı gerekir.
Sürekli hard bounce alan adresleri listede tutmak liste kalitesini ve reputation'ı bozabilir.
Yeni outbound IP, yanlış PTR, eski SPF/DKIM, değişen hostname veya shared IP reputation sebep olabilir.
Meşru third-party sender doğru authenticate/alignment yapmıyorsa kesilebilir. Önce p=none raporlarıyla envanter doğrulanmalıdır.
Evet. Hesaptan spam gönderilmesi reputation'ı olumsuz etkileyebilir; parola, oturumlar, MFA ve outbound loglar kontrol edilmelidir.
Evet. Zararlı PHP scripti sunucudan spam gönderiyorsa outbound IP/domain itibarı etkilenebilir.
Yeni kayıt public DNS'te görünür olduktan sonra yeni bir mail gönderip raw header sonucunu kontrol edin; reputation düzelmesi ayrıca zaman alabilir.
Domain, sorun yaşanan alıcı sağlayıcı, tam bounce/error metni ve mümkünse spam'e düşen test mailinin raw header bilgisi yeterlidir. İlk aşamada şifre göndermeyin.
Evet. Public DNS ve header analizi sağlayıcıdan bağımsızdır; derin sunucu analizi gerekirse yetkili erişim ayrıca istenir.
İlk ön analizde alan adınızı, sorun yaşadığınız alıcı sağlayıcısını ve varsa tam hata mesajını inceleyelim. Mümkünse spam'e düşen veya geri dönen mesajın raw header bilgisini paylaşın. Şifre veya panel erişimi ilk aşamada gerekli değildir.