E-mailbezorging en DNS

E-maildomeinreputatie: diagnose en verantwoord herstel

Door Alexey Bulygin
Dashboard voor e-maildomeinreputatie met afzenderscore en statistieken over bezorging

Je verstuurt een bericht en de server antwoordt met 250 OK. Twee weken later blijkt dat de e-mail nooit is aangekomen: hij stond in de spammap of werd door een gatewayfilter verwijderd voordat de ontvanger zich aanmeldde. De onderwerpregel of pech hoeft niet de oorzaak te zijn. Mogelijk speelde je e-maildomeinreputatie mee, die al weken achteruitging.

Sinds Google en Yahoo in februari 2024 bepaalde regels aanscherpten, moeten afzenders die binnen hun gedefinieerde categorieën vallen aan de toepasselijke eisen voldoen. Overschrijding van drempels kan de zichtbaarheid beperken, maar betekent niet dat elke afzender overal wordt gedempt. Deze gids bespreekt oorzaken, diagnostische foutcodes en een herstelplan. Heb je eerst de DNS-basis nodig, begin dan met e-mail op je domein instellen.

Wat e-maildomeinreputatie werkelijk betekent

E-maildomeinreputatie bestaat uit vertrouwenssignalen die inboxproviders zoals Google, Microsoft en Yahoo in de loop van de tijd aan je verzenddomein koppelen. Veel spamklachten, mislukte authenticatie en gebrekkig lijstbeheer kunnen die beoordeling schaden. Er bestaat geen universele score. Herstel vergt doorgaans een periode met verantwoord verzendgedrag, maar de duur en uitkomst verschillen per provider.

Belangrijk is dat reputatie niet vanzelf verbetert. Een domein met jarenlange positieve historie kan soms een fout opvangen. Herhaalde klachten of blokkades door authenticatieproblemen kunnen meer hersteltijd vragen. Dat vormt echter geen vooraf vaststaand, permanent oordeel.

Providers kunnen signalen op het niveau van het organisatiedomein samenvoegen. Subdomeinen bieden geen gegarandeerde afscherming. Als marketing.example.com wordt geblokkeerd, kan e-mail van ceo@example.com daar ook last van krijgen. Hoe sterk die samenhang is, verschilt en moet per provider worden onderzocht.

De hoogste bereikte drempel en blijvende classificatie

Wanneer Google een domein als bulkafzender classificeert, op basis van ongeveer 5,000 e-mails per dag aan persoonlijke Gmail-accounts, beschouwt het die classificatie als blijvend. Minder verzenden maakt haar niet noodzakelijk ongedaan. De bijbehorende eisen blijven dan gelden, waaronder headers voor afmelden met één klik en publicatie van DMARC. Dit betekent niet dat elke provider dezelfde drempel hanteert of dat DMARC altijd op p=quarantine of p=reject moet staan.

Blijft je dagelijkse volume naar Gmail onder ~100 e-mails per dag, dan toont Postmaster Tools mogelijk "No Data". Testen met enkele controleadressen en analyse van bounces kunnen aanwijzingen geven, maar zo'n beperkte steekproef vertegenwoordigt niet alle ontvangers.

De 4 hoofdoorzaken van reputatieproblemen

Wanneer de reputatie instort, zijn er vier terugkerende gebieden om te onderzoeken: klachtpercentages, verkeerde authenticatie-uitlijning, de SPF-lookuplimiet en permanente bounces. Ook inhoud, toestemming en ontvangersbeleid kunnen een rol spelen. Bepaal eerst welke laag is geraakt, zodat je geen onnodige herstelmaatregelen neemt.

1. De klachtendrempel van 0.3%

Spamklachten zijn een belangrijk signaal voor Google en Yahoo. Een percentage van 0.3%, oftewel 3 klachten per 1,000 e-mails, geldt in hun richtlijnen als een risicodrempel en kan tot filtering of weigering leiden. Het is geen overal identieke, onmiddellijke blokkade. Google adviseert onder 0.1% te blijven en niet in de buurt van 0.3% te komen.

Yahoo kan een specifieke methode publiceren waarbij het klachtpercentage op in de inbox bezorgde berichten wordt berekend. Definities en noemers kunnen veranderen; controleer daarom de actuele documentatie in plaats van één universele berekening aan te nemen.

