• Methoden voor e-mailverificatie: hoe SPF, DKIM en DMARC uw domein beschermen

Methoden voor e-mailverificatie: hoe SPF, DKIM en DMARC uw domein beschermen

door

Laatst bijgewerkt:
9 leestijd: 9 minuten
Methoden voor e-mailverificatie: hoe SPF, DKIM en DMARC uw domein beschermen

Belangrijkste Conclusies

  • Met e-mailverificatiemethoden wordt gecontroleerd of een bericht daadwerkelijk afkomstig is van uw domein en niet is vervalst.
  • SPF, DKIM en DMARC vormen de drie belangrijkste. Elk controleert iets anders, en ze werken het beste in combinatie met elkaar.
  • Samen voorkomen ze spoofing, zorgen ze ervoor dat je e-mail niet in de spam terechtkomt en beschermen ze je merk in Gmail, Outlook en Yahoo.
  • ARC, MTA-STS, TLS-RPT en BIMI breiden die bescherming uit naar doorgestuurde e-mail, versleuteld transport en merklogo’s.
  • Zonder deze maatregelen kan iedereen je domein misbruiken en heb je geen inzicht in hoe het wordt gebruikt.
  • Met DMARC-rapportage kunt u ongeautoriseerde afzenders en fouten veel sneller opsporen dan wanneer u DNS of headers handmatig controleert.

E-mailverificatiemethoden zijn de protocollen – met name SPF, DKIM en DMARC – waarmee ontvangende servers kunnen controleren of een bericht daadwerkelijk afkomstig is van uw domein. Zonder deze methoden kan iedereen uw afzenderadres vervalsen, waardoor de kans groter wordt dat uw legitieme e-mails in de spamfolder terechtkomen.

Als deze methoden correct worden geconfigureerd, beschermen ze uw merk tegen identiteitsfraude, zorgen ze ervoor dat legitieme e-mails in de inbox terechtkomen en laten ze u precies zien hoe uw domein wordt gebruikt. Nu Google, Yahoo, Microsoft en Apple authenticatie voor bulkverzenders verplicht stellen, is het instellen hiervan niet langer optioneel. In deze handleiding worden de belangrijkste methoden voor e-mailauthenticatie besproken, hoe ze werken, waarom ze van invloed zijn op de afleverbaarheid en hoe u ze kunt implementeren.

Voor teams die meerdere domeinen beheren of verzendservices gebruiken, is het moeilijkste deel niet het eenmalig publiceren van records. Het gaat erom het overzicht te behouden, aangezien elk nieuw CRM-systeem, marketingplatform, helpdesk of regionaal domein de SPF-, DKIM- en DMARC- onderliggende structuur verandert.

Wat is e-mailverificatie?

E-mailverificatie is een reeks methoden waarmee wordt gecontroleerd of een bericht daadwerkelijk afkomstig is van het domein dat het opgeeft en of het tijdens de verzending niet is vervalst. Deze methoden, voornamelijk SPF, DKIM en DMARC, worden als TXT-records in het DNS gepubliceerd. Wanneer een ontvangende server een binnenkomend bericht controleert, raadpleegt deze de DNS-records om het domeineigendom te verifiëren en te beslissen of het bericht moet worden afgeleverd, naar de spamfolder moet worden doorgestuurd of moet worden geweigerd.

Goed om te weten

Authenticatie wordt vaak verward met drie verwante begrippen. Bij authenticatie wordt gecontroleerd wie het bericht heeft verzonden. Autorisatie bepaalt wat een afzender mag doen. Versleuteling beschermt de inhoud tijdens het verzenden. De reputatie van de afzender geeft de verzendgeschiedenis en het aantal klachten van een domein weer. Alle vier zijn van invloed op de afleverbaarheid, hoewel authenticatie de basis vormt waarop de andere drie voortbouwen.

Belangrijkste methoden voor e-mailverificatie: SPF, DKIM en DMARC

Dit zijn de methoden die ervoor zorgen dat e-mailverificatie werkt; elke methode is verantwoordelijk voor een ander onderdeel van de verificatie.

Beschouw SPF, DKIM en DMARC als drie lagen van identiteitscontrole. SPF controleert of de verzendende server bevoegd is om namens uw domein te verzenden. DKIM controleert of het bericht tijdens het verzenden niet is gewijzigd. DMARC controleert of deze resultaten overeenkomen met het zichtbare ‘Van’-adres en geeft providers aan wat ze moeten doen als dat niet het geval is.

