Zelf e-mail hosten in 2026: is het nog de moeite waard?

Het korte antwoord

Het zelf hosten van e-mail is in 2026 nog steeds de moeite waard, mits u de taken opsplitst. Het ontvangen van uw eigen e-mail op uw eigen VPS brengt weinig risico met zich mee en werkt goed, omdat u de ontvanger bent en niemand u hoeft te vertrouwen. Het versturen van e-mail die door grote mailbox-providers wordt geaccepteerd is een andere taak; dit hangt af van een IP-adresreputatie die u erft in plaats van opbouwt.

De configuratie die ervaren beheerders daadwerkelijk gebruiken is een hybride model. Hun eigen server beheert de mailboxen en het archief, terwijl uitgaande e-mail via een geauthenticeerde relay op poort 587 wordt verstuurd. Volledig zelf hosten, in beide richtingen, is in een aantal specifieke gevallen nog steeds de beste keuze; deze gevallen worden tegen het einde van dit bericht besproken.

Het lastige aspect van het zelf hosten van e-mail is de afleverbaarheid

Het installeren van een mailserver kost een weekend werk. Een moderne stack biedt u SMTP (simple mail transfer protocol) voor het versturen van e-mail, IMAP (internet message access protocol) voor het lezen ervan, spamfiltering en een webmail-interface vanuit één compose-bestand, en de Mailcow mailserver installatie op een VPS behandelt dit onderwerp. Niets aan de installatie is het moeilijke gedeelte.

De moeilijkheid begint wanneer uw server een verbinding opent met een machine die wordt beheerd door een bedrijf dat nog nooit van u heeft gehoord, en vraagt om een bericht in iemands inbox te plaatsen. Die ontvanger heeft geen reden om akkoord te gaan. Hij beslist op basis van signalen: de reputatie van het verbindende IP-adres, de reputatie van uw domein, of het bericht is geverifieerd en hoe zijn eigen gebruikers in het verleden op uw e-mail hebben gereageerd. Een nieuwe afzender heeft helemaal geen geschiedenis, en het ontbreken van een geschiedenis wordt niet als neutraal beoordeeld. Het wordt beoordeeld als een risico. Daarom belanden de eerste berichten in de spammap, of ze worden uitgesteld totdat er een patroon ontstaat.

U zult de weigering zien. Gmail stuurt een permanente afwijzing in deze vorm:

550-5.7.1 [203.0.113.5      19] Our system has detected that this message is
550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,
550-5.7.1 this message has been blocked.

Microsoft stuurt een andere, eindigend met een block-list code die varieert:

550 5.7.1 Unfortunately, messages from [203.0.113.5] weren't sent. Please
contact your Internet service provider since part of their network is on
our block list (S3150).

Lees eerst het eerste cijfer. Een code die begint met een 4 is tijdelijk, dus uw server behoudt het bericht en probeert het opnieuw. Een code die begint met een 5 is permanent, dus het bericht wordt direct teruggestuurd naar de afzender. Een 4xx uitstel dat nooit verdwijnt, is een rate limit of een reputatielimiet, en dit kan vanzelf oplossen. Een 5xx is een besluit, en dat zal niet veranderen.

Waarom belandt e-mail van een nieuwe server in de spam?

Omdat het IP-adres niet nieuw is. U krijgt geen vers adres. U ontvangt een gerecycled adres uit de pool van uw provider, en de geschiedenis daarvan krijgt u erbij. Als de vorige gebruiker spam verstuurde, kan uw allereerste bericht al worden geweigerd voordat u een tweede heeft verzonden.

Controleer het adres voordat u er iets op bouwt. De openbare blocklists antwoorden via DNS, met de vier octetten van het adres in omgekeerde volgorde:

sudo apt update && sudo apt install -y bind9-dnsutils netcat-openbsd swaks
dig +short 10.0.0.10.zen.spamhaus.org

Een leeg antwoord betekent dat het adres niet op de lijst staat. Een antwoord binnen 127.0.0.0/8 betekent dat dit wel het geval is, en het laatste octet geeft aan welke lijst een match vond. Een valkuil bij deze test: Spamhaus weigert queries die binnenkomen via grote openbare resolvers. Daarom geeft dezelfde opzoeking via 8.8.8.8 de waarde 127.255.255.254 terug, ongeacht de werkelijke status. Die code betekent dat de query werd geweigerd, niet dat het adres op de lijst staat. Voer de test uit via de resolver van uw eigen server, of gebruik de web-lookup.

