Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Wenn geschäftliche E-Mails im Spam landen, nicht ankommen oder mit SMTP-Fehlern zurückkommen, kann die Ursache bei Authentifizierung, Reputation, Reverse DNS, TLS, Alignment, Versandverhalten oder SMTP-Infrastruktur liegen.
Für die erste Prüfung keine Mailbox- oder Hosting-Passwörter senden. Domain, betroffener Provider, vollständiger Bounce-Text und möglichst Raw Header reichen.
SPF, DKIM, DMARC, PTR und SMTP-Reputation
Authentifizierung garantiert keine Inbox. Reputation, Beschwerden, Bounces, Versandspitzen, Listenqualität, Links und Empfängerinteraktion beeinflussen die Filterung.
Domain adına hangi kaynakların mail göndermeye yetkili olduğunu belirtir.
Türkei (Türkisch)
Germany (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+| Fehler / Status | Bereich | Bedeutung | Erste Prüfung |
|---|---|---|---|
| 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 und DMARC bestätigen Identität; Inbox-Platzierung berücksichtigt zusätzlich Reputation, Beschwerden, Bounces und Engagement.
Die konkrete Ursache sollte mit Raw Header, DNS und Provider-Antwort bestätigt werden.
SPF autorisiert Quellen für 5321.MailFrom. Es sollte eine gültige Policy geben und das RFC-7208-Limit von 10 DNS-Lookups beachtet werden.
Die konkrete Ursache sollte mit Raw Header, DNS und Provider-Antwort bestätigt werden.
Der DNS-Key reicht nicht; das System muss die Mail wirklich signieren. d=, s= und Authentication-Results sind zu prüfen.
Die konkrete Ursache sollte mit Raw Header, DNS und Provider-Antwort bestätigt werden.
DMARC benötigt einen aligned SPF- oder DKIM-Pass für die sichtbare From-Domain. p=none eignet sich zum Monitoring.
Die konkrete Ursache sollte mit Raw Header, DNS und Provider-Antwort bestätigt werden.
SPF oder DKIM können technisch passen und trotzdem nicht mit der sichtbaren From-Domain aligned sein.
Die konkrete Ursache sollte mit Raw Header, DNS und Provider-Antwort bestätigt werden.
Große Provider erwarten gültiges Forward- und Reverse-DNS. PTR wird vom IP-Provider verwaltet.
Die konkrete Ursache sollte mit Raw Header, DNS und Provider-Antwort bestätigt werden.
HELO/EHLO sollte ein auflösbarer FQDN sein und bei eigenem SMTP sinnvoll zu PTR/A passen.
Die konkrete Ursache sollte mit Raw Header, DNS und Provider-Antwort bestätigt werden.
STARTTLS und aktuelle TLS-Unterstützung sind Teil moderner SMTP-Hygiene.
Die konkrete Ursache sollte mit Raw Header, DNS und Provider-Antwort bestätigt werden.
Google verlangt SPF oder DKIM, Forward/Reverse DNS und TLS; Bulk Sender benötigen zusätzliche DMARC-, Alignment- und Unsubscribe-Konformität.
Google nennt eine Spam-Rate unter 0,3 Prozent als Anforderung.
550 5.7.515 bedeutet, dass die sichtbare From-Domain die erforderliche Microsoft-Authentifizierung nicht erfüllt.
SPF, DKIM, DMARC und Drittanbieter-Alignment gemeinsam prüfen.
Yahoo erwartet Authentifizierung und niedrige Complaint-Raten; Bulk Sender sollten SPF, DKIM und DMARC einsetzen.
Die konkrete Ursache sollte mit Raw Header, DNS und Provider-Antwort bestätigt werden.
Authentifizierung beweist Identität; Reputation bewertet historische Vertrauenssignale. Dedicated IP ist nicht automatisch besser.
Die konkrete Ursache sollte mit Raw Header, DNS und Provider-Antwort bestätigt werden.
Public Blocklists sind ein Signal, aber nicht die einzige Filterquelle großer Provider.
Die konkrete Ursache sollte mit Raw Header, DNS und Provider-Antwort bestätigt werden.
Eigene Domain als From, Besucheradresse als Reply-To verwenden. SMTP hilft, ersetzt aber keine korrekten DNS-Records.
Nicht die Besucher-Gmail-Adresse direkt als From setzen.
PHP mail() nutzt den lokalen MTA; authentifiziertes SMTP/API bietet mehr Kontrolle und Logs.
Die konkrete Ursache sollte mit Raw Header, DNS und Provider-Antwort bestätigt werden.
Alte Listen, Hard Bounces und abrupte Volumensprünge können Reputation schnell verschlechtern.
Die konkrete Ursache sollte mit Raw Header, DNS und Provider-Antwort bestätigt werden.
Qualifizierende Bulk-Marketing-Sender benötigen einfache standardisierte Abmeldung.
Die konkrete Ursache sollte mit Raw Header, DNS und Provider-Antwort bestätigt werden.
Authentication-Results, Return-Path, From, DKIM d=/s= und Received-Zeilen sind die wichtigsten Felder.
Die konkrete Ursache sollte mit Raw Header, DNS und Provider-Antwort bestätigt werden.
Öffentliche Tester sind nützlich, bilden aber nicht alle privaten Reputation- und Engagement-Signale ab.
Die konkrete Ursache sollte mit Raw Header, DNS und Provider-Antwort bestätigt werden.
Website, CRM, Rechnung und Newsletter können unter derselben Domain unterschiedliche Authentifizierung haben.
Die konkrete Ursache sollte mit Raw Header, DNS und Provider-Antwort bestätigt werden.
TTL und Resolver-Cache verzögern Sichtbarkeit; Reputation wird durch TXT-Änderung nicht zurückgesetzt.
Die konkrete Ursache sollte mit Raw Header, DNS und Provider-Antwort bestätigt werden.
Domain, Provider, Bounce-Text und Raw Header reichen für die erste öffentliche Analyse.
Beim ersten Schritt keine Passwörter senden.
Beispiele nicht blind übernehmen; Werte müssen zur eigenen Infrastruktur passen.
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 oder Software müssen nicht von uns stammen.
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.
Domain, betroffenen Provider, vollständigen Fehler und möglichst Raw Header senden. Beim ersten Schritt sind keine Passwörter erforderlich.
Ja. Reputation, Beschwerden, Engagement und Listenqualität wirken zusätzlich.
Die MailFrom-Domain kann nicht mit der sichtbaren From-Domain aligned sein.
Ja, wenn die DKIM-Signing-Domain nicht aligned ist.
Es sollte eine gültige SPF-Policy pro Domain verwendet werden.
RFC 7208 begrenzt DNS-abfragende SPF-Terme auf 10 pro Auswertung.
Normalerweise nein. Reverse DNS verwaltet der IP-Provider.
Nein. Private Provider-Reputation wird nicht vollständig abgebildet.
Provider nutzen unterschiedliche Regeln und Reputation.
Häufig unzureichende Authentifizierung; SPF/DKIM/DMARC prüfen.
Die From-Domain erfüllt die erforderliche Authentifizierungsstufe nicht.
Nicht allein; DNS, Alignment und Reputation müssen stimmen.
Nein. Eigene Domain als From und Besucher als Reply-To.
Nein. Sie benötigt eigenen Ruf und kontrolliertes Warm-up.
Standardisierte Abmeldung für bestimmte Bulk-Marketing-/Subscription-Sender.
Ja, wenn Spam über Server oder Mailbox gesendet wird.
Domain, Provider, Bounce-Text und möglichst Raw Header; keine Passwörter im ersten Schritt.
Domain, betroffenen Provider, vollständigen Fehler und möglichst Raw Header senden. Beim ersten Schritt sind keine Passwörter erforderlich.