← wupper.io

Mail-Policy Mail policy

E-Mail abgelehnt? Email rejected?

Unser Mailserver hat Ihre Nachricht zurückgewiesen. Hier erfahren Sie warum, und was zu tun ist. Our mail server bounced your message. Here you find out why, and what to do about it.

Warum bin ich hier? Why am I here?

Sie haben eine E-Mail an einen Empfänger auf unserem Mailserver gesendet und eine Fehlermeldung mit einem Link auf diese Seite erhalten. Das bedeutet: Ihre Nachricht konnte eine unserer Authentifizierungs- oder Formatprüfungen nicht bestehen.

Die Fehlermeldung enthält einen Deep-Link zum passenden Abschnitt (z. B. #spf-fail). Dort finden Sie die Ursache und konkrete Schritte zur Behebung.

You sent a message to a recipient on our mail server and received a bounce referencing this page. That means your message did not pass one of our authentication or format checks.

The bounce message contains a deep link to the specific reason (e.g. #spf-fail). Jump there for the cause and concrete remediation steps.

Bei Infrastruktur-Problemen: postmaster@wupper.io Infrastructure issues: postmaster@wupper.io

postmaster@wupper.io ist die Rolladresse für technische Anfragen rund um unseren Mailserver, sie ist nach RFC 2142 garantiert erreichbar, auch wenn Ihre Domain unsere Authentifizierungsprüfungen nicht besteht.

Nicht zuständig für: Inhaltliche Fragen an einen Empfänger, Adresssuche, Korrektur von Tippfehlern. Solche Anfragen müssen Sie direkt an die Empfänger-Organisation richten, wir hosten Mailserver für viele Kunden und können keine Einzeladressen herausgeben.

postmaster@wupper.io is the role address for technical questions about our mail server, guaranteed reachable per RFC 2142, even when your domain fails our authentication checks.

Not the right contact for: Reaching out to a specific recipient, looking up addresses, fixing typos. Such requests must go directly to the recipient organization, we host mail servers for many customers and cannot disclose individual addresses.

Übersicht Overview

Weiche Ablehnung: Mail landet im Spam-Ordner, kein Bounce Soft handling, message goes to spam folder, no bounce

Harte Ablehnung: Bounce mit Fehlermeldung Hard reject: sender receives a bounce

Weiche Ablehnung: Spam-Markierung Soft handling: spam marking

Die folgenden Fälle führen nicht zu einem Bounce. Die Mail wird angenommen, mit X-Spam-Flag: YES markiert und landet im Spam-/Junk-Ordner des Empfängers. Der Absender erhält keine Fehlermeldung, die Mail gilt als zugestellt. Empfänger können die Mail im Spam-Ordner finden und bei Bedarf als „kein Spam" markieren. The following situations do not trigger a bounce. The message is accepted, marked with X-Spam-Flag: YES and delivered to the recipient's spam/junk folder. The sender does not receive an error, the message counts as delivered. Recipients can locate it in spam and flag it as "not spam" if needed.

SPF softfail : Mail landet im Spam-Ordner: message routed to spam folder

Was bedeutet das?

Ihr SPF-Record steht auf ~all (Softfail) und die absendende IP ist nicht im Record. Die Domain selbst signalisiert damit Unsicherheit, sie weiß nicht eindeutig, wer berechtigt ist. Da DKIM/ARC ebenfalls fehlt, behandeln wir die Mail als verdächtig und legen sie ins Spam-Postfach.

Empfehlung

Stellen Sie Ihren SPF-Record auf -all (Hardfail) um, sobald alle tatsächlichen Versand-IPs im Record stehen. ~all ist nur für die Einführungs- und Testphase gedacht. Hardfail bringt deutlich bessere Zustellraten bei seriösen Empfängern.

What does this mean?

Your SPF record uses ~all (softfail) and the sending IP is not listed. The domain itself signals uncertainty, it doesn't fully commit to who is authorized. With no DKIM/ARC alignment either, we route the message to spam.

Recommendation

Switch your SPF record to -all (hardfail) once all your sending IPs are accounted for. ~all is only intended for the rollout and testing phase. Hardfail gives noticeably better deliverability with reputable receivers.

SPF neutral : Mail landet im Spam-Ordner: message routed to spam folder

Was bedeutet das?

Ihr SPF-Record schließt mit ?all ab, was „keine Aussage" bedeutet. Die Domain dokumentiert damit explizit, dass sie über Versandberechtigungen keine Auskunft geben möchte. Das ist nicht spammy, aber auch nicht vertrauensbildend, wir routen die Mail vorsichtshalber in den Spam-Ordner, wenn keine valide DKIM/ARC vorliegt.

Empfehlung

?all entspricht praktisch keinem SPF, falls Sie Ihre Sender-IPs korrekt hinterlegt haben, wechseln Sie auf -all. Falls nicht, ist es ehrlicher, gar keinen SPF-Record zu publizieren.

What does this mean?

Your SPF record ends with ?all, meaning "no opinion". The domain explicitly declines to make a statement about sending authorization. Not spammy, but not trust-building either, without valid DKIM/ARC, we route the message to spam as a precaution.

Recommendation

?all is practically equivalent to having no SPF. If your sending IPs are correctly listed, switch to -all. If they aren't, it's more honest to publish no SPF record at all.

Kein SPF-RecordNo SPF record : Mail landet im Spam-Ordner: message routed to spam folder

Was bedeutet das?

Ihre Domain publiziert keinen SPF-Record. Seit 2024 verlangen die großen Mail-Provider SPF (oder DKIM) als Mindeststandard für seriösen Versand. Das Fehlen ist ein starker Qualitätsindikator, aber kein klarer Spam-Beweis. Wir routen die Mail in den Spam-Ordner, wenn auch DKIM/ARC fehlen.

Empfehlung

  • SPF-Record erzeugen, Einsteiger: v=spf1 include:_spf.ihranbieter.com -all (Mailprovider-Include) oder direkte IP-Mechanismen.
  • Alternativ DKIM einrichten, wenn DKIM korrekt aligned ist, wird SPF nicht mehr benötigt.
  • Ideal: beides plus DMARC mit p=quarantine oder p=reject.

What does this mean?

Your domain has no SPF record. Since 2024, major mail providers require SPF (or DKIM) as a baseline for legitimate sending. Absence is a strong quality indicator but not conclusive proof of spam. We route the message to spam when DKIM/ARC are also missing.

Recommendation

  • Publish an SPF record, beginner: v=spf1 include:_spf.your-provider.com -all or direct IP mechanisms.
  • Or set up DKIM, if DKIM aligns, SPF is not strictly required.
  • Ideal: both, plus DMARC with p=quarantine or p=reject.

Harte Ablehnung: Reject mit Bounce Hard reject, bounce returned to sender

Die folgenden Fälle führen zu einer sofortigen SMTP-Ablehnung. Der Absender erhält eine Bounce-Mail mit einem Deep-Link auf den passenden Abschnitt unten, Ursache, häufige Auslöser und konkrete Schritte zur Behebung. The following situations trigger an immediate SMTP rejection. The sender receives a bounce message with a deep link to the relevant section below, cause, common triggers and concrete remediation steps.

5.1.1 Empfänger existiert nichtRecipient does not exist

Was bedeutet das?

Die angegebene Empfänger-Adresse existiert auf unserem Mailserver nicht. Es gibt kein Postfach und auch keinen Alias, der diese Adresse abdeckt.

Ursachen

  • Tippfehler in der Adresse.
  • Die Adresse wurde geschlossen oder umgezogen.
  • Die gewünschte Person ist nicht (mehr) in der Empfänger-Organisation.

Was tun?

Verifizieren Sie die Adresse über einen anderen Kanal direkt mit dem gewünschten Empfänger oder dessen Organisation, Telefon, Website-Kontaktformular, Visitenkarte. Wir hosten Mailserver für viele Kunden und können Ihnen die korrekte Adresse einer einzelnen Person nicht nennen.

What does this mean?

The recipient address does not exist on our mail server. There is no mailbox or alias matching this address.

Common causes

  • Typo in the address.
  • The address was closed or moved.
  • The intended person is no longer with the recipient organization.

How to fix

Verify the address through another channel directly with the intended recipient or their organization, telephone, contact form, or business card. We host mail servers for many customers and cannot disclose the correct address of an individual.

5.2.2 Postfach des Empfängers vollRecipient mailbox is full

Was bedeutet das?

Das Postfach des Empfängers hat sein Speicher-Kontingent (Quota) erreicht. Unser Mailserver lehnt die Zustellung mit einem permanenten Fehler ab, das ist keine vorübergehende Störung, ein erneuter Versand bringt nichts, solange der Empfänger nicht aufräumt.

Was tun?

Diese Situation kann nur der Empfänger lösen, Postfach aufräumen oder beim eigenen Mail-Admin Quota-Erhöhung anfragen. Versuchen Sie, den Empfänger auf einem anderen Weg zu erreichen.

What does this mean?

The recipient's mailbox has reached its storage quota. Our mail server rejects delivery with a permanent error, this is not a temporary failure; resending will not help until the recipient cleans up.

How to fix

Only the recipient can resolve this, clean up the mailbox or ask their mail admin for a quota increase. Try contacting the recipient via another channel.

5.3.4 Nachricht zu großMessage too large

Was bedeutet das?

Ihre Mail ist größer als unser Empfangslimit. Unser Server lehnt sie schon im SIZE-Schritt der SMTP-Konversation ab, die eigentliche Nachricht wird erst gar nicht übertragen.

Was tun?

  • Anhänge entfernen oder komprimieren.
  • Große Dateien über einen Cloud-Speicher per Link teilen.
  • Im Zweifel beim Empfänger nachfragen, ob ein höheres Limit zugelassen werden kann, bei Geschäftskunden ist das auf Wunsch konfigurierbar.

What does this mean?

Your message exceeds our receive limit. Our server rejects it during the SIZE step of the SMTP conversation, the actual content is never transmitted.

How to fix

  • Remove or compress attachments.
  • Share large files via cloud storage and send a link.
  • If in doubt, ask the recipient whether a higher limit can be granted, for business customers this is configurable on request.

5.4.4 Absenderdomain ohne DNS-EinträgeSender domain has no DNS records

Was bedeutet das?

Die Domain in Ihrem MAIL FROM-Header (Envelope-Sender) hat weder einen MX- noch einen A-Record. Ohne auffindbare Rückmelde-Adresse können wir Bounces nicht zustellen, das würde zu Backscatter führen. Unser Mailserver lehnt deshalb solche Mails grundsätzlich ab.

Ursachen

  • DNS-Konfiguration der Absenderdomain ist unvollständig oder defekt.
  • Domain wurde gerade erst registriert und DNS-Records sind noch nicht propagiert.
  • Tippfehler in der Sender-Adresse.

Was tun?

  • DNS-Konfiguration prüfen, mindestens ein MX- oder A-Record für die Sender-Domain ist erforderlich.
  • Mit dig MX absender-domain.example die Auflösung überprüfen.

What does this mean?

The domain in your MAIL FROM (envelope sender) has neither an MX nor an A record. Without a deliverable bounce address, we cannot return delivery status notifications, that would cause backscatter. Our mail server rejects such messages outright.

Common causes

  • DNS configuration of the sender domain is incomplete or broken.
  • Domain was just registered and DNS records have not propagated yet.
  • Typo in the sender address.

How to fix

  • Audit the DNS configuration, at least an MX or A record for the sender domain is required.
  • Use dig MX sender-domain.example to verify resolution.

5.6.0 From-Header fehltMessage is missing From header

Was bedeutet das?

Der From:-Header ist nach RFC 5322 § 3.6 Pflicht. Er fehlt in Ihrer Nachricht.

Was tun?

Das ist fast immer ein Bug in der Versandsoftware (Skripte, Monitoring-Tools, Legacy-Systeme). Stellen Sie sicher, dass der From:-Header immer gesetzt wird.

What does this mean?

The From: header is mandatory per RFC 5322 § 3.6. It is missing from your message.

How to fix

This is almost always a bug in sending software (scripts, monitoring tools, legacy systems). Ensure the From header is always set.

5.6.0 Mehrere From-HeaderMessage has multiple From headers

Was bedeutet das?

Die Nachricht enthält mehr als einen From:-Header. Laut RFC 5322 ist genau einer zulässig. Mehrere From-Header sind ein bekannter Spoofing-Trick, weil Mail-Clients und DKIM-Prüfer unterschiedliche Header sehen können.

Was tun?

Versandsoftware prüfen. Andere doppelt gesetzte Unique-Header werden ebenfalls abgelehnt, siehe Doppelte Unique-Header.

What does this mean?

The message contains more than one From: header. RFC 5322 permits exactly one. Duplicated From headers are a known spoofing technique because mail clients and DKIM verifiers may see different headers.

How to fix

Audit your sending software. Other duplicated unique headers are also rejected, see Duplicate unique headers.

5.6.0 Doppelte Unique-HeaderMessage has duplicate unique headers

Was bedeutet das?

Die Nachricht enthält mehrere Exemplare eines Headers, der laut RFC 5322 nur einmal vorkommen darf, z. B. Subject, Date, Message-ID, To, Cc, Bcc, Reply-To, References, In-Reply-To. Wie bei mehrfachem From entsteht eine Spoofing-Lücke: unterschiedliche Stationen einer Mail-Verarbeitung können unterschiedliche Werte sehen.

Ursachen

  • Bug in der Versandsoftware bei MIME-Manipulation oder Header-Injection.
  • Mailinglisten-Software, die das Original modifiziert statt eine neue Mail zu bauen.
  • Skript-basierte Versendung, die einen Setter-Aufruf doppelt macht.

Was tun?

  • Versandsoftware prüfen, meist ein Bug, der bei MIME-Manipulation entsteht.
  • Bei Mailinglisten: nicht das Original verändern, sondern eine neue Mail mit eigenen Headern bauen.
  • Bei Skripten: nicht zweimal $mail->setSubject(...) aufrufen, sondern den Header explizit setzen.

What does this mean?

The message contains multiple instances of a header that RFC 5322 mandates as unique, e.g. Subject, Date, Message-ID, To, Cc, Bcc, Reply-To, References, In-Reply-To. Like duplicated From, this opens a spoofing gap: different stages of mail processing may see different values.

Common causes

  • Bug in sending software during MIME manipulation or header injection.
  • Mailing list software that modifies the original instead of building a new message.
  • Script-based sending that calls a setter twice.

How to fix

  • Audit your sending software, usually a bug introduced during MIME manipulation.
  • For mailing lists: don't modify the original; build a new message with your own headers.
  • For scripts: avoid calling $mail->setSubject(...) twice; set the header explicitly.

5.6.0 Ungültige Message-IDInvalid Message-ID format

Was bedeutet das?

Der Message-ID-Header der Nachricht entspricht nicht dem RFC-5322-Format. Korrektes Format: <eindeutiger-string@absender-domain>, in spitzen Klammern, mit @ und einem auflösbaren Domain-Teil. Massenmailer und Bot-Netze produzieren oft schlecht formatierte Message-IDs.

Ursachen

  • Spitze Klammern fehlen.
  • Kein @ im Wert.
  • Doppelte oder fehlende Klammern.
  • Domain-Teil ist eine IP-Adresse oder Localhost.

Was tun?

Eine korrekte Message-ID sieht z. B. so aus: <abc123.20260505@absender.example.com>

In der Versandsoftware sicherstellen, dass die Message-ID von einer etablierten Mail-Bibliothek erzeugt wird, nicht selbst zusammenbasteln.

What does this mean?

The message's Message-ID header does not conform to RFC 5322 format. Correct format: <unique-string@sender-domain>, angle brackets, an @ sign, and a resolvable domain. Bulk mailers and botnets often produce malformed Message-IDs.

Common causes

  • Missing angle brackets.
  • No @ in the value.
  • Doubled or missing brackets.
  • Domain part is an IP address or localhost.

How to fix

A valid Message-ID looks like this: <abc123.20260505@sender.example.com>

Use an established mail library to generate Message-IDs instead of crafting them manually.

5.6.0 Date-Header fehltMessage is missing Date header

Was bedeutet das?

Der Date:-Header ist nach RFC 5322 § 3.6 Pflicht. Er fehlt in Ihrer Nachricht.

Was tun?

In der Versandsoftware sicherstellen, dass der Date-Header im korrekten RFC-5322-Format gesetzt wird (z. B. Sun, 10 May 2026 15:38:08 +0200).

What does this mean?

The Date: header is mandatory per RFC 5322 § 3.6. It is missing from your message.

How to fix

Ensure your sending software emits a Date header in RFC 5322 format (e.g. Sun, 10 May 2026 15:38:08 +0200).

5.7.0 Sender-IP auf Blocklist (DNSBL)Sending IP listed in DNSBL

Was bedeutet das?

Die IP, von der Ihre Mail kommt, ist auf einer öffentlichen Blockliste (DNSBL) eingetragen. Unser Verbindungsfilter lehnt die Verbindung schon vor dem SMTP-Dialog ab. Solche Listen führen IPs auf, die kürzlich Spam, Botnet-Traffic oder Backscatter verursacht haben.

Ursachen

  • Ihr Mailserver wurde missbraucht (kompromittierter Account, offenes Relay, Botnet-Infektion).
  • Sie nutzen einen Shared-Hosting-Provider, dessen IP-Range von einem anderen Kunden negativ belegt wurde.
  • IP wurde gerade neu vergeben und trägt noch das Erbe des Vorbesitzers.

Was tun?

  • Ihre IP gegen die gängigen DNSBLs prüfen, Mehrfach-Lookup-Tools sind frei verfügbar.
  • Bei jeder Liste, auf der die IP steht, den Delisting-Prozess durchführen, die meisten erlauben kostenlose Selbst-Delistings.
  • Vor dem Delisting Ursache beheben (kompromittierter Account, fehlende SPF/DKIM, etc.), sonst landen Sie sofort wieder drauf.

What does this mean?

The IP your mail originates from is listed in a public blocklist (DNSBL). Our connection filter rejects the connection before the SMTP dialog even begins. Such lists track IPs that recently caused spam, botnet traffic, or backscatter.

Common causes

  • Your mail server was abused (compromised account, open relay, botnet infection).
  • You use a shared-hosting provider whose IP range was tainted by another customer.
  • IP was recently reassigned and still carries the previous owner's reputation.

How to fix

  • Check your IP against the common DNSBLs, multi-lookup tools are freely available.
  • Run the delisting process on every list that lists your IP, most permit free self-delisting.
  • Before delisting, fix the root cause (compromised account, missing SPF/DKIM, etc.), otherwise you'll land back on the list immediately.

5.7.1 DMARC p=reject: Ablehnung wegen DMARC-PolicyDMARC p=reject: message rejected by sender's DMARC policy

Was bedeutet das?

Die im From-Header genannte Domain publiziert eine DMARC-Policy mit p=reject. DMARC-Alignment war nicht gegeben, weder SPF noch DKIM haben gegen die From-Domain validiert. Die Domain weist empfangende Server selbst an, solche Mails abzulehnen.

Ursachen

  • Versendung unter fremdem Namen ohne Autorisierung (Spoofing).
  • Drittanbieter (z. B. Newsletter-Tool), dessen Versand nicht DKIM-signiert oder SPF-aligned ist.
  • Eine Weiterleitung hat SPF und DKIM gebrochen.

Was tun?

  • DMARC-Record prüfen und sicherstellen, dass SPF oder DKIM gegen die From-Domain aligned.
  • Bei DKIM: d=-Tag der Signatur muss zur From-Domain passen (oder eine übergeordnete, bei adkim=r).
  • Bei Newslettern: Signing-Domain beim Anbieter hinterlegen.

What does this mean?

The domain in your From header publishes a DMARC policy of p=reject. DMARC alignment was missing, neither SPF nor DKIM validated against your From domain. The domain itself instructs receiving servers to reject such messages.

Common causes

  • Sending under someone else's domain without authorization (spoofing).
  • Third-party sender (e.g. newsletter tool) without DKIM-aligned signing or SPF alignment.
  • Forwarding broke both SPF and DKIM.

How to fix

  • Audit the DMARC record and ensure SPF or DKIM aligns with the From domain.
  • For DKIM: the d= tag must match the From domain (or a parent, with adkim=r).
  • For newsletters: register your signing domain with the provider.

5.7.1 DMARC p=quarantine: Ablehnung wegen DMARC-PolicyDMARC p=quarantine: message rejected by sender's DMARC policy

Was bedeutet das?

Die Absenderdomain publiziert p=quarantine. Damit bittet sie empfangende Server, verdächtige Mails in die Quarantäne zu verschieben. Wir gehen einen Schritt weiter und lehnen direkt ab, das gibt einen klaren Bounce statt stillem Versacken im Spam-Ordner.

Was tun?

Identisch zu DMARC p=reject: Alignment von SPF oder DKIM zur From-Domain sicherstellen.

What does this mean?

The sender domain publishes p=quarantine, meaning it asks receivers to quarantine suspicious messages. We go one step further and reject outright, that gives a clear bounce instead of silent spam-folder delivery.

How to fix

Same as DMARC p=reject: ensure SPF or DKIM alignment with your From domain.

5.7.1 Relaying nicht erlaubtRelay access denied

Was bedeutet das?

Sie versuchen, eine Nachricht an einen Empfänger zuzustellen, der nicht auf unserem Mailserver liegt. Unser Server akzeptiert Mails ausschließlich für eigene Domains. Ein Relay über uns ist ohne SMTP-Authentifizierung nicht möglich (und mit Authentifizierung nur für unsere Kunden).

Ursachen

  • Falsch konfigurierter Smarthost, Ihr Mailclient sendet Mails an externe Empfänger über unseren Server.
  • Fehlerhafte Domain-Weiterleitung.
  • Spoofing-Versuch eines Spammers über unsere Infrastruktur.

Was tun?

  • SMTP-Server in Ihrem Mailclient auf den Server Ihres eigenen Providers umstellen.
  • Als unser Kunde: SMTP-Authentifizierung mit Mail-Adresse und Passwort verwenden.

What does this mean?

You are trying to deliver a message to a recipient not hosted on our server. Our server only accepts mail for its own domains. Relaying through us without SMTP authentication is not permitted (and with authentication only for our customers).

Common causes

  • Misconfigured smart host, your mail client sends mail for external recipients via our server.
  • Broken domain forwarding setup.
  • Spoofing attempt by a spammer routing through our infrastructure.

How to fix

  • Set the SMTP server in your mail client to your own provider's server.
  • As our customer: use SMTP authentication with your mail address and password.

5.7.1 HELO-Hostname nicht auflösbarHELO hostname is not resolvable

Was bedeutet das?

Der Mailserver hat sich beim Verbindungsaufbau mit einem HELO/EHLO-Hostnamen vorgestellt, der weder A- noch MX-Record im DNS hat, und die übergebene IP passt auch nicht zum Hostnamen.

Was tun?

  • HELO/EHLO auf einen auflösbaren FQDN setzen, der auf die Versand-IP zeigt.
  • Keine IPs in eckigen Klammern, keine lokalen Hostnamen wie mailserver.local.
  • Konvention: HELO-Name = PTR-Record der Versand-IP.

What does this mean?

The mail server announced itself with a HELO/EHLO hostname that has neither A nor MX record, and the passed IP does not match either.

How to fix

  • Set HELO/EHLO to a resolvable FQDN pointing to the sending IP.
  • No bracketed IPs, no local hostnames like mailserver.local.
  • Convention: HELO name equals the PTR record of the sending IP.

5.7.23 SPF Hardfail ohne DKIM-/ARC-AlignmentSPF hardfail without aligned DKIM or valid ARC chain

Was bedeutet das?

Die absendende IP ist laut SPF-Record Ihrer Domain nicht zum Versand berechtigt (-all). Weder eine zur Absenderdomain passende DKIM-Signatur noch eine gültige ARC-Kette lag vor, die dies ausgleichen könnte.

Ursachen

  • Mailserver oder Smarthost ist nicht im SPF-Record der Domain eingetragen.
  • Versand über einen Dienst (Newsletter-Provider, CRM, SaaS), dessen Versand-IPs nicht im SPF stehen.
  • SPF-Record enthält mehr als 10 DNS-Lookups und liefert PermError, siehe SPF PermError.

Was tun?

  • SPF-Record prüfen und alle tatsächlich versendenden IPs oder include:-Mechanismen ergänzen.
  • Alternativ DKIM korrekt mit Alignment zur From-Domain signieren, dann wird SPF nicht mehr benötigt.
  • Bei fortlaufenden Problemen postmaster@wupper.io kontaktieren.

What does this mean?

The sending IP is not authorized to send for your domain according to its SPF record (-all). Neither an aligned DKIM signature nor a valid ARC chain was present to compensate.

Common causes

  • Mail server or smart host is not listed in your domain's SPF record.
  • Sending via a third-party service (newsletter, CRM, SaaS) whose sending IPs are not covered.
  • SPF record exceeds 10 DNS lookups (PermError), see SPF PermError.

How to fix

  • Audit your SPF record and add all actual sending IPs or the correct include: mechanisms.
  • Alternatively sign with DKIM aligned to your From domain, SPF is then not required.
  • For persistent issues, contact postmaster@wupper.io.

5.7.23 SPF PermError: Record fehlerhaft oder Lookup-Limit überschrittenSPF permanent error: malformed record or lookup limit exceeded

Was bedeutet das?

Der SPF-Record der Domain liefert einen permanenten Fehler bei der Auswertung. Das ist nicht dasselbe wie ein Hardfail (-all), der Record ist kaputt, nicht das Ergebnis. Häufigste Ursache: mehr als 10 DNS-Lookups durch zu viele include:-Mechanismen, oder Syntaxfehler im Record.

Ursachen

  • Mehr als 10 verschachtelte DNS-Lookups (RFC 7208 § 4.6.4 setzt das Limit).
  • Doppelte SPF-Records (mehrere v=spf1-Einträge an derselben Stelle).
  • Syntaxfehler, falsch gesetzte Mechanismen, ungültige Modifier, Tippfehler.
  • Dangling include: auf Domains ohne SPF-Record.

Was tun?

  • SPF-Record mit einem Validator prüfen.
  • Lookups konsolidieren, viele include:-Ketten lassen sich durch direkte IP-Mechanismen ersetzen.
  • Auf einen einzelnen v=spf1-Eintrag pro Domain reduzieren.

What does this mean?

The domain's SPF record yields a permanent error on evaluation. This is not the same as a hardfail (-all), the record itself is broken, not the result. Most common cause: more than 10 DNS lookups via too many include: mechanisms, or syntax errors.

Common causes

  • More than 10 nested DNS lookups (RFC 7208 § 4.6.4 sets the limit).
  • Multiple SPF records (more than one v=spf1 entry on the same name).
  • Syntax errors, invalid mechanisms, malformed modifiers, typos.
  • Dangling include: targets pointing to domains without SPF.

How to fix

  • Validate the SPF record with an SPF lookup tool.
  • Consolidate lookups, many include: chains can be replaced with direct IP mechanisms.
  • Reduce to a single v=spf1 entry per domain.

5.7.25 Kein Reverse DNS (PTR) für Versand-IPReverse DNS lookup failed for sending IP

Was bedeutet das?

Zur absendenden IP-Adresse existiert kein PTR-Record. Seriöse Mailserver haben einen vollständigen Reverse-DNS-Eintrag. Fehlt dieser, ist das ein starker Spam-Indikator und Standard bei Bot-Netzen.

Was tun?

  • Beim Hosting-Provider einen PTR-Record für die Versand-IP einrichten.
  • Der PTR-Hostname sollte vorwärts wieder auf dieselbe IP auflösen (Forward-Confirmed Reverse DNS).
  • Bei IPv6-Versand: unbedingt auch einen PTR für die IPv6-Adresse setzen.

What does this mean?

The sending IP has no PTR record. Legitimate mail servers have a complete reverse DNS entry. Absence is a strong spam indicator and typical for botnets.

How to fix

  • Configure a PTR record for your sending IP at your hosting provider.
  • The PTR hostname should forward-resolve back to the same IP (forward-confirmed reverse DNS).
  • If you send over IPv6, set a PTR for the IPv6 address as well.

5.7.26 DKIM-Signatur konnte nicht verifiziert werdenDKIM signature verification failed

Was bedeutet das?

Die Mail trägt eine DKIM-Signatur, die kryptographisch nicht verifiziert werden konnte. Eine ungültige Signatur deutet auf Manipulation unterwegs, eine fehlerhafte Signatur-Implementierung oder einen defekten DNS-Record hin.

Ursachen

  • DKIM-Schlüssel im DNS fehlerhaft, abgelaufen oder vertauscht.
  • Ein zwischengeschalteter Server modifiziert den Body oder signierte Header (häufig bei Antivirus-Gateways mit aktivem Disclaimer-Append).
  • Base64-Zeilenumbrüche oder Whitespace im DKIM-DNS-Record.

Was tun?

  • DKIM-Record im DNS auf Integrität prüfen.
  • Keine Disclaimer oder Footer nach der Signatur anfügen lassen.
  • Neu-Signierung der Mail erzwingen (falls Smarthost oder Gateway im Weg).

What does this mean?

The message carries a DKIM signature that could not be cryptographically verified. This indicates tampering in transit, a broken signing implementation, or an incorrect DNS record.

Common causes

  • DKIM key in DNS is malformed, expired, or mismatched.
  • An intermediate server modifies the body or signed headers (often antivirus gateways with disclaimer injection).
  • Base64 line wrapping or whitespace in the DNS record.

How to fix

  • Verify the DKIM record integrity in DNS.
  • Avoid any footer or disclaimer injection after signing.
  • Force re-signing at the final hop (if a smart host or gateway is in the way).

Unsere Empfangs-Policy im Überblick Our inbound policy at a glance

Wir folgen den gängigen E-Mail-Authentifizierungsstandards (SPF nach RFC 7208, DKIM nach RFC 6376, DMARC nach RFC 7489, ARC nach RFC 8617) und den Header-Anforderungen nach RFC 5322.

Mailinglisten werden unterstützt, sofern sie entweder die Nachricht mit einer gültigen DKIM-Signatur der Listen-Domain neu signieren oder eine gültige ARC-Kette setzen. Software, die weder das eine noch das andere kann, entspricht nicht mehr dem Stand der Technik.

Ausgenommen von allen Authentifizierungsprüfungen sind Nachrichten an Rollenadressen nach RFC 2142: postmaster@, abuse@, security@. Diese sind immer erreichbar, damit Sie uns auch im Fehlerfall kontaktieren können.

We follow the established email authentication standards (SPF per RFC 7208, DKIM per RFC 6376, DMARC per RFC 7489, ARC per RFC 8617) and header requirements per RFC 5322.

Mailing lists are supported as long as they either re-sign the modified message with a valid DKIM signature using the list domain or add a valid ARC chain. Software capable of neither is no longer state of the art.

All authentication checks are bypassed for role accounts per RFC 2142: postmaster@, abuse@, security@. These are always reachable so you can contact us even when things go wrong.

{# Floating language switcher: an jeder Scroll-Position erreichbar. Toggle-Logik (data-lang-Setting auf html, persistenz in localStorage, button-binding) liegt zentral in static/js/wio-app.js, damit sie auch bei HTMX-Boost-Navigation auf diese Page sicher initialisiert ist. #}