Een schoon resultaat is noodzakelijk, maar niet voldoende. Niet op een lijst staan betekent alleen dat niemand onlangs over dat adres heeft geklaagd. Het draagt geen positieve reputatie met zich mee, en een positieve reputatie is wat e-mail daadwerkelijk in de inbox krijgt. Deze wordt verdiend door gedurende enkele weken kleine volumes gewenste e-mail te versturen.

Uw buren tellen ook mee, omdat sommige ontvangers de reputatie over een heel netwerkblok beoordelen in plaats van over een enkel adres. Wanneer een andere klant in hetzelfde /24-bereik spam begint te versturen, kan uw e-mail vertragen door associatie. Dat perspectief op blokniveau is ook de reden waarom misbruikmeldingen in een VPS-inbox aankomen voor verkeer dat de accounthouder nooit heeft verzonden: de klacht volgt het adresbereik.

Wat u moet controleren voordat u begint: poort 25 en het PTR-record

Uitgaande TCP-poort 25 is de meest misbruikte poort op het internet, waardoor veel hostingproviders deze standaard blokkeren voor nieuwe accounts. Sommigen openen deze op verzoek. Sommigen openen deze pas zodra een account een bepaalde leeftijd heeft en een betalingshistorie kan aantonen. Sommigen openen deze nooit. Het beleid verschilt per provider en verandert in de loop van de tijd; beschouw dit bericht, een oude forumdiscussie of de marketingpagina van een provider daarom niet als actuele waarheid. Vraag het na en zorg dat u het antwoord schriftelijk ontvangt voordat u betaalt.

Test het pad vanaf de server zelf:

nc -vz gmail-smtp-in.l.google.com 25

Een open pad geeft binnen een seconde succeeded! weer. Een geblokkeerd pad loopt vast en geeft na verloop van tijd een time-out zonder melding die de blokkade benoemt, omdat een stilletjes gedropt pakket er precies zo uitziet als een alledaags netwerkprobleem.

De tweede vereiste is een PTR-record, ook wel reverse DNS genoemd. Ontvangers nemen het IP-adres dat verbinding met hen maakt, zoeken het bijbehorende PTR-record op om een naam te verkrijgen en zoeken vervolgens die naam op om het adres terug te krijgen. Wanneer deze twee overeenkomen, wordt dit forward-confirmed reverse DNS genoemd. Dit is een eenvoudige controle om te verifiëren of de verbindende host toebehoort aan de partij die hij claimt te zijn.

dig -x 203.0.113.5 +short
dig +short mail.example.com

De eerste opdracht moet uw mail-hostname retourneren. De tweede moet hetzelfde adres retourneren waarmee u begon. Alleen de eigenaar van een IP-adres kan het PTR-record publiceren; dit is dus iets dat uw host voor u instelt of beschikbaar stelt in een configuratiescherm. Een ontbrekend PTR-record, of een generiek record zoals 203-0-113-5.static.example-isp.net, is een sterk negatief signaal, omdat legitieme mailservers bijna altijd een overeenkomende naam hebben en bronnen van bulk-spam dit vaak niet hebben.

Als uw host ook IPv6 toewijst en uw server de voorkeur geeft aan dit protocol, is alles hierboven ook van toepassing op het IPv6-adres, waarbij Gmail hier strenger op toeziet. Verzenden via IPv6 vanaf een adres zonder PTR-record leidt tot een afwijzing met de melding dat het bericht niet voldoet aan de IPv6-verzendrichtlijnen met betrekking tot PTR-records en authenticatie. Als u geen IPv6 PTR-record kunt instellen, verzend dan uitsluitend via IPv4. In Postfix gebruikt u smtp_address_preference = ipv4 om de voorkeur aan IPv4 te geven, of inet_protocols = ipv4 om IPv6 volledig uit te schakelen.

De drie vragen die u aan elke host moet stellen

