---
title: "Kontaktformular-Mails kommen nicht an: WordPress-Diagnose"
description: "WordPress meldet Erfolg, die Mail kommt nie an. Die fünf Ursachen in der Reihenfolge, in der ein Techniker sie prüft – plus 15-Minuten-Testprotokoll."
url: "https://digitaldomination.xyz/blog/kontaktformular-mails-kommen-nicht-an-wordpress"
language: de-DE
alternates:
  de-DE: "https://digitaldomination.xyz/blog/kontaktformular-mails-kommen-nicht-an-wordpress"
  en-US: "https://digitaldomination.xyz/en/blog/why-wordpress-contact-form-emails-vanish"
  x-default: "https://digitaldomination.xyz/blog/kontaktformular-mails-kommen-nicht-an-wordpress"
image: "https://digitaldomination.xyz/assets/images/og-image.de.png"
organization:
  name: Digital Domination
  telephone: "+49 1577 5527800"
  email: "hey@digitaldomination.xyz"
  address: "523 Jackson Street, Unit #210, Saint Paul, Minnesota 55101, US"
---

WordPress E-Mail-Zustellbarkeit DMARC Kontaktformular

# Kontaktformular-Mails kommen nicht an: Warum WordPress still scheitert – und wie Sie es beheben

Die fünf Ursachen in der Reihenfolge, in der ich sie prüfe, ein Testprotokoll für eine Viertelstunde und ein Monitoring, das den Fehler beim nächsten Mal laut macht.

