{"id":21891,"date":"2026-10-11T17:50:27","date_gmt":"2026-10-11T09:50:27","guid":{"rendered":"https:\/\/synopower.club\/?post_type=docs&p=21891"},"modified":"2026-10-11T18:06:54","modified_gmt":"2026-10-11T10:06:54","password":"","slug":"synology-mailplus-smtp-relay-resend","status":"publish","type":"docs","link":"https:\/\/synopower.club\/nl\/docs\/synology-mailplus-smtp-relay-resend\/","title":{"rendered":"Synology MailPlus SMTP-relais: Afgewezen e-mail herstellen met opnieuw verzenden"},"content":{"rendered":"

Een SMTP-relay is een tweede mailserver die uw berichten namens u verzendt, zodat de ontvangende partij de reputatie van de relay beoordeelt in plaats van die van u. Op 9 oktober 2026 hadden we er snel een nodig. SynoPower Club draait volledig op Synology en elke orderbevestiging en licentiesleutel wordt via Synology MailPlus verzonden. Die avond betaalde een klant in Belgi\u00eb voor een licentie en de e-mail met de sleutel kwam direct terug met een foutmelding. 552 5.2.0 Uw bericht wordt beschouwd als spam<\/code>. SPF, DKIM en DMARC slaagden allemaal. Dit artikel over NAS Hosting 101 laat zien hoe we Resend hebben toegevoegd als SMTP-relay, maar alleen voor de domeinen van de ontvangers die ons afwijzen, welke records daarvoor nodig zijn, hoe we het hebben getest en wat de service stilletjes in uw berichten wijzigt.<\/p>\n\n\n\n

\n

SynoPower Club-punt:<\/strong> Ik heb jarenlang in de supportafdeling van Synology gewerkt, en de leverbaarheid van e-mails was de reden waarom de meeste mensen het opgaven om hun eigen e-mail te beheren. Ze gingen ervan uit dat de oplossing was om alle mailboxen naar een gehoste suite te verplaatsen. Dat is zelden het geval. In ons geval was de mailserver gezond, de DNS correct, en precies \u00e9\u00e9n hop in de uitgaande route had een slechte naam bij een paar strikte providers. Synology MailPlus biedt de mogelijkheid om die ene hop alleen voor die providers te wijzigen, met een regel die we in tien minuten hebben aangemaakt. De mailboxen, de logs en de klantgegevens hebben onze eigen NAS nooit verlaten.<\/p>\n<\/blockquote>\n\n\n\n

Waarom correct ondertekende e-mails van een NAS nog steeds worden geweigerd<\/h2>\n\n\n\n

Authenticatie bewijst wie je bent. Het bewijst niet dat je welkom bent. SPF, DKIM en DMARC vertellen de ontvangende server dat een bericht daadwerkelijk van jouw domein afkomstig is, en daarna stelt de server een tweede vraag: wat heeft hij eerder gezien van het IP-adres dat het bericht doorstuurt?<\/p>\n\n\n\n

Een zelfgehoste mailserver beantwoordt die tweede vraag meestal op een van de volgende twee manieren niet. Als de server rechtstreeks verzendt, gebruikt het publieke IP-adres vaak een generieke reverse DNS-naam van de internetprovider, die door veel ontvangers als een thuisverbinding wordt beschouwd. Als de server daarentegen via de eigen uitgaande server van de provider verzendt, zoals bij ons het geval was, erft het bericht de reputatie van een machine die door duizenden andere klanten wordt gebruikt.<\/p>\n\n\n\n

\"Een
De e-mail werd op 9 oktober teruggestuurd naar onze supportmailbox, waarbij het klantadres en ons serveradres verborgen waren. De weigering kwam van de mailserver van de provider zelf tijdens de bezorging.<\/figcaption><\/figure>\n\n\n\n

Dat was onze situatie. De bounce had niets te maken met ons domein of onze handtekening. Het was een oordeel over het pad, en grote Europese e-mailproviders zoals Telenet en GMX staan erom bekend dat ze juist op dat soort signalen streng filteren. Niets binnen de mailserver kon dit veranderen, omdat het probleem zich \u00e9\u00e9n hop na de NAS bevond.<\/p>\n\n\n\n

Wat een SMTP-relay wel en niet verandert.<\/h2>\n\n\n\n

Een SMTP-relay vervangt die laatste stap. Uw server authenticeert zich bij de relay op poort 587, geeft het bericht door en de SMTP-relay levert het af vanaf zijn eigen IP-adressen met zijn eigen verzendgeschiedenis. Transactionele e-mailservices bestaan precies voor deze taak: hun adressen verzenden alleen ontvangstbevestigingen, wachtwoordherstel en notificaties, waardoor ontvangers ze meer vertrouwen dan een algemene uitgaande server.<\/p>\n\n\n\n

Een goede SMTP-relay ondertekent het bericht ook met een DKIM-sleutel voor uw domein, zodat de klant uw adres nog steeds ziet en DMARC nog steeds slaagt. Wat een goede relay niet kan doen, is slechte inhoud herstellen, een ontbrekend SPF-record of een lijst met mensen die nooit om uw e-mail hebben gevraagd. Los eerst de authenticatieproblemen op en kijk daarna pas naar het pad.<\/p>\n\n\n\n

Waarom we Resend als SMTP-relais hebben gekozen<\/h2>\n\n\n\n

Onze eerste poging was met Amazon SES. We hebben het domein geverifieerd, ons volume omschreven als 20 tot 50 transactionele e-mails per dag, en de volgende dag werd onze aanvraag voor productietoegang zonder opgave van reden afgewezen. Dat is een veelvoorkomende ervaring voor een gloednieuw account, en het resultaat was dat we met licentiesleutels bleven zitten die nog moesten worden geleverd.<\/p>\n\n\n\n

\"Amazon
Het begin van het antwoord van Amazon Web Services. De rest van het bericht legt uit dat de beoordeling rekening houdt met factoren die niet openbaar gemaakt kunnen worden, waardoor er niets specifieks te verhelpen viel.<\/figcaption><\/figure>\n\n\n\n

Resend was de tweede poging en ongeveer tien minuten na de aanmelding verstuurde het ondertekende e-mails voor ons domein. Drie dingen maakten het een goede oplossing voor een kleine webwinkel die gehost werd door Synology:<\/p>\n\n\n\n