Befund mit Ausgangswerten
Die sechs Prüfpunkte, gemessen vor den Korrekturen.
E-Mails landen im Spam? Ursache finden und Maßnahmen festlegen
Rechnungen, Angebote oder Einmalpasswörter landen im Spam oder kommen zurück? Gmail setzt seine Regeln für Absender seit November 2025 verstärkt durch, auch mit Ablehnungen (Stand: 2026-10). Wir prüfen SPF, DKIM, DMARC und Reputation und legen Ihnen eine schriftliche Maßnahmenliste vor.
- Postfix- und Dovecot-Server und Transaktionsmail für praktisch alle Kunden
- Antwort innerhalb eines Werktags
Landet die Mail im Spam-Ordner oder kommt sie zurück?
Die Mail liegt im Spam-Ordner
Der Empfänger nimmt die Mail an, stuft sie aber als verdächtig ein. Häufige Ursachen sind fehlende Authentifizierung (SPF, DKIM, DMARC), ein schlechter Ruf von Domain oder IP-Adresse und ein System, das ungeprüft in Ihrem Namen sendet.
Die Mail kommt zurück
Im Rücklauf (Bounce) steht ein Fehlercode wie 4.7.x oder 5.7.x. Der Empfängerserver lehnt die Mail ab, weil die Authentifizierung scheitert, der Reverse-DNS-Eintrag fehlt, die Verbindung unverschlüsselt ist oder die IP-Adresse auf einer Sperrliste steht.
Ein Beispiel ist Microsoft. Wer 5.000 oder mehr Mails mit derselben Absenderdomain an Outlook.com, Hotmail, Live.com oder MSN sendet, muss SPF und DKIM bestehen und einen DMARC-Eintrag mit mindestens p=none haben. Die Domain der Absenderadresse muss dabei zu SPF oder DKIM passen. Sonst kommt die Mail mit dem Fehlercode „550 5.7.515 Access denied“ zurück. Microsoft setzt diese Anforderungen nach eigener Angabe jetzt durch (Microsoft Support (öffnet in einem neuen Fenster), Stand: 2026-10).
Typische Anlässe
- Ein Umzug auf einen neuen Server, etwa von Windows/IIS nach Linux: IP-Adresse, Reverse-DNS-Eintrag und HELO-Name ändern sich, der SPF-Eintrag nennt noch die alte Adresse.
- Ein neues CRM, ein Newsletter-Dienst oder ein Helpdesk sendet mit Ihrer Domain.
- Ein Großkunde fragt nach SPF, DKIM und DMARC.
- Niemand im Haus kennt den Mailserver mehr.
Erste Diagnose in 15 Minuten: sechs Prüfpunkte
| Prüfpunkt | Was er sichert | So prüfen Sie es | Typischer Fehler |
|---|---|---|---|
| SPF | Welche Server für Ihre Domain senden dürfen. |
TXT-Eintrag abfragen: dig +short TXT ihre-domain.de. Er beginnt mit v=spf1.
|
Ein Absender fehlt, es gibt zwei SPF-Einträge oder mehr als zehn DNS-Abfragen. |
| DKIM | Versieht jede Mail mit einer Signatur Ihrer Domain, an der der Empfänger Herkunft und Unversehrtheit prüft. | Testmail an ein Gmail-Postfach senden und dort „Original anzeigen“ wählen. Dort stehen auch SPF und DMARC. | Das System signiert nicht oder mit einer anderen Domain als der Absenderdomain. |
| DMARC | Was mit Mails geschieht, die SPF und DKIM nicht bestehen, und Berichte darüber. | TXT-Eintrag unter _dmarc.ihre-domain.de abfragen. Er beginnt mit v=DMARC1. | Kein Eintrag, oder p=none seit Jahren ohne Auswertung der Berichte. |
| Reverse-DNS (PTR) | Ordnet der IP-Adresse des Mailservers einen Namen zu, der zurück auf die Adresse zeigt. |
dig -x mit der IP-Adresse abfragen, den Namen danach wieder auflösen.
|
Standardname des Hosters, oder er weicht vom HELO-Namen des Servers ab. |
| TLS | Verschlüsselt die Übertragung zwischen Mailservern. |
openssl s_client -starttls smtp -connect mail.ihre-domain.de:25 zeigt Zertifikat und Verschlüsselung.
|
Zertifikat abgelaufen oder für einen anderen Namen ausgestellt, oder kein STARTTLS. |
| Abmelde-Kopfzeile | Abmeldung mit einem Klick, bei Newslettern und Werbemails im Massenversand verlangt. | Kopfzeilen einer Newsletter-Mail auf List-Unsubscribe und List-Unsubscribe-Post prüfen. | Die Kopfzeile fehlt, oder Abmeldungen werden nicht verarbeitet. |
Welche Systeme senden noch in Ihrem Namen?
Stimmen die sechs Prüfpunkte, lohnt ein Blick auf die anderen Systeme, die mit Ihrer Domain senden: CRM, Newsletter-Dienst, Helpdesk, Buchhaltung oder ein Webformular. Jedes davon sollte im SPF-Eintrag stehen und einen DKIM-Schlüssel für Ihre Domain haben; sonst fallen seine Mails bei der Prüfung des Empfängers unter Umständen durch.
Diese Absender suchen wir im DNS, in den Logs Ihres Mailservers und in vorhandenen DMARC-Berichten. Die Berichte zeigen alle Server, die mit Ihrer Domain senden. Fehlen Berichte, sammeln wir sie zunächst mit p=none. Das braucht mehr Zeit als der Check selbst.
So läuft der Zustellbarkeits-Check
-
Zugang und Messung
Wir erhalten Zugriff auf DNS und Mailserver oder Auszüge der Logs, dazu Beispiele betroffener Mails. Wir messen die sechs Prüfpunkte und senden Testmails an Postfächer großer Anbieter.
-
Absender erfassen
Wir ermitteln aus DNS, Logs und vorhandenen DMARC-Berichten, welche Systeme in Ihrem Namen senden, und prüfen ihre Mails auf SPF und DKIM.
-
Ursachen bewerten
Wir prüfen die Reputation Ihrer IP-Adressen und Ihrer Domain, zum Beispiel auf Sperrlisten, und ordnen die Befunde nach Wirkung und Aufwand.
-
Maßnahmenliste und Besprechung
Sie erhalten den schriftlichen Befund und den Plan für DMARC. Wir besprechen beides mit Ihnen und Ihrer IT.
Was der Check-Bericht enthält
Die Korrekturen setzt Ihre IT anhand der Liste um, oder wir führen sie auf Wunsch als eigenes Projekt aus.
-
-
Liste der gefundenen Absender
Die Systeme, die mit Ihrer Domain senden, jedes mit dem Ergebnis der Prüfung.
-
Maßnahmen nach Priorität
Mit Ort der Änderung (DNS, Anwendung oder Mailserver) und Aufwand.
-
Plan für DMARC
Die Schritte von p=none bis p=reject, mit Adresse für die Berichte.
Was Gmail und Yahoo von Absendern verlangen
| Datum | Ereignis | Quelle |
|---|---|---|
| 2024-02-01 | Gmail verlangt von allen Absendern SPF oder DKIM, gültige Forward- und Reverse-DNS-Einträge (PTR), TLS und eine Spam-Rate unter 0,3 %. Ab etwa 5.000 Mails pro Tag an Gmail-Adressen kommen SPF und DKIM zusammen sowie DMARC mit Alignment hinzu. | support.google.com (öffnet in einem neuen Fenster) |
| 2024-02-01 | Ab Februar 2024 verlangt Yahoo von allen Absendern SPF oder DKIM, gültige Forward- und Reverse-DNS-Einträge und Spam-Beschwerden unter 0,3 %. Massenversender brauchen beides, dazu DMARC und die Bearbeitung von Abmeldungen binnen zwei Tagen. | senders.yahooinc.com (öffnet in einem neuen Fenster) |
| 2024-06-01 | Gmail verlangt von Massenversendern für Marketing- und Werbemails die Abmeldung mit einem Klick. Wer schon einen Abmeldelink hatte, bekam bis zu diesem Datum Zeit. | support.google.com (öffnet in einem neuen Fenster) |
| 2025-11-01 | Ab November 2025 setzt Gmail die Anforderungen verstärkt durch. Nicht konforme Mails werden zunehmend zeitweise oder dauerhaft abgelehnt, erkennbar an Fehlercodes der Reihen 4.7.x und 5.7.x. | support.google.com (öffnet in einem neuen Fenster) |
DMARC-Plan: von p=none bis p=reject, ohne eigene Mails zu blockieren
-
Beobachten mit p=none
Wir veröffentlichen DMARC mit p=none und einer Adresse für die Berichte. Mails kommen weiter an wie bisher, und die Berichte zeigen alle Absender und wo SPF oder DKIM scheitern.
-
Absender in Ordnung bringen
Wir richten SPF und DKIM für jedes legitime System ein, bis die Berichte keine eigenen Mails mehr als fehlerhaft ausweisen. Je nach Zahl der Absender dauert das Wochen.
-
Umstellen auf p=quarantine
Mails, die DMARC nicht bestehen, landen beim Empfänger im Spam-Ordner. Wir lesen die Berichte weiter und korrigieren, was auffällt.
-
Umstellen auf p=reject
Bleiben die Berichte sauber, lehnen Empfänger Mails ab, die Ihre Domain als Absender tragen, aber DMARC nicht bestehen. Wir beobachten weiter, denn neue Systeme kommen dazu. BIMI, die Anzeige Ihres Logos beim Empfänger, ist ein optionaler Zusatz und keine Voraussetzung für die Zustellung.
Wenn die Anwendung selbst die Mails verschickt
Viele Anwendungen versenden Mails selbst: ColdFusion und Lucee mit cfmail, PHP mit mail() oder mit einer Bibliothek. Typische Fehler:
- Die Anwendung sendet direkt vom Webserver, statt sich per SMTP an einem Mailserver anzumelden (Submission). Der SPF-Eintrag kennt diesen Server nicht.
- Die Absenderadresse gehört zu einer anderen Domain als die, für die SPF und DKIM gelten.
- Rückläufer landen in einem Postfach, das niemand liest, und ungültige Adressen bleiben im Verteiler.
Läuft der Versand über einen eigenen Postfix-Server, prüfen wir auch dessen Konfiguration, die Warteschlange und die Logs. Die Maßnahmenliste nennt, wo der Fehler entsteht: in der Anwendung, auf dem Mailserver oder im DNS. Mehr zu unserer Arbeit mit ColdFusion und Lucee und mit PHP finden Sie auf den Technologie-Seiten.
Erfahrung unserer Ingenieure mit Mailserver und Anwendungsmail
- Mailbetrieb
- Postfix- und Dovecot-Server sowie Systeme für Transaktionsmail, für praktisch alle Kunden
- Anwendungsmail
- Versand aus ColdFusion, Lucee und PHP, einschließlich Rückläufern und Abmeldungen
- Authentifizierung und Ruf
- SPF, DKIM und DMARC mit Berichten, Reverse-DNS, TLS und Reputation von Absendern
- Full Stack und DevOps
- Seit 2012, von der Anwendung bis zum Server
So arbeiten wir an der Zustellbarkeit Ihrer Mails
- Zugangsdaten, Konfiguration und Dokumentation bleiben bei Ihnen.
- Wir sagen Ihnen auch, wenn sich etwas nicht lohnt.
Über die Zustellung entscheidet der Empfängerserver
Der Check umfasst deshalb das, worauf wir Einfluss haben: den technisch korrekten Versand, die Vorgaben der Mailanbieter und die Messung des Ergebnisses.
Und wenn bei uns jemand ausfällt?
Die Dokumentation erstellen wir auf Wunsch. Das Repository liegt in der Regel bei Ihnen. Eine Vertretung stellen wir auf Wunsch. Wie wir zusammenarbeiten, beschreibt die Seite So arbeiten wir.
Der erste Schritt: Zustellbarkeits-Check mit Maßnahmenliste und Plan für DMARC
Zustellbarkeits-Check
Für Unternehmen, deren Rechnungen, Angebote oder Einmalpasswörter im Spam landen oder als unzustellbar zurückkommen.
- DNS-Einträge Ihrer Domain: SPF, DKIM, DMARC und Reverse DNS (PTR)
- Reputation Ihrer Domain und Ihrer Absender-IP-Adressen
- Header echter Mails aus Ihrer Anwendung und Ihren übrigen Systemen
- Testversand an Postfächer großer Anbieter
- Liste der Korrekturen nach Priorität
Umfang und Preis legen wir im Erstgespräch fest und bestätigen sie schriftlich, bevor wir beginnen. Nicht enthalten sind die Korrekturen selbst und der dauerhafte Betrieb von Mailservern. Beides vereinbaren wir auf Wunsch danach.
Was das Ergebnis enthält
Eine schriftliche Maßnahmenliste mit den Ursachen und den Korrekturen nach Priorität, dazu ein Plan für DMARC. Beides gehört Ihnen.
Zwei Fälle aus unserer Arbeit
-
E-Mail-Zustellbarkeit für vier Firmendomains
Ein Mailserver für vier Firmendomains signierte nichts, veröffentlichte keine DMARC-Richtlinie und wurde von Microsoft abgewiesen. Unsere Ingenieure haben ihn geprüft, die Änderung an einer Domain erprobt und in Gruppen ausgerollt. Das Ergebnis: Alle drei Prüfungen bestehen bei Gmail, die Microsoft-Sperre ist aufgehoben, und die Nutzer haben nichts bemerkt.
-
Ein Spamfilter, der lief, aber nicht schützte
Dienste liefen, die Konfiguration war gültig, im Systemstatus stand kein Fehler. Trotzdem landete Phishing im Posteingang, während Newsletter von Partnern im Spam lagen. Unsere Ingenieure haben gemessen, welche Erkennungsmechanismen tatsächlich ansprangen, die Ursachen behoben und drei Monate später eine Regression gefunden und behoben, die sich nur stundenweise zeigte.
Häufige Fragen zu Spam, SPF, DKIM und DMARC
Blockiert DMARC mit p=reject unsere eigenen Rechnungen?
Nicht, wenn alle Absender vorher erfasst und eingerichtet sind. Wir beginnen mit p=none und lesen die DMARC-Berichte: Sie zeigen, welche Systeme in Ihrem Namen senden. Für jedes legitime System richten wir SPF und DKIM ein und stellen erst auf p=quarantine und dann auf p=reject um, wenn die Berichte keine eigenen Mails mehr als fehlerhaft ausweisen.
Kommt später ein neues System dazu, braucht es vor dem ersten Versand eine Freigabe in SPF und einen DKIM-Schlüssel. Sonst lehnen Empfänger seine Mails ab.
Reicht es, wenn unser Newsletter-Dienst die Mails signiert?
Nicht automatisch. Viele Dienste signieren zunächst mit ihrer eigenen Domain. Für DMARC muss die Signatur oder der SPF-Eintrag aber zu Ihrer Absenderdomain passen (Alignment). Dafür richten Sie beim Dienst Ihre Domain als Absenderdomain ein und tragen die genannten DNS-Einträge bei sich ein.
Ob das geschehen ist, zeigen die Kopfzeilen einer Testmail (Authentication-Results) und die DMARC-Berichte. Dasselbe gilt für CRM, Helpdesk und andere Systeme, die in Ihrem Namen senden.
Warum landen Mails nach einem Serverumzug im Spam?
Bei einem Umzug ändern sich meist IP-Adresse, Reverse-DNS-Eintrag und der Name, mit dem sich der Server meldet (HELO). Der SPF-Eintrag nennt dann noch die alte Adresse, und der DKIM-Schlüssel fehlt oft auf dem neuen System. Außerdem hat eine neue IP-Adresse bei den großen Anbietern noch keinen Ruf.
Das betrifft auch Anwendungen, die selbst Mails versenden, etwa mit cfmail nach einem Wechsel von Windows/IIS auf Linux. Bei einem geplanten Umzug gehören diese Punkte deshalb auf die Checkliste, bevor die Server umgestellt werden.
Wie schnell wirken die Korrekturen?
Das hängt zuerst davon ab, wann die Korrekturen in die Systeme kommen: Änderungen im DNS, am Mailserver oder in der Anwendung nimmt Ihre IT vor, Ihr Hoster oder wir, sobald wir Zugang haben. Änderungen im DNS greifen, wenn die Gültigkeitsdauer des bisherigen Eintrags (TTL) abgelaufen ist. Der Ruf einer Domain oder IP-Adresse erholt sich je nach Anbieter und Ursache unterschiedlich schnell; deshalb lohnt nach den Korrekturen eine erneute Messung.
Können Sie garantieren, dass unsere E-Mails im Posteingang landen?
Eine Zustellgarantie ist technisch nicht möglich, denn der Empfängerserver entscheidet. Wir sorgen für eine technisch korrekte, richtlinienkonforme und überwachte Zustellung. SPF, DKIM und DMARC stimmen, die Reputation Ihrer Absender wird beobachtet, und alle Systeme, die in Ihrem Namen senden, sind erfasst. Danach messen wir das Ergebnis.
Was ist, wenn uns Zugangsdaten fehlen?
Das lässt sich meist lösen. Wir beginnen mit dem, was Sie in der Hand haben: Vertrag und Kundenkonto beim Hoster, Zugang zur Domain und, soweit vorhanden, Zugriff auf Repository und Backups. Server-Zugänge lassen sich über den Hoster oft zurücksetzen, wenn Sie als Vertragspartner auftreten. Zugang zu einem System verschaffen wir uns nur mit Ihrer ausdrücklichen Zustimmung.
Wann können Sie starten?
Eine erste Antwort erhalten Sie innerhalb eines Werktags. Wann wir mit der Arbeit beginnen, hängt von der aktuellen Auslastung und vom Umfang ab. Das sagen wir Ihnen im Erstgespräch verbindlich. Ist es dringend, beginnt die 48-Stunden-Einschätzung, sobald wir Zugriff auf das System haben.
Welche Mails landen bei Ihnen im Spam?
Nennen Sie uns, welche Mails betroffen sind, bei welchen Empfängern und seit wann. Wir antworten innerhalb eines Werktags und schlagen den passenden ersten Schritt vor.