1. Is uitgaande TCP-poort 25 open op een nieuw account, en zo niet, wat is dan de exacte procedure en termijn voor het openen ervan?
2. Kan ik het PTR-record instellen voor mijn IPv4-adres en voor mijn IPv6-adres, en waar doe ik dat?
3. Als mijn adres op een blocklist blijkt te staan vanwege een vorige klant, verplaatst u mij dan naar een ander adres?

Stel deze drie vragen voordat u koopt, niet erna. Een host die de eerste twee vragen duidelijk beantwoordt en 'nee' zegt op de derde, is nog steeds bruikbaar, omdat u het adres op de eerste dag kunt controleren en eventueel kunt opzeggen. Een host die geen van deze vragen schriftelijk wil beantwoorden, heeft u al laten weten hoe het zal zijn om daar mail te hosten.

Wat SPF, DKIM en DMARC daadwerkelijk bewijzen

Drie DNS-records bewijzen dat e-mail die claimt van uw domein afkomstig te zijn, dat ook daadwerkelijk is. Elk record beantwoordt een andere vraag, en het derde werkt pas als u de eerste twee begrijpt.

SPF (sender policy framework) is een TXT-record waarin staat welke servers e-mail voor uw domein mogen versturen. De ontvanger controleert dit tegen de envelope sender, het adres dat wordt opgegeven in het SMTP MAIL FROM-commando; dit is niet de From:-header die de lezer ziet.

DKIM (domainkeys identified mail) voegt een cryptografische handtekening toe aan de berichtheaders, die de body en een gekozen lijst met headers omvat. De bijbehorende publieke sleutel staat in DNS onder een door u gekozen selector. Iedereen kan vervolgens verifiëren dat het bericht afkomstig is van een houder van uw privésleutel en onderweg niet is gewijzigd.

DMARC (domain-based message authentication, reporting and conformance) koppelt de andere twee aan het domein in de zichtbare From:-header en vertelt ontvangers wat ze moeten doen als de koppeling faalt.

example.com.                  TXT  "v=spf1 mx -all"
mail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.example.com.           TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Het woord dat ertoe doet is alignment (uitlijning). DMARC slaagt niet simpelweg omdat SPF slaagt. Het slaagt wanneer SPF of DKIM slaagt en het domein dat slaagde hetzelfde domein is als dat in de From:-header. Hier faalt doorgestuurde e-mail vaak ongemerkt: een relay die de envelope sender herschrijft naar zijn eigen domein levert nog steeds een SPF-pass op, maar het domein dat slaagt is dat van de relay. Er is dus geen sprake van alignment en DMARC faalt, tenzij uw eigen DKIM-handtekening aanwezig en geldig is. Onderteken met een sleutel die onder uw domein is gepubliceerd en het probleem verdwijnt.

Alignment verklaart ook het doorsturen van e-mail. Wanneer een mailinglijst of een oud universiteitsadres uw bericht doorstuurt, wordt de doorsturende server het verbindende IP-adres. Omdat dit adres niet in uw SPF-record staat, faalt SPF bij de eindbestemming. DKIM overleeft het doorsturen zolang de headers die het heeft ondertekend niet zijn gewijzigd. DKIM is degene die moet werken.

Publiceer eerst p=none met een rua=-rapportageadres en lees de verzamelde rapporten gedurende twee weken voordat u de instellingen aanscherpt. Die rapporten zijn de enige plek waar u e-mail ziet die in uw naam is verzonden zonder dat u deze zelf heeft verstuurd, en de enige manier om de doorstuurder te vinden die u was vergeten. Direct overstappen op p=reject slaat die stap over en blokkeert legitieme e-mail zonder dat u een overzicht heeft van wat er precies is misgegaan.

Test vervolgens de gehele keten van begin tot eind. Verstuur één bericht naar een account dat u beheert bij een grote provider en open de ruwe broncode:

swaks --to you@gmail.com --from postmaster@example.com --server 127.0.0.1
sudo journalctl -t postfix/smtp -f

swaks toont de SMTP-conversatie terwijl deze plaatsvindt. De eigen logregel van Postfix voor de aflevering eindigt met status=sent (250 2.0.0 OK ...) wanneer de ontvangende server het bericht heeft geaccepteerd. Elke andere melding logt de weigeringstekst letterlijk, en die tekst is waar u op moet zoeken. In het afgeleverde bericht bevat de ruwe broncode een Authentication-Results:-header die elke controle benoemt met een pass of fail en het domein dat is geauthenticeerd. Alle drie moeten op pass staan en het domein moet het uwe zijn.

