Wegwerf-Adressen sperren: WordPress, CF7 und Shopware

Ein Formular, das jede formal gültige Adresse akzeptiert, lädt Wegwerf-Postfächer ein. Dieser Ratgeber zeigt, wie Sie Wegwerf-Adressen sperren, ohne echte Kunden auszusperren: mit einem serverseitigen Aufruf der mailcheck-API, konkretem Code für Contact Form 7, WooCommerce und Shopware sowie Regeln für Zeitlimit, Fallback und Fehlermeldungen.

Wegwerf-Adressen sperren: Warum ein regulärer Ausdruck nicht reicht

Ein regulärer Ausdruck prüft nur die Form. Eine Adresse wie test@mailinator.com ist formal einwandfrei. Selbst WordPress-eigene Prüfungen fragen im Kern nach der Gestalt der Adresse, nicht nach dem Anbieter dahinter. Erst eine Abfrage der Domain gegen Sperrlisten, eine Prüfung der Mailserver und weitere Signale erkennen Wegwerf-Anbieter. Das leistet mailcheck, indem es jede Adresse in fester Reihenfolge abarbeitet (siehe Methodik).

Eine eigene Sperrliste im Code zu pflegen ist möglich, aber aufwendig: Sie müssten Quellen laden, Lizenzen beachten, Subdomains behandeln und die Liste täglich aktualisieren. Wie das aussieht, beschreibt der Ratgeber Temporäre E-Mail-Liste.

Grundregeln für jede Einbindung

Beachten Sie das Limit: 10 Anfragen pro Minute und 500 pro Tag je IP-Adresse. Bei einem serverseitigen Aufruf zählt die IP Ihres Servers, alle Besucher teilen sich das Kontingent; mehr als 10 Anmeldungen in einer Minute beantwortet die API mit 429. Für kleine Seiten reicht das, ein Shop mit vielen Anmeldungen stößt daran. Planen Sie deshalb den Fail-open-Fall ein (Anmeldung durchlassen, wenn die Prüfung nicht antwortet). Jede Antwort nennt den Rest in den Headern X-RateLimit-Limit, X-RateLimit-Remaining und X-RateLimit-Reset (Unix-Sekunden), bei 429 steht die Wartezeit in Retry-After. API-Schlüssel für höhere Limits folgen. Wer viele Adressen auf einmal prüft, etwa beim Bereinigen einer Kundenliste, nutzt POST /api/v1/pruefen/stapel mit bis zu 10 Adressen je Anfrage (jede zählt einzeln gegen das Limit).

Gemeinsame Hilfsfunktion für WordPress

Alle WordPress-Beispiele nutzen dieselbe Funktion. Sie ruft die API mit wp_remote_post() auf, das bei einem Fehler ein WP_Error zurückgibt. Legen Sie sie in ein eigenes kleines Plugin, nicht in die functions.php eines Themes, das bei einem Wechsel verloren geht.

<?php
/**
 * Plugin Name: mailcheck-Prüfung
 */

function mc_pruefen( string $email ): ?array {
	$antwort = wp_remote_post(
		'https://mailcheck.moersbergerit.de/api/v1/pruefen',
		array(
			'timeout' => 3,
			'headers' => array( 'Content-Type' => 'application/json' ),
			'body'    => wp_json_encode( array( 'email' => $email ) ),
		)
	);
	if ( is_wp_error( $antwort ) || 200 !== wp_remote_retrieve_response_code( $antwort ) ) {
		return null; // Fail open: Anmeldung nicht blockieren.
	}
	$daten = json_decode( wp_remote_retrieve_body( $antwort ), true );
	return is_array( $daten ) ? $daten : null;
}

function mc_ablehnen( string $email ): bool {
	$daten = mc_pruefen( $email );
	return is_array( $daten ) && ( $daten['empfehlung'] ?? '' ) === 'ablehnen';
}

Die Funktion liefert null, wenn die Prüfung nicht möglich war, auch bei jedem Fehlerstatus. Fehlerantworten der API haben die Form {"fehler": "limit", "text": "..."}; für Programmlogik zählt der Code in fehler, nicht der Text. Erst bei einer eindeutigen Empfehlung ablehnen wird gesperrt.

Contact Form 7

