Resend-E-Mails landen im Spam? So behebst du es

Resend stellt erst dann an echte Empfänger zu, wenn du eine Domain verifiziert hast. Die Falle mit der geteilten Versanddomain, in die Klaviyo- und Mailchimp-Nutzer laufen, gibt es hier also gar nicht. Was stattdessen bricht, ist enger gefasst und leichter zu übersehen: die Records, die Resend auf die Versand-Subdomain legt, eine DMARC-Policy, die dir niemand anlegt, ein DKIM-Schlüssel, den du nicht aufwerten kannst, und eine Domain, deren gesamte Versandhistorie an dem Tag beginnt, an dem du live gehst. Dieser Guide behandelt das DNS, das Resend tatsächlich ausgibt, die resend.dev-Sandbox-Falle, dedizierte gegenüber geteilten IPs und wie du einen echten Versand mit Unspam prüfst.

Kostenlosen Spam-Test starten So testest du deine Mailings

Warum Resend-E-Mails im Spam landen.

Niemand hat einen DMARC-Record veröffentlicht, denn Resend tut es nicht

Die Domain-Verifizierung schreibt SPF und DKIM für dich und hört dann auf. Resends eigene Troubleshooting-Seite zum Thema Spam sagt, DMARC werde nicht automatisch eingerichtet, sei aber dringend empfohlen, und Deliverability Insights führt eine eigene Prüfung auf einen gültigen DMARC-Record, die bei jeder Nachricht still durchfällt. Seit den Bulk-Sender-Regeln von Google und Yahoo ist eine Absenderdomain ohne DMARC-Policy für sich genommen ein Filtersignal. Veröffentliche v=DMARC1; p=none; rua=mailto:dmarcreports@example.com; auf _dmarc.deinedomain.de, bevor du dir irgendetwas anderes ansiehst.

Dein erster Produktivversand ist der allererste Versand deiner Domain

Jede Nachricht, die du während der Entwicklung verschickt hast, ging über resend.dev hinaus und trug damit Resends Reputation, nicht deine. An dem Tag, an dem du die Absenderadresse auf deine eigene Domain umstellst, sieht Gmail einen brandneuen Absender mit dem Volumen, das dein Launch erzeugt. Resends Warm-up-Plan startet bei bis zu 150 E-Mails am ersten Tag und erreicht bis zu 2.000 am siebten, und der Rechner streckt die Rampe für größere Ziele auf 42 Tage. Ein Launch, der mehrere tausend Anmeldebestätigungen von einer am selben Morgen verifizierten Domain abfeuert, ist genau das Muster, das der Plan verhindern soll.

DKIM läuft mit 1024 Bit und du kannst daran nichts ändern

Resend signiert ausgehende Mail mit DKIM-Schlüsseln zu 1024 Bit und sagt klar, dass 2048-Bit-Schlüssel nicht unterstützt werden. Das ist die Untergrenze, die empfangende Server weiterhin validieren müssen, die Signaturen verifizieren also normal, aber dir bleibt kein Spielraum und kein Weg, innerhalb des Produkts auf einen stärkeren Schlüssel zu wechseln. Es heißt außerdem, dass DKIM kein Hebel ist, an dem du ziehen kannst, wenn ein Unternehmensfilter wie Mimecast oder Proofpoint dich schlechter bewertet. Steck die Mühe dorthin, wo du tatsächlich Kontrolle hast: eine veröffentlichte DMARC-Policy, eine Subdomain mit eigener Historie und Inhalte, die keine Entschuldigung brauchen.

Broadcasts und Passwort-Resets gehen von derselben verifizierten Domain raus

Resend trennt den Versand in die Emails-API für transaktionale Mail und Broadcasts fürs Marketing, aber beide gehen von der Domain raus, die du verifiziert hast. Ein Newsletter, der Beschwerden sammelt, zieht deine Passwort-Resets mit nach unten, denn für einen Filter sind sie derselbe Absender. Resends eigene Empfehlung lautet, von einer Subdomain zu senden, damit Mailbox-Provider einen klaren Hinweis bekommen, wohin sie deine Mail einsortieren sollen. Verifiziere zwei, zum Beispiel notifications.deinedomain.de für die API und updates.deinedomain.de für Broadcasts, und halte sie vom ersten Tag an getrennt.