ProtocolWat er wordt gecontroleerdWaarom het belangrijk isBelangrijkste beperking
SPFOf het verzendende IP-adres geautoriseerd isBeperkt spoofing en misbruik door afzendersLimiet van 10 DNS-opzoekingen; wordt onderbroken bij doorsturen
DKIMOf het bericht tijdens de verzending is gewijzigdWaarborgt de integriteit van berichtenControleert het zichtbare ‘Van’-adres niet
DMARCOf SPF of DKIM overeenkomen met het ‘From’-domeinMaakt het handhaven van beleid en rapportage mogelijkSPF of DKIM is vereist om te werken
BIMIWeergave van het merklogo bij geverifieerde e-mailVerhoogt het vertrouwen in het merk en de herkenbaarheid in de inboxDMARC moet zijn ingesteld op p=quarantine of p=reject
MTA-STSVerplichte TLS-beveiliging voor het dataverkeerVoorkomt downgrade- en onderscheppingsaanvallenHiervoor moet een HTTPS-beleidsbestand worden gehost
TLS-RPTRapportage van mislukte TLS-leveringenBiedt inzicht in problemen op de transportlaagRuwe JSON-rapporten zijn moeilijk handmatig te ontleden
ARCVerificatieketen voor doorgestuurde e-mailBehoudt authenticatie bij doorsturenWerkt alleen als de ontvangende server ARC ondersteunt

SPF (Sender Policy Framework)

e-mailverificatie

Sender Policy Framework vormt de eerste verdedigingslaag. SPF voorkomt spoofing door de geautoriseerde IP-adressen aan te geven die e-mail mogen verzenden vanuit een domein. Het controleert uitsluitend de afzender in het MAIL FROM-domein en houdt geen rekening met het ‘Van’-adres dat de ontvanger ziet, omdat SPF zich richt op de bericht-envelop, het Return-Path, in plaats van op de zichtbare header. Een IP-adres dat overeenkomt, wordt geaccepteerd; alle andere worden afgewezen.

DKIM (DomainKeys Identified Mail)

Terwijl SPF de afzender-server verifieert, controleert DKIM of de inhoud tijdens het verzenden niet is gemanipuleerd. Hierbij wordt een digitale handtekening toegevoegd met behulp van cryptografische sleutels: de server van de afzender ondertekent elk bericht met een privésleutel, waardoor een DKIM-handtekening die aan de headers wordt toegevoegd, en de ontvangende server haalt de bijbehorende openbare sleutel op uit het DNS om deze te verifiëren. Als de handtekening overeenkomt en de inhoud ongewijzigd is, slaagt DKIM, waarmee wordt bevestigd dat het bericht daadwerkelijk afkomstig is van het opgegeven domein en onderweg niet is gewijzigd.

DMARC (domeingebaseerde berichtenauthenticatie, -rapportage en -conformiteit)

DMARC is het protocol dat alles samenbrengt. Het controleert of een inkomende e-mail voldoet aan SPF of DKIM en of het domein dat bij die controles wordt gebruikt, overeenkomt met het ‘Van’-adres. Juist dankzij die vereiste van overeenstemming is DMARC effectief in het opsporen van vervalste berichten die langs SPF of DKIM alleen glippen, en het bepaalt welke actie het ontvangende systeem moet ondernemen bij fouten.

De DMARC-beleidsopties worden in een weloverwogen volgorde uitgevoerd:

  • p=none: alleen monitoren. Berichten worden niet beïnvloed, terwijl u geaggregeerde rapporten ontvangt over authenticatieresultaten voor alle afzenders. Dit is het aanbevolen startpunt.
  • p=quarantaine: mislukte berichten komen in de spam- of junkmap terecht. Gebruik deze optie pas als u er zeker van bent dat alle legitieme afzenders worden doorgelaten.
  • p=afwijzen: mislukte berichten worden op de ontvangende server geblokkeerd. Dit is het strengste niveau en beschermt uw domein volledig tegen spoofing.

DMARC genereert ook twee soorten rapporten: RUA-geaggregeerde rapporten, waarin de resultaten van alle afzenders worden samengevat, en RUF-forensische rapporten, die gedetailleerde informatie op berichtniveau geven over fouten. Beide rapporten worden in XML-formaat verzonden naar de adressen in uw DMARC-record.

