E-mail bezorgbaarheid in Joomla
Je kunt de mailinstellingen van Joomla perfect configureren, versturen via een goede SMTP-server, en toch zien hoe je berichten in de spammap belanden. Als dat gebeurt, ligt de oorzaak bijna nooit binnen Joomla. Hij zit in de DNS van je domein, in drie kleine tekstrecords die bepalen of de ontvangende mailserver je vertrouwt: SPF, DKIM en DMARC.
Dit artikel is de uitgebreide aanvulling op het Focus On-artikel over E-mail en Joomla. Dat artikel legt uit hoe je mail verstuurt; dit artikel legt uit hoe je je mail afgeleverd krijgt. Het behandelt wat DNS is en hoe mail je server vindt, de drie authenticatierecords in detail, de uitlijningsregel waar zoveel mensen over struikelen, reverse DNS en andere signalen, de exacte records voor Google en Microsoft 365, en hoe je alles achteraf verifieert.
Mail versturen is een Joomla-instelling. De inbox bereiken is een DNS-project.
Het doel is om eigenaren, beheerders en ontwikkelaars genoeg begrip van e-mailauthenticatie te geven om het een keer goed in te stellen, te bewijzen dat het werkt, en te stoppen met raden waarom mail verdwijnt.
1. De basis: DNS en e-mail
E-mailauthenticatie is volledig gebouwd op DNS, dus een korte opfrisser loont voordat we SPF aanraken.
1.1 Wat DNS is
DNS (Domain Name System) is het telefoonboek van het internet. Het koppelt een domeinnaam aan adressen en bewaart kleine records over het domein. Je bewerkt DNS niet in Joomla. Je bewerkt het daar waar je domein wordt beheerd: bij je registrar, in je hosting-controlepaneel, of bij een DNS-dienst zoals Cloudflare.
1.2 De records die belangrijk zijn voor mail
| Record | Taak bij e-mail |
|---|---|
MX |
Noemt de server die mail voor je domein ontvangt. |
TXT |
Bevat SPF, DKIM en DMARC als tekst. Bijna alle authenticatie woont hier. |
A / AAAA |
Koppelt een hostnaam aan een IPv4- / IPv6-adres. |
PTR |
Omgekeerde lookup: koppelt een verzendend IP terug aan een hostnaam. |
CNAME |
Een alias naar een andere hostnaam; sommige providers gebruiken het voor DKIM. |
SPF, DKIM en DMARC worden allemaal gepubliceerd als TXT-records (een paar providers gebruiken CNAME voor DKIM). Ze beschermen uitgaande mail. Het MX-record is het aparte record dat je domein naar zijn inkomende mailserver wijst.
1.3 Twee getallen om te kennen: TTL en propagatie
Elk DNS-record heeft een TTL (Time To Live), het aantal seconden dat andere servers het mogen cachen. Nadat je een record wijzigt, kan de oude waarde blijven hangen totdat de TTL verloopt. Dit heet propagatie. Houd er rekening mee dat wijzigingen overal van minuten tot een dag kunnen duren om zichtbaar te worden, en verlaag de TTL voor een geplande wijziging zodat de omschakeling sneller gaat.
Naar boven2. De drie records in een oogopslag
Voordat we de details ingaan, hier het hele plaatje op een plek. Elk record beantwoordt een andere vraag voor de ontvangende server.
| Record | Beantwoordt de vraag | Waar je het vandaan haalt |
|---|---|---|
| SPF | Mag deze server versturen namens het domein? | Je schrijft het zelf en somt je verzenders op. |
| DKIM | Is de handtekening geldig en het bericht ongewijzigd? | Je mailprovider geeft je het record. |
| DMARC | Als SPF of DKIM faalt, wat moet ik doen, en meld het aan de eigenaar. | Je schrijft het beleid zelf. |
Inkomend bericht beweert van jou te zijn
└─ SPF → is het verstuurd vanaf een goedgekeurde server?
└─ DKIM → is de cryptografische handtekening geldig?
└─ DMARC → slagen SPF of DKIM EN lijnen ze uit met het From-domein?
zo niet, pas het beleid toe (none / quarantine / reject)Het cruciale idee dat ze aan elkaar bindt is uitlijning, behandeld in sectie 5. Onthoud voor nu dat DMARC geen vierde controle is die erbij is geplakt; het is de scheidsrechter die de resultaten van SPF en DKIM leest en een regel afdwingt.
Naar boven3. SPF: je verzenders autoriseren
SPF (Sender Policy Framework) is een openbare lijst van de servers die mail mogen versturen namens je domein. Wanneer een bericht binnenkomt, controleert de ontvanger of de verzendende server op die lijst staat.
3.1 Hoe een SPF-record eruitziet
Type: TXT
Name: @ (de root van je domein)
Value: v=spf1 include:_spf.google.com ~allHet begint altijd met v=spf1 en eindigt met een all-regel. Daartussen staan een of meer mechanismen die goedgekeurde verzenders benoemen.
3.2 De gangbare mechanismen
| Mechanisme | Betekenis |
|---|---|
include:domain |
Vertrouw ook de verzenders die door dat domein worden opgesomd (gebruikt door Google, Microsoft, Brevo, enzovoort). |
ip4:1.2.3.4 |
Vertrouw dit exacte IPv4-adres (je eigen mailserver). |
ip6:... |
Vertrouw dit IPv6-adres. |
a |
Vertrouw het IP uit het eigen A-record van het domein. |
mx |
Vertrouw de servers in de MX-records van het domein. |
3.3 Soft fail versus hard fail: de all-regel
Het laatste all-mechanisme bepaalt wat er gebeurt met elke server die er niet boven is gematcht. De kwalificator ervoor is wat telt:
| Einde | Naam | Effect op niet-vermelde verzenders |
|---|---|---|
~all |
Soft fail | Accepteren, maar markeren als verdacht. Veilig om mee te beginnen. |
-all |
Hard fail | Weigeren. De strenge, aanbevolen eindtoestand. |
+all |
Alles toestaan | Gebruik dit nooit; het autoriseert het hele internet. |
Begin met ~all terwijl je bevestigt dat elke legitieme verzender vermeld staat, en verstevig daarna tot -all zodra je zeker bent.
3.4 Twee harde limieten
SPF heeft twee regels die opstellingen stilletjes breken:
- Slechts een record. Een domein mag precies een SPF TXT-record hebben. Als je er een tweede toevoegt wanneer je een nieuwe provider gaat gebruiken, worden ze allebei ongeldig. Voeg in plaats daarvan de
include:-waarden samen in een enkel record. - Tien DNS-lookups. SPF staat tijdens de evaluatie maximaal tien DNS-lookups toe. Elke
include:kan er meer veroorzaken. Koppel te veel providers en SPF geeft een permanente fout terug, wat als een mislukking telt. Als je hiertegenaan loopt, gebruik dan SPF-flattening: vervang sommigeinclude:-waarden door de daadwerkelijkeip4:-reeksen, of gebruik een provider die je aantal lookups laag houdt.
4. DKIM: je mail ondertekenen
DKIM (DomainKeys Identified Mail) voegt aan elk bericht een fraudebestendige handtekening toe. Waar SPF de server controleert, controleert DKIM het bericht zelf.
4.1 Hoe het werkt
DKIM gebruikt een sleutelpaar. Je verzendende dienst heeft een privesleutel en ondertekent elk uitgaand bericht daarmee. Je publiceert de bijbehorende publieke sleutel in DNS. De ontvanger haalt de publieke sleutel op, controleert de handtekening en bevestigt twee dingen: de mail kwam echt van je domein, en niemand heeft hem onderweg gewijzigd.
Jij verstuurt → provider tekent met privesleutel → DKIM-Signature header toegevoegd
Ontvanger → leest de handtekening, haalt je publieke sleutel op uit DNS → verifieert4.2 Selectors
Een domein kan meerdere DKIM-sleutels tegelijk hebben (voor verschillende providers, of voor sleutelrotatie). DKIM houdt ze uit elkaar met een selector, een korte naam in de handtekening. De selector wijst naar het exacte DNS-record dat die sleutel bevat:
Handtekening bevat: s=selector1
DNS-record staat op: selector1._domainkey.yourdomain.comJe verzint deze bijna nooit met de hand. Je mailprovider (Google, Microsoft 365, Brevo, enzovoort) laat je het exacte record zien dat je moet plakken, inclusief de selector. Jouw taak is om het getrouw in DNS over te nemen.
4.3 Een praktische opmerking
DKIM-records zijn lang en gemakkelijk te beschadigen bij het kopieren. Een enkel ontbrekend teken laat de handtekening falen. Plak zorgvuldig, voeg geen regeleindes of aanhalingstekens toe die de provider niet meegaf, en verifieer daarna met een controletool (sectie 8) voordat je erop vertrouwt.
Naar boven5. DMARC: het beleid en de uitlijning
DMARC (Domain-based Message Authentication, Reporting and Conformance) bindt SPF en DKIM samen. Het vertelt ontvangers wat ze moeten doen wanneer authenticatie faalt en vraagt hen om je rapporten te sturen.
5.1 Het record
Type: TXT
Name: _dmarc (een subdomein-label)
Value: v=DMARC1; p=none; rua=mailto:Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken. | Tag | Betekenis |
|---|---|
p |
Het beleid: none, quarantine of reject. |
rua |
Waar geaggregeerde (samenvattende) rapporten naartoe gestuurd worden. |
ruf |
Waar forensische (per-bericht) rapporten naartoe gestuurd worden, indien aangeboden. |
sp |
Een optioneel apart beleid voor subdomeinen. |
5.2 Uitlijning: het deel dat iedereen mist
Dit is het meest verkeerd begrepen punt in e-mailauthenticatie. DMARC vraagt niet alleen "is SPF of DKIM geslaagd?" Het vraagt "zijn ze geslaagd en komen ze overeen met het domein in het zichtbare From-adres?" Die overeenkomst heet uitlijning.
Een bericht kan dus slagen voor SPF voor het domein van de provider en toch falen voor DMARC, omdat het geslaagde domein niet je From-domein was. Dit is precies waarom het artikel E-mail en Joomla erop hamert dat het From-adres je eigen domein gebruikt, en waarom je met DKIM ondertekent voor datzelfde domein. Uitlijning is wat een technische pass omzet in een vertrouwde pass.
5.3 De drie beleidsregels
| Beleid | Wat de ontvanger doet bij falen |
|---|---|
p=none |
Niets. Alleen monitoren en rapporteren. Het veilige startpunt. |
p=quarantine |
Stuurt falende mail naar de spammap. |
p=reject |
Weigert falende mail ronduit. De strenge eindtoestand. |
5.4 De rapporten
Met rua ingesteld mailen mailboxproviders je een dagelijks geaggregeerd rapport: een XML-samenvatting van hoeveel mail beweerde van je domein te zijn, vanaf welke servers, en of het slaagde. Met deze rapporten ontdek je een vergeten verzender (een CRM, een nieuwsbrieftool, je Joomla-host) voordat je het beleid aanscherpt en het per ongeluk blokkeert.
5.5 Een veilige uitrol
- Publiceer
p=nonemet eenrua-adres. Blokkeer nog niets. - Lees de rapporten een week of twee. Zorg dat elke echte verzender slaagt en uitlijnt.
- Ga over naar
p=quarantine. Houd de rapporten opnieuw in de gaten. - Ga ten slotte over naar
p=reject. Nu kan niemand je domein nog spoofen.
Meteen naar reject springen voordat de rapporten schoon zijn, is de snelste manier om je eigen legitieme mail te blokkeren.
6. Reverse DNS en andere signalen
SPF, DKIM en DMARC zijn de grote drie, maar er zijn nog een paar signalen die beinvloeden of je de inbox bereikt.
6.1 Reverse DNS (PTR)
Een PTR-record koppelt een verzendend IP-adres terug aan een hostnaam, het omgekeerde van een normale lookup. Ontvangers wantrouwen mail van een IP zonder bijbehorend reverse-record. Dit kun je meestal niet zelf instellen; het hoort bij degene die het IP bezit. Dit is nog een sterke reden om te versturen via een betrouwbare SMTP-provider, die correcte reverse DNS bijhoudt voor zijn verzendende IP's.
6.2 HELO / EHLO
Wanneer twee mailservers verbinding maken, begroet de verzender de ontvanger met een HELO- of EHLO-commando en noemt zichzelf. Een begroeting die overeenkomt met echte DNS ziet er legitiem uit; een niet-overeenkomende of ontbrekende ziet er verdacht uit. Ook hier regelt een goede SMTP-provider dit correct voor je.
6.3 Greylisting
Greylisting is een spamverdediging waarbij de ontvanger mail van een onbekende verzender tijdelijk weigert en vraagt om het later opnieuw te proberen. Echte mailservers proberen het opnieuw en komen erdoor; veel spamscripts doen dat nooit. Het zichtbare effect is een korte, eenmalige vertraging op het eerste bericht aan een nieuwe ontvanger. Dit is normaal en vereist geen actie.
6.4 Blacklists (blocklists)
Als je verzendende IP of domein wordt gemeld voor spam, kan het op een openbare blocklist belanden, en mail ervan wordt geweigerd of in de spammap gezet. IP's van gedeelde hosting staan vaak al op zo'n lijst vanwege andere sites. Je kunt je status controleren met een tool zoals MXToolbox (sectie 8). De schoonste oplossing is om te versturen via een speciale provider op wiens reputatie je kunt vertrouwen.
Naar boven7. Het instellen voor gangbare providers
Hier zijn typische records voor de meest gangbare verzenders. Kopieer altijd de exacte waarden uit het instelscherm van je eigen provider, want ze veranderen en je DKIM-record is uniek voor jou.
7.1 Google Workspace
SPF TXT @ v=spf1 include:_spf.google.com ~all
DKIM TXT google._domainkey (de lange sleutel die Google voor je genereert)
DMARC TXT _dmarc v=DMARC1; p=none; rua=mailto:Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken. In de adminconsole van Google genereer je de DKIM-sleutel, publiceer je het record en klik je op "Start authentication." Gebruik een App-wachtwoord in de SMTP-instellingen van Joomla, zoals het artikel E-mail en Joomla uitlegt.
7.2 Microsoft 365
SPF TXT @ v=spf1 include:spf.protection.outlook.com ~all
DKIM CNAME selector1._domainkey → (target getoond in de M365-portal)
CNAME selector2._domainkey → (tweede target voor sleutelrotatie)
DMARC TXT _dmarc v=DMARC1; p=none; rua=mailto:Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken. Microsoft 365 gebruikt twee CNAME-records voor DKIM zodat het sleutels automatisch kan roteren. Je schakelt DKIM in in de Microsoft Defender-portal nadat de CNAME's bestaan.
7.3 Een transactionele dienst (Amazon SES, Brevo, Postmark, enzovoort)
SPF TXT @ v=spf1 include:(spf-domein van provider) ~all
DKIM CNAME/TXT (drie of meer records die de provider voor je opsomt)
DMARC TXT _dmarc v=DMARC1; p=none; rua=mailto:Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken. Deze diensten leiden je door "verify your domain," wat simpelweg betekent dat je de DNS-records toevoegt die ze tonen. Eenmaal geverifieerd plak je hun SMTP-host, gebruikersnaam en API-sleutel-wachtwoord in Joomla.
7.4 Als je meer dan een verzender gebruikt
Veel sites versturen vanaf twee plekken: systeemmail van Joomla via een provider en nieuwsbrieven (bijvoorbeeld AcyMailing) via een andere. Beide moeten geautoriseerd zijn. Combineer hun verzenders in het ene SPF-record en voeg voor elk een DKIM-record toe, met het oog op de tien-lookuplimiet uit sectie 3.4.
Naar boven8. Verifieren en monitoren
Ga er nooit van uit dat een DNS-wijziging werkte. Controleer het, en houd het daarna in de gaten.
8.1 Controles via de opdrachtregel
Als je shell-toegang hebt, lezen deze je records rechtstreeks:
dig example.com TXT toont SPF en andere TXT-records
dig _dmarc.example.com TXT toont het DMARC-record
dig selector1._domainkey.example.com TXT toont een DKIM-sleutel
dig example.com MX toont de mailserver
nslookup -type=TXT example.com hetzelfde op Windows8.2 Online tools
| Tool | Wat het je vertelt |
|---|---|
| Mail Tester | Een spamscore plus SPF-, DKIM- en DMARC-resultaten voor een echt bericht. |
| MXToolbox | DNS-, MX-, blacklist- en SMTP-controles. |
| Google Postmaster Tools | De reputatie en aflevering van je domein bij Gmail. |
| DMARC-rapportviewers | Zetten de dagelijkse XML-aggregaatrapporten om in leesbare samenvattingen. |
8.3 Het resultaat lezen in een echte e-mail
De snelste enkele controle: stuur jezelf een bericht, open het in Gmail en kies "Show original." Gmail drukt het oordeel duidelijk af:
SPF: PASS with IP 1.2.3.4
DKIM: PASS with domain yourdomain.com
DMARC: PASSDrie passes betekenen dat je opstelling deugt. Elke fail vertelt je precies welk record je opnieuw moet bekijken. Het Focus On-artikel over Joomla-e-mail problemen oplossen gaat dieper in op het lezen van deze headers.
Naar boven9. Hoe dit aansluit op Joomla
Geen van deze records wordt in Joomla ingesteld, en toch bepalen ze of de mail van Joomla aankomt. Drie keuzes aan de Joomla-kant zorgen dat de authenticatie klopt:
- From-adres op je eigen domein. Stel in de Globale configuratie het From-e-mailadres in op een adres op het domein dat je hebt geauthenticeerd, zodat SPF en DKIM ermee kunnen uitlijnen. Een gratis Gmail-From-adres kan nooit uitlijnen met de DMARC van je domein.
- Verstuur via de provider die je hebt geautoriseerd. Wijs de SMTP van Joomla naar dezelfde provider wiens
include:in je SPF staat en wiens DKIM je hebt gepubliceerd. Dan komt de mail van Joomla van een goedgekeurde, ondertekende bron. - Let op extensies met hun eigen mailconfiguratie. Een extensie zoals AcyMailing die via een andere dienst verstuurt, moet ook gedekt zijn door je SPF en DKIM, anders faalt zijn mail voor DMARC, ook al slaagt de eigen mail van Joomla.
Kortom, authenticatie is een DNS-project, maar Joomla moet zo zijn ingesteld dat het overeenkomt met wat je hebt gepubliceerd. Het artikel E-mail en Joomla behandelt die Joomla-kant stap voor stap.
Naar boven10. Veelgemaakte fouten en valkuilen
10.1 Twee SPF-records
Symptoom: Je hebt een provider toegevoegd en nu faalt SPF voor alles.
Oplossing: Een domein mag maar een SPF-record hebben. Voeg alle include:-waarden samen in een enkel v=spf1 ... ~all-record.
10.2 SPF-lookuplimiet overschreden
Symptoom: SPF geeft een permanente fout terug hoewel het record er juist uitziet.
Oplossing: Je bent over de limiet van tien DNS-lookups gegaan. Verwijder ongebruikte include:-waarden of plat sommige af tot ip4:-reeksen.
10.3 DMARC slaagt technisch maar faalt op uitlijning
Symptoom: SPF zegt pass, maar DMARC zegt fail.
Oplossing: Het geslaagde domein kwam niet overeen met je From-domein. Verstuur vanaf je eigen domein en onderteken er met DKIM voor, zodat het resultaat uitlijnt.
10.4 Meteen naar p=reject springen
Symptoom: Na het instellen van DMARC verdwijnt een deel van je eigen mail.
Oplossing: Draai terug naar p=none, lees de rapporten, bevestig dat elke echte verzender slaagt, en verstevig daarna geleidelijk.
10.5 Een beschadigd DKIM-record
Symptoom: DKIM faalt ook al is de sleutel gepubliceerd.
Oplossing: Er is een teken weggevallen of een regeleinde toegevoegd bij het plakken. Kopieer het exacte record opnieuw van de provider en verifieer met een tool.
10.6 Een tweede verzender vergeten
Symptoom: Systeemmail is in orde, maar nieuwsbrieven belanden in spam.
Oplossing: De nieuwsbriefdienst staat niet in je SPF of heeft geen DKIM. Autoriseer elke dienst die als jouw domein verstuurt.
Naar boven11. Best practices
Als je maar een paar dingen uit dit artikel onthoudt, onthoud dan deze:
- Publiceer alle drie de records: SPF, DKIM en DMARC. Samen maken ze de inbox.
- Houd precies een SPF-record aan en blijf onder de tien DNS-lookups.
- Begin SPF op
~allen DMARC opp=none, en verstevig zodra de rapporten schoon zijn. - Onderteken met DKIM voor hetzelfde domein dat je in het From-adres zet, zodat DMARC uitlijnt.
- Verstuur via een betrouwbare provider zodat reverse DNS, HELO en reputatie voor je worden geregeld.
- Autoriseer elke verzender, inclusief nieuwsbrief- en CRM-tools, niet alleen Joomla.
- Verifieer met een tool na elke wijziging, en houd de DMARC-rapporten in de loop van de tijd in de gaten.
- Verlaag de TTL van een record voor een geplande wijziging zodat de omschakeling sneller propageert.
12. In het kort
WAAR Je DNS-host (registrar / hostingpaneel / Cloudflare), NIET Joomla
SPF TXT @ v=spf1 include:provider ~all (een record, max 10 lookups)
~all soft fail (start) -all hard fail (eind) +all nooit
DKIM TXT/CNAME selector._domainkey publieke sleutel van je provider
DMARC TXT _dmarc v=DMARC1; p=none; rua=mailto:you@domain
p=none monitor → p=quarantine → p=reject
ALIGN From-domein moet overeenkomen met het SPF/DKIM-domein, anders faalt DMARC
PTR reverse DNS op het verzendende IP (taak van de provider)
GOOGLE SPF include:_spf.google.com DKIM google._domainkey
MICROSOFT 365 SPF include:spf.protection.outlook.com DKIM 2x CNAME selectors
VERIFIEER dig example.com TXT
dig _dmarc.example.com TXT
Mail Tester / MXToolbox / Google Postmaster / "Show original"
JOOMLA-KANT From-e-mail op je eigen domein + SMTP via de geautoriseerde provider13. Samenvatting
Afleverbaarheid wordt buiten Joomla beslist, in drie DNS-records die de wereld vertellen dat je mail echt is:
- SPF somt de servers op die mogen versturen namens je domein. Een record, onder de tien lookups, eindigend op
~allen daarna-all. - DKIM ondertekent elk bericht met een sleutel, bewijst dat het van jou is en ongewijzigd, geidentificeerd door een selector.
- DMARC stelt het beleid in en stuurt rapporten, en dwingt uitlijning met je From-domein af.
- Reverse DNS, HELO, greylisting en blocklists zijn kleinere signalen die een goede provider voor je regelt.
- Joomla moet overeenkomen met wat je publiceert: een From-adres op je domein, verstuurd via de geautoriseerde provider.
Stel dit een keer in, verifieer het met een echt testbericht, en houd de rapporten in de gaten terwijl je het beleid aanscherpt. Als je Joomla-site mail verstuurt die ondanks correcte SMTP-instellingen toch in spam belandt, ligt het antwoord bijna altijd hier, in de DNS. SPF, DKIM en DMARC goed krijgen is het verschil tussen mail die technisch verstuurt en mail die echt aankomt, en het is een middag goed besteed om het netjes te doen.
Naar boven
Veelgestelde vragen
E-mails kunnen in de spamfolder terechtkomen of helemaal niet aankomen omdat je domein niet over de juiste authenticatie beschikt (SPF, DKIM of DMARC), je server een slechte afzenderreputatie heeft, je inhoud spamfilters activeert of ontvangers zelden op je e-mails reageren.
Configureer SPF, DKIM en DMARC correct, gebruik een betrouwbare SMTP-server en zorg voor een goede reputatie als afzender. Verstuur relevante e-mails, houd je mailinglijsten up-to-date, vermijd inhoud die spamfilters activeert en test regelmatig je e-mailauthenticatie om ervoor te zorgen dat berichten de inbox bereiken.
- SPF (Sender Policy Framework) controleert welke mailservers bevoegd zijn om namens je domein e-mail te versturen.
- DKIM (DomainKeys Identified Mail) voegt een digitale handtekening toe aan elke e-mail, waardoor ontvangende servers kunnen controleren of het bericht tijdens het verzenden niet is gewijzigd.
- DMARC (Domain-based Message Authentication, Reporting and Conformance) combineert SPF en DKIM door ontvangende mailservers te vertellen hoe ze met niet-geverifieerde e-mails moeten omgaan en door rapporten te verstrekken over authenticatieresultaten.
Ja. Het gebruik van een betrouwbare SMTP-dienst of een correct geconfigureerde e-mailserver verbetert de authenticatie, de reputatie en de afleveringspercentages. SMTP alleen is echter niet voldoende zonder SPF, DKIM en DMARC.
Je kunt online tools gebruiken om je SPF-, DKIM- en DMARC-records te controleren, e-mailheaders te bekijken en te testen of je berichten de authenticatie doorstaan voordat je ze naar klanten of abonnees verstuurt.
