Bij een mailserver met meerdere domeinen verdienen zowel domeinreputatie als gedeelde infrastructuur aandacht. Wie 50-1,000+ klantdomeinen beheert, kan drie maatregelen beoordelen: DKIM-sleutels per domein, gescheiden verzend-IP-pools voor klantsegmenten en herkenbare verwerking van DMARC-rapporten per domein. Ze kunnen bepaalde risico's beperken, maar voorkomen niet alle gevolgen van een incident voor andere klanten.
Bezorging is niet alleen een taak van de host. Op bureauschaal moet je ook per klant het verzendgedrag en de reputatie volgen. Een spamcampagne kan een gedeeld IP op een blokkeerlijst laten belanden en andere afzenders raken, afhankelijk van het beleid van ontvangers. De drie maatregelen hieronder helpen dat risico beheersen, zonder volledige scheiding van alle reputatiefactoren te garanderen.
Deze gids bespreekt de drie maatregelen en de incidenten waarbij ze kunnen helpen. Voor de bredere afweging zie een mailserver voor meerdere domeinen.
Waarom reputatie per domein belangrijk is bij groei
Ontvangers en blokkeerlijsten kunnen signalen op IP- en domeinniveau gebruiken. Een beheerder met 200 klantdomeinen op één verzend-IP deelt daarmee een deel van de reputatie. Een incident van één klant kan anderen raken, maar niet iedere ontvanger blokkeert daardoor automatisch alle berichten. Het doel is de gedeelde risico's te herkennen en waar mogelijk te beperken.
De drie maatregelen richten zich op verschillende lagen. DKIM-sleutels per domein scheiden de cryptografische ondertekening; segmentatie van verzend-IP's kan gedeelde IP-risico's verkleinen; domeinherkenbare DMARC-verwerking helpt bij monitoring. Sleutels scheiden geen gemeenschappelijke serverrechten of klantgegevens, en reputatie kan via inhoud, links of andere infrastructuur samenhangen. De combinatie vervangt daarom geen bredere beveiliging en zorgvuldig verzendbeheer.
De drie maatregelen in één overzicht
Deze drie maatregelen vormen een bruikbaar kader voor bezorging over klantdomeinen in 2026. De tabel beschrijft de laag waarop ze helpen en een mogelijk beperkt risico. Beschikbaarheid en uitvoering verschillen tussen beheerde platforms en zelf gehoste systemen; de maatregelen dekken niet alle soorten incidenten.
| Maatregel | Wat wordt gescheiden | Risico dat wordt beperkt |
|---|---|---|
| DKIM-sleutels per domein | Cryptografische ondertekening per klantdomein | Gevolgen van blootstelling van één afzonderlijke sleutel |
| Scheiding van IP-pools | Een deel van de IP-reputatie per klantsegment | Gevolgen van een spamincident voor andere pools |
| DMARC-rapportverwerking per domein | Authenticatiemonitoring per klantdomein | Gebrekkig zicht op de herkomst van problemen |
Samen kunnen de drie maatregelen bepaalde doorwerking van incidenten beperken. Ontbrekende scheiding of monitoring kan extra risico geven, maar aanwezigheid bewijst niet dat alle incidenten worden voorkomen. Beoordeel niet alleen een functienaam: controleer de inrichting, toegangsrechten, dekking en het proces voor incidentrespons.
Maatregel 1: DKIM-sleutels per domein
Met DKIM-sleutels per domein wordt uitgaande mail ondertekend met een eigen private sleutel. De selector verwijst naar de bijbehorende publieke sleutel in de DNS van dat domein. Dat kan de gevolgen van blootstelling van één private sleutel beperken. DNS-kaping en beheerfouten vragen eveneens om incidentrespons. Als de gemeenschappelijke ondertekeningsinfrastructuur of beheerdersrechten worden overgenomen, zijn afzonderlijke domeinsleutels geen volledige bescherming van andere klanten. Ook de gebruikte verzendrelay moet correct ondertekenen; alleen een publieke DNS-sleutel publiceren garandeert dat niet.
TrekMail maakt bij het aanmaken van een nieuw domein DKIM-sleutels aan. Ga niet uit van periodieke automatische sleutelrotatie in ieder abonnement; controleer de ondersteunde procedure. Bij zelfhosting kun je domeinsleutels en geplande rotatie inrichten met passend DNS- en sleutelbeheer. Ook systemen zoals cPanel ondersteunen domeingebonden DKIM, dus neem niet aan dat consumentgerichte hosts allemaal één sleutel delen.
Maatregel 2: Scheiding van IP-pools
Gescheiden IP-pools kunnen klanten of verzendstromen verdelen over verschillende uitgaande IP-adressen. Transactionele berichten en laagvolumemail kunnen bijvoorbeeld een andere inrichting krijgen dan intensieve verzending. Ongevraagde acquisitie is daarmee niet toegestaan; toestemming en misbruikbeleid blijven gelden. Een incident kan zo minder direct andere pools raken, maar inhoud, links en netwerkreputatie kunnen nog steeds verbanden tussen segmenten leggen.
De uitvoering verschilt per dienst. Vraag bij TrekMail Agency of een mailrelay expliciet of poolscheiding beschikbaar is en welke voorwaarden gelden; een extern SMTP-profiel is geen garantie van een eigen IP-pool. Bij zelfhosting zijn meerdere verzend-IP's en daadwerkelijke transport-, bind- en route-instellingen nodig. Met alleen Postfix transport_maps wordt het bron-IP niet vanzelf gekozen. Ook een gedeelde dienst kan segmenteren, afhankelijk van de aanbieder. Zie de reputatiescore van een e-mailafzender voor de bredere achtergrond.
Maatregel 3: DMARC-rapportverwerking per domein
DMARC-aggregatierapporten herkenbaar per domein verwerken helpt de beheerder bij het volgen van authenticatie en afstemming op het zichtbare afzenderdomein. Dat kan via afzonderlijke ontvangstbestemmingen of via een centrale verwerker die rapporten per domein onderscheidt. De rapporten komen alleen van deelnemende ontvangers en meten geen inboxplaatsing. Goede verwerking kan onderzoek versnellen, maar garandeert geen vroegtijdige melding.
Een gedeeld rapportadres maakt domeinen niet ononderscheidbaar: een geschikte centrale collector kan op beleidsdomein groeperen. TrekMail gebruikt een gemeenschappelijke rapportbestemming en aggregatieanalyse voor platformbeheerders; ga niet uit van een klantdashboard met afzonderlijke rapporten of een vrij instelbaar rapportadres per klant. Controleer toegangsrechten en gebruik zo nodig een geautoriseerde externe collector voor eigen analyses. Zie risico's van e-mailhosting voor meerdere domeinen.
Incidenten waarbij de drie maatregelen kunnen helpen
Drie voorbeelden verdienen aandacht. Eerst de doorwerking van een spamcampagne: één klant veroorzaakt een blokkering van een gedeeld verzend-IP, waardoor andere klanten mogelijk slechter worden bezorgd totdat de oorzaak is aangepakt. Vervolgens het uitlekken van een DKIM-sleutel: afzonderlijke sleutels beperken bepaalde gevolgen, maar een compromis van gedeelde infrastructuur kan meerdere klanten raken.
Het derde voorbeeld is geleidelijke achteruitgang. Het verzendpatroon van een klant kan ontvangers aanleiding geven de reputatie anders te beoordelen; zonder gerichte monitoring valt dat mogelijk pas op bij klachten. DMARC kan authenticatieproblemen zichtbaar maken, maar niet iedere bezorgverandering meten. De drie maatregelen verkleinen bepaalde risico's, niet alle drie incidenttypen in iedere situatie.
Wat je bij TrekMail Agency moet controleren
Bij TrekMail worden DKIM-sleutels bij domeinaanmaak ingericht. Vraag voor geplande rotatie naar de ondersteunde procedure in plaats van periodieke automatisering aan te nemen. Controleer afzonderlijk of IP-pools kunnen worden gescheiden; het bestaan van externe SMTP-configuratie bewijst dat niet. DNS-vereisten en controles zijn niet hetzelfde als klanttoegang tot DMARC-aggregatierapporten. Voor eigen monitoring kunnen een externe collector en verwerking met passende machtiging nodig zijn.
Een beheerd platform neemt bepaalde beheertaken over, maar je moet de werkelijk inbegrepen maatregelen controleren. Het Agency-tarief van $279/jaar is een historisch prijsvoorbeeld. Of je 50 klantdomeinen of 1,000 beheert, de gedeelde accountopslag van tweehonderd gigabyte, verzend- en verbindingslimieten en rechten blijven gelden. Het tarief bewijst niet dat alle genoemde vormen van scheiding inbegrepen zijn. Zie e-mailhosting voor bureaus voor de beheerafwegingen.
Afwegingen bij zelfhosting
Zelfhosting kan de drie maatregelen ondersteunen met passende inrichting en beheer. Domeinsleutels vragen om veilig sleutelbeheer en een ondersteund rotatieproces in DNS. Voor IP-pools moeten daadwerkelijke verzendtransports en bron-IP-instellingen overeenkomen met de gewenste routes. DMARC-verwerking vereist een collector en analyse die rapporten per klantdomein herkennen, met voldoende toegangsbeveiliging.
Dit blijft doorlopend werk. Een raming van enkele beheeruren per maand voor 50+ klantdomeinen is slechts een planningsvoorbeeld; incidenten of complexiteit kunnen meer tijd kosten. Bij een beheerde dienst moet je controleren welke taken echt worden uitgevoerd en welke bij jou blijven. Zelfhosting kan meer configuratievrijheid geven; beheerde diensten kunnen werk verminderen. Vergelijk de werkelijke beheerlast in plaats van automatisch voordeel voor één model aan te nemen.
Volgende stappen
Een bruikbaar kader voor bezorging bij meerdere domeinen omvat DKIM per domein, passende scheiding van verzend-IP's en domeinherkenbare DMARC-verwerking. Ze kunnen bepaalde incidenten en gebrekkige monitoring helpen beperken, maar dekken niet vrijwel ieder risico van gedeelde infrastructuur. Bij groei blijven veilige rechten, verzendbeleid, capaciteit en incidentrespons noodzakelijk.
Bekijk TrekMail Agency op trekmail.net/pricing. Het historische prijsvoorbeeld is $279/jaar voor maximaal 1,000 klantdomeinen binnen de overige accountlimieten. Controleer de actuele voorwaarden en beschikbaarheid van elke maatregel, zonder inbegrepen IP-pools, periodieke rotatie of klantgerichte DMARC-analyse te veronderstellen. Een beheerde dienst is niet automatisch sterker dan een zorgvuldig beheerde eigen installatie. Zie een e-mailserver voor meerdere domeinen voor de bredere afweging.
Consistente basisinstellingen over klantdomeinen kunnen incidentrespons overzichtelijker maken. Leg vast welke maatregelen standaard gelden en welke uitzonderingen nodig zijn. Maatwerk kan nieuwe foutmogelijkheden geven, maar is niet op zichzelf verkeerd; controleer afhankelijkheden en documenteer verantwoordelijkheden.
Het gaat om doorlopende monitoring, niet alleen om eenmalige inrichting. Maandelijkse beoordeling van rapporten kan helpen bepaalde authenticatieveranderingen op te merken. De genoemde tijdsbesteding van 10 minuten per klant per maand is een planningsvoorbeeld, geen garantie van volledige dekking of vroege waarschuwing. Houd rekening met rapportvertraging, meetperiode en deelnemende ontvangers, en combineer rapporten met andere relevante signalen.
Wie als MSP 500+ klantdomeinen beheert, kan baat hebben bij automatisering. TrekMail API en MCP bieden mogelijkheden rond DNS-vereisten, hercontroles en status binnen de toegestane rechten; ga niet uit van een klantfunctie voor het ophalen van DMARC-aggregatierapporten of kant-en-klare reputatiewaarschuwingen. Een rapportpipeline vraagt zo nodig een geautoriseerde externe collector en verwerker. Automatisering kan werk beperken, maar maakt deskundig beheer niet noodzakelijk overbodig.
Als illustratieve onderzoekssignalen kun je een DKIM-slaagpercentage boven 98% en DMARC-afstemming boven 95% bekijken, niet als universele norm of dienstverleningstoezegging. Doorsturen, mailinglijsten, meetperiode en ontvangerdekking beïnvloeden de interpretatie. Een melding bij een DKIM-slaagpercentage onder 95% kan onderzoek ondersteunen, mits gegevens, machtiging en vertraging bekend zijn. Een middag om zo'n melding te programmeren is een tijdsinschatting, geen garantie dat incidenten altijd vóór klachten worden ontdekt.