Aanvullende methoden: ARC, MTA-STS, TLS-RPT en BIMI

Het kerntrio voorziet in de meeste behoeften. Vier aanvullende protocollen breiden de bescherming uit voor specifieke scenario’s: doorsturen, versleuteld transport, transportzichtbaarheid en merkweergave.

ARC (Authenticated Received Chain)

Als je e-mails doorstuurt via mailinglijsten, ticketsystemen of andere tussenpersonen, kunnen doorgestuurde berichten soms niet voldoen aan de SPF- of DKIM-verificatie. ARC lost dit op door de oorspronkelijke authenticatieresultaten bij elke tussenstap te behouden. Wanneer een bericht via een vertrouwde tussenpersoon wordt doorgestuurd, registreert ARC de resultaten bij elke stap en creëert het een cryptografisch ondertekende keten, die de eindserver verifieert om te bevestigen dat de e-mail oorspronkelijk geauthenticeerd was, zelfs nadat het doorsturen de oorspronkelijke handtekening had verbroken. Dit is een veelvoorkomende oorzaak van DMARC-fouten.

MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS vereist versleutelde SMTP-verbindingen tussen mailservers, waardoor wordt voorkomen dat aanvallers het verkeer kunnen onderscheppen of omzetten naar leesbare tekst bij man-in-the-middle-aanvallen. Wanneer dit is geconfigureerd, geeft het aan verzendende servers door dat ze TLS -versleuteling moeten gebruiken om e-mail naar uw domein te verzenden, en de bezorging moeten weigeren als er geen beveiligde verbinding tot stand kan worden gebracht.

Gehoste MTA-STS- en TLS-RPT-diensten vereenvoudigen de implementatie doordat het niet langer nodig is om beleidsbestanden handmatig te hosten en transportrapporten te analyseren. Dit biedt voordelen voor organisaties in de financiële sector, de gezondheidszorg en de publieke sector die versleutelde gegevensoverdracht vereisen als nalevingsmaatregel.

TLS-RPT (SMTP TLS-rapportage)

TLS-RPT biedt domeineigenaren inzicht in bezorgingsproblemen die verband houden met TLS-versleuteling, en laat zien wanneer berichten niet veilig konden worden bezorgd. In combinatie met MTA-STS helpt het teams om downgrade-aanvallen, verkeerde beleidsinstellingen en certificaatfouten sneller op te sporen. Zonder deze functie vinden versleutelingsfouten onopgemerkt plaats, zonder dat er een signaal is dat er geen veilige verbinding tot stand kon worden gebracht.

BIMI (merkindicatoren voor berichtidentificatie)

BIMI toont een geverifieerd merklogo in de inbox van de ontvanger naast geauthenticeerde berichten, wat een visueel bewijs van legitimiteit biedt. Om dit te laten werken, heeft uw domein een DMARC-beleid met ten minste p=quarantine. Het logo zorgt voor merkherkenning, waardoor ontvangers echte e-mails direct kunnen herkennen, wat de open rates kan verhogen. BIMI is ook een doelwit voor logo-spoofing wanneer domeinen niet goed beveiligd zijn.

Voor de weergave van het blauwe vinkje in Gmail is een Verified Mark Certificate (VMC) vereist, en met gehoste BIMI in combinatie met VMC-ondersteuning hoef je minder handmatig in te stellen. Als je klaar bent om dit in te stellen, kun je deze handleiding over het publiceren van een BIMI-record bevat de stappen die u moet volgen.

Hoe e-mailverificatie werkt

Authenticatie verloopt als een reeks automatische controles tussen de verzendende en de ontvangende server. Het end-to-end-proces ziet er als volgt uit.

  1. De afzender verstuurt een bericht. Uw mailserver verstuurt een e-mail namens uw domein.
  2. De ontvangende server voert een DNS-zoekopdracht uit. Hij zoekt de DNS-records van het verzendende domein op om de SPF-, DKIM- en DMARC-configuratie te vinden.
  3. SPF-controle. De server controleert of het verzendende IP-adres als geautoriseerd is opgenomen in het SPF-record van het domein. Als er een overeenkomst is, is de controle geslaagd.
  4. DKIM-controle. De server haalt de openbare DKIM-sleutel op uit DNS en controleert de cryptografische handtekening in de berichtkoppen. Een geldige handtekening op ongewijzigde inhoud wordt geaccepteerd.
  5. DMARC-afstemming en beleidscontrole. DMARC controleert of het domein dat de SPF- of DKIM-controle heeft doorstaan, overeenkomt met het zichtbare ‘Van’-domein. Als dat niet het geval is, past het het beleid van het domein toe: geen actie, in quarantaine plaatsen of afwijzen.
  6. Definitieve afleveringsbeslissing. De provider bezorgt het bericht, plaatst het in quarantaine of weigert het, en stuurt DMARC-geaggregeerde rapporten terug naar de domeineigenaar.