Hoe komt u achter een reputatieprobleem?

Een feedback loop is een voorziening waarbij een mailboxprovider u een kopie van een bericht stuurt zodra een van zijn gebruikers op de knop 'spam rapporteren' klikt. Zonder zo'n loop is het eerste teken van problemen een afgebroken aflevering, wat vaak weken te laat is.

De programma's verschillen onderling en niet elk programma is geschikt voor een enkele VPS met één adres. Sinds augustus 2026 beheert Microsoft een data- en klachtenservice per adres waarvoor de eigenaar van het adres zich kan registreren. Yahoo biedt een feedback loop voor klachten die gebaseerd is op het DKIM-ondertekeningsdomein. Google publiceert geaggregeerde reputatiedata in plaats van individuele klachten in een dashboard dat leeg blijft totdat u een aanzienlijk dagelijks volume aan berichten naar hun gebruikers verstuurt. Lees de actuele voorwaarden van elk programma voordat u ervan afhankelijk wordt, aangezien deze programma's veranderen en geen van deze partijen verplicht is u toegang te verlenen.

De gepubliceerde vereisten van Google voor bulkverzenders, die sinds februari 2024 van kracht zijn, vormen de duidelijkste openbare verklaring van wat een grote ontvanger tegenwoordig verwacht. Een verzender die meer dan 5000 berichten per dag naar persoonlijke Gmail-accounts stuurt, moet authenticeren met SPF en DKIM, een DMARC-beleid publiceren, een afmeldmogelijkheid met één klik bieden voor bulkmail en het spamklachtenpercentage onder de 0,3 procent houden. Persoonlijke e-mail vanaf een kleine server blijft ver onder die drempel, maar dezelfde signalen worden bij elk volume geanalyseerd. Het klachtenpercentage is de factor die u niet kunt inzien zonder een feedback loop.

De splitsing die werkt: zelf hosten voor ontvangst, relay voor uitgaand verkeer

Ontvangst is het gedeelte met vrijwel geen nadelen. Niemand hoeft u te vertrouwen om e-mail te accepteren die naar u is verzonden. Uw MX-record, het DNS-record dat de mailserver voor uw domein aanwijst, wijst naar uw server. Afzenders maken verbinding met u en elke beslissing daarna is aan u: wat u bewaart, hoe lang, hoe het wordt geïndexeerd en wie het mag doorzoeken. Opslag is goedkoop en een archief dat u in eigen beheer heeft, kan niet door een geautomatiseerd beleidsbesluit elders worden afgesloten. Het werk is reëel en begrensd: houd het spamfilter bijgewerkt, zorg voor de vernieuwing van TLS (transport layer security)-certificaten, maak back-ups en voorkom dat de schijf vol raakt.

Bij uitgaand verkeer koopt u zich vrij van het complexe probleem. Configureer uw server om elk uitgaand bericht door te sturen naar een geauthenticeerde relay op poort 587, in plaats van zelf via poort 25 met de rest van de wereld te communiceren. In main.cf van Postfix:

relayhost = [smtp.relay.example]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

Schrijf de inloggegevens met een editor in /etc/postfix/sasl_passwd, zodat het wachtwoord nooit in uw shell-geschiedenis terechtkomt. Het is één regel en de host aan de linkerzijde moet exact zo worden geschreven als deze in relayhost voorkomt:

[smtp.relay.example]:587 username:password

sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd.db
sudo systemctl reload postfix

Een bericht dat na die herlading wordt verzonden, logt relay=smtp.relay.example[...]:587 en status=sent. Een logregel met de tekst SASL authentication failed betekent dat de inloggegevens niet werden geaccepteerd. De gebruikelijke oorzaak is een hostnaam in sasl_passwd die anders is geschreven dan die in relayhost, omdat de opzoekactie een exacte tekenreeksvergelijking is.

