Eben landet ein Newsletter im Spam. Von den Grünen! Warum im Spam?
Ich schaue in die Header.
Kein DKIM.
Kein DMARC.
Grundlagen fehlen.
Und ich werde wütend.
Nicht aus Prinzip.
Sondern weil es vermeidbar ist.
Was hier technisch passiert
E-Mail ist längst kein harmloses Kommunikationsmittel mehr.
Sie ist ein Hochsicherheits-Ökosystem.
Damit eine Domain vertrauenswürdig wirkt, braucht sie mindestens:
- SPF – wer darf senden?
- DKIM – wurde die Mail unterwegs verändert?
- DMARC – was soll passieren, wenn die Prüfung fehlschlägt?
Fehlt das, entsteht:
- Unsicherheit bei empfangenden Servern
- geringere Zustellwahrscheinlichkeit
- leichteres Spoofing
- kein sauberer Reputationsaufbau
Gerade Newsletter-Systeme stellen diese Mechanismen bereit.
Man muss die DNS-Einträge nur setzen.
Das ist kein High-End-Security-Thema.
Das ist Basisarbeit.
Warum das mehr ist als ein technischer Schönheitsfehler
Mailserver arbeiten mit Reputationssystemen.
Sie bewerten:
- Beschwerderaten
- Spam-Treffer
- Bounce-Quoten
- IP-Historie
- Domain-Verhalten
Wenn über eine Domain problematische Mails laufen, kann passieren:
- Die Versand-IP wird blockiert
- Die Domain landet auf Blocklists
- Große Provider senken das Trust-Level
Das betrifft nicht nur den einen Newsletter.
Das betrifft alle legitimen Absender unter dieser Domain.
Reputationsschaden ist ein kollektives Problem.
Ein realistisches Szenario
Stell dir eine kleine gemeinnützige Organisation vor:
- Günstiger Newsletter-Tarif
- Ein gemeinsamer Account
- Passwort wird geteilt
- Kein Passwortmanager
- Keine Zwei-Faktor-Authentifizierung
- Keine saubere Rollenstruktur
Ein kompromittiertes Passwort reicht.
Dann kann jemand:
- Spam versenden
- Listen exportieren
- Reputation beschädigen
Das merkt niemand sofort.
Ein paar Tage genügen.
Kein spektakulärer Hack.
Nur ein schwaches Setup.
Reputations-DoS
Das ist kein klassischer Denial-of-Service.
Es ist subtiler.
Man beschädigt die Vertrauenswürdigkeit einer Domain,
bis legitime Kommunikation nicht mehr zugestellt wird.
Für NGOs, Initiativen oder kleine Vereine kann das existenziell sein.
Kommunikationsfähigkeit ist Handlungsfähigkeit.
Böser Wille oder fehlendes Wissen?
In vielen Fällen ist es:
- kein Budget
- kein IT-Know-how
- kein Bewusstsein für Risiken
- „es lief doch bisher“
Mail wirkt einfach.
Ist es nicht.
Digitale Souveränität beginnt hier
Wenn Organisationen:
- ihre Mail-Infrastruktur nicht verstehen
- keine saubere Authentifizierung haben
- keine Passwortkultur pflegen
dann sind sie angreifbar.
Nicht spektakulär.
Still.
Systemisch.
Digitale Souveränität ist keine Ideologie.
Sie beginnt mit SPF, DKIM, DMARC und einem Passwortmanager.
Und mit der Entscheidung, Verantwortung für die eigene Infrastruktur zu übernehmen.
Ein kleiner technischer Mindeststandard
Wer Newsletter versendet, sollte mindestens:
- SPF korrekt setzen
- DKIM aktivieren
- DMARC mit Monitoring konfigurieren
- 2FA für alle Accounts nutzen
- Rollen statt geteilte Logins verwenden
- Bounce- und Complaint-Raten beobachten
Das ist kein Luxus.
Das ist Grundhygiene.
Warum mich das beschäftigt
Weil fehlende Mail-Signaturen kein isolierter Fehler sind.
Sie sind ein Symptom.
Für strukturelle Unterfinanzierung.
Für fehlende Begleitung.
Für digitale Abhängigkeit.
Und genau dort beginnt die eigentliche Arbeit.
Digitale Infrastruktur ist kein Nebenthema.
Sie ist Voraussetzung für Vertrauen.
Für Wirksamkeit.
Für gesellschaftliche Teilhabe.
Wenn wir das ernst nehmen, dann kümmern wir uns auch um die Header.
Ein konkretes Beispiel
Praxisbeispiel: Warum dieser Newsletter im Spam landete
Vor kurzem landet ein politischer Newsletter im Spam-Ordner.
Kein dubioser Absender. Keine obskuren Links. Offizielle Kommunikation.
Ein Blick in die Header zeigt:
Authentication-Results:
dkim=none;
spf=pass (für bounce-domain);
dmarc=noneUnd weiter unten:
Precedence: bulk
X-Spam: Yes
X-Spam-Level: **********Was ist hier passiert?
1. Keine DKIM-Signatur
Die Mail wurde nicht kryptografisch signiert.
Das bedeutet: Der empfangende Server kann nicht prüfen, ob der Inhalt unterwegs verändert wurde.
Für professionelle Newsletter ist das heute ein schwerwiegender Mangel.
2. Kein DMARC
Es existiert keine veröffentlichte Richtlinie, wie Empfänger mit Authentifizierungsfehlern umgehen sollen.
Das erschwert die Vertrauensbewertung erheblich.
3. SPF zwar „pass“, aber nicht aligned
Der SPF-Check bezieht sich auf eine technische Bounce-Domain.
Die sichtbare Absenderadresse nutzt eine andere Domain.
Moderne Spamfilter bewerten dieses Domain-Mismatch kritisch, insbesondere bei Massenmail.
4. Bulk-Versand ohne moderne Absicherung
Die Mail trägt den Header:
Precedence: bulk
Bulk-Mails unterliegen verschärften Prüfungen.
Ohne DKIM und DMARC ist die Wahrscheinlichkeit hoch, dass sie aussortiert werden.
Das Problem ist strukturell
Hier liegt kein offensichtlicher Angriff vor.
Es wirkt wie eine gewachsene, technisch nicht modernisierte Newsletter-Infrastruktur.
Das ist kein Einzelfall.
Viele Organisationen betreiben:
- eigene phpList-Installationen
- ältere Mailserver
- unvollständige DNS-Konfiguration
- keine saubere Domain-Authentifizierung
Solange nichts eskaliert, bleibt das unbemerkt.
Erst wenn Mails systematisch im Spam landen, wird es sichtbar.
Warum das relevant ist
Fehlende DKIM- und DMARC-Einträge sind kein Detail.
Sie beeinflussen:
- Zustellbarkeit
- Domain-Reputation
- Wahrnehmung der Organisation
- langfristige Kommunikationsfähigkeit
Digitale Souveränität beginnt nicht bei großen Strategien.
Sie beginnt bei korrekt gesetzten DNS-Einträgen.
Und bei der Entscheidung, Infrastruktur nicht nur zu betreiben, sondern zu verstehen.
Fazit zum konkreten Beispiel
Der untersuchte Newsletter landete im Spam, weil ihm zwei zentrale Elemente moderner Mail-Authentifizierung fehlen: DKIM und DMARC. Technisch ist das im Jahr 2026 ein klarer Nachteil – insbesondere bei Bulk-Versand.
Im konkreten Fall spricht jedoch vieles dafür, dass es sich um einen internen Verteiler handelt. Die Infrastruktur wirkt eigenständig betrieben, konsistent konfiguriert und nicht kompromittiert. SPF funktioniert. Der Mailfluss ist sauber. Es gibt keine Hinweise auf Manipulation oder Missbrauch.
Allerdings filtert ja offenbar selbst der hausinterne Mailserver diese Mailings als Spam raus. Das ist total unnötig!
Das Problem ist hier weniger Sicherheit im Sinne eines Angriffs, sondern fehlende Modernisierung.
Für interne Kommunikation kann das ausreichend sein.
Für externe, reputationsrelevante Massenkommunikation wäre es deutlich zu wenig.
Ich kenne keinen guten Grund, warum das so sein sollte. Es ist mit wenig Aufwand korrigierbar und es gibt keinen technischen oder wirtschaftlichen Vorteil, das so zu machen.
Weg damit!
Zuletzt aktualisiert am 12. Februar 2026.