Waarom is e-mailverificatie belangrijk?

Het overslaan van authenticatie leidt tot reële bedrijfsrisico’s op vijf gebieden die elkaar vaak versterken. Zwakke authenticatie leidt zelden tot slechts één op zichzelf staand probleem.

Beschermt de reputatie van uw merk

Authenticatie voorkomt dat oplichters je domein gebruiken om frauduleuze berichten te versturen. Wanneer aanvallers uw domein vervalsen, associëren ontvangers de de phishingpoging met uw merk, ook al had u er niets mee te maken. Het voorkomen daarvan is essentieel om het vertrouwen van klanten te behouden.

Voorkomt phishing en spoofingphishing e-mail

SPF, DKIM en DMARC werken samen om de identiteit van een afzender te verifiëren voordat het bericht de ontvanger bereikt, waardoor het veel moeilijker wordt om zich voor te doen als een vertrouwd merk. Zonder deze controles kunnen aanvallers naar believen afzenderadressen vervalsen en campagnes opzetten waarbij zakelijke e-mailaccounts worden gekaapt. Het verschil tussen phishing en spoofing is hier van belang, aangezien authenticatie de spoofing aanpakt die phishing overtuigend maakt.

Verbetert de bezorgbaarheid van e-mail

Geverifieerde e-mails worden minder snel als spam gemarkeerd door providers zoals Gmail of Outlook, waardoor legitieme berichten de inbox bereiken. Veel providers eisen tegenwoordig DKIM en DMARC voor een succesvolle bezorging, en het voldoen aan die normen verhoogt de kans dat berichten in de inbox terechtkomen.

Voldoet aan de nalevingsvereisten

Google, Yahoo, Microsoft en Apple stellen allemaal SPF, DKIM en DMARC verplicht voor domeinen die meer dan 5.000 e-mails per dag versturen, waarbij Google dit vanaf november 2025 strikt zal handhaven door e-mails die niet aan de vereisten voldoen te weigeren.

Voor gereguleerde sectoren zoals de financiële sector, de gezondheidszorg, het onderwijs, de detailhandel en de publieke sector draagt authenticatie ook bij aan bredere compliance- en risicobeheerprogramma’s. In de vereisten van Google, Microsoft, PCI DSS, op de AVG afgestemde programma’s en regionale overheidsvoorschriften worden SPF, DKIM en DMARC steeds vaker beschouwd als essentiële controlemaatregelen in plaats van als best practices.

Geeft u zichtbaarheid en controle

Met name DMARC rapporteert hoe uw domein wordt gebruikt voor het verzenden van e-mail. Deze rapporten brengen ongeautoriseerde afzenders, authenticatiefouten en pogingen tot spoofing aan het licht – gegevens waarop u actie kunt ondernemen. Zonder authenticatie hebt u geen inzicht in de prestaties of beveiliging van e-mail binnen uw verzendinfrastructuur.

Dient als strategisch voordeel

Aanbieders van e-maildiensten belonen steeds vaker afzenders die zich op de juiste manier hebben geauthenticeerd. Organisaties die dit goed aanpakken, bouwen meer vertrouwen op bij hun ontvangers, hebben minder problemen met de bezorging en beschermen hun verzendinfrastructuur tegen misbruik, waardoor ze een voorsprong hebben op concurrenten die dit niet doen.

e-mailverificatie

Hoe e-mailverificatie te implementeren