![Alexander Kirsch-Clayton](https://digitaldomination.xyz/assets/images/alexander.webp) von [Alexander Kirsch-Clayton](https://www.linkedin.com/in/alexanderkc/), Gründer 28. September 2026 ·11 Min. Lesezeit [Digital Domination auf LinkedIn](https://www.linkedin.com/company/digidomination/) [Digital Domination auf GitHub](https://github.com/digidomination)

Das Formular meldet „Vielen Dank“. Die Besucherin glaubt, ihre Anfrage sei raus. Im Unternehmen sieht sie niemand. Kein Fehler im Backend, kein Bounce, nichts im Posteingang. Die Anfrage ist weg – und niemand weiß, dass es sie je gab.

## Drei Muster, die in Audits immer wieder auftauchen

Wenn mich jemand mit diesem Problem anspricht, sortiere ich zuerst das Symptom. Es gibt praktisch immer eines von drei Bildern, und jedes zeigt in eine andere Richtung.

- **Gar nichts kommt an.** Weder Benachrichtigung noch Autoresponder, auch nicht im Spam-Ordner. Das deutet auf den Sendeweg: Der Server gibt die Nachricht nie wirklich ab, oder sie wird direkt an der Tür abgewiesen.
- **Gmail bekommt die Mail, Outlook und GMX nicht.** Das klassische Authentifizierungsbild. Ein Empfänger ist noch nachsichtig, der nächste nicht mehr.
- **Mal kommt sie, mal nicht.** Sieht aus wie „das Internet spinnt gerade“. In der Praxis ist es meistens eine halbfertige Authentifizierung, die je nach Empfänger, Tageszeit und Absenderreputation anders bewertet wird – oder tatsächlich eine Störung auf der Empfängerseite.

Der Reflex der meisten Anleitungen lautet: SMTP-Plugin installieren, fertig. Das repariert einen Teil von Ursache vier und manchmal etwas von Ursache zwei. Die übrigen drei Ursachen bleiben unangetastet, und genau deshalb kommen Leute nach zwei Wochen mit demselben Problem zurück.

## Warum der Fehler still ist

WordPress verschickt Mail über `wp_mail()`, und ohne zusätzliche Konfiguration landet das bei PHPs `mail()`. Diese Funktion übergibt die Nachricht an den lokalen Mail-Daemon des Servers und meldet Erfolg, sobald die Übergabe geklappt hat. Nicht, wenn die Nachricht ankommt.

> `mail()` meldet Erfolg, sobald die Nachricht beim lokalen Mail-Daemon liegt – nicht, wenn sie ankommt. Was danach schiefgeht, erfährt WordPress nie.

Das ist der ganze Mechanismus hinter dem stillen Scheitern. Wenn der Empfängerserver die Nachricht Sekunden später ablehnt, geht die Fehlermeldung an die Adresse im Envelope zurück – und die ist auf typischem Shared Hosting eine serverlokale Adresse wie `www-data@srv1234.hoster.tld`, in die nie jemand hineinschaut. WordPress erfährt davon nichts, das Plugin zeigt ein grünes Häkchen, und der Formular-Dialog sagt „Vielen Dank“.

Ein „erfolgreich gesendet“ in WordPress ist keine Zustellbestätigung. Es ist die Quittung dafür, dass der Webserver die Nachricht angenommen hat. Alles danach passiert außerhalb Ihrer Sichtweite – es sei denn, Sie bauen sich diese Sichtweite bewusst.

## Ursache 1 – die Lüge im From-Header

Das ist der häufigste Einzelfehler, und er steckt in der Standardkonfiguration vieler Formular-Plugins: Die Adresse der Besucherin wird als Absender eingetragen. Im Header steht dann `From: kunde@gmail.com`, obwohl die Nachricht von Ihrem Webserver stammt.

Der Empfänger prüft nun, ob Ihr Server berechtigt ist, im Namen von `gmail.com` zu senden. Er ist es nicht. Gmail quittiert das mit einem Fehler der Klasse `550-5.7.26`; SendLayer beschreibt diesen Code als reines Authentifizierungsurteil – DKIM schlägt fehl, SPF für die angegebene Domain ebenfalls – und ausdrücklich nicht als Inhaltsbewertung. Ihr Text ist also egal. Die Nachricht ist schon vor dem Spamfilter erledigt.

Das richtige Muster ist seit Jahren dasselbe und kostet fünf Minuten in den Plugin-Einstellungen:

```
From:       website@beispiel.de
Reply-To:   kunde@gmail.com
Return-Path: bounces@beispiel.de
Subject:    Neue Anfrage über das Kontaktformular
```

Absender ist Ihre eigene Domain, für die Sie die Berechtigung nachweisen können. Die Adresse der Besucherin wandert in `Reply-To`, damit „Antworten“ im Mailprogramm weiterhin bei ihr landet. Funktional ändert sich für Ihr Team nichts – für den Empfängerserver ändert sich alles.

## Ursache 2 – der Envelope-Absender passt nicht zur Domain

Hier wird es unintuitiv, und deshalb übersehen es auch erfahrene Entwickler. SPF prüft nicht die Adresse, die der Empfänger sieht. SPF prüft die Domain im Envelope-Absender, also im Return-Path. MxToolbox formuliert es so: Der Return-Path ist die Adresse, über die der Mailserver den SPF-Eintrag ermittelt – und gleichzeitig die Adresse, an die Zustellfehler zurückgemeldet werden.

Auf Shared Hosting lautet dieser Envelope typischerweise `www-data@srv1234.hoster.tld`. Das Ergebnis: SPF besteht – für die Domain des Hosters. Für Ihre Domain ist damit nichts gewonnen. Suped bringt die Konsequenz auf den Punkt: SPF authentifiziert ausschließlich die Envelope-Domain; um die sichtbare From-Adresse abzusichern, braucht es DMARC darüber. Ein SPF-Pass auf fremde Domain ist also kein bisschen Schutz für Ihre eigene, sondern nur ein grünes Häkchen an der falschen Stelle.

Ein korrekter Envelope sieht aus wie oben: `bounces@beispiel.de` oder `bounce@mail.beispiel.de` – eine Subdomain, die Ihr Versanddienst kontrolliert und für die er die nötigen Einträge vorgibt. Entscheidend ist, dass die Domain im Return-Path mit der Domain im From-Header zusammenpasst. Erst dann ist SPF für DMARC verwertbar.

## Ursache 3 – auf dem Sendeweg fehlt jede DKIM-Signatur

Mail, die direkt vom Webserver über `mail()` hinausgeht, ist in aller Regel unsigniert. Keine DKIM-Signatur, kein kryptografischer Nachweis, dass die Nachricht wirklich aus Ihrer Domain stammt.

Damit fällt die zweite von zwei möglichen Säulen weg. DMARC besteht, wenn *entweder* SPF *oder* DKIM passt und die jeweilige Domain zur From-Domain ausgerichtet ist. Ist SPF auf die Hoster-Domain ausgerichtet und DKIM gar nicht vorhanden, kann DMARC nicht bestehen. Bei einer Domain, die auf `p=quarantine` oder `p=reject` steht, weist die eigene Richtlinie also die eigenen Formular-Mails ab. Das ist der Fall, bei dem die Kundin sagt: „Wir haben doch alles für E-Mail-Sicherheit gemacht.“ Ja – und dabei den Webserver vergessen.

Die Schlüssel für DKIM generiert immer Ihr Mail- oder Relay-Anbieter. Sie kopieren den Wert in Ihre DNS-Zone und aktivieren die Signierung beim Anbieter. Eigene Schlüssel zu basteln ist unnötig und geht regelmäßig schief. RFC 8301 setzt 1024 Bit als Untergrenze an und empfiehlt 2048; wenn ein Dienst nur 1024 Bit anbietet, ist das eine Einschränkung des Anbieters, kein Konfigurationsfehler Ihrerseits.

## Ursache 4 – der Hoster lässt den Versand gar nicht erst zu

Auf dieses Bild stoße ich vor allem bei Managed-WordPress-Hosting. WP Engine dokumentiert offen, dass ausgehende Mail über Port 25 plattformweit nicht möglich ist – die Infrastrukturanbieter erlauben es schlicht nicht. Jede SMTP-Lösung muss also einen alternativen Port oder eine API verwenden. Mehrere andere Managed- und Shared-Hoster handhaben das ähnlich restriktiv; prüfen Sie im Zweifel die Dokumentation Ihres eigenen Anbieters, statt es zu vermuten.

Das Symptom ist charakteristisch: Das SMTP-Plugin zeigt „konfiguriert“, der Testdialog dreht sich, ein Timeout, keine Nachricht. In zwei Minuten bestätigt:

1. Testversand im Plugin auslösen und den Fehlertext wörtlich lesen. „Connection timed out“ auf Port 25 oder 587 ist ein Netzwerkblock, „535 Authentication failed“ ist ein Zugangsdatenproblem – zwei völlig verschiedene Baustellen.
2. Die Support-Dokumentation des Hosters nach „outbound SMTP“ oder „Port 25“ durchsuchen. Steht dort eine Richtlinie, sparen Sie sich jedes weitere Debugging.
3. Auf Port 587 oder 465 mit STARTTLS beziehungsweise TLS umstellen – oder, wenn der Anbieter das nahelegt, auf die HTTP-API des Relays wechseln. Eine API geht durch jeden Port-Block hindurch, weil sie schlicht kein SMTP spricht.

## Ursache 5 – es liegt nicht immer an Ihnen

Bevor Sie einen halben Tag in Ihre DNS-Zone investieren: Die Empfängerseite kann genauso die Quelle sein. Ende August 2026 verzögerte ein mehrtägiger Vorfall in Exchange Online, von Microsoft als EX1464935 geführt, Versand und Empfang von Nachrichten und erzeugte Authentifizierungsfehler; Microsoft führte das auf ein gemeinsames Fehlermuster bei Authentifizierung und Protokollverbindungen zurück und meldete die Behebung zum 3. September. Einen Tag später begann mit EX1467029 ein zweiter, davon getrennter Vorfall, der gezielt Mail von und zu externen Domains verzögerte – laut Microsoft verstärkten dabei Anti-Spam-Schutzmechanismen das Problem für einen Teil der betroffenen Konten.

Dazu kommen die hausgemachten Empfängerprobleme: Transportregeln im Tenant, Quarantäne, ein Junk-Ordner, in den seit Monaten niemand schaut, eine Weiterleitung, die unterwegs die Signatur bricht.

Unterscheiden lässt sich das an einer einzigen zugestellten Nachricht. Öffnen Sie in Gmail „Original anzeigen“ beziehungsweise in Outlook die Nachrichtenkopfzeilen und suchen Sie die Zeile `Authentication-Results`:

```
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounces@beispiel.de designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounces@beispiel.de;
       dkim=pass header.i=@beispiel.de;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=beispiel.de
```

Stehen hier drei Mal `pass` und zeigt `header.from` auf Ihre Domain, ist Ihre Seite sauber. Was danach passiert – Regel, Quarantäne, Verzögerung beim Anbieter – gehört dem Empfänger. Steht irgendwo `fail`, `softfail` oder `permerror`, gehört es Ihnen. Ein `200` auf der Website sagt darüber übrigens gar nichts; er belegt nur, dass der Server geantwortet hat.

## Die Architektur, die funktioniert

Unabhängig davon, welche der fünf Ursachen zuerst zuschlägt, sieht das Ziel immer gleich aus. Fünf Punkte, mehr nicht:

- **Authentifiziertes Relay statt `mail()`.** SMTP mit Zugangsdaten oder eine Versand-API. Der Webserver gibt Mail nicht mehr selbst ab.
- **From auf Ihrer eigenen Domain** – eine feste Adresse wie `website@beispiel.de`, nie die Adresse der Besucherin.
- **Reply-To trägt die Besucherin.** Antworten funktioniert wie vorher.
- **Envelope-Absender ausgerichtet** auf dieselbe Domain oder eine kontrollierte Subdomain davon.
- **Eine Absenderidentität pro System.** Website, Newsletter, CRM, Rechnungstool – jedes mit eigener Adresse oder eigenem Selector, damit ein Fehler zuordenbar bleibt.

Der letzte Punkt wird gern übersprungen und rächt sich später. Wenn alle vier Systeme als `info@beispiel.de` senden, sagt Ihnen kein DMARC-Report der Welt, welches davon gerade kaputt ist.

## Die DNS-Hälfte – und was Sie vorher ansehen

Jede DNS-Änderung beginnt mit einem Blick auf den Ist-Stand. Diese Abfragen lesen nur, sie ändern nichts:

```
dig +short TXT beispiel.de
dig +short TXT _dmarc.beispiel.de
dig +short TXT selector1._domainkey.beispiel.de

# Windows:
nslookup -type=TXT _dmarc.beispiel.de
```

Kopieren Sie jeden aktuellen Wert in eine Datei, bevor Sie etwas ändern. Eine Domain hat genau einen `v=spf1`-Eintrag und genau einen `_dmarc`-Eintrag – ein zweiter macht die Prüfung kaputt. Sie bearbeiten also den bestehenden Eintrag, Sie legen keinen neuen an. Und ändern Sie einen Eintrag nach dem anderen: Bis die TTL abgelaufen ist, liefern Resolver weiter die alte Antwort.

**SPF:** Der `include`-Mechanismus Ihres Relays kommt in den bestehenden Eintrag. Achten Sie dabei auf die Lookup-Grenze: RFC 7208 deckelt die Zahl der DNS-Abfragen pro Auswertung bei zehn, verschachtelte Includes eingerechnet. Wer darüber liegt, erhält einen `permerror`, den Empfänger als SPF-Fehlschlag werten – und der DMARC-Ausrichtung damit die Grundlage entzieht. Das merkt man nur, wenn man testet.

```
v=spf1 include:_spf.relay-anbieter.tld include:_spf.google.com ~all
```

Ein hartes `-all` setzt man erst, wenn jeder legitime Absender inventarisiert ist – jedes Newslettertool, jedes Shopsystem, jedes Rechnungsprogramm. Vorher ist `~all` die ehrlichere Angabe.

**DKIM:** Den vom Anbieter erzeugten Schlüssel veröffentlichen *und* die Signierung im Anbieter-Dashboard tatsächlich aktivieren. Ein veröffentlichter, aber nicht ausgewählter Selector ist ein Klassiker: im DNS sichtbar, in der Nachricht abwesend.

**DMARC:** Beginnen Sie bei `p=none` mit einer Reportadresse, die jemand liest. Sendmarc beschreibt die Monitoring-Phase genau so – `p=none` mit konfiguriertem `rua` existiert, um Daten zu sammeln – und weist ebenso deutlich darauf hin, dass dauerhaftes Verharren bei `p=none` keinerlei Schutz vor Spoofing bietet.

```
v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de; fo=1
```

Der Weg von `p=none` über `p=quarantine` zu `p=reject` ist eine Rampe, kein Sprung: Reports lesen, jeden legitimen Absender in Ordnung bringen, dann erst anziehen. Das ist ein eigenes Projekt mit eigenem Zeitbedarf und gehört nicht in dieselbe Sitzung wie die Formular-Reparatur. Ein `p=none` „bittet die Empfänger um keine bestimmte Maßnahme“ bei Nachrichten, die durchfallen – es schützt nicht, und es tut auch nicht nichts.

## Das Testprotokoll für eine Viertelstunde

1. Legen Sie sich drei Testadressen an: eine bei Gmail, eine bei Outlook.com, eine bei GMX. Drei verschiedene Bewertungsschulen, drei verschiedene Ergebnisse.
2. Füllen Sie das *echte* Formular auf der Live-Seite aus, nicht den Testdialog des Plugins. Der Testdialog umgeht oft genau den Pfad, der kaputt ist.
3. Öffnen Sie in Gmail „Original anzeigen“ und lesen Sie `Authentication-Results`. Sie suchen `spf=pass`, `dkim=pass`, `dmarc=pass` – und `header.from` auf Ihrer Domain.
4. Prüfen Sie die Ausrichtung mit eigenen Augen: Steht in `smtp.mailfrom` Ihre Domain oder die Ihres Hosters? Das ist der Unterschied zwischen „SPF besteht“ und „SPF hilft mir“.
5. Wiederholen Sie Schritt drei für Outlook und GMX. Unterschiedliche Ergebnisse bei identischer Nachricht sind das stärkste Indiz für eine halbfertige Authentifizierung.
6. Senden Sie dieselbe Formular-Nachricht an eine Adresse von mail-tester.com und lesen Sie den Score von 0 bis 10. Der Dienst prüft SPF, DKIM, DMARC, Blocklisten und Formatierung – und weist selbst darauf hin, dass der Wert Orientierung ist und keine Zustellgarantie.
7. Aktivieren Sie ein Mail-Logging-Plugin, senden Sie erneut und prüfen Sie, ob das Protokoll eine echte Übergabe mit Antwort des Relays dokumentiert – nicht nur einen Eintrag „gesendet“.

Wenn Schritt sieben leer bleibt oder nur ein nacktes „true“ zeigt, sind Sie noch auf `mail()`. Dann beginnt die Arbeit bei Ursache vier.

## Monitoring, damit es beim nächsten Mal laut scheitert

Die eigentliche Lehre aus diesem Fehlerbild ist nicht die Reparatur, sondern die Sichtbarkeit. Vier Dinge, die wir bei den Seiten, die wir betreuen, zur Routine machen:

- **Mail-Logging mit Aufbewahrungsfrist.** Mindestens 30 Tage, damit die Frage „ist die Anfrage von letzter Woche rausgegangen?“ beantwortbar ist.
- **DMARC-Aggregatreports monatlich ansehen.** Nicht täglich – monatlich, aber wirklich. Dort steht, welches System als Ihre Domain sendet und ob es ausgerichtet ist.
- **Eine geplante Testeinsendung pro Monat** über das echte Formular an eine überwachte Adresse. Bleibt sie aus, wissen Sie es innerhalb eines Monats statt innerhalb eines Quartals.
- **Ein Punkt in der Wartungsroutine**, der nach jedem Plugin- oder Hoster-Wechsel den Testlauf auslöst.

Wer nennenswerte Mengen an Gmail-Adressen erreicht, sollte zusätzlich in die Google Postmaster Tools schauen. In Version 2 gibt es unter „Compliance status“ eine Rubrik „Deliverability analysis“, die die Rohsignale – Volumen, Spam-Schwelle, Interaktion, Authentifizierung – in eine verständliche Einschätzung samt Handlungsempfehlung übersetzt. Die Botschaft dahinter ist nützlich: Bestandene Authentifizierung ist die Eintrittskarte, nicht die Ziellinie.

## Fünf Momente, an denen es wieder kaputtgeht

Das hier ist kein einmaliger Fix. Es ist eine Konfiguration, die an bestimmten Stellen zuverlässig zerbricht. Führen Sie das Testprotokoll nach jedem dieser Ereignisse erneut aus:

1. Domainumzug zu einem anderen Registrar.
2. Wechsel des Hosters oder des DNS-Anbieters – Nameserverwechsel nehmen MX, SPF, jeden DKIM-Selector und DMARC gern nicht mit. Prüfen Sie vorher, ob jeder Eintrag beim neuen Anbieter existiert; ist DNSSEC aktiv, klären Sie zuerst den DS-Eintrag beim Registrar.
3. Ein neues System, das als Ihre Domain sendet: CRM, Newslettertool, Buchungssoftware, Rechnungsdienst.
4. Ein Relaunch, bei dem die Seite migriert wird und die Mail-Einträge nicht.
5. Jede Verschärfung der DMARC-Richtlinie – von `p=none` auf `p=quarantine` oder weiter.

## Häufige Fragen

### Reicht ein SMTP-Plugin allein?

Nein. Es ersetzt den Versandweg, und das ist ein notwendiger Schritt. Es korrigiert aber nicht automatisch den From-Header, es veröffentlicht keine DNS-Einträge und es hilft nicht, wenn Ihr Hoster den Port blockiert. Das Plugin ist ein Werkzeug, keine Lösung.

### Warum kommt meine Formular-Mail bei Gmail an, bei Outlook aber nicht?

Weil beide Anbieter dieselben Signale unterschiedlich gewichten. Eine Nachricht ohne DKIM-Signatur und mit falsch ausgerichtetem SPF kann bei einem Empfänger noch durchrutschen und beim nächsten abgewiesen werden. Die Antwort steht in der Zeile `Authentication-Results` der Nachricht, die angekommen ist – lesen Sie die, statt zu raten.

### Darf die Adresse der Besucherin in den From-Header?

Technisch darf sie, funktional sollte sie nicht. Sie senden damit im Namen einer Domain, für die Sie keine Berechtigung nachweisen können – das ist genau das Muster, das moderne Authentifizierung unterbinden soll. Setzen Sie die Besucheradresse in `Reply-To`; der Komfort bleibt, die Zustellung wird verlässlich.

### Blockiert DMARC mein eigenes Kontaktformular?

Das kann es, ja – und es ist ein häufiger Auslöser. Steht Ihre Domain auf `p=quarantine` oder `p=reject` und sendet der Webserver unsigniert mit fremdem Envelope, fällt die eigene Formular-Mail durch die eigene Richtlinie. Deshalb gehört der Webserver vor jeder Verschärfung auf die Liste der legitimen Absender.

### Wie weise ich nach, dass eine Anfrage nie zugestellt wurde?

Rückwirkend nur mit einem Mail-Log, das den Übergabezeitpunkt und die Antwort des Relays festhält, plus – falls vorhanden – dem Bounce im Relay-Dashboard. Ohne Logging gibt es keinen Nachweis, nur Vermutungen. Das ist der eigentliche Grund, Logging einzuschalten, bevor der Streitfall da ist.

## Zum Schluss

Das Testprotokoll oben ist eine Viertelstunde Arbeit und beantwortet die Frage, ob Sie ein Problem haben. Die Reparatur liegt je nach Ursache zwischen 30 Minuten und einem halben Tag; die DMARC-Rampe ist ein eigenes Projekt über Wochen. Wenn Sie das nicht selbst machen möchten: Wir prüfen die Zustellbarkeit von Formular- und Systemmails im Rahmen der [Website-Pflege](https://digitaldomination.xyz/leistungen), und für einen einmaligen Blick darauf genügt eine [kurze Nachricht](https://digitaldomination.xyz/kontakt).

## Quellen

1. [Why wp_mail() silently eats your form notifications — and how to fix it for free](https://dev.to/mrpsiho/why-wpmail-silently-eats-your-form-notifications-and-how-to-fix-it-for-free-5ckl) (abgerufen 2026-09-28)
2. [Error 550-5.7.26: This Mail Is Unauthenticated — SendLayer](https://sendlayer.com/docs/error-550-5-7-26-this-mail-is-unauthenticated/) (abgerufen 2026-09-28)
3. [What Is an Email Return-Path? — MxToolbox](https://mxtoolbox.com/dmarc/spf/setup/spf-return-path) (abgerufen 2026-09-28)
4. [How to Send Email on WP Engine — WP Engine Support](https://wpengine.com/support/using-3rd-party-email-provider-send-mail-wordpress/) (abgerufen 2026-09-28)
5. [When SPF Lookup Limits Actually Break Things — DuoCircle](https://www.duocircle.com/blog/when-spf-lookup-limits-actually-break-things/) (abgerufen 2026-09-28)
6. [DMARC Aggregate Reports: What They Reveal — Sendmarc](https://sendmarc.com/dmarc/aggregate-reports/) (abgerufen 2026-09-28)
7. [How to use mail-tester.com to check email deliverability — mybox.com Help](https://mybox.com/help/en/knowledgebase/mail-tester-com-evaluating-and-interpreting-your-email-quality/) (abgerufen 2026-09-28)
8. [Ultimate Guide to Google Postmaster Tools V2 — Suped](https://www.suped.com/blog/ultimate-guide-to-google-postmaster-tools-v2) (abgerufen 2026-09-28)
9. [Massive Microsoft 365 outage causes auth issues, service failures — BleepingComputer](https://www.bleepingcomputer.com/news/microsoft/microsoft-exchange-online-outage-causes-email-failures-auth-issues/) (abgerufen 2026-09-28)
10. [Microsoft Confirms New Exchange Online Outage Delaying Emails from External Domains — Cyber Security News](https://cybersecuritynews.com/exchange-online-outage-delaying-emails/) (abgerufen 2026-09-28)
11. [Against which domain is SPF checked? — Suped](https://www.suped.com/learn/spf/against-which-domain-is-spf-checked) (abgerufen 2026-09-28)