SMTP in Contao: Warum, wie – und was jeder Hoster anders macht

„Contao verschickt doch auch ohne SMTP Mails.“ Stimmt. Die Frage ist nur, ob sie ankommen.

Die kurze Antwort: Ein SMTP-Account ist keine Pflicht – doch fast immer die bessere Wahl. Ohne Einrichtung gibt Contao jede Mail an den Mailversand des Webservers weiter. Der verschickt sie im Namen deiner Domain, ohne dafür eingetragen zu sein. Empfangende Mailserver merken das. Und sortieren aus.

Mit SMTP meldet sich Contao bei einem echten Postfach an und verschickt darüber. Absender, Server und Domain passen dann zusammen.

Das gilt für Contao 5 und Contao 6 gleichermaßen. Nachgesehen haben wir im Code von Contao 5.3 und 6.0.

Was Contao ohne SMTP macht

Ist kein Mailserver eingetragen, nutzt Contao automatisch den Transport native://default. Die Mail geht dann an das Programm, das in der php.ini unter sendmail_path hinterlegt ist – meist sendmail auf dem Webserver.

Das funktioniert, wenn

• der Hoster sendmail eingerichtet hat,
• er den Versand nicht einschränkt
• und die empfangenden Mailserver dem Webserver vertrauen.

Drei Bedingungen. Keine davon hast du in der Hand.

3 Gründe für SMTP

1. Absender und Server passen zusammen

Empfangende Mailserver prüfen jede Mail: Darf dieser Server für diese Domain verschicken? Die Antwort steht im DNS der Domain – in drei Einträgen:

• SPF listet die Server, die für die Domain verschicken dürfen.
• DKIM signiert jede Mail. Den Schlüssel zum Prüfen findet der Empfänger im DNS.
• DMARC legt fest, was mit Mails passiert, die durchfallen: zustellen, in den Spam oder ablehnen.

Ein typischer Fall: Die Mails von beispiel.de laufen über Microsoft 365, die Website liegt bei einem Webhoster. Schickt Contao das Kontaktformular über den Webserver, steht der in keinem SPF-Eintrag. Ergebnis: Spam-Ordner. Oder gar keine Zustellung.

Mit SMTP verschickt Contao über die Server, die im SPF-Eintrag stehen und per DKIM signieren.

Seit Februar 2024 ist das kein Bonus mehr. Gmail und Yahoo verlangen von jedem Absender mindestens SPF oder DKIM (Google-Richtlinien für E-Mail-Absender). Wer mehr als 5.000 Mails am Tag an Gmail-Adressen schickt, braucht beides – plus DMARC.

2. Spam von fremden Websites trifft deine Mails nicht

Beim Shared Hosting teilt sich deine Website den Server mit vielen anderen Websites. Ohne SMTP verschicken alle ihre Mails über diesen Server – und damit über dieselbe IP-Adresse.

Empfangende Mailserver bewerten Mails auch nach dieser IP-Adresse. Verschickt eine andere Website auf dem Server Spam, etwa über ein gehacktes Formular, kommt die IP-Adresse auf eine Sperrliste. Ab dann landen auch deine Mails im Spam oder werden abgelehnt. Obwohl deine Website nichts falsch gemacht hat.

Mit SMTP verschickt Contao über die Mailserver deines Mailanbieters. Was andere Websites auf dem Webserver treiben, spielt für deine Mails dann keine Rolle mehr.

3. Der Versand hängt nicht am Server

Nicht jeder Server bringt einen funktionierenden Mailversand mit. Eigene Cloud-Server haben oft keinen. Manche Hoster schränken ihn ein oder sperren Ports (siehe unten).

Mit SMTP verschickt Contao auf der Stage und auf dem Live-System gleich. Und nach einem Serverumzug nimmst du die .env.local mit – fertig.

So richtest du SMTP in Contao 5 und 6 ein

Der Weg ist in beiden Versionen identisch. Du brauchst die Zugangsdaten des Postfachs: Server, Port, Benutzername, Passwort.

Ein Postfach: die .env.local

Trag den Mailserver als MAILER_DSN in die .env.local im Hauptverzeichnis deiner Installation ein:

MAILER_DSN=smtp://website%40beispiel.de:PASSWORT@smtp.beispiel.de:587

Das Schema dahinter: smtp://BENUTZER:PASSWORT@SERVER:PORT.

Drei Details, an denen es meistens hakt:

• Sonderzeichen müssen URL-kodiert sein. Das gilt für Benutzername und Passwort. Aus @ wird %40, aus # wird %23. Mehr dazu in Umgebungsvariablen in Contao: die Dotenv.
• Port 465 oder 587. Bei Port 465 ist die Verbindung von Anfang an verschlüsselt (SSL/TLS). Bei jedem anderen Port – meist 587 – startet sie unverschlüsselt und wechselt per STARTTLS, sobald der Server das anbietet. Bietet er es nicht an, bleibt sie unverschlüsselt. Welchen Port du nimmst, steht in der Anleitung deines Mailanbieters.
• Die .env.local gehört nicht ins Git-Repository. Sie enthält das Passwort im Klartext.

Stehen in deiner parameters.yml noch mailer_host, mailer_user und Co.? Das funktioniert auch in Contao 6 noch. Für neue Projekte nimm trotzdem die .env.local. Dort liegen auch die Datenbank-Zugangsdaten – alles an einem Ort.

Testen, bevor es jemand anderes merkt

Ob der Versand klappt, prüfst du ab Contao 5.3 auf der Kommandozeile – in Contao 4.13 gibt es den Befehl noch nicht:

vendor/bin/contao-console mailer:test deine@adresse.de --from=website@beispiel.de

Vergiss --from nicht. Ohne die Option verschickt der Befehl als from@example.org – und das lehnen die meisten SMTP-Server ab.

Danach schickst du einmal das echte Formular ab. Die Mail ist da und nicht im Spam? Dann wirf einen Blick in ihren Quelltext, in Gmail über „Original anzeigen“. Dort sollte bei SPF, DKIM und DMARC jeweils PASS stehen.

Mehrere Postfächer: Mailer-Transports

Eine Contao-Installation, mehrere Domains – und jede soll über ihr eigenes Postfach verschicken. Das betrifft Agenturen mit Multidomain-Installationen genauso wie Unternehmen mit mehreren Marken.

Dafür legst du in der config/config.yaml mehrere Transports an:

framework:
    mailer:
        transports:
            domain_a: '%env(MAILER_DSN_DOMAIN_A)%'
            domain_b: '%env(MAILER_DSN_DOMAIN_B)%'

contao:
    mailer:
        transports:
            domain_a:
                from: 'Domain A <website@domain-a.de>'
            domain_b:
                from: 'Domain B <website@domain-b.de>'

Die Zugangsdaten bleiben in der .env.local:

MAILER_DSN_DOMAIN_A=smtp://website%40domain-a.de:PASSWORT@smtp.domain-a.de:587
MAILER_DSN_DOMAIN_B=smtp://website%40domain-b.de:PASSWORT@smtp.domain-b.de:465

So spielt das zusammen:

• Unter framework legst du die Transports an. Der erste ist der Standard.
• Unter contao gibst du sie fürs Backend frei. Die Namen müssen übereinstimmen.
• from ist optional. Ist es gesetzt, überschreibt Contao damit den Absender jeder Mail, die über diesen Transport geht. So passt der Absender immer zum Postfach. Ohne from schreibst du einfach domain_a: ~.

Danach den Cache leeren. Im Backend gibt es jetzt das Feld Mailer-Transport: im Startpunkt der Website, in Formularen, in Newsletter-Verteilern und in einzelnen Newslettern. Ein Transport im Formular hat Vorrang vor dem im Startpunkt.

5 Punkte, die du bei der Einrichtung beachten musst

1. Der Absender muss zum Postfach passen

Formular-Mails verschickt Contao mit der E-Mail-Adresse des Webseiten-Administrators aus dem Startpunkt. Ist dort nichts eingetragen, nimmt Contao die E-Mail-Adresse des Systemadministrators aus den Einstellungen. Newsletter-Verteiler und Newsletter haben eigene Absenderfelder.

Jede dieser Adressen muss zum SMTP-Postfach gehören – als Hauptadresse oder als erlaubter Alias. Sonst lehnt der Mailserver ab. Bei IONOS heißt es dann „Sender address is not allowed“, bei Strato „You are not authorized to send mail from“.

Bei mehreren Transports löst from das Problem (siehe oben).

2. Die Besucher:innen gehören in die Antwortadresse – nicht in den Absender

Klingt praktisch: Die Mail aus dem Kontaktformular kommt „von“ der Person, die es ausgefüllt hat. Funktioniert nur nicht. Ihre Adresse gehört nicht zu deinem Postfach. Der Server lehnt ab – oder die Mail fällt bei SPF und DMARC durch.

Contao löst das selbst: Heißt das E-Mail-Feld im Formular email, trägt Contao die Adresse als Antwortadresse (Reply-To) ein. Gibt es zusätzlich ein Feld name – oder firstname und lastname –, kommt der Name dazu. „Antworten“ geht dann an die richtige Person.

Nutzt du das Notification Center, gilt dasselbe: Absender ist das Postfach, die Adresse der Besucher:innen kommt ins Feld für Reply-To, etwa als ##form_email##.

