E-mailverificatie is het proces waarbij de identiteit van een e-mailafzender wordt geverifieerd en ervoor wordt gezorgd dat er tijdens de verzending niet met de e-mail is geknoeid. Als ontwikkelaar is het essentieel om de verschillende e-mailverificatiemethoden te begrijpen en ze correct te implementeren om e-mailfraude te voorkomen en de deliverability van e-mails te verhogen. In deze blog verkennen we de verschillende e-mailverificatiemethoden en hoe u ze als ontwikkelaar kunt implementeren.

Waarom e-mailverificatie belangrijk is?

E-mailverificatie voor ontwikkelaars is een proces dat ervoor zorgt dat e-mails die vanaf uw domein worden verzonden, legitiem zijn. Laten we eens kijken naar de top 5 redenen om in deze protocollen te investeren.

1. Verlaagd bouncepercentage

E-mailverificatie helpt de deliverability van e-mails te verbeteren door e-mailadressen in de database te controleren en realtime tests uit te voeren om te weten of de accounts actief of slapend zijn. Het verkleint de kans dat uw e-mails in de inbox van de gewenste ontvangers terechtkomen. 

2. Nauwkeurige inzichten

Naarmate uw mailinglijst wordt opgeschoond met behulp van de tools, krijgt u betrouwbare en bruikbare analyses van uw marketingcampagnes.

3. Bespaart geld

U moet geld uitgeven aan de opslag van e-mails en het beheer van een database om berichten te versturen. Wanneer ontwikkelaars de protocollen in hun toepassingen implementeren, wordt de e-maillijst opgeruimd en neemt de omvang van uw database af, wat geld bespaart. 

4.Hoge ROI

Een gedetailleerd begrip van e-mailverificatie voor ontwikkelaars helpt het bounce-backpercentage te verlagen, waardoor u een betere ROI krijgt. E-mail bounces betekenen een verspilling van de in e-mailmarketing geïnvesteerde bedragen.

5. Minder spamklachten van klanten en prospects

In 2022 zal maar liefst 49% van de e-mails wereldwijd als spam gemarkeerd. Idealiter moeten de spamklachten minder dan vijf zijn voor elke 5000 e-mailberichten die vanaf een account worden verzonden. Het e-mailverificatieproces markeert spamberichten en stelt u op de hoogte zodat u tijdig actie kunt ondernemen om dit te beheersen.

Wat is SPF?

E-mailverificatie voor ontwikkelaars begint met het begrijpen en implementeren van SPF of Sender Policy Framework. Dit protocol werkt door u te vragen een lijst te maken en bij te werken van servers die e-mails mogen versturen met uw domeinnaam. De lijst wordt toegevoegd aan de DNS-server van waaruit de servers van de ontvangers controleren of de server van een afzender al dan niet deel uitmaakt van de lijst. Alle e-mails die worden verzonden vanaf IP-adressen die niet op de lijst staan, falen in de SPF e-mailverificatie.

Dit alles vereist een SPF-record, een TXT-record waarmee beheerders willekeurige teksten in DNS kunnen invoeren. 

Wat zijn SPF Record Tags?

Tag	Doel
Versie (v)	Het vertegenwoordigt de SPF-versies en moet de eerste tag zijn in een SPF-record.
mx	Het mx record specificeert welke server verantwoordelijk is voor het accepteren van e-mails namens het domein. Het heeft een IP-adres en een prioriteitswaarde voor elke server voor het accepteren van berichten.
a	Het wordt gebruikt wanneer u een A of AAAA record opvraagt in een domein met het IP adres van de afzender.
ptr	Ptr tag gebruikt de omgekeerde hostnaam of subdomein van het verzendende IP-adres om de doeldomeinnaam te specificeren. Het wordt alleen gebruikt als er één MX record is. Het gebruik van deze tag wordt NIET aanbevolen volgens RFC 7208.
ip4	Het vertelt een IPv4 IP adres of IP CIDR Range die mail mag versturen vanaf uw domein.
ip6	Het vertelt een IPv6 IP-adres of IP CIDR Range die is toegestaan om e-mails van uw domein te versturen.
omvatten	Met deze tag kunnen app-ontwikkelaars het volledige SPF-record van een ander domein of subdomein opnemen. U moet het gebruiken wanneer een dienst van derden namens u e-mails verstuurt.
bestaat	Deze tag kijkt of er een A-record bestaat. Je ziet de 'pass' resultaten als het er is.
alle	Deze tag wordt toegevoegd aan het einde van een SPF TXT record. Het specificeert instructies over hoe uw e-mails moeten worden behandeld als er geen match is met uw SPF record. Er zijn 3 veel gebruikte opties waarmee een verzender de gebruiker kan vertellen om mail te weigeren die wel overeenkomt met het record (-all), mail te behandelen als verdacht (~all), en een neutrale aanbeveling te doen (?all) die het aan de ontvanger overlaat.

