SMTP-Ports in 2026: Warum 587 fast immer die richtige Wahl ist (und 25 dich zuverlässig scheitern lässt)
Wenn du eine Website betreibst, erwartest du zurecht, dass E-Mails zuverlässig ankommen: Kontaktformular-Anfragen, WooCommerce-Bestellbestätigungen, Registrierungs- und Passwort-Reset-Mails. Wenn genau diese Mails nicht im Posteingang landen, ist das nicht nur nervig – es kostet Leads, Kunden und Vertrauen.

Der „stille Täter“ hinter verschwundenen Website-Mails sind sehr häufig die Default-Mail-Einstellungen. Viele Websites – besonders WordPress-Installationen – senden E-Mails über Mechanismen, die für moderne Inbox-Provider wie Gmail oder Outlook wie Spam aussehen. Die Lösung ist fast immer dieselbe: Weg vom Default-Versand, hin zu einem professionellen, authentifizierten Versandkanal via SMTP (Simple Mail Transfer Protocol).
Sobald du SMTP einsetzt, kommt eine scheinbar banale, aber in der Praxis entscheidende Frage auf: Welchen SMTP-Port solltest du 2026 verwenden? Die richtige Port-Wahl ist der Schlüssel zu stabiler Zustellung, Sicherheit (Verschlüsselung) und einem Setup, das nicht ständig an Provider- oder Hosting-Beschränkungen scheitert.
Key Takeaways: Die Port-Wahl in einem Satz (plus die Details, die wirklich zählen)
- Schnelle Empfehlung: Nutze Port 587 mit STARTTLS-Verschlüsselung. Das ist der moderne Standard für Mail Submission (Versand aus Website/Client).
- Gute Alternative: Port 465 mit SMTPS (implizites SSL/TLS) ist ebenfalls sehr verbreitet und sicher. Wenn 587 nicht funktioniert, ist 465 dein nächster Versuch.
- Port, den du vermeiden solltest: Port 25 ist für E-Mail-Submission (Versand aus deiner Website) praktisch tabu: unverschlüsselt, für Server-zu-Server-Relay gedacht und bei fast allen ISPs/Hostern ausgehenden blockiert (Anti-Spam).
- Das eigentliche Problem: WordPress’ Standard-Mailversand (z. B.
wp_mail()) ist typischerweise nicht authentifiziert und kommt von einem Webserver ohne Mail-Reputation – das triggert Spamfilter. - Die echte Lösung: Versand über einen dedizierten SMTP-/Transactional-Email-Service (z. B. SendGrid, Brevo, Mailgun). Damit läuft die Mail über vertrauenswürdige, authentifizierte Infrastruktur.
- Der „Easy Button“ für WordPress: Wer Port-/API-/DNS-Konfiguration vermeiden will, kann eine „Zero-Configuration“-Lösung wie Site Mailer by Elementor nutzen, die Website-Mails automatisch über einen zustellstarken Anbieter routet.
- Wichtig: SMTP/Transactional-Email ist für transaktionale E-Mails (Formulare, Passwörter, Belege). Newsletter und Massenversand gehören in eine separate E-Mail-Marketing-Plattform (ESP), sonst ruinierst du dir die Sender-Reputation.
SMTP kurz erklärt: Warum es für Websites überhaupt relevant ist
SMTP (Simple Mail Transfer Protocol) ist das Regelwerk, mit dem E-Mail-Clients und Mailserver Nachrichten verschicken und weiterreichen. Stell dir SMTP wie das „Postamt-Protokoll“ des Internets vor: standardisiert, überall implementiert, und letztlich die Basis dafür, dass E-Mail überhaupt funktioniert.
Wenn du eine E-Mail sendest, passiert grob Folgendes:
- Dein Client (oder deine Website) übergibt die Mail an den Outgoing Mail Server (z. B.
smtp.gmail.com). Das ist der Submission-Schritt. - Dieser Mailserver findet den Zielserver und relayed die Nachricht dorthin.
- Der Zielserver hält die Nachricht vor, bis der Empfänger sein Postfach abruft.
SMTP ist dabei das Protokoll für Submission und Relay. Ein SMTP-Port ist schlicht die nummerierte „Tür“ am Server, über die diese Kommunikation stattfinden darf.
Das WordPress-Problem: wp_mail() ist bequem – und oft der Zustellbarkeits-Killer
Standardmäßig nutzt WordPress häufig nicht SMTP, sondern eine PHP-basierte Versandfunktion (wp_mail()), die versucht, E-Mails direkt vom Webserver aus zu verschicken. Genau das sorgt in der Praxis für miserable Deliverability.
- Kein echter Mailserver: Ein Webserver ist fürs Ausliefern von Websites optimiert – nicht für den E-Mail-Versand. Typische Mailserver-Features/Best-Practices fehlen.
- Keine Authentifizierung: Der Server „behauptet“ Absender
deine-domain.tldzu sein, ohne saubere Authentifizierungskette. - Keine Reputation: Inbox-Provider bewerten bekannte sendende Systeme über Reputation Scores. Ein Webserver ohne Mailhistorie wirkt wie ein unbekannter Sender – verdächtig per Default.
- Schlechtes IP-Umfeld (Shared Hosting): Auf Shared-Hosts teilen sich viele Websites IPs/Server. Wenn ein Nachbar spammt und die IP auf Blacklists landet, leidest du mit – auch wenn du seriös sendest.
Das Ergebnis ist klassisch: E-Mails landen im Spam – oder werden still verworfen. Deshalb ist der sinnvollste Schritt, WordPress-Mails konsequent über einen professionellen SMTP-/Transactional-Mail-Anbieter zu senden. Und dafür musst du den richtigen Port wählen.
Warum es mehrere SMTP-Ports gibt: Ein kurzer Blick in die Geschichte
Die Port-Landschaft ist im Kern ein Nebenprodukt aus Standardisierung und dem jahrzehntelangen Kampf gegen Spam. Wenn du verstehst, wofür die Ports entstanden sind, wird sofort klar, warum 2026 praktisch nur zwei echte Optionen übrig bleiben.
Port 25: Der Original-Port von 1982 – heute vor allem eine Spam-Autobahn
Port 25 war der ursprüngliche SMTP-Port und wurde für Server-zu-Server-Relay zwischen Mail Transfer Agents (MTAs) gebaut. Anfangs ohne Authentifizierung, offen und unverschlüsselt – in einer Zeit, in der das Internet deutlich „vertrauensseliger“ war.
Das Problem: Spammer haben schnell erkannt, dass man über Port 25 massenhaft Nachrichten über fremde Server zustellen lassen kann. Ohne Authentifizierung und ohne Verschlüsselung wurde Port 25 zur Angriffsfläche.
Der Stand heute: Nahezu jeder ISP, viele Cloud-Provider und generell viele Netzwerke blockieren ausgehende Verbindungen auf Port 25. Das ist eine Anti-Spam-Maßnahme gegen Botnetze und kompromittierte Systeme.
Wichtig
Für den Versand von Website-Mails (Submission) solltest du niemals Port 25 einsetzen. Selbst wenn dein Hoster es zulässt (was er idealerweise nicht tut), wird „das Internet draußen“ die Zustellung oft verhindern.
Port 465: SMTPS mit implizitem SSL/TLS (die erste sichere Lösung)
Ende der 1990er wurde klar, dass E-Mail-Versand Verschlüsselung braucht. Port 465 etablierte sich als früher „Secure SMTP“-Port: SMTPS (SMTP über SSL, heute TLS).
Technisch heißt das: Sobald der Client verbindet, startet direkt der TLS-Handshake. Die gesamte Session läuft von Beginn an im verschlüsselten Tunnel – man spricht von Implicit SSL/TLS.
Port 465 war lange verbreitet, galt dann zeitweise als „deprecated“, weil Standards lieber auf STARTTLS setzen wollten. In der Praxis kam 465 jedoch stark zurück und ist heute wieder ein akzeptierter, sehr populärer Standard. Große Anbieter – inklusive Google/Gmail – empfehlen ihn weiterhin häufig.
Port 587: Der moderne Standard für Submission mit STARTTLS (Explicit TLS)
Um das Thema Submission sauber zu standardisieren, wurde Port 587 als offizieller Submission-Port etabliert. Der Unterschied liegt in der Verschlüsselungs-Aushandlung: Port 587 nutzt typischerweise STARTTLS (auch Explicit TLS genannt).
So läuft STARTTLS grob ab:
- Deine Website verbindet sich auf Port 587 zunächst im Klartext.
- Sie sendet
EHLO(quasi „Hallo“ + Capability-Abfrage). - Der Server antwortet mit unterstützten Features – darunter
STARTTLS. - Deine Website sendet den Befehl
STARTTLS, um die Verbindung „upzugraden“. - Erst dann wird der TLS-Tunnel aufgebaut, und danach werden Credentials und Maildaten übertragen.
2026 gilt: Wenn ein Server auf 587 keine Verschlüsselung erzwingt, ist das ein Sicherheitsproblem. In der Praxis ist Port 587 jedoch der am häufigsten empfohlene Standard für Submission und wird von nahezu allen SMTP-Anbietern unterstützt.
Port 2525: Inoffizieller Fallback, wenn Hosting-Policies nerven
Port 2525 ist kein offizieller SMTP-Standardport, taucht aber häufig als Alternative auf. Viele Provider unterstützen ihn als „Ausweichport“.
Wann ist das relevant? Wenn dein Hosting-Provider sowohl 587 als auch 465 blockiert (selten, aber möglich). Manche Cloud-Plattformen sperren Ports, um Spam aus ihren Netzwerken zu reduzieren, und erzwingen dann einen dedizierten Relay-Service – der wiederum oft auf 2525 lauscht. Üblicherweise läuft auch hier STARTTLS wie bei 587.
Das Urteil für 2026: Welchen SMTP-Port solltest du verwenden?
Primäre Wahl: Port 587 mit STARTTLS
Port 587 ist der offizielle, moderne Submission-Standard. Er ist breit unterstützt, sauber für den Zweck gedacht und in den meisten Umgebungen die beste erste Wahl. Wenn du ein SMTP-Plugin konfigurierst, ist 587 mit STARTTLS/TLS in der Regel dein Default.
Sekundäre Wahl: Port 465 mit SMTPS
Wenn 587 aus irgendeinem Grund scheitert oder dein Provider explizit 465 empfiehlt (Gmail/Google Workspace wird hier oft genannt), ist 465 eine sehr gute, sichere Alternative. Hier läuft TLS „implicit“, also direkt ab Connect.
Praktisch nie für Submission: Port 25
Port 25 ist für Server-zu-Server-Relay gedacht, nicht für Website-/Client-Versand. Für deinen WordPress-Versand ist das in der Praxis ein Garant für Zustellprobleme oder direkte Blockaden.
SMTP-Port-Vergleich (kompakt)
- 25 – SMTP, keine Sicherheit, typischer Use Case: Server-to-Server Relay, für Websites: Nein (oft geblockt)
- 465 – SMTPS, Implicit SSL/TLS, typischer Use Case: Client-to-Server Submission, für Websites: Ja (sicher & verbreitet)
- 587 – SMTP + STARTTLS, Explicit TLS, typischer Use Case: Client-to-Server Submission, für Websites: Ja (empfohlener Standard)
- 2525 – SMTP + STARTTLS, Explicit TLS, typischer Use Case: Fallback Submission, für Websites: nur wenn 587/465 geblockt
WordPress-E-Mail fixen: Schritt-für-Schritt zu zuverlässiger Zustellung
Mit dem Port-Wissen allein ist es noch nicht getan – du musst WordPress aktiv dazu bringen, E-Mails über einen authentifizierten Kanal zu senden. Das Standard-Setup ist fast nie ausreichend.
Schritt 1: Einen dedizierten Transactional-Email-/SMTP-Anbieter auswählen
Zuerst: Hör auf, deinen Webserver als Mailserver zu benutzen. Stattdessen brauchst du einen dedizierten Anbieter für transaktionale E-Mails. Deren Kerngeschäft ist Deliverability.
- Was diese Anbieter liefern: Professionelle, reputationsstarke Mailserver, über die du per SMTP oder API senden kannst.
- Beispiele (häufig genutzt): SendGrid (sehr verbreitet, starker Free-Tier), Brevo (ehemals Sendinblue), Mailgun, Postmark (bekannt für sehr hohe Zustellraten), Amazon SES (mächtig, aber komplexer), Google Workspace / Gmail (für kleine Volumina möglich, aber für Business eher nicht empfohlen wegen Limits).
Für kleine bis mittlere Websites reichen die Free-Tiers oft völlig aus – solange es um transaktionale Mails geht (nicht um Newsletter-Broadcasts).
Schritt 2: DNS korrekt setzen – SPF und DKIM (ohne das wird’s nichts)
Das ist der wichtigste technische Teil: Du musst öffentlich nachweisen, dass der Provider in deinem Namen senden darf. Das passiert über DNS-Einträge bei deiner Domain (Registrar oder DNS-Provider). Dein SMTP-Anbieter gibt dir die konkreten Records zum Copy/Paste.
- SPF (Sender Policy Framework): Ein TXT-Record als „Gästeliste“ für deine Domain. Er sagt empfangenden Servern: Mails, die behaupten von
deine-domain.tldzu kommen, sind nur dann legitim, wenn sie von den dort erlaubten IPs/Services stammen (z. B. deine Infrastruktur + SendGrid). Das reduziert Spoofing. - DKIM (DomainKeys Identified Mail): Ebenfalls TXT-Records, die einen öffentlichen Schlüssel bereitstellen. Der Provider signiert ausgehende Mails mit einem privaten Schlüssel; Empfänger verifizieren die Signatur mit dem öffentlichen Schlüssel aus deinem DNS. Dadurch wird nachvollziehbar, dass die Mail nicht manipuliert wurde.
SPF & DKIM sind nicht optional
Ohne SPF und DKIM hilft dir selbst der beste SMTP-Anbieter nur begrenzt – deine Mails wirken weiterhin verdächtig und landen leichter im Spam.
Schritt 3: SMTP-Plugin installieren und WordPress auf den Provider umstellen
Damit WordPress tatsächlich über deinen Provider sendet, brauchst du in der Regel ein Plugin, das wp_mail() abfängt und den Versand umleitet.
- Gängige Plugins: WP Mail SMTP, FluentSMTP, Post SMTP.
- Prinzip: Alle intercepten den Default-Mailweg und routen über SMTP oder API des Providers.
Ein generischer Ablauf, der für die meisten Plugins passt:
- Plugin installieren und aktivieren.
- Im WordPress-Backend die Plugin-Einstellungen öffnen.
- Unter „Mailer“ deinen Provider auswählen (z. B. SendGrid).
- Zugangsdaten hinterlegen:
- Bevorzugt (API): Viele Plugins empfehlen einen API-Key. Das ist meist sicherer und stabiler als Benutzername/Passwort.
- Alternativ (SMTP-Credentials): Wenn du „Other SMTP“ nutzt, trägst du Host/Port/Username/Password manuell ein.
- Wenn SMTP manuell konfiguriert wird, setze diese Werte:
- SMTP Host: kommt vom Provider (z. B.
smtp.sendgrid.net). - Encryption: TLS (entspricht STARTTLS). Falls es stattdessen „SMTPS“/„SSL“ gibt, ist das meist die 465-Variante.
- SMTP Port: 587 (für TLS/STARTTLS) oder 465 (für SMTPS/SSL).
- Authentication: aktivieren.
- SMTP Username und SMTP Password: vom Provider.
- Absender setzen:
- From Email: sollte zu deiner authentifizierten Domain passen.
- From Name: z. B. Projekt-/Shop-Name.
Schritt 4: Testmail senden und Logs/Spam prüfen
Die meisten SMTP-Plugins haben einen Bereich „Test Email“. Nutze ihn und sende an eine Gmail- oder Outlook-Adresse.
- Mail kommt im Posteingang an: Setup passt, du sendest jetzt authentifiziert.
- Mail landet im Spam: SPF/DKIM prüfen; DNS-Propagation kann Stunden dauern.
- Mailversand schlägt fehl: Oft Port- oder Credential-Thema. Host/Port/User/Passwort verifizieren. Wenn 587 (TLS) nicht klappt, 465 (SSL/SMTPS) testen – oder umgekehrt.
„Einfach machen“ statt DNS und Ports: Integrierte Lösungen im WordPress-Ökosystem
Aus Entwicklerperspektive sind die vier Schritte absolut machbar. In der Realität ist das für viele Site-Owner jedoch ein Puzzle aus Domain-Registrar, DNS, Provider-Accounts und Plugin-Konfiguration. Genau deshalb gibt es zunehmend integrierte Plattform-Ansätze, die diese Pflichtbausteine bündeln.
Option 1: Integrierter Transactional-Mail-Versand als „Easy Button“
Wenn das Kernproblem die fehlende Authentifizierung des WordPress-Default-Versands ist, ist die einfachste Lösung eine Variante, die diesen Standardweg ohne Konfigurationsaufwand ersetzt.
Ein Beispiel ist Site Mailer by Elementor als „Zero-Configuration“-Plugin:
- So läuft’s: Plugin installieren und aktivieren – fertig.
- Was es macht: Transaktionale Website-Mails (Kontaktformulare, WooCommerce-Mails, Passwort-Resets etc.) werden automatisch über einen authentifizierten, zustellstarken Dienst geroutet.
- Warum das attraktiv ist: Kein separater SendGrid-Account, keine API-Keys, kein SPF/DKIM-Setup und keine Port-Wahl – das Ziel ist, dass es out of the box funktioniert.
Option 2: Managed Hosting, das SMTP nicht „wegblockt“
Ein weiterer Praxis-Faktor sind restriktive Hosting-Umgebungen. Gute Managed-WordPress-Hosts kennen das wp_mail()-Problem und sorgen zumindest dafür, dass du Best Practices überhaupt umsetzen kannst – inklusive offener Ports wie 587 für deinen SMTP-Versand.
Als Beispiel nennt der Source Elementor Hosting: Cloud-Infrastruktur mit Fokus auf Performance, plus eine Umgebung, die Mail-Integrationen nicht unnötig erschwert. Die Idee dahinter ist eine stabile Basis, auf der du SMTP sauber konfigurieren kannst, ohne gegen dein eigenes Server-Setup zu kämpfen.
Wichtige Trennlinie: Transactional vs. Marketing (und warum das deine Zustellung schützt)
Wenn du Website-Mails sauber über SMTP/Transactional-Provider versendest, ist der nächste typische Fehler: Newsletter und Massenmailings über denselben Kanal zu schicken. Genau das kann dir die Zustellbarkeit deiner wichtigsten Mails zerstören.
Merksatz: SMTP/Transactional-Setup ist für transaktionale E-Mails gedacht – nicht für Marketing-Broadcasts.
Transactional E-Mail (über SMTP/Transactional-Provider)
Transactional E-Mails sind 1:1-Nachrichten, ausgelöst durch eine konkrete Aktion eines Users. Diese Mails sind erwartet und kritisch.
- Passwort-Resets
- Bestellbestätigungen
- Formular-Benachrichtigungen
- Welcome-/Registrierungs-Mails
Marketing E-Mail (über eine ESP)
Marketing-Mails sind 1:n-Broadcasts, typischerweise Newsletter oder Promo-Kampagnen. Auch wenn Empfänger „opted-in“ sind, ist die Spam-Beschwerdequote und Unsubscribe-Rate naturgemäß höher – und das wirkt direkt auf deine Sender-Reputation.
- Wöchentliche Newsletter
- Sales-/Holiday-Promotions
- Produktankündigungen
Wenn du 10.000 Empfänger über deinen Transactional-Kanal anschreibst, riskierst du Beschwerden, Bounces und Reputation-Schäden. Im Worst Case landen danach auch Passwort-Resets im Spam. Darum: Für Marketing bitte eine dedizierte ESP (Email Service Provider) nutzen, z. B. Mailchimp oder ConvertKit – mit getrenntem Reputation- und Unsubscribe-Handling.
Empfohlene E-Mail-Strategie für 2026 (aus der Praxis für Webprojekte)
Wenn ich Projekte „aus dem E-Mail-Nirvana“ ziehen muss, ist das Muster fast immer gleich: Default-WordPress-Mail, keine Authentifizierung, kein klarer Versandkanal. Die Strategie, die 2026 zuverlässig funktioniert, besteht aus drei Bausteinen:
- Stabile Basis: Hosting, das Best Practices nicht verhindert (Ports/Policies/Umgebung). Der Source nennt hier als Beispiel Elementor Hosting.
- Zuverlässiger Transactional-Kanal: Entweder „Zero-Config“ wie Site Mailer by Elementor oder klassisch: SMTP-Plugin + Transactional-Provider – mit Port 587 als Standard.
- Professioneller Marketing-Kanal: Newsletter/Bulk-Mails über eine ESP, getrennt von Transactional, um deine Domain-Reputation zu schützen.
Fazit: Nicht nur den Port wählen – den Versandweg grundsätzlich richtig bauen
Die Frage „Welchen SMTP-Port soll ich nehmen?“ ist der Einstieg, nicht das Ende. Für 2026 ist die klare Standardantwort: Port 587 mit STARTTLS. Wenn das in deinem Umfeld nicht klappt oder dein Provider es so vorgibt, ist Port 465 mit SMTPS die saubere Alternative. Port 25 ist für Website-Versand praktisch ein No-Go.
Entscheidend ist aber der größere Schritt: Weg vom unzuverlässigen Default-Versand (wp_mail()), hin zu einem authentifizierten Transactional-Setup (inklusive SPF/DKIM oder einer integrierten Lösung, die das abnimmt). Damit stellst du sicher, dass Belege ankommen, Leads nicht verschwinden und deine Website tatsächlich zuverlässig „sprechen“ kann.
FAQ: Häufige Fragen zu SMTP-Ports und WordPress-Mail
1. Was ist die einfache Antwort – welchen SMTP-Port nutze ich?
Nutze Port 587 mit STARTTLS. Falls das nicht funktioniert, ist Port 465 mit SMTPS (SSL/TLS) die beste Alternative.
2. Warum sollte ich Port 25 nicht verwenden?
Port 25 ist der ursprüngliche, unverschlüsselte SMTP-Port (seit 1982) und wurde massiv für Spam missbraucht. Deshalb blockieren ihn heute die meisten Residential-ISPs und viele Cloud-Hosting-Provider für ausgehende Verbindungen – es funktioniert in der Praxis nicht zuverlässig.
3. Was ist der Unterschied zwischen Port 587 (STARTTLS) und Port 465 (SMTPS)?
Beide sind sicher. Port 465 nutzt Implicit TLS (Verschlüsselung startet sofort). Port 587 nutzt Explicit TLS via STARTTLS (Verbindung startet im Klartext und wird dann verschlüsselt „upgegradet“). Port 587 ist der moderne Standard, beide sind aber gängige Optionen.
4. Was ist eine „transactional email“?
Eine transaktionale E-Mail ist eine 1:1-Nachricht, ausgelöst durch eine User-Aktion auf deiner Website: Kontaktformular, Passwort-Reset, neue Registrierung oder Bestellbestätigung im eCommerce. Diese Mails sollten über einen dedizierten SMTP-/Transactional-Service laufen.
5. Worin unterscheidet sich transactional von marketing email?
Marketing-E-Mail ist ein 1:n-Broadcast (Newsletter, Promo, Ankündigung). Dafür solltest du eine separate Plattform (ESP) nutzen, um deine Domain-Reputation nicht zu beschädigen – sonst leiden irgendwann auch die transaktionalen Mails.
6. Was sind SPF und DKIM – brauche ich das wirklich?
Ja. Beides sind DNS-Records, die die Legitimität deiner Mails beweisen. SPF ist die Liste erlaubter sendender Systeme für deine Domain. DKIM ist eine digitale Signatur, die Manipulation erschwert und Authentizität prüfbar macht. Ohne SPF/DKIM wirkst du schnell wie Spam.
7. Mein SMTP-Plugin fragt nach „Host“. Was ist damit gemeint?
Der „Host“ ist die Serveradresse deines SMTP-Anbieters, z. B. smtp.sendgrid.net oder smtp.gmail.com. Diese Angaben bekommst du vom Provider.
8. Kann ich einfach meinen normalen Gmail-Account für Website-Mails verwenden?
Technisch ja, praktisch eher nicht empfehlenswert: Du müsstest persönliche Credentials im WordPress-Backend hinterlegen (Sicherheitsrisiko) und Google hat strikte Sending-Limits. Bei Traffic-Spitzen kann der Versand temporär blockiert werden. Dedizierte Provider sind dafür besser geeignet.
9. Was ist der einfachste Weg, alle WordPress-Mailprobleme zu lösen?
Eine „Zero-Configuration“-Lösung wie Site Mailer by Elementor: installieren, aktivieren, und die transaktionalen Mails werden automatisch über einen zustellstarken Dienst geroutet – ohne Port-/API-/DNS-Konfiguration.
10. Wie teste ich, ob mein SMTP-Setup funktioniert?
Viele SMTP-Plugins (z. B. WP Mail SMTP) bieten einen „Test Email“-Bereich in den Einstellungen. Sende eine Testmail an deine private Adresse (Gmail/Outlook). Kommt sie im Posteingang an, ist das Setup grundsätzlich korrekt.
Amara Schmidt
Full-Stack-Entwicklerin, Spezialistin für TypeScript und moderne Web-Frameworks. Next.js und serverlose Architekturen interessieren mich am meisten. Offen für neue Technologien.
Alle Beiträge