3. Ein eigenes Postfach für die Website

Hängt das Kontaktformular am Postfach info@, hängt es auch an dessen Passwort. Ändert jemand im Team das Passwort, verschickt die Website keine Mails mehr. Und niemand merkt es – bis eine Anfrage fehlt.

Besser: ein eigenes Postfach nur für die Website, etwa website@, contao@ oder noreply@.

4. SPF, DKIM und DMARC prüfen

SMTP allein reicht nicht, wenn der DNS nicht mitspielt. Prüfe:

• Steht der Mailserver deines Anbieters im SPF-Eintrag der Domain?
• Ist DKIM beim Mailanbieter aktiviert und der Schlüssel im DNS hinterlegt?
• Gibt es einen DMARC-Eintrag?

Liegen Domain und Postfach beim selben Anbieter, ist das meist schon erledigt. Liegt der DNS woanders, setzt du die Einträge selbst.

5. Versandlimits kennen

Mailanbieter begrenzen, wie viele Mails ein Postfach pro Stunde oder Tag verschicken darf. Für Formulare spielt das keine Rolle. Für Newsletter schon.

Contao verschickt Newsletter deshalb in Etappen. Beim Versand stellst du Mails pro Zyklus und Wartezeit in Sekunden ein. Stimm beides auf das Limit deines Anbieters ab. Bei großen Verteilern ist ein Newsletter-Dienst die bessere Wahl – mehr dazu in Der Contao Newsletter: Möglichkeiten, Grenzen und Alternativen.

Sonderfälle: Was jeder Hoster anders macht

SMTP funktioniert überall gleich. Die Regeln drumherum nicht. Hier sammeln wir, worauf wir in Projekten gestoßen sind. Stand: November 2026.

IONOS: nur Absender aus dem eigenen Vertrag

Seit dem 29. Januar 2024 brauchen Mails, die über den IONOS-Webspace verschickt werden, eine Absenderadresse aus einer Domain des IONOS-Vertrags. Das gilt für Webhosting und Managed Dedicated Server.