Deine Beschwerdezahl steht bei fast null und bedeutet nichts

Resends Dokumentation zu Suppressions hält fest, dass nicht alle Mailbox-Provider ein complained-Event zurückmelden, allen voran Gmail und Google Workspace. Die Zahl, auf die du im Dashboard schaust, lässt also ausgerechnet den Provider aus, der den größten Teil deiner Platzierung entscheidet. Suppressions gelten zudem teamweit: Eine Adresse, die nach einem Marketing-Bounce unterdrückt wurde, wird über alle deine Domains und Subdomains hinweg übersprungen, transaktional eingeschlossen, sodass ein Passwort-Reset stillschweigend nie rausgeht. Lies deine echte Gmail-Spamrate in den Google Postmaster Tools und behandle Resends Wert als Untergrenze.

Das Template verlinkt woanders hin als auf deine Versanddomain, oder es ist zu groß

Resends Deliverability Insights prüft, ob die Links einer Nachricht auf dieselbe Domain zeigen, von der sie versendet wird, und ein Template, dessen Buttons alle auf eine Marketing-Site, einen Link-Kürzer oder einen Drittanbieter-Tracker auflösen, fällt bei jedem Versand durch. Nutze für das Klick-Tracking eine Subdomain deiner Versanddomain statt eines Kürzers und halte zumindest den wichtigsten Call to Action auf deiner eigenen Domain. Auch die Größe zählt: Resend weist darauf hin, dass Gmail jede Nachricht auf 102 KB begrenzt und der Rest darüber hinaus abgeschnitten und hinter einem Link zur vollständigen Nachricht versteckt wird, womit dein Abmeldelink einen Klick weiter weg rutscht.

So authentifiziert Resend deine E-Mails.

Resend ist unter den Versandplattformen ungewöhnlich: Bis eine Domain verifiziert ist, stellt es an niemanden außer deiner eigenen Kontoadresse zu, und die Verifizierung selbst schreibt SPF und DKIM. Das nimmt die Fehlausrichtung durch geteilte Domains, unter der andere Plattformen leiden, komplett heraus und lässt genau zwei Dinge übrig, die du richtig machen musst: die Versand-Subdomain und DMARC.