Contact Form 7 validiert jedes Feld über einen Filter, dessen Name vom Typ des Form-Tags abhängt. Für E-Mail-Felder heißt er wpcf7_validate_email, bei Pflichtfeldern (email*) wpcf7_validate_email*. Die Dokumentation zur eigenen Validierung beschreibt das Muster: Der Filter erhält das Ergebnisobjekt und das Tag, markiert ein Feld mit invalidate() als fehlerhaft und gibt das Ergebnis zurück. Registrieren Sie die Funktion für beide Varianten:

add_filter( 'wpcf7_validate_email', 'mc_cf7_pruefen', 20, 2 );
add_filter( 'wpcf7_validate_email*', 'mc_cf7_pruefen', 20, 2 );

function mc_cf7_pruefen( $result, $tag ) {
	$feld  = $tag->name;
	$email = isset( $_POST[ $feld ] ) ? sanitize_email( wp_unslash( $_POST[ $feld ] ) ) : '';

	if ( '' !== $email && mc_ablehnen( $email ) ) {
		$result->invalidate(
			$tag,
			'Bitte nennen Sie eine Adresse, unter der wir Sie dauerhaft erreichen.'
		);
	}
	return $result;
}

Testen Sie das Formular mit einer Adresse wie test@mailinator.com. Das Feld sollte rot markiert werden und die Meldung zeigen. Nach einem Update von Contact Form 7 lohnt sich ein kurzer Test, weil Sie an eine Schnittstelle des Plugins andocken.

WooCommerce: Registrierung und Checkout

Für die Kundenregistrierung bietet WooCommerce den Filter woocommerce_registration_errors. Laut der Referenz von wp-kama erhält er ein WP_Error-Objekt, den Benutzernamen und die Adresse und wird vor dem Anlegen des Nutzers ausgeführt. Enthält das zurückgegebene Objekt einen Fehler, wird das Konto nicht angelegt:

add_filter( 'woocommerce_registration_errors', 'mc_woo_registrierung', 10, 3 );

function mc_woo_registrierung( $fehler, $benutzername, $email ) {
	if ( mc_ablehnen( $email ) ) {
		$fehler->add(
			'mc-wegwerf',
			'Bitte verwenden Sie eine Adresse, unter der wir Sie dauerhaft erreichen.'
		);
	}
	return $fehler;
}

Dieser Filter greift bei der Kontoregistrierung. Gastbestellungen im Checkout laufen über eine andere Validierung. Wenn Sie auch dort prüfen wollen, hängen Sie sich in die Checkout-Validierung Ihrer WooCommerce-Version ein und testen Sie den Ablauf mit Gast- und Kontobestellung. Welche Hooks dafür in Ihrer Version zur Verfügung stehen, lesen Sie in der WooCommerce-Entwicklerdokumentation nach.

Shopware 6

Shopware baut die Prüfdefinition der Registrierung in der RegisterRoute auf und schickt dabei ein BuildValidationEvent. Ein Plugin kann diese Definition ergänzen. Der Name des Events setzt sich aus dem Präfix framework.validation. und dem Namen der Definition zusammen; für die Kundenregistrierung ist das nach Aussage eines Beitrags im Shopware-Forum framework.validation.customer.create. Der Quelltext der RegisterRoute zeigt, dass dieselbe Definition auch für Gastbestellungen aufgebaut wird; die Eindeutigkeit der Adresse und das Passwort werden dort nur für Konten ergänzt.

Ein Subscriber, der eine Symfony-Callback-Constraint hinzufügt, sieht so aus:

<?php declare(strict_types=1);

namespace MeinPlugin\Subscriber;

use Shopware\Core\Framework\Validation\BuildValidationEvent;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\Validator\Constraints\Callback;
use Symfony\Component\Validator\Context\ExecutionContextInterface;
use Symfony\Contracts\HttpClient\HttpClientInterface;

class MailcheckSubscriber implements EventSubscriberInterface
{
    public function __construct(private readonly HttpClientInterface $http) {}

    public static function getSubscribedEvents(): array
    {
        return ['framework.validation.customer.create' => 'beimAufbau'];
    }