• Ohne SMTP (über mail() bzw. native://default): Die Absenderadresse muss zur Domain des Webhosting-Vertrags gehören, auf der die Website läuft.
• Mit SMTP über IONOS (smtp.ionos.de, Port 465): Die Absenderadresse muss dieselbe Domain haben wie das Postfach, mit dem sich Contao anmeldet.

Sonst kommt „Sender address is not allowed“ zurück, und die Mail wird nicht zugestellt (IONOS-Hilfe).

Für Contao heißt das: Die E-Mail-Adresse des Webseiten-Administrators im Startpunkt muss eine Adresse der Website-Domain sein. Eine Gmail-Adresse geht nicht. Die Adresse einer Domain, die nicht im Vertrag liegt, auch nicht.

Ein Postfach bei einem anderen Anbieter funktioniert trotzdem. In einem unserer Projekte verschickt Contao vom IONOS-Webspace aus über einen externen Mailserver. Website und Postfach nutzen dabei dieselbe Domain.

Strato: nur Absender aus dem eigenen Paket

Strato lehnt Mails ab, deren Absenderadresse nicht zum angemeldeten Strato-Paket gehört. Die Meldung: „You are not authorized to send mail from …“. In kleinen Mengen lässt Strato fremde Absender noch durch – laut eigener FAQ aber nur noch vorübergehend (Strato-FAQ: Fehlermeldungen). Verlass dich nicht darauf.

Für den SMTP-Versand nennt Strato smtp.strato.de mit Port 465 (SSL/TLS). Port 587 ist laut Strato nur für Relay-Szenarien gedacht, etwa für einen eigenen Exchange-Server. Unverschlüsselte Verbindungen unterstützt Strato nicht (Strato-FAQ: SSL/TLS).

Hetzner: Port 25 und 465 gesperrt

Auf Cloud-Servern und dedizierten Servern sperrt Hetzner ausgehende Verbindungen über die Ports 25 und 465 – standardmäßig, gegen Spam. Port 587 ist offen. Beim Webhosting ist es noch strenger: Externe Mailserver erreichst du nur über Port 587.

Für Contao heißt das:

• Im MAILER_DSN Port 587 eintragen. Mit Port 465 bricht die Verbindung nach einer Wartezeit ab.
• Prüf vorher, ob dein Mailanbieter Port 587 anbietet. Nicht jeder sieht ihn für den Versand aus Anwendungen vor – siehe Strato.
• Ohne SMTP kommt auf Cloud- und dedizierten Servern in der Regel nichts an. Ein lokaler Mailserver liefert direkt über Port 25 aus. Und der ist zu.

Freischalten lassen sich die Ports 25 und 465 erst, wenn du seit mindestens einem Monat Kund:in bist und mindestens eine Rechnung bezahlt hast. Bei Cloud-Servern stellst du dann einen Antrag, Hetzner prüft jeden einzeln (Hetzner Cloud FAQ). Bei dedizierten Servern schaltest du die Ports selbst in der Administrationsoberfläche frei (Hetzner Robot FAQ).

Microsoft 365: Die Anmeldung per Passwort läuft aus

Viele Unternehmen haben ihre Postfächer bei Microsoft 365. Der SMTP-Versand läuft dort über smtp.office365.com, Port 587. Zwei Hürden:

1. SMTP AUTH muss erlaubt sein. Bei Microsoft-365-Konten, die nach Januar 2020 angelegt wurden, ist die Anmeldung per SMTP standardmäßig aus. Die IT schaltet sie pro Postfach im Microsoft 365 Admin Center frei: Aktive Benutzer → Benutzer wählen → E-Mail → E-Mail-Apps verwalten → Authentifiziertes SMTP. Sind die Sicherheitsstandards aktiv, hilft das allerdings nichts. Dann ist SMTP AUTH komplett gesperrt (Microsoft Learn).
2. Benutzername und Passwort reichen bald nicht mehr. Microsoft schaltet die Anmeldung mit Passwort (Basic Auth) für SMTP AUTH bei bestehenden Konten Ende Dezember 2026 standardmäßig ab. Admins können sie danach wieder einschalten. Neue Konten haben sie ab dann standardmäßig nicht mehr. Den Termin für das endgültige Aus will Microsoft in der zweiten Jahreshälfte 2027 bekannt geben (Exchange Team Blog).

Der MAILER_DSN mit smtp:// arbeitet genau mit Benutzername und Passwort. Es gibt einen anderen Weg: die Microsoft Graph API. Dafür brauchst du keine Contao-Erweiterung, nur eine Anbindung für den Mailer.

Ab Contao 5.7 bringt Symfony sie selbst mit, seit Version 7.4:

composer require symfony/microsoft-graph-mailer

MAILER_DSN=microsoftgraph+api://CLIENT_ID:CLIENT_SECRET@default?tenantId=TENANT_ID

In Contao 5.3 hilft das Paket vitrus/symfony-office-graph-mailer eines Drittanbieters. Das setzen wir in zwei Projekten ein. Anders als die offizielle Anbindung registrierst du es selbst in der config/services.yaml:

composer require vitrus/symfony-office-graph-mailer

services:
    Vitrus\SymfonyOfficeGraphMailer\Transport\GraphApiTransportFactory:
        tags: ['mailer.transport_factory']

MAILER_DSN=microsoft-graph-api://CLIENT_ID:CLIENT_SECRET@TENANT_ID

In beiden Fällen legt die IT in Microsoft Entra eine App-Registrierung mit der Berechtigung Mail.Send an. Der Absender muss ein Postfach im eigenen Microsoft-365-Konto sein.

Von der IT brauchst du drei Werte: Client-ID, Client-Secret und Tenant-ID. Genau die stehen im MAILER_DSN.

Ohne weitere Einschränkung darf die App im Namen jedes Postfachs im Konto verschicken. Die IT kann das auf einzelne Postfächer begrenzen – Microsoft nennt das RBAC for Applications in Exchange Online.

Das Client-Secret läuft ab. Länger als 24 Monate geht nicht, Microsoft empfiehlt sogar weniger als 12 (Microsoft Learn). Danach verschickt die Website keine Mails mehr. Und niemand merkt es – bis eine Anfrage fehlt. Trag dir das Ablaufdatum in den Kalender und lass dir rechtzeitig ein neues Secret geben.

Verschickt deine Website – oder die deiner Kund:innen – über ein Microsoft-365-Postfach? Dann prüf das jetzt, nicht im Januar. Drei Wege:

• Kurzfristig: Die IT schaltet die Anmeldung mit Passwort für das Postfach wieder ein. Das geht laut Microsoft vorerst noch – doch nur bis zum endgültigen Aus.
• Dauerhaft mit Microsoft 365: Die Website verschickt über die Graph API (siehe oben).
• Dauerhaft ohne Microsoft 365: Die Website verschickt über ein anderes Postfach, etwa beim Webhoster, oder über einen Versanddienst für Systemmails. Achte dabei auf:
  • Serverstandort in der EU und einen Vertrag zur Auftragsverarbeitung
  • SMTP-Zugangsdaten – dann reicht der MAILER_DSN, ganz ohne Erweiterung
  • SPF und DKIM