Scenario: Je verstuurt 1,000 e-mails. 900 worden automatisch als spam gefilterd. 100 belanden in de inbox. 1 persoon klaagt.
Berekening: 1 klacht ÷ 100 inboxberichten = een klachtpercentage van 1.0%.
Uitkomst: In dit voorbeeld zit je 3× boven de limiet en kan de filtering verder toenemen.

Dalende openingspercentages kunnen een signaal zijn, maar opens zijn onvolledig en worden door privacyfuncties beïnvloed. Google Postmaster Tools kan bij voldoende gegevens statussen als "Low" of "Bad" tonen; de interface en dekking kunnen wijzigen.

2. Verkeerde authenticatie-uitlijning en spoofingsignalen

SPF en DKIM kunnen slagen zonder te zijn uitgelijnd met het zichtbare From-domein. DMARC faalt dan, tenzij de andere uitgelijnde methode wel slaagt. Een DMARC-fout kan op spoofing lijken en de reputatie schaden, maar moet samen met andere signalen worden beoordeeld.

Bij een ESP als Mailchimp of SendGrid kan de envelope sender voor SPF bijvoorbeeld naar mail.sendgrid.net wijzen, terwijl de From-header yourcompany.com gebruikt. SPF slaagt omdat het IP is gemachtigd, maar de DMARC-uitlijning via SPF faalt omdat de domeinen verschillen. DMARC kan alsnog slagen via een uitgelijnde DKIM-handtekening.

Microsoft kan 550 5.7.515 retourneren in verband met authenticatie- of beleidseisen voor afzenders met grote volumes. De volledige code bewijst op zichzelf geen inhouds- of Return-Path-probleem. Configureer de opties voor authenticatie met een eigen domein in je ESP, soms "Whitelabeling" genoemd, en controleer zowel SPF- als DKIM-uitlijning.

3. De SPF-limiet van 10 lookups (RFC 7208)

SPF is geen onbeperkte lijst. RFC 7208 §4.6.4 stelt een limiet van 10 DNS-lookups voor mechanismen die tijdens één SPF-evaluatie een lookup veroorzaken. Google, Outlook, Zendesk, Mailchimp en een CRM opnemen kan je dicht bij die limiet brengen. Geneste include:-instructies kunnen extra lookups verbruiken.

Bij 11 lookups door de betreffende mechanismen kan de evaluatie een PermError opleveren. Het SPF-record geeft voor die controle dan geen geldig resultaat. Reacties kunnen per ontvanger en DNS-pad verschillen, maar schrijf dit zonder loggegevens niet algemeen toe aan soepele of strenge parsers.

4. Microsofts gevoeligheid voor bounces door onbekende ontvangers

Microsoft let op permanente bounces en gedrag dat op namespace mining lijkt. Een bouncepercentage boven 2-3% is een praktijkvoorbeeld van verhoogd risico, geen officiële drempel die altijd onmiddellijk blokkeert. Mogelijke reacties zijn 550 5.7.1 of vertraging met 421 RP-001, maar controleer de volledige melding voor de betekenis.

Een spamklachtpercentage van 0% sluit problemen door permanent ongeldige adressen, authenticatie of beleid niet uit. Onderscheid "User Unknown" van permanente beleids- en authenticatiegerelateerde antwoorden en controleer toestemming en geldigheid voordat je Microsoft-adressen benadert.

Informatie per provider

Om reputatieproblemen op te lossen, moet je weten welke provider filtert of weigert. Elke provider kan signalen anders wegen en eigen diagnostische hulpmiddelen bieden. Controleer steeds de actuele beschikbaarheid, toelatingseisen en documentatie.

Provider Belangrijk aandachtspunt Diagnostisch hulpmiddel Belangrijke nuance
Google (Gmail / Workspace) Klachtpercentage + betrokkenheid Google Postmaster Tools Bij weinig verkeer (<100 per dag naar Gmail) kan "No Data" verschijnen; controletests geven slechts een beperkt beeld
Microsoft (Outlook / 365) Technische naleving + IP-reputatie SNDS (Smart Network Data Services) Nieuwe IP's kunnen geleidelijke opwarming vereisen; tempo en beperkingen hangen af van waargenomen signalen
Yahoo / AOL Inhoud + klachtpercentage Yahoo Sender Hub + CFL Indien beschikbaar en ingesteld, kan de Complaint Feedback Loop ARF-rapporten over daarvoor geschikte klachten leveren

Diagnostisch proces: isoleer de fout