Beperkingen en uitdagingen van SPF

SPF is niet voldoende om alle vormen van phishing en spamming aanvallen die in naam van uw bedrijf worden uitgevoerd. Bij het leren over e-mailverificatie voor ontwikkelaars moet u zich dus concentreren op het begrijpen van de beperkingen van SPF beperkingen.

Er is een limiet van 10 lookups die is geïmplementeerd om overbelasting van de validatiebronnen van een DNS-server, zoals bandbreedte en CPU, te voorkomen. Zodra de limiet is bereikt, zal uw mailserver niet verder verwerken, en krijgt u een SPF Permerror. Overschrijding van deze limiet veroorzaakt problemen met de bezorgbaarheid van e-mail, doordat de kans afneemt dat e-mails in de inbox van de gewenste ontvangers terechtkomen. U kunt binnen de limiet blijven door:

• Ongebruikte diensten verwijderen
• Verwijderen van de standaard SPF-waarden
• Vermijden van het gebruik van het ptr-mechanisme
• Het gebruik van het mx-mechanisme vermijden
• IPv6 of IPv4 gebruiken
• Uw SPF-record niet afvlakken

Een andere beperking is dat SPF-records worden toegepast op specifieke Return-Path-domeinen en niet op het Van-adres. Bedreigers maken gebruik van dit zwakke punt in de cyberbeveiliging om phishing-aanvallen uit te voeren door het Van-adres te vervalsen.

Wat is DKIM?

DKIM staat voor DomainKeys Identified Mail, een protocol dat e-mails authenticeert met behulp van de encryptiemethode. Een domeinbeheerder voegt een DKIM record toe aan DNS en ontvangt een paar publieke en private sleutels. De oorspronkelijke e-mailserver heeft geheime privé DKIM-sleutels, die door de ontvangende e-mailserver worden geverifieerd met de andere helft van het sleutelpaar, de publieke DKIM-sleutel. Deze DKIM-handtekeningen bewegen mee met de e-mails en werken ook op doorgestuurde mailketens.

Wanneer DKIM alignment mislukt, wordt de e-mail deliverability rate van uw domein negatief beïnvloed, waardoor e-mails in de spamfolder belanden of door de mailbox van de ontvanger worden geweigerd. 

Wat zijn DKIM Tags?

Er zijn vele informele elementen als onderdeel van de DKIM tag cluster. Deze worden ingedeeld in verplichte en optionele tags. Wij bespreken hier het gebruik van verplichte tags; klik hier om andere tags in detail te leren kennen.

Vereiste tags

Deze tags zijn nodig voor verificatie, aangezien de mailboxen van de ontvangers e-mails zonder tags weigeren.

