E-maildeliverability voor je webshop

E-maildeliverability begint bij het lokaliseren van het probleem

Bij e-maildeliverability onderzoek je wat er tussen verzending en ontvangst gebeurt. Een bericht dat het platform als afgeleverd registreert, is daarmee niet aantoonbaar in de primaire inbox terechtgekomen of door iemand gelezen. Alleen een daling van opens is dus onvoldoende om een spamprobleem vast te stellen.

Beschrijf eerst het symptoom voordat je afzender of template wijzigt: welke campagne of automatisering is getroffen, sinds wanneer, voor welke ontvangers en bij welke mailboxprovider? Bewaar voorbeeldberichten, hun identificatie en beschikbare serverreacties. Zo kun je gevallen vergelijken zonder verschillende gedragingen als één storing te behandelen.

Een deliverabilityonderzoek moet een gedocumenteerde diagnose, toegewezen correcties en controleerbare afrondingscriteria opleveren. Is nog onduidelijk of verzending, inhoud of het klanttraject de oorzaak is, dan helpt een e-mailmarketingaudit om de scope af te bakenen.

Gebruik symptomen om het onderzoek te ordenen

De tabel is een voorgestelde werkwijze. Elke rij geeft aan welk bewijs je eerst zoekt, niet welke oorzaak al vaststaat. Controleer of één provider getroffen is voordat je conclusies trekt over het hele bestand.

Bewaar een eerdere vergelijking met dezelfde selectiecriteria. Een algemeen gemiddelde kan een veranderde samenstelling van de doelgroep verbergen. Bekijk aantallen, percentages en de bijbehorende noemers.

Wat je controleert bij SPF, DKIM en DMARC

SPF machtigt servers om een domein bij verzending te gebruiken. Begin bij het domein dat daadwerkelijk wordt gecontroleerd en de systemen die daarmee verzenden.

DKIM verifieert een handtekening die aan een domein is gekoppeld. Controleer een ontvangen bericht: een gepubliceerd record bewijst niet dat dit bericht correct is ondertekend.

DMARC controleert de afstemming van het zichtbare From-domein op een via SPF of DKIM geauthenticeerd domein. Het voegt beleid en rapportage toe; een ander geauthenticeerd domein levert niet automatisch die afstemming.

Gmail vereist SPF, DKIM en DMARC voor bulkverzenders naar persoonlijke accounts. De richtlijn adviseert spamklachten onder 0,1% te houden en 0,3% te vermijden. Die bovengrens is geen gewenst doel.

Inventariseer vóór DNS-wijzigingen alle verzendsystemen: marketingplatform, webshop, klantenservice en andere afzenders. Noteer per systeem de verantwoordelijke, het domein en een ontvangsttest. Een wijziging voor campagnes kan ook andere bedrijfsberichten raken.

De technische overdracht moet de vorige waarde, de goedgekeurde wijziging en het waargenomen resultaat bevatten. Kopieer geen records van een andere webshop en wijzig beleid niet blind. Beheert iemand anders DNS, vraag dan om de precieze aanpassing en controleer daarna een bericht uit het getroffen systeem.

Controleer waar contacten vandaan komen en waarom ze berichten krijgen

Authenticatie beantwoordt niet de basisvraag of iemand dit bericht verwacht. Bekijk de aanmeldbron, de gemaakte belofte en de communicatiegeschiedenis. Analyseer bronnen afzonderlijk. Iemand die net om updates vroeg heeft een andere context dan een oud record zonder bekende activiteit.

Contactsegmentatie moet helpen bepalen wie een bericht krijgt en wie wordt uitgesloten. Documenteer de regel en controleer werkelijke ontvangers. Het label “inactief” voorkomt verzending niet vanzelf: de betreffende uitsluiting moet in de ontvangerselectie worden toegepast.

Klaviyo herkent opens die samenhangen met Mail Privacy Protection. Zo’n open bewijst niet dat een mens heeft gelezen. Combineer signalen en leg vast wat in de analyse als activiteit telt.