Ga niet uit van vermoedens. Voer geautoriseerde technische controles in de juiste omgeving uit en lees daarna de headers van een ontvangen bericht. Samen helpen ze onderscheid te maken tussen infrastructuur, authenticatie en verzendgedrag, maar één steekproef geeft geen volledige diagnose.

Infrastructuurcontrole via de terminal

Controleer de authenticatiestack voordat je het volume verhoogt. Deze drie controles behandelen veelvoorkomende punten, maar zijn voorbeelden die je moet aanpassen en alleen met toestemming voor het betreffende domein mag uitvoeren.

# Check SPF - count the includes, verify it ends in ~all or -all
dig txt yourdomain.com +short

# Check DMARC - p= should be quarantine or reject for live domains
dig txt _dmarc.yourdomain.com +short

# Check FCrDNS (Forward-Confirmed Reverse DNS)
# Step 1: Get the hostname from your sending IP
dig -x 1.2.3.4 +short
# Expected output: mail.yourdomain.com.

# Step 2: Verify the hostname resolves back to the same IP
dig mail.yourdomain.com +short
# Expected output: 1.2.3.4

Als de FCrDNS-controle faalt en IP en hostnaam niet overeenkomen, kunnen sommige ontvangers dat als een negatief signaal behandelen. Dit veroorzaakt geen universele weigering door Gmail of Yahoo, maar corrigeer het en controleer de DNS-propagatie voordat je het volume verhoogt.

Headeronderzoek

Stuur een geautoriseerd testbericht naar een Gmail-account dat je beheert. Open het, klik op de drie punten en kies "Origineel weergeven". Zoek de header Authentication-Results. Het resultaat geldt voor dat pad en die ontvanger en garandeert geen toekomstige bezorging.

Negatief signaal, uitlijning mislukt:

spf=pass smtp.mailfrom=sendgrid.net
dkim=pass header.d=sendgrid.net
dmarc=fail (p=reject) header.from=yourcompany.com

SPF slaagt en DKIM slaagt, maar DMARC faalt omdat geen van beide domeinen is uitgelijnd met yourcompany.com. Dit voorbeeld toont de verkeerde uitlijning van hierboven en kan aan negatieve signalen bijdragen.

Positief signaal, correct uitgelijnd:

spf=pass smtp.mailfrom=em.yourcompany.com
dkim=pass header.d=yourcompany.com
dmarc=pass

Herstelprotocol

Wanneer Google Postmaster Tools "Bad" toont, is 2-4 weken verantwoord verzendgedrag een praktische schatting en geen gegarandeerde termijn. Herstel hangt af van oorzaak, volume en ontvangers. Werk in fasen zodat je de effecten kunt meten.

Fase 1: de lijst beoordelen

Blijven verzenden naar ongeldige ontvangers belemmert herstel. Verwijder niet automatisch iedereen die in 90 dagen niet heeft geopend of geklikt: opens zijn onbetrouwbaar en toestemming, dienstnoodzaak of bewaarplichten kunnen gelden. Onderdruk bevestigde permanent ongeldige adressen en herstel de afhandeling als je na twee "User Unknown"-reacties voor hetzelfde adres blijft verzenden.

Fase 2: technische correcties

Overweeg na autorisatie en inventarisatie van alle legitieme afzenders een geleidelijke overgang van p=none naar p=quarantine. DMARC-beleid beperkt bepaalde vormen van misbruik, maar stopt niet alle spoofing en garandeert geen reputatieherstel. Gebruik je 1024-bit DKIM-sleutels, controleer dan actuele ondersteuning en plan een veilige rotatie naar 2048-bit of een geaccepteerd algoritme met een zorgvuldige DNS-update. De gids met vereiste DNS-records beschrijft het verwachte formaat voor TrekMail-domeinen; verifieer de actuele configuratie.

Fase 3: lineair en gecontroleerd opwarmen

Begin opnieuw met segmenten die in de afgelopen 30 dagen een echte relatie met de afzender hebben getoond en wek geen kunstmatige betrokkenheid op. Een illustratieve reeks is:

  • Dag 1: 50 e-mails
  • Dag 2: 100 e-mails
  • Dag 3: 200 e-mails
  • Dag 4: 400 e-mails

Controleer dagelijks de beschikbare gegevens. Bij slechtere signalen zijn 48 uur pauze en hervatten op het vorige volume voorbeelden, geen universele regel. Pas het tempo aan het providerbeleid en de waargenomen resultaten aan.

Infrastructuurhygiëne: minder zichtbare problemen