    public function beimAufbau(BuildValidationEvent $event): void
    {
        $event->getDefinition()->add('email', new Callback(
            function ($wert, ExecutionContextInterface $kontext): void {
                if (!is_string($wert) || $wert === '') {
                    return;
                }
                try {
                    $antwort = $this->http->request('POST', 'https://mailcheck.moersbergerit.de/api/v1/pruefen', [
                        'json' => ['email' => $wert],
                        'timeout' => 3,
                    ])->toArray();
                } catch (\Throwable) {
                    return; // Fail open
                }
                if (($antwort['empfehlung'] ?? '') === 'ablehnen') {
                    $kontext->buildViolation('Bitte nennen Sie eine Adresse, unter der wir Sie dauerhaft erreichen.')
                        ->addViolation();
                }
            }
        ));
    }
}

Registrieren Sie die Klasse in der services.xml Ihres Plugins als Service mit dem Tag kernel.event_subscriber. Prüfen Sie nach der Installation auf einer Testumgebung, ob die Fehlermeldung im Storefront-Formular erscheint. Im oben genannten Forumsbeitrag berichtet ein Entwickler, dass die Meldung in Shopware 6.7.3 nicht angezeigt wurde, während sie in 6.4 funktionierte. Die Ursache ist dort nicht geklärt; testen Sie daher mit Ihrer Version, bevor Sie live gehen.

Fehlermeldungen, die nicht abschrecken

Die Meldung entscheidet darüber, ob ein echter Kunde einen zweiten Versuch startet. Drei Beispiele:

• Gut: „Bitte nennen Sie eine Adresse, unter der wir Sie dauerhaft erreichen.“
• Gut: „Diese Adresse scheint nur kurze Zeit zu bestehen. Bitte geben Sie eine andere an.“
• Schlecht: „Wegwerf-Adressen sind verboten.“ Das klingt nach Vorwurf und sagt nicht, was zu tun ist.

Erklären Sie knapp den Zweck und nennen Sie die Handlung. Zeigen Sie das Ergebnis nicht an, wenn es „verdächtig“ lautet: Lassen Sie die Anmeldung zu und verlangen Sie die Bestätigung per Link.

Alias-Adressen und verdächtige Fälle

Zwei Ergebnisse brauchen eine bewusste Entscheidung:

Die Beispiele zeigen, wie sich die Urteile für bekannte Domains darstellen (Stand 05.11.2026): mailinator.com und trashmail.com liefern wegwerf mit 98 Punkten, mozmail.com liefert alias mit 20 Punkten, gmail.com liefert frei mit 0 Punkten.

Datenschutz bei der Einbindung

Wenn Ihr Server die Adresse eines Besuchers an mailcheck übergibt, verarbeiten Sie ein personenbezogenes Datum bei einem Dienstleister. Der Dienst läuft auf einem Server in Deutschland, Cloudflare ist als Netzbetreiber vorgeschaltet, sodass die Anfrage technisch über dessen Netz läuft. Die Anwendung selbst speichert und protokolliert die Adresse nicht; gezählt werden Tageszähler je Ergebnisart und bei Wegwerf- und Alias-Treffern die Domain. Ihre eigene Rechtsgrundlage und die Nennung in der Datenschutzerklärung bleiben Ihre Aufgabe. Das ist ein allgemeiner Hinweis und keine Rechtsberatung; klären Sie Einzelheiten mit einer fachkundigen Stelle. Das Verhalten im Detail beschreibt die Methodik-Seite.

Test-Checkliste vor dem Livegang

1. Wegwerf-Adresse (test@mailinator.com) wird mit Meldung abgelehnt.
2. Normale Adresse (test@gmail.com) wird akzeptiert.
3. Fehlerfall: Schalten Sie testweise das Netz zur API ab oder setzen Sie die URL auf eine ungültige Adresse; das Formular darf nicht blockieren.
4. Syntaktisch ungültige Adresse liefert die Standardmeldung Ihres Formulars, nicht einen Absturz.
5. Kein Eintrag mit der Adresse im Fehlerprotokoll.

Wenn Sie nur eine einzelne Adresse prüfen möchten, nutzen Sie das Prüffeld. Weitere Maßnahmen gegen Scheinanmeldungen, etwa Honeypot und Rate-Limit, beschreibt Fake-Anmeldungen verhindern.

Häufige Fragen