Controleer vóór het heractiveren van oude contacten hun herkomst en huidige status. Maak bij opschonen onderscheid tussen niet meer verzenden, een inschrijving wijzigen en een profiel verwijderen. Bewaar de geschiedenis die nodig is om uitsluitingen te respecteren en meld afgemelde contacten niet via een import opnieuw aan.

Veroorzaakt bijvoorbeeld een fictieve campagne aan eerdere kopers relatief veel klachten, vergelijk die groep dan met recente abonnees en bekijk de ontvangen frequentie. Dat helpt een hypothese over de selectie te formuleren, maar bewijst niet automatisch dat het geadverteerde product de oorzaak is.

Test de zichtbare en technische afmelding afzonderlijk

One-click afmelden volgens RFC 8058 gebruikt List-Unsubscribe- en List-Unsubscribe-Post-headers en een HTTPS POST-verzoek. Alleen een link in de footer bewijst niet dat dit mechanisme is ingericht.

Test afmelden met een testadres en controleer de status daarna. Kijk vervolgens of de selectie voor een latere campagne dat adres uitsluit. Volg het volledige gedrag; stop niet bij een pagina die een succesvolle afmelding meldt.

In het zichtbare bericht moeten de afzender en de aanleiding herkenbaar zijn. Maak afmelden leesbaar, ook wanneer afbeeldingen geblokkeerd zijn. Een voorkeurencentrum kan alternatieven bieden, maar mag vertrekken niet onnodig verwarrend maken.

Neem deze controle mee in campagnebeheer en herbruikbare templates. Herhaal de test als het platform of voorkeurensysteem verandert in plaats van aan te nemen dat het oude gedrag behouden blijft.

Een correctieplan met verantwoordelijken en besliscriteria

Een bruikbaar plan scheidt accountwijzigingen van werk voor het technische team of de provider. Het benoemt welke verzendingen onderzoek nodig hebben, welke blijven functioneren en welk bewijs een latere uitbreiding van de doelgroep zou rechtvaardigen. Zonder diagnose kun je geen herstelplanning beloven.

Dit werkblad is illustratief. Acties hangen van de diagnose af en moeten vóór uitvoering worden goedgekeurd.

Ontstond het probleem na een e-mailmarketingmigratie, bekijk dan ook veranderingen in domeinen, selectie en contactstatussen. Opnieuw van tool wisselen zonder die overgang te reconstrueren laat dezelfde vragen onbeantwoord.

Wat deliverabilitymonitoring moet bevatten

Spreek een analyse van e-mailstatistieken af met consistente definities. Splits provider, berichttype en doelgroep wanneer er voldoende gegevens zijn. Een algemene verbetering kan komen doordat de meest problematische groep niet meer wordt aangeschreven. Leg dat uit bij het resultaat.

Monitoring eindigt niet wanneer een testmail in je inbox komt. Dat bevestigt één geval. Beoordeel de ontwikkeling met vergelijkbare echte verzendingen, documenteer tussentijdse wijzigingen en houd onopgeloste incidenten bij.

• Eerste diagnose en scope van de onderzochte gegevens.
• Uitgevoerde wijzigingen, datum, verantwoordelijke en vorige configuratie.
• Authenticatieresultaten en relevante serverreacties.
• Ontwikkeling per provider en doelgroep, met aantallen en noemers.
• Afmeld- en uitsluitingstests na belangrijke wijzigingen.
• Volgende beslissing en het bewijs dat daarvoor nog ontbreekt.

Deliverabilityadvies moet vermijdbare problemen verminderen en het team beter laten diagnosticeren. De uiteindelijke plaatsing hangt ook van het ontvangende systeem af. Presenteer die daarom niet als een garantie op de primaire inbox.

Bronnen en meer informatie

• Google · Gmail sender guidelines
• IETF · SPF (RFC 7208)
• IETF · DKIM (RFC 6376)
• IETF · DMARC (RFC 7489)
• IETF · One-click unsubscribe (RFC 8058)
• Klaviyo · Mail Privacy Protection