De implementatie komt neer op het configureren van de DNS-records die ontvangende servers gebruiken om elk bericht dat uw domein verstuurt te valideren. Doorloop de vijf stappen in de juiste volgorde, vanaf uw eerste TXT-record tot de volledige implementatie.

  1. Controleer uw verzendinfrastructuur. Breng alle bronnen in kaart die namens uw domein e-mails versturen: primaire mailservers, marketingautomatisering, CRM, helpdesk, facturering en eventuele transactieproviders. De meeste authenticatiefouten zijn terug te voeren op een over het hoofd geziene afzender, dus deze stap bepaalt hoe schoon de implementatie is.
  2. Publiceer je SPF-record. Maak één TXT-record aan waarin alle geautoriseerde IP-adressen en verzendservices worden vermeld. Elke vermelding telt mee voor de limiet van 10 lookups; als deze limiet wordt overschreden, mislukt de SPF-controle voor alle berichten.
  3. Configureer DKIM -ondertekening. Genereer een sleutelpaar via uw provider of mailserver. De privésleutel blijft op de verzendende server staan en ondertekent uitgaande e-mail; de openbare sleutel wordt als TXT-record in DNS opgenomen, zodat ontvangers elke handtekening kunnen verifiëren.
  4. Voeg je DMARC-record toe. Publiceer een DMARC TXT-record, te beginnen met een beleid dat uitsluitend op monitoring is gericht (p=none), zodat u de resultaten kunt observeren voordat u het beleid afdwingt. Een basisrecord ziet er als volgt uit: v=DMARC1; p=none; rua=mailto:[email protected]; fo=1.
  5. Testen en valideren. Verzend een testmail vanuit elke bron die in stap één is geïdentificeerd en controleer de header 'Authentication-Results' op de SPF-, DKIM- en DMARC-uitspraken.

Veelgemaakte fout

Een voorbeeld van een SPF- of DMARC-record rechtstreeks in DNS kopiëren. De bovenstaande voorbeelden zijn sjablonen, geen kant-en-klare records. Een SPF-regel die diensten bevat die u niet gebruikt, verspilt lookups ten koste van het maximum van 10 lookups, en een DMARC-record dat verwijst naar een rapportage-mailbox waarvan niemand de eigenaar is, betekent dat de verzamelde gegevens nergens terechtkomen. Pas beide aan voor uw eigen afzenders en rapportageadressen voordat u ze publiceert.

Voor records die de opzoeklimiet overschrijden naarmate SaaS-platforms groeien, is een SPF-afvlakkingstool zorgt ervoor dat ze automatisch binnen de grenzen blijven. Zodra de records live zijn, gebruik je een domeinanalysator om de volledige SPF-, DKIM- en DMARC-configuratie binnen enkele seconden te valideren.

OpdrachtProtocolVereistGereedschap
Controleer alle bronnen waaruit e-mails worden verzondenAlleJaHandmatige of DMARC-rapporten
SPF TXT-record in DNS publicerenSPFJaSPF Generator of PowerSPF
DKIM-ondertekening configureren en sleutel publicerenDKIMJaDKIM-generator of gehoste DKIM
DMARC-record publiceren met p=noneDMARCJaDMARC generator
Bekijk de DMARC-rapporten en los de fouten opDMARCJaPowerDMARC-dashboard
DMARC naar quarantaine verplaatsen en vervolgens afwijzenDMARCAanbevolenHandhavingswizard
MTA-STS en TLS-RPT implementerenMTA-STS / TLS-RPTAanbevolenGehoste MTA-STS / TLS-RPT
BIMI instellen met VMC of CMCBIMIOptioneelPowerBIMI / VMC-ondersteuning

Veelvoorkomende fouten bij authenticatie en hoe je deze kunt oplossen

Er treden meestal problemen op wanneer de verzendomgeving verandert. Nieuwe SaaS-tools, regionale afzenders, doorstuurservices en DNS-wijzigingen hebben allemaal invloed op SPF, DKIM, DMARC en de transportbeveiliging. Hieronder volgen de meest voorkomende scenario’s en de bijbehorende oplossingen.

MislukkingHoe dit te verhelpen
SPF-opzoekingen overschrijden 10 DNS-opzoekingenGebruik SPF-afvlakking of geautomatiseerd beheer om onder de limiet te blijven zonder bestaande records te verbreken
Afzender van een derde partij die niet in de SPF is opgenomenControleer de bronnen waaruit wordt geïmporteerd en voeg het ‘include’-mechanisme van de ontbrekende service toe
DKIM-selector ontbreekt of is verouderdDKIM-sleutels rouleren en controleren; zorg ervoor dat de ondertekeningsselector overeenkomt met die in DNS
DMARC-afstemmingsfoutZorg ervoor dat het SPF Return-Path of het DKIM-ondertekeningsdomein overeenkomt met het zichtbare „Van”-domein
Doorgestuurde e-mails slagen niet voor de authenticatieImplementeer ARC waar dit wordt ondersteund om resultaten te behouden bij het doorsturen via tussenliggende partijen
Fouten bij de levering via TLSImplementeer MTA-STS om versleutelde verzending af te dwingen en houd TLS-RPT in de gaten om storingen op te sporen
SPF of DKIM wordt goedgekeurd, maar DMARC misluktHet geverifieerde domein komt niet overeen met het „Van”-domein; controleer de afstemmingsmodus en het ondertekeningsdomein