Eintrag	Standard	das Problem	die Lösung
SPF	Die Domain-Verifizierung erzeugt einen TXT-Record auf der Subdomain send der Domain, die du hinzugefügt hast, mit dem Wert v=spf1 include:amazonses.com ~all. Sowohl der Include als auch der Bounce-Host zeigen auf amazonses.com, SPF authentifiziert also Amazons Versandinfrastruktur.	Weil der Record auf send.deinedomain.de liegt, authentifiziert SPF die Subdomain und nicht deine Absenderdomain. Relaxed Alignment, die DMARC-Voreinstellung, wertet das trotzdem als ausgerichtet. Wer das nicht weiß, fügt einen Resend-Include in den Root-SPF-Record ein, was überhaupt nichts bewirkt, oder setzt aspf=s und lässt DMARC allein auf DKIM ruhen.	Veröffentliche den Record genau so, wie er erzeugt wurde, mit send als Host, denn dein DNS-Anbieter hängt die Domain selbst an. Lass deinen Root-SPF-Record unangetastet, inklusive deines Google-Workspace- oder Microsoft-365-Includes, und setze aspf=s nicht.
DKIM	Die Verifizierung erzeugt einen TXT-Record auf resend._domainkey der hinzugefügten Domain mit einem öffentlichen Schlüssel zu 1024 Bit. Resend signiert mit 1024 Bit und unterstützt 2048 Bit nicht.	Der Wert ist lang genug, dass DNS-Oberflächen ihn abschneiden, in mehrere Strings in Anführungszeichen aufteilen oder eigene Anführungszeichen ergänzen. Passiert das, verlässt die Domain den Status pending nie und du kannst überhaupt nicht von ihr senden, was Entwickler meist als Resend-Ausfall fehldeuten. Einen Weg zu einem stärkeren Schlüssel gibt es im Produkt nicht.	Kopiere den Wert und tippe ihn nicht ab, nutze resend._domainkey als Host ohne angehängte Domain und stelle Cloudflare-Records auf DNS only statt proxied. Bestätige ihn öffentlich mit dns.email oder nslookup und prüfe dann den d=-Wert an einer echten Nachricht: Er sollte deine eigene Domain sein.
DMARC	Resend legt keinen DMARC-Record an. Deine Domain verifiziert sich, sendet und meldet Gesundheit, ohne dass irgendwo eine Policy veröffentlicht wäre.	Resends Troubleshooting-Checkliste stellt die Authentifizierung an den Anfang und benennt DMARC als den einen Record, den es nicht anlegt, und Deliverability Insights markiert einen fehlenden oder ungültigen Record bei jeder Nachricht. Direkt zu einer harten Policy zu springen ist ein Fehler für sich: quarantine oder reject, bevor jeder legitime Absender ausgerichtet ist, und du filterst deine eigenen Rechnungen und deine Support-Mail weg.	Starte mit v=DMARC1; p=none; rua=mailto:dmarcreports@example.com; auf _dmarc.deinedomain.de. Lies die Reports, Resend betreibt unter checkdmarc.email einen kostenlosen Open-Source-DMARC-Analyzer, bestätige, dass jeder legitime Absender ausgerichtet ist, und geh dann auf p=quarantine und p=reject.
Return-Path subdomain	Resend nutzt für den Return-Path die Subdomain send deiner verifizierten Domain, und deshalb liegen sowohl der SPF-TXT-Record als auch der Bounce-MX-Record auf send.deinedomain.de. Der MX-Wert ist regionsabhängig, feedback-smtp.us-east-1.amazonses.com für eine in Nord-Virginia angelegte Domain und ein anderer Host für Irland, São Paulo oder Tokio, kopiere also den exakten Wert aus dem Records-Tab der Domain.	Manche Mail-Clients zeigen Empfängern den Return-Path an, ein erfundener Wert ist also ein Glaubwürdigkeitsproblem, und Resend warnt ausdrücklich vor Werten wie testing. Diesen MX-Record auf der Root-Domain statt auf der Subdomain zu veröffentlichen ist weit schlimmer: Er übernimmt den eingehenden Mailverkehr der gesamten Domain.	Behalte die Voreinstellung. Musst du sie ändern, übergib custom_return_path beim Anlegen oder Aktualisieren der Domain: maximal 63 Zeichen, nur Buchstaben, Ziffern und Bindestriche, beginnend mit einem Buchstaben und endend auf Buchstabe oder Ziffer.

Wenn du diese Einträge aktualisiert hast, prüfe mit den kostenlosen Tools von Unspam, ob alles passt: SPF-Check, DKIM-Check und DMARC-Check.

So testest du eine Resend-Kampagne mit Unspam.

Resends Dashboard sagt dir, was die API verlassen hat, und endet bei Delivered, was nach ihrer eigenen Definition nur heißt, dass der empfangende Server mit 250 OK geantwortet hat. Danach kann die Nachricht in den Posteingang, in den Spam-Ordner, in eine Unternehmens-Quarantäne oder ins Nichts gehen, und Resend sieht nie, wohin. Der einzige Weg, es zu erfahren, ist eine echte Nachricht über deinen eigenen Code-Pfad an Seed-Postfächer.

01
Hol dir deine Unspam-Seed-Adresse und die Test ID