Deze splitsing werkt omdat de relay eigenaar is van adressen met jarenlange geaccepteerde e-mail en het onderhouden van die reputatie hun volledige bedrijfsmodel is. U behoudt het domein, de mailboxen, het archief en de mogelijkheid om over te stappen, aangezien het wijzigen van een relay slechts één configuratieregel en één DNS-record vereist. Wat u opgeeft, is de vertrouwelijkheid van uitgaande e-mail ten opzichte van de relay-operator. Dat is de eerlijke prijs van deze opzet, en het is beter om die bewust te bepalen dan er achteraf achter te komen.

Het is de moeite waard om vanaf de eerste dag nog een scheiding aan te brengen. Alles wat bulk is, moet worden verzonden vanaf een eigen subdomein met een eigen DKIM-sleutel: news.example.com voor een nieuwsbrief en mail.example.com voor persoonlijke e-mail. Reputatie is gekoppeld aan het verzendende domein, waardoor een klachtenpercentage bij een zelf-gehoste Listmonk-nieuwsbrief uw persoonlijke e-mail niet kan schaden.

Wanneer is volledig zelf hosten nog steeds de juiste keuze?

Volume. Prijzen per bericht zijn acceptabel bij honderden berichten per maand, maar worden onbetaalbaar bij miljoenen. Op die schaal kunt u zich toegewezen adressen en het opwarmingsschema veroorloven dat nodig is om ze effectief te maken.

Jurisdictie. Wanneer een regelgeving of contract vereist dat e-mail niet op de schijf van een derde partij mag staan, is de afleverkwaliteit niet de doorslaggevende factor. Een relay is dan simpelweg geen optie voor u.

Controle die niet te koop is. Bewaarbeleid dat aansluit bij uw eigen richtlijnen in plaats van bij een abonnementsvorm, een uniek adres per service zodat u kunt zien wie gegevens heeft gelekt, filtering die uw eigen code uitvoert, en geen accountschorsingen door een systeem zonder beroepsmogelijkheid.

E-mail die uw netwerk nooit verlaat. Waarschuwingen en andere machine-to-machine e-mail hebben geen enkel afleverprobleem, omdat beide uiteinden van u zijn. Een lokale SMTP-server die aflevert in uw eigen mailboxen is de volledige oplossing, en dit is hetzelfde patroon als bij het geven van een eigen zelf-gehoste mailbox aan een assistent via MCP (model context protocol).

Als u wel direct uitgaand verkeer verstuurt, warm het adres dan op. Begin met een laag dagelijks volume naar mensen die uw e-mail verwachten, verhoog dit geleidelijk over meerdere weken en verstuur nooit een grote hoeveelheid berichten vanaf een koud adres. Reputatie wordt opgebouwd door geaccepteerde e-mail met weinig klachten over een langere periode; een plotselinge piek vanaf een adres zonder historie ziet er precies uit als een gecompromitteerde server en wordt ook als zodanig behandeld.

Wat kost het eerste jaar van het draaien van een mailserver?

Week één is de opbouw: pakketten, DNS-records, TLS-certificaten, de eerste testberichten, DMARC op p=none.

Week twee tot en met zes zijn het deel waar niemand rekening mee houdt. U leest de DMARC-aggregatierapporten, vindt het uitlijningsprobleem waarvan u niet wist dat u het had, ontdekt de forwarder die SPF breekt, en verplaatst het beleid vervolgens naar p=quarantine en later naar p=reject. Deze periode bepaalt of self-hosting een routine voor u wordt of iets waar u een hekel aan krijgt.

Daarna stabiliseert het zich op ongeveer een uur per maand: pakketupdates, een certificaatvernieuwing die u verifieert in plaats van aanneemt, een hersteltest vanaf een back-up, een blik op de schijfgroei, één blocklist-opzoeking.

Dan is er de week die u niet kunt inplannen. Een adres wordt geblokkeerd voor iets wat u niet heeft gedaan. Een grote ontvanger wijzigt een regel en uw mail belandt weer in de spam. In de wachtrij geplaatste mail is geen verloren mail: Postfix probeert een uitgesteld bericht standaard vijf dagen lang opnieuw te verzenden, ingesteld via maximal_queue_lifetime = 5d, dus een storing die in uren wordt gemeten kost u alleen latentie en niets anders. Een storing die in een week wordt gemeten kost u mail.

