Benodigde licentie
| Abonnement | Elk abonnement |
| Toegang | Admin |
Drie DNS-records bepalen of je antwoorden in de inbox of in de spammap belanden. Twee zijn verplicht en de derde is het hebben waard.
Wat elk doet
- SPF somt op wie er post mag versturen voor jouw domein. Zendesk moet in die lijst staan.
- DKIM ondertekent elk bericht, zodat de ontvanger kan vaststellen dat het niet is gewijzigd en werkelijk van jou komt. Anders dan SPF gaat deze er als CNAME-records in en niet als TXT-record, en daar gaat het geregeld mis.
- DMARC vertelt ontvangers wat ze moeten doen als die eerste twee falen, en kan je rapportages sturen. Begin op p=none, wat meekijkt zonder iets te weigeren, en ga pas naar p=quarantine of p=reject als de rapportages laten zien dat je legitieme post, die van Zendesk inbegrepen, door SPF en DKIM komt. Meteen op reject beginnen is hoe een bedrijf zijn eigen post blokkeert.
Ze instellen
- Open het Beheercentrum, dan Kanalen, dan Spraak en e-mail, dan E-mail.
- Zoek de records die Zendesk voor jouw domein toont.
- Voeg ze toe bij je DNS-provider.
- Wacht tot ze zijn doorgevoerd. Zendesk rekent op maximaal 48 uur voordat een gewijzigd record verifieert, dus een controle dezelfde middag die niets oplevert is geen storing.
- Ga terug naar Zendesk en verifieer ze.
De SPF-fout
Een domein mag maar één SPF-record hebben. Heb je er al een voor je eigen post, dan wordt Zendesk daaraan toegevoegd en niet apart gepubliceerd. Twee SPF-records is slechter dan geen, want ontvangers zien dat als fout en negeren ze allebei.
Dat toevoegen in plaats van apart publiceren heeft één gevolg: een SPF-record mag hooguit tien DNS-lookups oplossen, en elke include verbruikt er daarvan een paar. Een domein dat al via een mailprovider, een nieuwsbrieftool en een CRM verstuurt, kan over dat plafond gaan zodra Zendesk erbij komt, en dan faalt het record terwijl het er volkomen redelijk uitziet.
De include die je gebruikt is mail.zendesk.com, dus een domein dat alleen via Zendesk verstuurt leest zo:
v=spf1 include:mail.zendesk.com -all
Kijk na wat je hebt geërfd. Twee oudere includes duiken nog op in records van jaren terug: smtp.zendesk.com en support.zendesk.com. Die zijn verouderd, en Zendesk markeert ze als zodanig in plaats van ze te laten falen, dus een account kan jarenlang een record hebben dat technisch werkt en niet het record is dat het zou moeten zijn.
Per domein, niet per account
Elk domein waarvandaan je verstuurt heeft eigen records nodig. Een tweede merk op een ander domein betekent dit opnieuw doen, en dat vergeten is waarom de post van een nieuw merk in de spam belandt terwijl die van het eerste merk gewoon aankomt.
Waarom het niet optioneel is
Grote mailproviders weigeren of filteren niet-geauthenticeerde post steeds vaker meteen. Zonder deze records komt een groeiend deel van je antwoorden nooit aan, en niemand vertelt het je: de klant denkt dat je niet hebt geantwoord.
Er is nu een tweede reden, en die wijst de andere kant op. Zendesk controleert de authenticatie ook op binnenkomende post, doorgestuurde post inbegrepen. Staat die controle al aan, dan geldt hij meteen. Staat hij uit, dan begint Zendesk hem vanaf 23 september 2026 aan te zetten. Dezelfde records die bepalen of je antwoorden aankomen, bepalen dus ook of post die vanaf je eigen domein wordt doorgestuurd in je wachtrij belandt in plaats van in de geschorste lijst. Eén set records, twee richtingen.
DNS wordt vaak elders in de organisatie beheerd. Stuur ons de records die Zendesk je gaf, dan helpen we jou en je DNS-beheerder ze in één keer goed te krijgen.
Opmerkingen
0 opmerkingen
Artikel is gesloten voor opmerkingen.