Starte in Unspam einen kostenlosen Spam-Test oder einen Inbox-Placement-Test und kopiere die erzeugte Seed-Adresse. Ein Placement-Test vergibt zusätzlich eine Test ID. Füge sie vor dem Versand in die Betreffzeile oder in den Text ein, sonst erreicht die Nachricht die Seed-Postfächer und wird deinem Test nie zugeordnet. Placement-Tests stellen an Seed-Postfächer bei Gmail, Outlook, Yahoo und fünf weiteren Anbietern zu und melden, wo jede Kopie gelandet ist.
02
Sende von deiner verifizierten Domain, nicht von resend.dev

Setze from auf eine Adresse der Domain, die du verifiziert hast, zum Beispiel notifications@notifications.deinedomain.de. Lässt du den Quickstart-Wert stehen, bekommst du einen 403 mit dem Hinweis, dass du Test-E-Mails nur an deine eigene Adresse senden darfst, und eine Absenderdomain, die nicht exakt zur verifizierten passt, Subdomain eingeschlossen, liefert einen 403 wegen Domain-Mismatch. Das Postfach selbst muss nicht existieren, Resend empfiehlt aber Adressen, die Antworten empfangen können.
03
Schick sie durch den echten Code-Pfad

Ruf dieselbe API-Route, denselben Broadcast oder dieselbe Automation auf, die deine Kundinnen und Kunden bekommen, mit demselben Template, denselben Links und denselben eigenen Headern. Ein von Hand getippter Einzelversand überspringt deine List-Unsubscribe-Header, dein gerendertes React-Email-Markup und das Link-Rewriting, falls du Klick-Tracking aktiviert hast, und prüft damit nicht das, was du tatsächlich ausspielst.
04
Gib Unspam SMTP-Zugangsdaten für wiederholte Läufe

Für geplante Inbox-Placement-Tests gibst du Unspam die SMTP-Daten von Resend: Host smtp.resend.com, Port 587, Benutzername resend, Passwort ein Resend-API-Key. Leg einen eigenen Key mit der Berechtigung sending_access und einer domain_id-Einschränkung an, damit er nichts kann außer von dieser einen Domain zu senden, und kopiere den Wert sofort, denn Resend zeigt einen Key kein zweites Mal. Unspam nutzt diese Zugangsdaten ausschließlich, um eigene Testnachrichten zu versenden; es liest weder deine Resend-Kontakte noch deine Logs oder dein Dashboard.
05
Lies den Report und behebe, was er anzeigt

Unspam meldet den Spam-Score, die SPF-, DKIM- und DMARC-Ergebnisse der echten Nachricht, welchen Ordner jeder Seed-Anbieter gewählt hat, Client-Vorschauen und eine Heatmap. Bestätige, dass der d=-Wert von DKIM deine eigene Domain ist und dass DMARC besteht, statt schlicht zu fehlen. Behebe, was markiert ist, und wiederhole denselben Versand, um zu bestätigen, dass die Änderung die Platzierung bewegt hat.

Derselbe Test rendert deine Kampagne in über 50 echten E-Mail-Clients, darunter Gmail, Outlook, Apple Mail, iPhone und Android, jeweils im hellen und im dunklen Modus, über Client-Vorschauen, damit du Platzierung und Darstellung in einem Durchgang prüfst.

Resend-Funktionen, die still und leise die Zustellung beeinflussen.

Resends MX-Record auf der Root-Domain kapert deinen eingehenden Mailverkehr

Resends Versand-Records gehören auf die Subdomain send, und Resend weist darauf hin, dass ein MX-Record nur die Subdomain betrifft, auf der er liegt, der Record auf send.deinedomain.de lässt dein Google-Workspace- oder Microsoft-365-Postfach also in Ruhe. Verschiebst du diesen Wert auf die Root, leitest du die Mail für irgendwer@deinedomain.de auf Resends Bounce-Host statt zu deinem Mail-Anbieter um. Resend veröffentlicht dieselbe Warnung zu seiner Inbound-Funktion: Ein empfangender MX-Record am Apex leitet jede Nachricht der Domain zu Resend statt zu deinem bisherigen Anbieter, und deshalb sagt Resend, dass Inbound auf eine eigene Subdomain gehört (zum Beispiel subdomain.deinedomain.de). Halte jeden Resend-Record auf genau dem Host, den der Records-Tab der Domain zeigt, und ändere am Apex nichts.

