Deliverability is geen setuptaak
Het meeste advies over e-mail deliverability behandelt het als een checklist: zet drie DNS-records, vink het vakje af, ga verder. De records zijn belangrijk, en ze komen eerst. Maar deliverability configureer je niet één keer. Het is een reputatie die mailboxproviders elke dag herberekenen op basis van hoe je mail ontvangen wordt, en je moet ze opvolgen en verdedigen zoals een reputatie. Wat volgt is hoe we het aanpakken bij Waer Waters, waar zowel marketing- als transactionele mail via HubSpot vertrekt.
Eerst: authenticatie
SPF legt vast welke servers mail mogen versturen voor je domein. DKIM ondertekent elk bericht, zodat de ontvanger kan nagaan dat het echt van jou komt en onderweg niet aangepast is. DMARC vertelt ontvangers wat ze moeten doen als die controles falen en, even belangrijk, waar ze de rapporten daarover naartoe moeten sturen. Zonder alle drie, correct en afgestemd op het domein waarvan je verstuurt, helpt niets anders in dit artikel. Google en Yahoo eisen ze sinds 2024 van bulkverzenders, Microsoft volgde in 2025 voor Outlook.com, dus dit is geen goede gewoonte meer maar het toegangsticket. Start DMARC op p=none, lees de rapporten, en verstrak pas als ze proper zijn.
; SPF: één record, met elke dienst die namens jou verstuurt
example.com. TXT "v=spf1 include:<verzenddienst> -all"
; DKIM: de sleutels krijg je van HubSpot bij het koppelen van je verzenddomein
<selector>._domainkey.example.com. CNAME <waarde van HubSpot>
; DMARC: eerst opvolgen, later afdwingen (p=quarantine, dan p=reject)
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"Warm een dedicated IP op
Op gedeelde IP's hoort een deel van je reputatie toe aan wie er verder nog van verstuurt. Een dedicated IP in HubSpot maakt de reputatie helemaal van jou, en dat is alleen goed nieuws als je ze degelijk opbouwt. Een nieuw IP heeft geen geschiedenis, en mailboxproviders behandelen een onbekende die plots grote volumes verstuurt als een spammer tot het tegendeel bewezen is. Dus warm je het op: begin met kleine volumes naar je meest betrokken contacten en bouw over enkele weken op, in plaats van op dag één de volledige lijst te versturen.
Twee IP's: één voor transactioneel, één voor marketing
Neem twee dedicated IP's in plaats van één: één voor transactionele mail, zoals boekingsbevestigingen, facturen en wachtwoordresets, en één voor marketing. Marketingmail is waar de klachten en uitschrijvingen vallen. Delen ze een IP, dan trekt een nieuwsbrief die slecht valt de reputatie mee waar je bevestigingen van afhangen, en dat zijn net de berichten die klanten echt moeten ontvangen. De meeste artikels stoppen bij de DNS-records en komen nooit aan IP-strategie toe, terwijl dat vaak precies is waar het verschil tussen inbox en spamfolder gemaakt wordt.
Volg elke bron op die je kan krijgen
Geen enkel rapport toont het volledige beeld. DMARC aggregate reports vertellen je wie mail verstuurt uit naam van je domein en of die slaagt. Google Postmaster Tools toont hoe Gmail je domein inschat en hoe vaak ontvangers je als spam markeren. Microsoft SNDS doet hetzelfde voor je IP's bij Outlook en Hotmail, en alleen voor IP's die je zelf beheert, wat nog een reden is om er een eigen te hebben. Staat je DNS bij Cloudflare, dan kan dat je DMARC-rapporten ook verzamelen en samenvatten. Hoe meer bronnen je opvolgt, hoe vroeger je een dip in reputatie opvangt, voor het een inboxprobleem wordt dat je klanten merken.
Je hebt een tool nodig om de rapporten te lezen
Ruwe DMARC-rapporten zijn XML-bestanden, één per provider per dag, en niemand leest ze lang met de hand. Rapportering aanzetten is niet hetzelfde als weten wat erin staat. Gebruik iets dat ze parset en visualiseert: het DMARC-beheer van Cloudflare is één optie, en aparte DMARC-analyzers gaan verder. De les is eenvoudig. Zet de rapporten niet alleen aan; zorg dat ze iets worden waar een mens effectief naar kijkt.
Verstuur nooit met de hand naar een lijst
We versturen nooit een manuele nieuwsbrief of een losse mail naar onze lijsten. Alles vertrekt via een workflow. Dat klinkt als extra werk voor een nieuwsbrief, maar het is wat je laat bepalen wie een verzending krijgt, in welke volgorde en aan welk tempo, en met de rapportering hierboven zie je ook of het werkt. De workflow heeft drie delen, en die staan hieronder uitgetekend.
inschrijving nieuwsbrieflijst
branch 1 geopend of geklikt in de laatste <n> dagen? nee -> niet versturen
branch 2 e-maildomein
gmail.com -> throttle -> ga naar nieuwsbrief
outlook.com, hotmail.com, live.com -> throttle -> ga naar nieuwsbrief
telenet.be -> throttle -> ga naar nieuwsbrief
al de rest -> throttle -> ga naar nieuwsbrief
throttle custom coded action zonder logica, met rate limit
nieuwsbrief één geautomatiseerde e-mail, één keer onderhoudenSegmenteer eerst op engagement
De eerste branch laat alleen contacten door die recent geopend of geklikt hebben. Al de rest wordt tegengehouden in plaats van gemaild. Elke keer naar de volledige lijst sturen betekent dode adressen raken en mensen die je als spam markeren, verzending na verzending, en allebei tellen ze tegen je reputatie. Weeg kliks zwaarder dan opens waar je kan, want privacyfuncties in mailapps laden berichten op de achtergrond en blazen je openratio op. Een kleinere lijst die reageert, doet meer voor je deliverability dan een grote die dat niet doet.
Branch per provider, en throttle elke branch
Na de engagement-branch splits je opnieuw per mailboxprovider: gmail.com voor Google, outlook.com, hotmail.com en live.com voor Microsoft, telenet.be, en welke andere domeinen er in jouw lijst toe doen. In elke branch zet je een custom coded action zonder logica erin. Die doet niets behalve een rate limit dragen, en dat is net de bedoeling: ze wordt een throttle, zodat elke provider je verzending aan een gecontroleerd tempo binnenkrijgt in plaats van alles in één keer. Een gestage stroom ziet er voor een spamfilter natuurlijker uit dan een piek, en houdt je onder de volumedrempels die extra controle uitlokken. Custom coded actions vragen Data Hub Professional, vroeger Operations Hub.
Breng de branches weer samen
Na de throttles springt elke branch met een go-to action naar één en dezelfde geautomatiseerde e-mail. Zet niet onder elke branch een kopie van de e-mail. Dan heb je vijf e-mails om in sync te houden, en vroeg of laat vertrekt er een met de link van vorige maand. De branches bestaan om timing en tempo te sturen, nooit de inhoud. Wil je een nieuwsbrief versturen, dan pas je die ene e-mail aan en laat je de workflow lopen.
Verdedigd, niet geconfigureerd
De records krijgen je binnen, de IP-strategie beschermt de mail die het meest telt, de opvolging vertelt je wanneer er iets verschuift, en de workflow maakt van elke verzending een gecontroleerde. Niets daarvan is op zich moeilijk. Het verschil zit in alles doen, en het volhouden na de eerste maand, wanneer alles er goed uitziet.