Twee infrastructuuraspecten kunnen invloed hebben zonder duidelijke foutsignalen. Ook met correcte authenticatierecords verdienen TLS-instellingen en de kwaliteit van het IP-pool aandacht. Ze zijn echter niet de enige mogelijke oorzaken.

TLS gebruiken

Grote providers verwachten waar mogelijk beveiligd SMTP-transport, maar beleid, context en ondersteunde versies verschillen. Configureer TLS 1.2 of hoger wanneer dat wordt vereist en ondersteund, zonder aan te nemen dat elke onversleutelde verbinding automatisch wordt geweigerd. TrekMail beschrijft TLS als standaard ingeschakeld; controleer huidig gedrag en je plan.

Andere afzenders op gedeelde IP's

Bij goedkope gedeelde hosting of een gratis ESP-plan kan je IP door veel andere afzenders worden gebruikt. Misbruik door een andere gebruiker kan het pool op Spamhaus SBL brengen en je berichten beïnvloeden, ook als je domein geen bekende problemen heeft.

Boven 100k per maand is een eigen IP niet automatisch beter: je hebt stabiel volume, operationele capaciteit en monitoring nodig. Bij lagere volumes kun je het poolbeheer van de provider beoordelen of externe SMTP gebruiken. Met de BYO SMTP-optie van TrekMail kun je volgens plan en beschikbaarheid Amazon SES, SendGrid of Mailgun aansluiten. Een gekozen provider gebruiken betekent niet dat je het IP rechtstreeks beheert of dat de reputatie ervan is gegarandeerd.

Hoe TrekMail hierin past

E-maildomeinreputatie is een technische en operationele randvoorwaarde. Ze vereist nauwkeurige DNS-configuratie, verantwoord ontvangersbeheer en uitgaande infrastructuur waarop passende controle wordt uitgeoefend.

Bij meerdere domeinen groeit de complexiteit. De gids voor e-mailhosting met meerdere domeinen legt uit hoe je ze kunt scheiden en het risico op samenhang verkleint, zonder volledige isolatie te beloven. De basisgids voor e-mailbeveiliging gaat dieper in op DMARC-beleid en rotatie van DKIM-sleutels.

TrekMail beschrijft functies voor inkomende post, waaronder opslag voor een vast tarief, IMAP-mailboxen, catch-all-routing en migratie aan serverzijde, zonder prijs per gebruiker. Voor uitgaande post kun je binnen plan en limieten een externe SMTP-provider koppelen. De SPF/DKIM/DMARC-wizard wordt bij de onboarding aangeboden, maar controleer configuratie, beschikbaarheid en eindresultaat voordat je verstuurt.

Plannen worden aangeboden vanaf $3.50 per maand. Er wordt een gratis proefperiode van 14 dagen met verplichte creditcard beschreven, of een Nano-plan zonder kaart dat als blijvend gratis wordt gepresenteerd, met 10 domeinen en 5 GB inbegrepen. Bekijk trekmail.net/pricing voor de huidige prijzen, voorwaarden, functies en limieten.

Samenvatting

Te onderzoeken oorzaken zijn een klachtpercentage boven 0.3%, fouten in DMARC-uitlijning door ESP-configuratie, overschrijding van de SPF-limiet van 10 lookups en permanente bounces bij Microsoft. Dit zijn niet de enige vier oorzaken en elk probleem vraagt om eigen gegevens en diagnostiek.

Is de reputatie al beschadigd, beoordeel dan de lijst, herstel de technische laag en warm het verzendvolume geleidelijk op. Twee tot vier weken is slechts een indicatie: er is geen snelkoppeling of vaste termijn.

Controleer vandaag je DNS met geautoriseerde hulpmiddelen. Herstel gevonden fouten en valideer het resultaat voordat je een nieuwe campagne verstuurt.

Dit artikel delen

We gebruiken noodzakelijke technologieën om TrekMail te laten werken en te beveiligen. Door te bevestigen staat u ook beperkte analyses en advertentiemeting toe zoals beschreven in ons Cookiebeleid.

Inloggen bij TrekMail

Toegang tot je dashboard, mailboxen en DNS.

of

12 tekens wachtwoorden komen overeen

of

Herstelmail verzonden

Als er een account bestaat voor dit e-mailadres, hebben we instructies gestuurd om je wachtwoord opnieuw in te stellen.

Door verder te gaan ga je akkoord met de TrekMail- Voorwaarden en het Privacybeleid.