Der Bounce-Host ist regionsabhängig, und DNS-Oberflächen zerlegen ihn

Eine Domain wird in Nord-Virginia (us-east-1), Irland (eu-west-1), São Paulo (sa-east-1) oder Tokio (ap-northeast-1) angelegt, und der MX-Wert muss zu dieser Region passen. Zwei Fehler dominieren: ein Record, der auf eine andere Region zeigt als die, in der die Domain angelegt wurde, und ein DNS-Anbieter, der deine Domain anhängt, sodass der Wert zu feedback-smtp.eu-west-1.amazonses.com.example.com wird. Setze einen abschließenden Punkt, um den Wert als vollqualifiziert zu kennzeichnen. Die Region zu wechseln ist keine Bearbeitung: Es heißt, die Domain zu löschen, sie neu anzulegen und jeden Record neu zu veröffentlichen.

Delivered heißt nicht Posteingang

Resend markiert eine E-Mail als Delivered, sobald der Server des Empfängers sie mit 250 OK annimmt. Alles danach, Posteingang, Spam-Ordner, Unternehmens-Quarantäne oder stilles Verwerfen, passiert außerhalb von Resends Sichtfeld. Ein Dashboard voller grüner Delivered-Zeilen verträgt sich vollständig damit, dass jede einzelne dieser Nachrichten im Junk liegt, und genau deshalb jagen Teams das wochenlang, bevor sie die Platzierung testen.

Die Emails-API setzt keinen List-Unsubscribe-Header für dich

Broadcasts und Automations wickeln den Abmeldeweg automatisch ab, wenn du einen Abmeldelink einbaust. Transaktionale Sendungen über die Emails-API tun das nicht, weil Resend dafür keine Kontaktlisten verwaltet, du übergibst die Header also selbst: List-Unsubscribe mit deiner URL in spitzen Klammern und List-Unsubscribe-Post mit dem Wert List-Unsubscribe=One-Click. Dein Endpoint muss sowohl auf GET als auch auf POST antworten und die Anfrage innerhalb von 48 Stunden umsetzen.

Worauf Resend-Absender in der Praxis stoßen.

Die häufigsten Probleme mit der Zustellbarkeit bei Resend-Absendern, jeweils mit der passenden Lösung.

Die Domain steht in Resend auf Verified, SPF und DKIM bestehen beide, und Gmail packt trotzdem alles in den Spam-Ordner.

Die Verifizierung erzeugt nur SPF und DKIM. Sie veröffentlicht kein DMARC, und Resend sagt selbst, dass DMARC nicht automatisch eingerichtet wird. SPF und DKIM zu bestehen, ohne dass auf der Absenderdomain eine DMARC-Policy liegt, ist genau das, worauf die Bulk-Sender-Anforderungen von Google und Yahoo zielen, und Resends eigenes Deliverability Insights markiert es bei jeder Nachricht, die du dir ansiehst.

Die Lösung Veröffentliche v=DMARC1; p=none; rua=mailto:dmarcreports@example.com; auf _dmarc.deinedomain.de, öffne danach das Insights-Panel an einem echten Versand und räum jede verbleibende Prüfung ab, vor allem die Übereinstimmung der Link-URLs und den No-Reply-Absender.

Ich bekomme ständig 403 domain is not verified beim Senden von localhost, sogar an meine eigene Adresse.

Hier prallen zwei verschiedene Regeln aufeinander. Die Absenderdomain muss exakt zur verifizierten Domain passen, eine als sending.example.com verifizierte Domain weist also eine Anfrage ab, die example.com sagt. Davon unabhängig gilt: Steht in from weiterhin onboarding@resend.dev, ist der einzig erlaubte Empfänger die Adresse deines Resend-Kontos, ein Tippfehler in deiner eigenen Adresse erzeugt also scheinbar denselben Fehler.

