Post die je vanuit Ascensie verstuurt gaat vanaf jouw eigen adres de deur uit, niet vanaf een adres van ons. Dat vraagt wat werk aan de voorkant: je moet bewijzen dat het domein van jou is. Hieronder staat wat er gebeurt, waarom die stappen bestaan, en wat wij doen met de signalen die daarna terugkomen.
Waarom het domein ertoe doet
Een ontvanger die naam@jouwbedrijf.nl ziet staan weet met wie hij te maken heeft. Een ontvanger die een onbekend adres van een tussenpartij ziet, weet dat niet, en zijn mailserver ook niet.
Mailservers beslissen grotendeels op reputatie, en die reputatie hangt aan het domein dat de post ondertekent. Post vanaf je eigen geverifieerde domein bouwt geschiedenis op waar jij iets aan hebt. Post vanaf een gedeeld adres deelt die geschiedenis met iedereen die dat adres ook gebruikt, inclusief degene die vorige week een gekochte lijst heeft gemaild.
Het domein verifiëren
Je meldt je domein aan in de instellingen en krijgt een set DNS-records terug die je bij je domeinbeheerder zet. Er moeten drie dingen kloppen voordat je mag versturen.
DKIM. Drie CNAME-records die verwijzen naar sleutels die voor jouw domein zijn aangemaakt. Daarmee krijgt elk bericht dat uitgaat een handtekening die de ontvanger kan narekenen. Klopt de handtekening, dan staat vast dat het bericht onderweg niet is aangepast en dat het echt van dit domein komt.
Een eigen retourpad. Een subdomein met een eigen MX-record en een eigen SPF-regel, waar de meldingen over onbestelbare post naartoe gaan. Dit is een tweede verificatie, los van DKIM, en die twee kunnen dagenlang op een verschillend punt staan. Beide moeten groen zijn.
Een verificatierecord van ons. Eén TXT-record met een waarde die per aanmelding wordt aangemaakt. Dat is nodig omdat Amazon per domein één identiteit kent: zonder dat extra record zou het antwoord "dit domein is geverifieerd" ook gelden voor iemand die het domein alleen maar heeft ingetikt. Een domein kan bij ons dan ook maar bij één account tegelijk actief zijn, en dat wordt in de database afgedwongen en niet in een formulier.
SPF, DKIM en DMARC, in gewone taal
Alle drie beantwoorden ze een andere vraag over hetzelfde bericht.
SPF zegt: welke servers mogen post versturen namens dit domein. Het is een lijst met afzenders, gepubliceerd in DNS.
DKIM zegt: dit bericht is ondertekend met een sleutel die bij dit domein hoort, en de inhoud is onderweg niet gewijzigd.
DMARC zegt: wat moet je doen als het niet klopt. Het bindt SPF en DKIM aan het domein dat de ontvanger in de afzenderregel ziet, en het vertelt de ontvangende server of hij zo'n bericht moet weigeren, in de map ongewenst moet zetten, of alleen moet rapporteren.
DKIM en het eigen retourpad regel je bij het verifiëren. DMARC publiceer je zelf, en dat is aan te raden: zonder DMARC-beleid kan iemand anders in jouw naam mailen zonder dat er iets tegen hem in stelling wordt gebracht. Begin met een beleid dat alleen rapporteert, lees de rapporten, en verscherp daarna.
Bounces en klachten zijn geen ruis
Zodra je verstuurt komen er signalen terug, en dat zijn de belangrijkste gegevens die je over je post krijgt. Wij ontvangen ze direct van Amazon zodra ze ontstaan.
Een harde bounce betekent dat het adres niet bestaat. Een zachte bounce betekent dat het vandaag niet lukte: postvak vol, server even weg. Een klacht betekent dat iemand op de spamknop heeft gedrukt.
Die drie zeggen iets heel verschillends, en behandelen ze als één ding gaat op twee manieren mis. Blijf je mailen naar adressen die niet bestaan, dan leest elke ontvangende partij dat als het gedrag van iemand die zijn lijst niet onderhoudt, en dat kost je binnen weken je bezorging. Behandel je omgekeerd een volle mailbox als een dood adres, dan verdwijnen echte klanten geruisloos uit je lijst.
Wat wij ermee doen
Een harde bounce zet het adres op de onderdrukkingslijst. Er gaat geen post meer heen tot jij dat terugdraait.
Een zachte bounce doet dat niet. Die wordt wel geregistreerd, zodat je een adres dat het structureel niet doet kunt terugvinden, maar hij snoeit je lijst niet weg.
Een klacht onderdrukt altijd. Iemand die op de spamknop drukt heeft gezegd dat hij niets meer wil ontvangen, en dat is het einde van de discussie.
Die onderdrukkingslijst is van jouw account alleen, en je kunt hem inzien. Bij elk adres staat waarom het erop staat. Dat je hem zelf ziet is belangrijk: een lijst die stilletjes groeit verklaart niet waarom een campagne minder mensen bereikte dan je dacht.
Het filteren gebeurt op één plek in de verzendcode, vlak voordat er wordt verstuurd. Eén plek is te bewijzen; twee plekken is één plek die iemand kan vergeten.
Afmelden staat bovendien in elke mailing, en een afmelding komt op dezelfde lijst terecht als een klacht. Wachten tot iemand de spamknop gebruikt is de duurste manier om erachter te komen dat hij weg wilde.
Iedere klant een eigen reputatie
Uitgaande post loopt via Amazon SES, in de regio Frankfurt. Elk account krijgt daar een eigen afgescheiden ruimte met een eigen onderdrukkingslijst.
Dat is precies de reden dat we voor deze opzet hebben gekozen. Cijfers over bezorging, bounces en klachten worden per klant gemeten. Gaat er bij één klant iets mis, dan is dat zichtbaar bij die klant en is die klant te stoppen zonder dat iemand anders er last van heeft. Naast onze eigen cijfers halen we ook de aanbevelingen van Amazon op, bijvoorbeeld dat er een DMARC-record ontbreekt of dat een bouncepercentage te hoog wordt. We tonen die twee apart en niet als één getal, want ze meten niet hetzelfde.
En post die binnenkomt
Ontvangen werkt op dezelfde gedachte. Je wijst een subdomein van je eigen domein aan en zet daar een MX-record op. Post die daarheen gaat komt in je gedeelde postvak terecht, bij het contact waar hij bij hoort. Bij welk account een bericht hoort bepalen we op het adres waaraan het werkelijk is afgeleverd, niet op wat er in de kopregels staat, want blind verstuurde post noemt zijn ontvanger daar helemaal niet.
Er is geen koppeling met Gmail of Outlook, en die komt er ook niet. Een MX-record werkt bij elke provider en blijft van jou.