Een backup MX-record is een zwakker antwoord daarop dan het lijkt. Verzenders proberen het zelf al dagenlang opnieuw, dus een secundaire server die alleen in de wachtrij plaatst, voegt weinig toe. Erger nog, een secundaire server die mail voor uw domein accepteert zonder te weten welke adressen bestaan, zal mail aannemen voor adressen die niet bestaan en deze vervolgens terugsturen naar vervalste afzenders, wat uw back-up verandert in een bron van backscatter. Besteed de inspanning aan monitoring en aan een herstelprocedure die u daadwerkelijk heeft getest.

Beoordeel het geheel met de vraag die u op alles op de server zou toepassen: levert het bezit hiervan u iets op dat u niet kunt kopen? Voor mailboxen en het archief is het antwoord meestal ja. Voor uitgaande bezorging aan vreemden is het meestal nee. Dat is dezelfde test die de rest van de lijst met zaken die het waard zijn om in 2026 zelf te hosten sorteert.

FAQ

Kan ik e-mail zelf hosten als mijn VPS-provider uitgaand poort 25 blokkeert?

Ja, voor het ontvangen van e-mail en voor het verzenden via een relay. Inkomende e-mail komt aan op poort 25 van uw server; een blokkade op uitgaand verkeer heeft hier geen invloed op. Uitgaande e-mail verlaat de server vervolgens via een geauthenticeerde relay op poort 587, wat providers niet blokkeren. Wat u niet kunt doen met een gesloten poort 25, is rechtstreeks afleveren bij andere mailservers, omdat server-naar-server-aflevering per definitie op poort 25 plaatsvindt. Test dit met nc -vz gmail-smtp-in.l.google.com 25. Een hangend proces gevolgd door een timeout betekent dat de poort is geblokkeerd.

Waarom belandt mijn e-mail in de spam, ook al zijn SPF, DKIM en DMARC in orde?

Authenticatie bewijst wie een bericht heeft verzonden. Het bewijst niet dat het bericht gewenst is. Het slagen voor alle drie de controles brengt u van ongeïdentificeerd naar geïdentificeerd. Daarna beoordeelt de ontvanger de reputatie van uw IP-adres en domein, die een nieuwe verzender nog niet heeft. Bouw deze reputatie op door gedurende enkele weken kleine volumes e-mail te versturen die mensen verwachten. Controleer vervolgens of het PTR-record in beide richtingen overeenkomt met uw mail-hostname en controleer of de inhoud geen eigen strafpunten toevoegt, zoals link-shorteners of een onbekend tracking-domein.

Heb ik een dedicated IP-adres nodig voor een zelfgehoste mailserver?

Voor directe uitgaande aflevering wel. Een mailserver heeft een adres nodig waarvan u het PTR-record beheert en waarvan de reputatie alleen aan u toebehoort; een VPS-adres is in die zin al dedicated. Wat u niet beheert, is de geschiedenis ervan of de buren in hetzelfde netwerkblok. Als u uitgaande e-mail via een relay verstuurt, dragen de adressen van de relay de reputatie en hoeft het uwe alleen inkomende verbindingen te accepteren.

Is het veilig om mijn hoofd-e-mailadres te verhuizen naar een zelfgehoste server?

Verhuis in fasen in plaats van in één keer. Houd de bestaande mailbox actief, voeg uw eigen server toe als tweede bestemming en stuur gedurende enkele weken een kopie door terwijl u DMARC-rapporten leest en bevestigt dat e-mailstromen in beide richtingen werken. Wijzig het MX-record pas nadat er een week lang testmail correct is aangekomen. De fout waar mensen spijt van krijgen, is een overstap waarbij inkomende e-mail verloren gaat; inkomende e-mail is het deel dat niet kan worden gereconstrueerd.

Wat is de kleinste opzet waarmee ik de controle over mijn e-mail behoud?

Uw eigen server voor de mailboxen en het archief, waarbij uitgaande e-mail wordt overgedragen aan een geauthenticeerde relay op poort 587. U bent eigenaar van de data en het domein, en u omzeilt het reputatieprobleem volledig. De kosten van een eventuele koerswijziging blijven laag, omdat de relay slechts één configuratieregel en één SPF-vermelding vereist; het later vervangen ervan is dus een middag werk.