Die Lösung Öffne die Domains-Seite und kopiere die verifizierte Domain zeichengenau in from, und prüfe dann, ob der API-Key nicht per domain_id auf eine andere Domain eingeschränkt ist. Sende während der Entwicklung an delivered@resend.dev, bounced@resend.dev, complained@resend.dev oder suppressed@resend.dev statt an dein eigenes Postfach.

Ich habe vor zwei Tagen alle Records in Cloudflare angelegt und die Domain steht immer noch auf pending. Beim Klick auf Verifizieren ändert sich nichts.

Drei Ursachen erklären fast alle diese Fälle. Der DNS-Anbieter hat deine Domain an den MX-Wert angehängt, sodass feedback-smtp.us-east-1.amazonses.com.example.com entsteht. Die Records sind beim Registrar gelandet, während die Nameserver woandershin zeigen, nichts von dem, was du veröffentlicht hast, ist also live. Oder die MX-Region passt nicht zu der Region, in der die Domain angelegt wurde, manchmal mit zwei gleichzeitig veröffentlichten Regionen.

Die Lösung Schlag die Records öffentlich mit dns.email oder nslookup nach, statt der DNS-Oberfläche zu trauen. Setz einen abschließenden Punkt an den MX-Wert, um ihn als vollqualifiziert zu markieren, lösch doppelte Regionszeilen, stell die Records auf DNS only statt proxied und nutz dann Restart verification.

Nachdem ich den MX-Record auf Resend gezeigt habe, hat unser Google-Workspace-Postfach gar nichts mehr empfangen.

Der MX-Record, den Resend erzeugt, gehört auf die Subdomain send. Auf der Root veröffentlicht, wird er zum Mail Exchanger der gesamten Domain, jede Nachricht an irgendwer@deinedomain.de wird also zu Resend geleitet und von Google Workspace oder Microsoft 365 weggenommen. Resend dokumentiert genau diesen Fehler und empfiehlt eine Subdomain, um ihn zu vermeiden.

Die Lösung Lösch den MX-Record von der Root, stell deine Google-Workspace- oder Microsoft-365-MX-Records exakt so wieder her, wie sie waren, und veröffentliche Resends MX erneut mit send als Host. Ist send bereits belegt, schlägt Resend send.sub.deinedomain.de vor.

Wir sind live gegangen, haben an einem Tag rund viertausend Anmeldebestätigungen von einer am selben Morgen verifizierten Domain verschickt, und das meiste landete im Junk.

Alles vor dem Launch ging über resend.dev raus, deine eigene Domain hatte also überhaupt keine Versandhistorie. Resend legt die Verantwortung fürs Warm-up einer Domain in deine Hände, anders als bei dedizierten IPs, die es automatisch warmfährt. Ihr Plan startet bei bis zu 150 E-Mails am ersten Tag und erreicht bis zu 2.000 am siebten, der Rechner streckt die Rampe für größere Ziele auf 42 Tage.

Die Lösung Verifiziere die Versand-Subdomain Wochen vor dem Launch und starte darauf echten Verkehr mit kleinem Volumen. Folge dem Warm-up-Plan, halte die Bounce-Rate unter 4 % und die Spamrate unter 0,08 %, und beschränke nicht-transaktionale Sendungen auf Leute, die in den letzten sechs Monaten geöffnet oder geklickt haben, wie es Resends Leitfaden zur Zielgruppenhygiene empfiehlt.

Zustellbarkeit bei Resend, kurz beantwortet.

Warum bekomme ich einen 403, wenn ich von onboarding@resend.dev an einen Kunden sende?