Best Practices voor e-mailverificatie

Het publiceren van de gegevens is de eerste stap. Om de authenticatie op de lange termijn sterk te houden, zijn een paar vaste gewoontes nodig.

Begin met monitoren, en vervolgens handhaven

Begin met p=none om gegevens te verzamelen zonder de bezorging te beïnvloeden. Analyseer de rapporten om alle legitieme afzenders te identificeren, corrigeer verkeerde instellingen en schakel vervolgens geleidelijk over naar p=quarantine en p=reject naarmate het vertrouwen toeneemt.

Zorg ervoor dat de SPF-gegevens actueel blijven en binnen de limiet blijven

Werk je SPF-record telkens bij wanneer je een verzendservice toevoegt of verwijdert, aangezien een verouderd record legitieme e-mail tegenhoudt. Let op de limiet van 10 lookups naarmate je stack groeit, want als je deze overschrijdt, wordt de gehele SPF-controle voor elk bericht mislukt. Organisaties die veel SaaS-platforms gebruiken, moeten de SPF-complexiteit continu in de gaten houden en geautomatiseerd beheer of ‘flattening’ toepassen om fouten te voorkomen naarmate het aantal afzenders toeneemt.

Draai DKIM-sleutels regelmatig

Het rouleren van DKIM-sleutels vermindert het risico dat sleutels in verkeerde handen vallen. Het wordt aanbevolen om dit elke 6 tot 12 maanden te doen, en onmiddellijk als u vermoedt dat de privésleutel is gelekt.

e-mailverificatie

Veelgestelde Vragen

Heb ik SPF, DKIM en DMARC nodig als ik gebruikmaak van een e-mailserviceprovider?

Ja. De meeste e-maildienstverleners (ESP’s) gebruiken voor veel klanten dezelfde verzendinfrastructuur, waardoor hun standaardconfiguratie je domein mogelijk niet volledig verifieert. Je publiceert je eigen SPF-, DKIM- en DMARC-records; de ESP helpt je bij het configureren van DKIM-ondertekening.

Welk protocol moet ik als eerste instellen?

Eerst SPF, dan DKIM en vervolgens DMARC met p=none. DMARC is voor zijn werking afhankelijk van de resultaten van SPF of DKIM; als je het dus als eerste implementeert zonder dat de andere twee al zijn ingesteld, heb je geen referentiepunt om je aan te spiegelen.

Wat is het verschil tussen authenticatie en versleuteling?

Authenticatie controleert wie een bericht heeft verzonden en of het is gewijzigd. Versleuteling beschermt de inhoud tijdens het verzenden. MTA-STS en TLS-RPT zorgen voor de versleuteling; SPF, DKIM en DMARC zorgen voor de identiteitscontrole.

Waarom slagen mijn doorgestuurde e-mails niet voor de authenticatie?

Het doorsturen via mailinglijsten of ticketsystemen kan de oorspronkelijke SPF- of DKIM-handtekening beschadigen. ARC behoudt de oorspronkelijke resultaten bij elke tussenstap, zodat een ontvangende server die ARC ondersteunt het bericht nog steeds kan vertrouwen.

Hoe lang duurt het voordat de authenticatie van kracht wordt?

DNS-wijzigingen worden binnen enkele minuten tot enkele uren doorgevoerd, afhankelijk van de TTL. Het duurt enkele dagen tot een paar weken voordat er voldoende DMARC-rapportagegegevens zijn verzameld voor al uw verzendbronnen.

Kan ik direct naar p=reject gaan?

Dit wordt ten zeerste afgeraden. Zonder een controleperiode bij p=none kun je niet zien welke legitieme afzenders er problemen ondervinden, en als je te snel overgaat tot afwijzing, kun je je eigen facturen en transactiemails blokkeren.

e-mailverificatie