Waarom belandt je nieuwsbrief in spam? Lessen uit een donatieproject op WordPress

Wat was de vraag?

Een landelijke stichting wilde online donaties ontvangen op de bestaande WordPress-site, eenmalig en maandelijks, met een vaste deadline.

De site draaide op WordPress met Elementor, en dat moest zo blijven. Donateurs moesten kunnen kiezen uit vaste bedragen of zelf een bedrag invullen. Betalen liep via Mollie, de betaalprovider die de stichting al gebruikte. Elke donateur moest automatisch een bevestiging en een ontvangstbewijs krijgen.

Hoe pakte ik het aan?

Direct op de live site, met de donatiepagina op privé tot de stichting akkoord gaf. Opgeleverd twee dagen voor de deadline.

Bouwen op de live site had een groot voordeel. Alles werd getest in de echte omgeving, met de echte koppeling naar Mollie, terwijl bezoekers niets zagen. Pas na akkoord ging de pagina openbaar.

Waarom kwamen bevestigingen niet vanzelf aan?

De site verstuurde zelf geen mail. Daarom kwam er een aparte maildienst bij, met SPF, DKIM en DMARC goed ingesteld.

Met die drie records laat je ontvangende mailservers zien dat een mail echt namens jouw domein is verstuurd. Ontbreken ze, dan belandt een ontvangstbewijs makkelijk in spam of komt het niet aan.

Bij het nalopen van de DNS bleek het oude DMARC-record een SPF-regel te bevatten, een restant van een mailingtool die niet meer werd gebruikt. Zulke resten blijven makkelijk staan als je van tool wisselt.

Waarom leken maandelijkse donaties dubbel te worden afgeschreven?

Door de testmodus van de betaalprovider. Die laat abonnementen versneld lopen, zodat je niet een maand hoeft te wachten op de volgende betaling.

In de testomgeving zag het eruit als een dubbele afschrijving. Bij een donatiemodule wil je dat zeker weten. Ik heb het nagevraagd bij de leverancier en daarna een kleine echte donatie gedaan als controle. Live gedroeg het zich zoals het hoort.

Waarom kwam de nieuwsbrief niet aan?

Omdat hij werd verstuurd vanaf een domein dat de mailingtool niet had gemachtigd. Daardoor kwam ongeveer 90 procent van een nieuwsbrief terug.

Een vrijwilliger verstuurde de nieuwsbrief vanaf het domein van de moederorganisatie. De stichting beheert dat domein niet, en in dat domein was de mailingtool niet gemachtigd. Ontvangende servers weigerden de mail dus.

De aanpak die ik voorstelde: verstuur vanaf het eigen domein van de stichting, met de authenticatie op orde, en zet het antwoordadres op het domein van de moederorganisatie. De vertrouwde mailingtool blijft in gebruik, en antwoorden komen binnen op de plek die lezers kennen.

Wat kun je hiervan leren als marketingteam?

Weet van welk domein elke tool mailt, ruim oude records op en test betalingen met een kleine echte transactie.

• Controleer per tool van welk domein hij mailt, en of dat domein de tool heeft gemachtigd met SPF en DKIM.
• Ruim oude DNS-records op als je van mailingtool wisselt.
• Laat ontvangstbewijzen en andere automatische mails via een maildienst met authenticatie lopen.
• Test terugkerende betalingen in testmodus, maar weet dat die sneller loopt dan live. Doe één kleine echte betaling als controle.
• Is de deadline krap, bouw dan op de live site met een privépagina en publiceer pas na akkoord.