resend.dev ist ein reiner Test-Absender. Er kann nur an die E-Mail-Adresse deines Resend-Kontos zustellen, alles andere liefert einen 403 mit dem Hinweis, dass du Test-E-Mails nur an deine eigene Adresse senden darfst. Der Quickstart und die meisten Framework-Gerüste kommen mit diesem Wert im Code, er überlebt also häufiger bis ins Staging, als irgendwer zugibt. Verifiziere eine Domain und ändere danach from auf eine Adresse dieser Domain.

Richtet Resend SPF und DKIM für mich ein?

Ja. Die Domain-Verifizierung erzeugt den DKIM-TXT-Record auf resend._domainkey und den SPF-TXT-Record auf der Subdomain send, dazu den MX-Record für den Return-Path, und du veröffentlichst alle drei bei deinem DNS-Anbieter. DMARC ist die Ausnahme: Resend legt es nicht an und sagt das auch. Die Verifizierung ist meist innerhalb von 15 Minuten nach dem Live-Gehen der Records abgeschlossen, DNS-Änderungen können sich weltweit aber bis zu 72 Stunden ausbreiten.

Brauche ich bei Resend eine dedizierte IP?

Nur oberhalb echter Volumina. Resends genannte Kriterien sind ein aktives Transactional-Scale- oder Marketing-Pro-Abo und ein Versandvolumen über 3.000 E-Mails pro Tag, und sie warnen, dass unter 90.000 E-Mails pro Monat womöglich nicht reicht, um die IPs warm zu halten. Darunter sind geteilte IPs die bessere Wahl, weil sie von anderen Absendern bereits warmgehalten ankommen. Resend legt die Adressen eines Pools zudem nicht offen, eine dedizierte IP taugt also nicht zum Allowlisting.

Soll ich meine Root-Domain oder eine Subdomain verifizieren?

Eine Subdomain. Resend empfiehlt das aus zwei Gründen: Sie isoliert die Versandreputation, sodass eine kompromittierte Subdomain in Quarantäne kann, ohne deine Hauptdomain zu berühren, und sie gibt Mailbox-Providern ein klares Signal, um welche Art Mail es sich handelt. Ihr Beispiel ist notifications.acme.com statt acme.com. Wovor sie warnen, ist eine ähnlich aussehende Domain wie acme-alerts.com, die für Filter nach Phishing klingt.

Resend zeigt fast keine Spam-Beschwerden, warum liegt meine Mail dann im Junk?

Weil der größte Mailbox-Provider es Resend nie mitteilt. Resends Dokumentation zu Suppressions hält fest, dass nicht alle Provider ein complained-Event zurückmelden, allen voran Gmail und Google Workspace. Dein Dashboard zählt also genau um den Anteil zu niedrig, den Gmail an deiner Liste hat. Melde dich bei den Google Postmaster Tools an, um die echte Spamrate zu sehen, und fahr Inbox-Placement-Tests, um den Ordner zu sehen, statt ihn aus der Interaktion abzuleiten.

Kann ich bei Resend einen DKIM-Schlüssel mit 2048 Bit nutzen?

Nein. Resend signiert ausgehende Mail mit DKIM-Schlüsseln zu 1024 Bit und unterstützt 2048 Bit nicht. Verlangt ein Sicherheits-Review oder eine interne Richtlinie eine Signatur mit 2048 Bit, ist das ein harter Blocker und keine Einstellung, und die Antwort ist ein anderer Versandweg für diese Mail. Für die alltägliche Zustellbarkeit ist es nicht das Problem, das du lösen musst: 1024-Bit-Signaturen verifizieren weiterhin bei jedem großen Anbieter.

Die Angaben zur Plattform Resend wurden anhand öffentlich zugänglicher Dokumentation geprüft (Stand: August 2026) und können sich seitdem geändert haben. Resend ist eine Marke des jeweiligen Inhabers. Unspam ist weder mit Resend verbunden noch wird Unspam von Resend unterstützt.

Teste deine nächste Resend-Kampagne, bevor deine Abonnenten es tun.

Kostenlosen Spam-Test starten Inbox-Placement-Test