• v= De versie-tag die de gebruikte DKIM-standaard vertegenwoordigt. De waarde is altijd 1.
• a= Deze DKIM tag vertegenwoordigt het cryptografische algoritme dat wordt gebruikt om de handtekening te maken. Over het algemeen is de waarde rsa-sha256. Als uw computer minder CPU mogelijkheden heeft, kunt u rsa-sha1 gebruiken. Experts raden het gebruik daarvan af vanwege de zwakke plekken in de beveiliging.
• s= deze tag specificeert de selector record naam die wordt gebruikt voor het vinden van de publieke sleutel in de DNS van een domein. Domeinbeheerders of app-ontwikkelaars moeten in dit veld een naam of een getal invoeren.
• d= U ziet het domein dat met het selectorrecord wordt gebruikt om publieke sleutels te lokaliseren. Het gebruikt dezelfde waarde als de door de afzender gebruikte domeinnaam.
• b= Deze DKIM tag wordt gebruikt voor de hash gegevens van de header. Het wordt gewoonlijk gekoppeld aan de h= tag voor het opstellen van de DKIM handtekening. Het is altijd gecodeerd in Base64.
• bh= Deze verplichte DKIM tag heeft de berekende hash van e-mails waarvan de waarde een tekenreeks is die een door een algoritme bepaalde hash aangeeft.
• h= Deze tag bevat de headers die in het ondertekeningsalgoritme worden gezien om de hash in de b=tag te genereren. De waarde ervan kan niet worden verwijderd of gewijzigd.

Beperkingen en uitdagingen van DKIM

Legitieme e-mails die vanaf uw domein worden verzonden, kunnen soms door mobiele apparaten worden geweigerd als het bericht wordt doorgestuurd. De server van de ontvanger identificeert ze als vervalste berichten wanneer ze de authenticatie-instructies lezen. 

Wat is DMARC?

Het laatste onderdeel van het begrip van e-mailverificatie voor ontwikkelaars is het leren over DMARC of Domain-based Message Authentication, Reporting, and Conformance. Het werkt in combinatie met SPF en/of DKIM resultaten om te bepalen hoe om te gaan met e-mails die de e-mailverificatiecontroles niet doorstaan. U kunt uw DMARC beleid op p=none (er wordt geen actie ondernomen tegen de mislukte e-mails), p=quarantaine (mislukte e-mails worden gemarkeerd als spam), of p=reject (de invoer van mislukte e-mails wordt geweigerd).

U kunt beginnen met uw beleid in te stellen op 'geen' om te controleren of alle legitieme e-mails de verificatiecontroles doorstaan. Later kunt u het opnieuw instellen op 'quarantaine' of 'afwijzen'.

Wat zijn DMARC Tags?

Als domeineigenaar kunt u het volgende specificeren DMARC tags in uw DMARC record-

• v: Geeft de versie van het DMARC-protocol aan en heeft altijd de waarde v=DMARC1.
• pct: Deze tag geeft aan welk percentage van de e-mails voldoet aan de beleidsmodus.
• p: De tag p heeft betrekking op de DMARC-beleidsmodus. U kunt kiezen uit weigeren, quarantaine en geen.
• rua: Deze optionele tag geeft het e-mailadres of de webserver aan waar rapporterende organisaties hun DMARC aggregate rua gegevens naartoe kunnen sturen.
• ruf: Geeft het adres aan waarnaar het DMARC forensisch ruf-rapport moet worden gestuurd.
• fo: het is een optionele tag die de beschikbare opties voor storings-/forensische rapportage aanpast waaruit domeineigenaars kunnen kiezen.
• aspf: Hiermee kunt u de SPF-uitlijningsmodus instellen. De waarde kan strikt(s) of ontspannen(r) zijn.
• adkim: Hiermee kunt u de DKIM-afstemmingsmodus instellen, waarvan de waarde strikt(s) of ontspannen(r) kan zijn.
• rf: Deze tag specificeert de verschillende formaten voor forensische rapportage.
• ri: Deze optionele DMARC tag heeft een standaardwaarde van 86400, en geeft het tijdsinterval in seconden aan tussen twee opeenvolgende geaggregeerde rapporten die door de rapporterende organisatie naar de eigenaar van het domein worden gestuurd.

Laatste woorden

E-mailverificatie voor ontwikkelaars is essentieel om op de hoogte te blijven van phishing- en spamaanvallen die in uw naam worden uitgevoerd. Begin met het genereren van SPF-, DKIM- en DMARC-records voor uw officiële domein voor e-mailverzending met behulp van onze PowerToolbox.