E-mailbezorgbaarheid begrijpen en optimaliseren
E-mailbezorgbaarheid bepaalt of een verzonden bericht daadwerkelijk de inbox van de ontvanger bereikt of geruisloos verdwijnt in de spambox. Grote e-mailproviders hanteren strikte standaarden om hun gebruikers te beschermen tegen ongewenste e-mail en phishing. Het handmatig controleren van alle technische instellingen en verzendpraktijken helpt domeineigenaren, operationeel personeel en verzendteams om fouten op te sporen voordat e-mails worden geweigerd.
De Checklist voor e-mailbezorgbaarheid biedt een gestructureerde methode om een verzenddomein te toetsen aan de hand van gepubliceerde standaarden en richtlijnen van providers. Door de specifieke context van de e-mailstroom op te geven, zoals het volume en het type e-mail, worden de toepasselijke vereisten direct in kaart gebracht.
Technische authenticatie met SPF, DKIM en DMARC
Authenticatie vormt de basis van een betrouwbare e-mailinfrastructuur. Zonder correcte authenticatie kunnen ontvangende servers de identiteit van de afzender niet verifiëren, wat direct leidt tot een verhoogde kans op weigering of spammarkering.
- SPF (Sender Policy Framework): Dit DNS-record specificeert welke IP-adressen en verzenddiensten namens het domein e-mail mogen versturen. Het is essentieel dat dit beleid elke actieve verzenddienst dekt.
- DKIM (DomainKeys Identified Mail): Deze methode voegt een cryptografische handtekening toe aan de e-mailheaders. Ontvangende servers gebruiken de openbare sleutel in de DNS om te controleren of het bericht onderweg is gewijzigd. Een geschikte sleutel heeft een lengte van minimaal 1024 bits, waarbij 2048 bits de voorkeur heeft wanneer dit wordt ondersteund.
- DMARC (Domain-based Message Authentication, Reporting, and Conformance): Dit beleid bouwt voort op SPF en DKIM. Het moet worden gepubliceerd met minimaal
p=noneom rapportage te starten, waarna een geleidelijke overstap naar quarantaine of weigeren kan plaatsvinden. - Uitlijning (Alignment): Voor een succesvolle authenticatie moet het domein in de SPF- of DKIM-controle overeenkomen met het domein in het zichtbare From-adres.
Infrastructuur en berichtindeling
Naast authenticatie moeten de netwerkinfrastructuur en de opbouw van de e-mails voldoen aan technische standaarden.
| Onderdeel | Richtlijn en verificatie |
|---|---|
| DNS-overeenstemming | Voorwaartse en omgekeerde DNS (rDNS) moeten overeenstemmen voor alle verzendende IP-adressen. Elk IP-adres moet een PTR-hostnaam hebben die terugverwijst naar datzelfde IP-adres. |
| TLS-versleuteling | Uitgaande e-mail moet gebruikmaken van TLS (Transport Layer Security). Verzenddiensten of SMTP-logboeken moeten bevestigen dat er een versleutelde verbinding wordt aangeboden aan ontvangende servers. |
| Header-integriteit | Berichten moeten geldige en nauwkeurige headers bevatten. Dit betekent één enkel From-adres, geldige Date- en Message-ID-velden, en een onderwerp en identiteit die niet misleidend zijn. |
Verzendpraktijken en reputatiebeheer
Een goede technische inrichting is onvoldoende als de verzendpraktijken leiden tot klachten of bounces. Providers monitoren het gedrag van ontvangers om de reputatie van een afzender te bepalen.
Toestemming is hierbij de belangrijkste factor. Ontvangers moeten expliciet toestemming hebben gegeven voor het ontvangen van de e-mails. Het consequent verwijderen van ongeldige e-mailadressen en het direct onderdrukken van harde bounces en klachten is noodzakelijk om de lijst schoon te houden.
Daarnaast moeten klachtpercentages strikt worden bewaakt via de dashboards van de respectievelijke e-mailproviders. Het spampercentage bij Gmail dient bijvoorbeeld onder de 0,10% te blijven, waarbij een percentage van 0,30% of hoger absoluut vermeden moet worden. Ook voor Yahoo geldt dat klachten onder de 0,30% gehouden moeten worden. Het structureel controleren van geaggregeerde DMARC-rapporten en feedbacklussen helpt om fouten in de verzendlijst vroegtijdig op te sporen.
Afmeldmechanismen voor marketing- en bulkmail
Voor marketingmail, nieuwsbrieven en bulkmail (ongeveer 5.000 of meer berichten per dag naar persoonlijke Gmail-accounts) gelden aanvullende eisen rondom het afmelden.
Ten eerste moeten headers voor afmelding met één klik correct functioneren. Dit vereist de aanwezigheid van de RFC 8058-headers List-Unsubscribe and List-Unsubscribe-Post in de e-mail. De werking hiervan kan worden geverifieerd door het HTTPS POST-eindpunt te testen.
Ten tweede moet er een zichtbare afmeldlink in het bericht aanwezig zijn. Deze link moet werken zonder dat de ontvanger hoeft in te loggen. Verzoeken tot afmelding moeten snel worden verwerkt, waarbij de onderdrukking van het adres binnen twee dagen voltooid moet zijn.
Werking en beperkingen van de checklist
De tool verwerkt alle ingevoerde gegevens lokaal. Je domein en checklistkeuzes blijven in je browser. BroBroGo uploadt ze niet en slaat ze niet op. De controle en de evaluatie vinden volledig plaats op het apparaat van de gebruiker.
De checklist maakt gebruik van een statische referentieset met de datum 2026-07-16. Deze set vat de op dat moment gepubliceerde standaarden en providerrichtlijnen samen. De tool voert zelf geen actieve DNS-query's uit en verstuurt geen testberichten. De evaluatie is uitsluitend gebaseerd op het ingevoerde domein, de geselecteerde context (zoals bulkafzender of marketingmail) en de handmatig aangevinkte vakjes.
Bij het invoeren van het verzenddomein gelden de volgende validatieregels en foutmeldingen:
- Als het veld leeg is bij het genereren van de controle, verschijnt de melding:
Voer eerst het verzenddomein in. - Als het domein langer is dan 253 tekens, toont de tool:
Dat domein is ongebruikelijk lang. Houd het binnen 253 tekens. - Als het ingevoerde domein geen geldig openbaar domein is (bijvoorbeeld met een schema of e-mailadres), verschijnt:
Voer alleen een openbaar domein in, zoals mail.example.com.
Wanneer alle toepasselijke stappen zijn aangevinkt, toont de interface de meldingen Geen niet-aangevinkte punten in deze referentieset en Blijf echte berichten, rapporten en richtlijnen van providers controleren, omdat status en vereisten kunnen veranderen.. Het voltooien van de checklist is een voorbereiding, maar biedt geen garantie op bezorging in de inbox, aangezien providers ook kijken naar realtime factoren zoals verkeerspatronen en inhoud.
Veelgestelde vragen
Welke regels gebruikt deze checklist?
De referentieset van 2026-07-16 gebruikt RFC 7208 voor SPF, RFC 6376 voor DKIM, RFC 9989 voor DMARC, RFC 8058 voor afmelding met één klik en de richtlijnen voor afzenders van Gmail en Yahoo die op die datum beschikbaar waren.
Vraagt de checklist DNS op of verstuurt deze een testmail?
Nee. De checklist beoordeelt alleen het domein, de context en de vakjes die je invoert. Volg de gegenereerde stappen bij je DNS-provider en verzenddienst en in de headers van een echt bericht.
Garandeert het voltooien van elk punt plaatsing in de inbox?
Nee. Ontvangers gebruiken ook reputatie, feedback van ontvangers, inhoud, verkeerspatronen en veranderende interne regels. Deze checklist helpt je een controle voor te bereiden, maar kan bezorging niet voorspellen of garanderen.