DMARC: Hoe bescherm je je e-mailreputatie
Bird
13 apr 2016
1 min read
Belangrijkste punten
DMARC helpt uw domein te beschermen tegen phishing, spoofing en ongeoorloofd e-mailgebruik door uw authenticatiepraktijken te publiceren en specifieke behandeling te vragen voor mislukte berichten.
Het werkt samen met SPF en DKIM om domeinafstemming te garanderen en te voorkomen dat frauduleuze mail uw zenderreputatie beschadigt.
Sterke DMARC-beleid ondersteunen hogere vertrouwen, hogere betrokkenheid en maken uw domein toekomstbestendig naarmate het ecosysteem verschuift naar domein-gebaseerde reputatiemodellen.
DMARC-validatiecontroles zijn afhankelijk van domeinafstemming tussen het Van-domein, Return-Path-domein (SPF) en DKIM-ondertekeningsdomein.
Het opzetten van DMARC vereist het ontvangen van rapporten, het begrijpen van aggregaat versus forensische gegevens en het configureren van tools om deze te analyseren.
U begint met een veilige p=none beleid om verkeer te monitoren voordat u doorgaat naar quarantine of reject.
Het publiceren van een DMARC-record houdt in dat u een DNS TXT-invoer maakt op _dmarc.yourdomain.com met beleidsregels, rapportadres en optionele parameters zoals percentage uitrol.
Geschikte rapporteringsmailboxen (aggregate + forensic) en parsingsinstrumenten zijn essentieel voor het monitoren van naleving, het detecteren van spoofing en het garanderen dat de afstemming correct is.
DMARC vereist alleen één van de volgende om te slagen: afgestemde SPF of afgestemde DKIM.
Het implementeren van DMARC versterkt e-mailbeveiliging en speelt een sleutelrol in merkintegriteit, vertrouwen en langetermijn leverbaarheid.
Q&A Hoogtepunten
Wat is DMARC en waarom is het belangrijk?
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is een DNS-gepubliceerd beleid dat uw domein beschermt tegen spoofing en phishing door domeinafwijkingen te handhaven en zichtbaarheid mogelijk te maken via rapportage.
Is DMARC een authenticatieprotocol?
Nee. DMARC is niet zelf authenticatie—het vertrouwt op SPF en DKIM om e-mails te authenticeren en gebruikt beleid + rapportage om te bepalen hoe ontvangende servers omgaan met mislukkingen.
Waar controleert DMARC op?
Het verifieert:
SPF-authenticatie + uitlijning
DKIM-authenticatie + uitlijning
Een afzender heeft maar één van deze nodig om DMARC te laten slagen.
Wat is "domain alignment"?
Het is de vereiste dat het zichtbare Van-domein overeenkomt (strikt) of hetzelfde organisatiedomein deelt (relaxed) met ofwel het SPF Return-Path-domein of het DKIM-ondertekeningsdomein.
Waarom verbetert DMARC de bezorgbaarheid?
Omdat mailboxproviders geverifieerde, uitgelijnde domeinen meer vertrouwen. DMARC voorkomt dat vervalste berichten je reputatie aantasten en verbetert de plaatsing van echte mail in de inbox.
Wat is het verschil tussen verzamel- en forensische DMARC-rapporten?
Geaggregeerde rapporten (RUA): XML-samenvattingen van authenticatieresultaten over al het verkeer.
Forensische rapporten (RUF): Individuele voorbeelden van mislukte berichten voor diepere analyse.
Welke mailboxes heb ik nodig voordat ik DMARC publiceer?
U moet twee adressen maken, zoals:
agg_reports@yourdomain.com (RUA)
afrf_reports@yourdomain.com (RUF)
Dit houdt rapportagestromen gescheiden en gemakkelijker te verwerken.
Met welk DMARC-beleid moet ik beginnen?
Begin altijd met p=none. Het bewaakt authenticatie-activiteit zonder de levering te beïnvloeden, waardoor je uitlijningsproblemen en spoofingpogingen veilig kunt identificeren.
Wat zijn de beschikbare DMARC policies?
geen: alleen monitoren
quarantaine: stuur mislukte berichten naar spam
afwijzen: blokkeer mislukte berichten volledig
Waar publiceer ik een DMARC record?
In uw DNS bij:
_dmarc.yourdomain.com
Het moet een TXT-record zijn dat uw beleid, versie en rapportage-eindpunten specificeert.
Hoe ziet een basis DMARC record eruit?
Voorbeeld:
v=DMARC1; p=none; rua=mailto:agg_reports@yourdomain.com; ruf=mailto:afrf_reports@yourdomain.com; pct=100
Wat gebeurt er als DMARC faalt?
De ontvangende server past uw gevraagde beleid toe (geen, quarantaine, afwijzen), hoewel de uiteindelijke behandeling uiteindelijk aan de provider is. Een strikt beleid kan phishingpogingen met uw domein aanzienlijk verminderen.
In dit bericht vertellen we je alles wat je moet weten over het benutten van DMARC om je e-mailreputatie te beschermen en geven we je aanwijzingen hoe je het voor je domeinen instelt.
In dit bericht vertellen we je alles wat je moet weten over het benutten van DMARC om je e-mailreputatie te beschermen en geven we je aanwijzingen hoe je het voor je domeinen instelt.
In dit bericht vertellen we je alles wat je moet weten over het benutten van DMARC om je e-mailreputatie te beschermen en geven we je aanwijzingen hoe je het voor je domeinen instelt.
Een Effectieve Tool om Frauduleuze Mail tegen te gaan
Vaak genoemd in dezelfde adem als de e-mailauthenticatieprotocollen SPF en DKIM, is DMARC, of Domein-gebaseerde Berichtverificatie, Rapportage en Conformance, niet op zichzelf een authenticatieprotocol. In plaats daarvan is het doel van DMARC om ons, de domeineigenaren, in staat te stellen onze e-mailreputatie te beschermen door:
Aankondigen van e-mailauthenticatiepraktijken,
Verzoeken om behandeling van e-mails die falen voor authenticatiecontroles, en
Verzoeken om rapporten over e-mails die beweren van onze domein te komen.
DMARC kan een effectief hulpmiddel voor ons zijn in de strijd tegen frauduleuze e-mails die onze domeinnaam (bijv. phishing en spoofing) gericht aanvallen, en dat kan leiden tot een groter vertrouwen van onze ontvangers in onze e-mails. Voor organisaties die end-to-end encryptie nodig hebben naast authenticatie, biedt implementatie van S/MIME met efficiënte methoden voor het verzamelen van publieke sleutels van ontvangers extra beveiligingslagen. Dit grotere vertrouwen zou op zijn beurt moeten leiden tot een hogere betrokkenheid bij onze e-mails, en e-mails die worden geopend en klikken genereren, verhogen de verkoop en een hogere ROI voor onze e-mailcampagnes.
Naast het beschermen van ons domein, voorspellen we dat het implementeren van DMARC nu een uitstekende manier zal zijn om ons domein "toekomstbestendig" te maken. Hier bij Bird geloven we dat naarmate de industrie overgaat op IPv6, het bijna zeker zal overstappen van een IP-gebaseerd reputatiemodel naar een domein-gebaseerd reputatiemodel. Domein-gebaseerde reputatie zal domein-gebaseerde authenticatie vereisen, en DMARC, in samenwerking met DKIM en SPF, zal domeinen helpen een domein-gebaseerde reputatie op te bouwen, lang voordat het absoluut noodzakelijk zou zijn.
In dit bericht vertellen we je alles wat je moet weten over het benutten van DMARC om je e-mailreputatie te beschermen en geven we je aanwijzingen over hoe je het voor je domeinen kunt instellen.
Vaak genoemd in dezelfde adem als de e-mailauthenticatieprotocollen SPF en DKIM, is DMARC, of Domein-gebaseerde Berichtverificatie, Rapportage en Conformance, niet op zichzelf een authenticatieprotocol. In plaats daarvan is het doel van DMARC om ons, de domeineigenaren, in staat te stellen onze e-mailreputatie te beschermen door:
Aankondigen van e-mailauthenticatiepraktijken,
Verzoeken om behandeling van e-mails die falen voor authenticatiecontroles, en
Verzoeken om rapporten over e-mails die beweren van onze domein te komen.
DMARC kan een effectief hulpmiddel voor ons zijn in de strijd tegen frauduleuze e-mails die onze domeinnaam (bijv. phishing en spoofing) gericht aanvallen, en dat kan leiden tot een groter vertrouwen van onze ontvangers in onze e-mails. Voor organisaties die end-to-end encryptie nodig hebben naast authenticatie, biedt implementatie van S/MIME met efficiënte methoden voor het verzamelen van publieke sleutels van ontvangers extra beveiligingslagen. Dit grotere vertrouwen zou op zijn beurt moeten leiden tot een hogere betrokkenheid bij onze e-mails, en e-mails die worden geopend en klikken genereren, verhogen de verkoop en een hogere ROI voor onze e-mailcampagnes.
Naast het beschermen van ons domein, voorspellen we dat het implementeren van DMARC nu een uitstekende manier zal zijn om ons domein "toekomstbestendig" te maken. Hier bij Bird geloven we dat naarmate de industrie overgaat op IPv6, het bijna zeker zal overstappen van een IP-gebaseerd reputatiemodel naar een domein-gebaseerd reputatiemodel. Domein-gebaseerde reputatie zal domein-gebaseerde authenticatie vereisen, en DMARC, in samenwerking met DKIM en SPF, zal domeinen helpen een domein-gebaseerde reputatie op te bouwen, lang voordat het absoluut noodzakelijk zou zijn.
In dit bericht vertellen we je alles wat je moet weten over het benutten van DMARC om je e-mailreputatie te beschermen en geven we je aanwijzingen over hoe je het voor je domeinen kunt instellen.
Vaak genoemd in dezelfde adem als de e-mailauthenticatieprotocollen SPF en DKIM, is DMARC, of Domein-gebaseerde Berichtverificatie, Rapportage en Conformance, niet op zichzelf een authenticatieprotocol. In plaats daarvan is het doel van DMARC om ons, de domeineigenaren, in staat te stellen onze e-mailreputatie te beschermen door:
Aankondigen van e-mailauthenticatiepraktijken,
Verzoeken om behandeling van e-mails die falen voor authenticatiecontroles, en
Verzoeken om rapporten over e-mails die beweren van onze domein te komen.
DMARC kan een effectief hulpmiddel voor ons zijn in de strijd tegen frauduleuze e-mails die onze domeinnaam (bijv. phishing en spoofing) gericht aanvallen, en dat kan leiden tot een groter vertrouwen van onze ontvangers in onze e-mails. Voor organisaties die end-to-end encryptie nodig hebben naast authenticatie, biedt implementatie van S/MIME met efficiënte methoden voor het verzamelen van publieke sleutels van ontvangers extra beveiligingslagen. Dit grotere vertrouwen zou op zijn beurt moeten leiden tot een hogere betrokkenheid bij onze e-mails, en e-mails die worden geopend en klikken genereren, verhogen de verkoop en een hogere ROI voor onze e-mailcampagnes.
Naast het beschermen van ons domein, voorspellen we dat het implementeren van DMARC nu een uitstekende manier zal zijn om ons domein "toekomstbestendig" te maken. Hier bij Bird geloven we dat naarmate de industrie overgaat op IPv6, het bijna zeker zal overstappen van een IP-gebaseerd reputatiemodel naar een domein-gebaseerd reputatiemodel. Domein-gebaseerde reputatie zal domein-gebaseerde authenticatie vereisen, en DMARC, in samenwerking met DKIM en SPF, zal domeinen helpen een domein-gebaseerde reputatie op te bouwen, lang voordat het absoluut noodzakelijk zou zijn.
In dit bericht vertellen we je alles wat je moet weten over het benutten van DMARC om je e-mailreputatie te beschermen en geven we je aanwijzingen over hoe je het voor je domeinen kunt instellen.
Terms to Know
Voordat we beginnen met het instellen van DMARC voor uw domein, willen we er zeker van zijn dat we dezelfde taal spreken. Laten we beginnen met het definiëren van enkele termen die we in de rest van dit document zullen gebruiken.
RFC5322.From Domain
Het RFC5322.From Domain is het domeingedeelte van het e-mailadres dat doorgaans wordt gezien door een ontvanger van onze e-mail wanneer deze wordt gelezen. In het volgende voorbeeld is het RFC5322.From domein "joesbaitshop.com"
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Domein
DKIM is een authenticatieprotocol waarmee een domein verantwoordelijkheid kan nemen voor een bericht op een manier die kan worden gevalideerd door de ontvanger van het bericht; dit wordt gedaan door cryptografische handtekeningen in de headers van het bericht in te voegen terwijl het zijn vertrekpunt verlaat. Deze handtekeningen zijn effectief momentopnames van hoe het bericht er op dat moment uitzag, en de ontvanger kan deze momentopnames gebruiken om te zien of het bericht ongewijzigd op zijn bestemming is aangekomen. Het proces van het produceren en invoegen van deze momentopnames wordt DKIM-handtekening genoemd, en het domein dat verantwoordelijkheid neemt voor het bericht door het te ondertekenen, voegt zijn naam in de header in als een sleutel-waarde tag als "d=signingDomain", en daarom wordt het het DKIM d= domein genoemd.
Return-Path Domein
Het Return-Path domein, soms het RFC5321. From Domein of het Mail From domein genoemd, is het domein waarnaar bounces worden gerouteerd; het is ook het domein waarop SPF-controles worden uitgevoerd tijdens de e-mailtransactie. Dit domein wordt meestal niet gezien door de ontvanger, tenzij de ontvanger slim genoeg is om alle headers in een gegeven bericht te bekijken.
Standaard zal alle mail die via bird.com wordt verzonden birdmail.com als Return-Path domein hebben, zoals in het volgende voorbeeld:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Om DMARC echter voor uw domein te laten werken, wilt u profiteren van een aangepast bounce-domein, een domein dat eindigt op hetzelfde domein als uw verzenddomein, bijvoorbeeld, bounces.uwdomein.com wanneer u uwdomein.com als uw verzenddomein gebruikt.
Organizational Domain
De term "Organizational Domain" verwijst naar het domein dat aan een registrar is ingediend om de aanwezigheid van het domein op het internet te creëren. Voor Bird zijn onze organisatorische domeinen bird.com en birdmail.com.
Domeinuitlijning
De laatste term om te begrijpen met betrekking tot DMARC is "Domeinuitlijning," en het komt in twee varianten: "relaxed" en "strict".
Relaxed Domeinuitlijning
Twee domeinen worden geacht een relaxed domeinuitlijning te hebben wanneer hun Organizational Domains gelijk zijn. Bijvoorbeeld, a.mail.bird.com en b.foo.bird.com hebben relaxed domeinuitlijning vanwege hun gemeenschappelijke Organizational Domain, bird.com.
Strict Domeinuitlijning
Twee domeinen worden geacht een strict domeinuitlijning te hebben als en alleen als ze identiek zijn. Dus, foo.bird.com en foo.bird.com zijn in strikte uitlijning, aangezien de twee domeinen identiek zijn. Aan de andere kant, foo.bird.com en bar.foo.bird.com hebben alleen een relaxed uitlijning.
DMARC Domeinuitlijningseisen
Om DMARC-validatiecontroles te laten slagen, vereist DMARC dat er domeinuitlijning is als volgt:
Voor SPF moeten het RFC5322.From domein en het Return-Path domein in lijn zijn
Voor DKIM moeten het RFC5322.From domein en het DKIM d= domein in lijn zijn
De uitlijning kan relaxed of strict zijn, op basis van het gepubliceerde beleid van het verzendende domein.
Voordat we beginnen met het instellen van DMARC voor uw domein, willen we er zeker van zijn dat we dezelfde taal spreken. Laten we beginnen met het definiëren van enkele termen die we in de rest van dit document zullen gebruiken.
RFC5322.From Domain
Het RFC5322.From Domain is het domeingedeelte van het e-mailadres dat doorgaans wordt gezien door een ontvanger van onze e-mail wanneer deze wordt gelezen. In het volgende voorbeeld is het RFC5322.From domein "joesbaitshop.com"
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Domein
DKIM is een authenticatieprotocol waarmee een domein verantwoordelijkheid kan nemen voor een bericht op een manier die kan worden gevalideerd door de ontvanger van het bericht; dit wordt gedaan door cryptografische handtekeningen in de headers van het bericht in te voegen terwijl het zijn vertrekpunt verlaat. Deze handtekeningen zijn effectief momentopnames van hoe het bericht er op dat moment uitzag, en de ontvanger kan deze momentopnames gebruiken om te zien of het bericht ongewijzigd op zijn bestemming is aangekomen. Het proces van het produceren en invoegen van deze momentopnames wordt DKIM-handtekening genoemd, en het domein dat verantwoordelijkheid neemt voor het bericht door het te ondertekenen, voegt zijn naam in de header in als een sleutel-waarde tag als "d=signingDomain", en daarom wordt het het DKIM d= domein genoemd.
Return-Path Domein
Het Return-Path domein, soms het RFC5321. From Domein of het Mail From domein genoemd, is het domein waarnaar bounces worden gerouteerd; het is ook het domein waarop SPF-controles worden uitgevoerd tijdens de e-mailtransactie. Dit domein wordt meestal niet gezien door de ontvanger, tenzij de ontvanger slim genoeg is om alle headers in een gegeven bericht te bekijken.
Standaard zal alle mail die via bird.com wordt verzonden birdmail.com als Return-Path domein hebben, zoals in het volgende voorbeeld:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Om DMARC echter voor uw domein te laten werken, wilt u profiteren van een aangepast bounce-domein, een domein dat eindigt op hetzelfde domein als uw verzenddomein, bijvoorbeeld, bounces.uwdomein.com wanneer u uwdomein.com als uw verzenddomein gebruikt.
Organizational Domain
De term "Organizational Domain" verwijst naar het domein dat aan een registrar is ingediend om de aanwezigheid van het domein op het internet te creëren. Voor Bird zijn onze organisatorische domeinen bird.com en birdmail.com.
Domeinuitlijning
De laatste term om te begrijpen met betrekking tot DMARC is "Domeinuitlijning," en het komt in twee varianten: "relaxed" en "strict".
Relaxed Domeinuitlijning
Twee domeinen worden geacht een relaxed domeinuitlijning te hebben wanneer hun Organizational Domains gelijk zijn. Bijvoorbeeld, a.mail.bird.com en b.foo.bird.com hebben relaxed domeinuitlijning vanwege hun gemeenschappelijke Organizational Domain, bird.com.
Strict Domeinuitlijning
Twee domeinen worden geacht een strict domeinuitlijning te hebben als en alleen als ze identiek zijn. Dus, foo.bird.com en foo.bird.com zijn in strikte uitlijning, aangezien de twee domeinen identiek zijn. Aan de andere kant, foo.bird.com en bar.foo.bird.com hebben alleen een relaxed uitlijning.
DMARC Domeinuitlijningseisen
Om DMARC-validatiecontroles te laten slagen, vereist DMARC dat er domeinuitlijning is als volgt:
Voor SPF moeten het RFC5322.From domein en het Return-Path domein in lijn zijn
Voor DKIM moeten het RFC5322.From domein en het DKIM d= domein in lijn zijn
De uitlijning kan relaxed of strict zijn, op basis van het gepubliceerde beleid van het verzendende domein.
Voordat we beginnen met het instellen van DMARC voor uw domein, willen we er zeker van zijn dat we dezelfde taal spreken. Laten we beginnen met het definiëren van enkele termen die we in de rest van dit document zullen gebruiken.
RFC5322.From Domain
Het RFC5322.From Domain is het domeingedeelte van het e-mailadres dat doorgaans wordt gezien door een ontvanger van onze e-mail wanneer deze wordt gelezen. In het volgende voorbeeld is het RFC5322.From domein "joesbaitshop.com"
From: Joe’s Bait and Tackle <sales@joesbaitshop.com>
DKIM d= Domein
DKIM is een authenticatieprotocol waarmee een domein verantwoordelijkheid kan nemen voor een bericht op een manier die kan worden gevalideerd door de ontvanger van het bericht; dit wordt gedaan door cryptografische handtekeningen in de headers van het bericht in te voegen terwijl het zijn vertrekpunt verlaat. Deze handtekeningen zijn effectief momentopnames van hoe het bericht er op dat moment uitzag, en de ontvanger kan deze momentopnames gebruiken om te zien of het bericht ongewijzigd op zijn bestemming is aangekomen. Het proces van het produceren en invoegen van deze momentopnames wordt DKIM-handtekening genoemd, en het domein dat verantwoordelijkheid neemt voor het bericht door het te ondertekenen, voegt zijn naam in de header in als een sleutel-waarde tag als "d=signingDomain", en daarom wordt het het DKIM d= domein genoemd.
Return-Path Domein
Het Return-Path domein, soms het RFC5321. From Domein of het Mail From domein genoemd, is het domein waarnaar bounces worden gerouteerd; het is ook het domein waarop SPF-controles worden uitgevoerd tijdens de e-mailtransactie. Dit domein wordt meestal niet gezien door de ontvanger, tenzij de ontvanger slim genoeg is om alle headers in een gegeven bericht te bekijken.
Standaard zal alle mail die via bird.com wordt verzonden birdmail.com als Return-Path domein hebben, zoals in het volgende voorbeeld:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Om DMARC echter voor uw domein te laten werken, wilt u profiteren van een aangepast bounce-domein, een domein dat eindigt op hetzelfde domein als uw verzenddomein, bijvoorbeeld, bounces.uwdomein.com wanneer u uwdomein.com als uw verzenddomein gebruikt.
Organizational Domain
De term "Organizational Domain" verwijst naar het domein dat aan een registrar is ingediend om de aanwezigheid van het domein op het internet te creëren. Voor Bird zijn onze organisatorische domeinen bird.com en birdmail.com.
Domeinuitlijning
De laatste term om te begrijpen met betrekking tot DMARC is "Domeinuitlijning," en het komt in twee varianten: "relaxed" en "strict".
Relaxed Domeinuitlijning
Twee domeinen worden geacht een relaxed domeinuitlijning te hebben wanneer hun Organizational Domains gelijk zijn. Bijvoorbeeld, a.mail.bird.com en b.foo.bird.com hebben relaxed domeinuitlijning vanwege hun gemeenschappelijke Organizational Domain, bird.com.
Strict Domeinuitlijning
Twee domeinen worden geacht een strict domeinuitlijning te hebben als en alleen als ze identiek zijn. Dus, foo.bird.com en foo.bird.com zijn in strikte uitlijning, aangezien de twee domeinen identiek zijn. Aan de andere kant, foo.bird.com en bar.foo.bird.com hebben alleen een relaxed uitlijning.
DMARC Domeinuitlijningseisen
Om DMARC-validatiecontroles te laten slagen, vereist DMARC dat er domeinuitlijning is als volgt:
Voor SPF moeten het RFC5322.From domein en het Return-Path domein in lijn zijn
Voor DKIM moeten het RFC5322.From domein en het DKIM d= domein in lijn zijn
De uitlijning kan relaxed of strict zijn, op basis van het gepubliceerde beleid van het verzendende domein.
Hoe DMARC Werkt om Uw Email Reputatie te Beschermen
Wanneer we spreken over een mailboxaanbieder of een ander domein die “DMARC controleren”, of “DMARC valideren”, of “DMARC policy toepassen”, bedoelen we dat het domein dat een bericht ontvangt de volgende stappen uitvoert:
Bepaal het RFC5322.From domein van het bericht
Zoek het DMARC beleid van dat domein op in DNS
Voer DKIM-handtekeningvalidatie uit
Voer SPF-validatie uit
Controleer domeinuitlijning
Pas DMARC beleid toe
Om een bericht de DMARC-validatie te laten doorstaan, moet het bericht slechts één van de twee authenticatie- en uitlijningscontroles doorstaan. Dus, een bericht slaagt voor DMARC-validatie als een van de volgende waar is:
Het bericht slaagt voor SPF-controles en het RFC5322.From domein en Return-Path domein zijn in uitlijning, of
Het bericht slaagt voor DKIM-validatie en het RFC5322.From domein en DKIM d= domein zijn in uitlijning, of
Beide bovenstaande zijn waar
Overzicht van DMARC Validatiepaden
Authenticatiepad | Domeinen vergeleken | Uitlijning vereist | DMARC slaagvoorwaarde |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | Versoepeld of strikt | SPF slaagt en domeinen komen overeen |
DKIM | RFC5322.From ↔ DKIM d= | Versoepeld of strikt | DKIM slaagt en domeinen komen overeen |
SPF + DKIM | Beide bovenstaande | Eén uitgelijnd | Eén of beide uitgelijnde controles slagen |
Wanneer we spreken over een mailboxaanbieder of een ander domein die “DMARC controleren”, of “DMARC valideren”, of “DMARC policy toepassen”, bedoelen we dat het domein dat een bericht ontvangt de volgende stappen uitvoert:
Bepaal het RFC5322.From domein van het bericht
Zoek het DMARC beleid van dat domein op in DNS
Voer DKIM-handtekeningvalidatie uit
Voer SPF-validatie uit
Controleer domeinuitlijning
Pas DMARC beleid toe
Om een bericht de DMARC-validatie te laten doorstaan, moet het bericht slechts één van de twee authenticatie- en uitlijningscontroles doorstaan. Dus, een bericht slaagt voor DMARC-validatie als een van de volgende waar is:
Het bericht slaagt voor SPF-controles en het RFC5322.From domein en Return-Path domein zijn in uitlijning, of
Het bericht slaagt voor DKIM-validatie en het RFC5322.From domein en DKIM d= domein zijn in uitlijning, of
Beide bovenstaande zijn waar
Overzicht van DMARC Validatiepaden
Authenticatiepad | Domeinen vergeleken | Uitlijning vereist | DMARC slaagvoorwaarde |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | Versoepeld of strikt | SPF slaagt en domeinen komen overeen |
DKIM | RFC5322.From ↔ DKIM d= | Versoepeld of strikt | DKIM slaagt en domeinen komen overeen |
SPF + DKIM | Beide bovenstaande | Eén uitgelijnd | Eén of beide uitgelijnde controles slagen |
Wanneer we spreken over een mailboxaanbieder of een ander domein die “DMARC controleren”, of “DMARC valideren”, of “DMARC policy toepassen”, bedoelen we dat het domein dat een bericht ontvangt de volgende stappen uitvoert:
Bepaal het RFC5322.From domein van het bericht
Zoek het DMARC beleid van dat domein op in DNS
Voer DKIM-handtekeningvalidatie uit
Voer SPF-validatie uit
Controleer domeinuitlijning
Pas DMARC beleid toe
Om een bericht de DMARC-validatie te laten doorstaan, moet het bericht slechts één van de twee authenticatie- en uitlijningscontroles doorstaan. Dus, een bericht slaagt voor DMARC-validatie als een van de volgende waar is:
Het bericht slaagt voor SPF-controles en het RFC5322.From domein en Return-Path domein zijn in uitlijning, of
Het bericht slaagt voor DKIM-validatie en het RFC5322.From domein en DKIM d= domein zijn in uitlijning, of
Beide bovenstaande zijn waar
Overzicht van DMARC Validatiepaden
Authenticatiepad | Domeinen vergeleken | Uitlijning vereist | DMARC slaagvoorwaarde |
|---|---|---|---|
SPF | RFC5322.From ↔ Return-Path | Versoepeld of strikt | SPF slaagt en domeinen komen overeen |
DKIM | RFC5322.From ↔ DKIM d= | Versoepeld of strikt | DKIM slaagt en domeinen komen overeen |
SPF + DKIM | Beide bovenstaande | Eén uitgelijnd | Eén of beide uitgelijnde controles slagen |
Hoe DMARC werkt voor uw domein
Nu we de mechanica van DMARC hebben uitgelegd, laten we eens praten over hoe we DMARC voor ons kunnen laten werken, wat de volgende drie stappen omvat:
Voorbereidingen treffen om DMARC-rapporten te ontvangen
Beslissen welk DMARC-beleid u voor uw domein wilt gebruiken
Uw DMARC-record publiceren
We zullen elk van deze in detail hieronder behandelen, maar we vertellen u meteen dat stap 1 hierboven ongeveer 95% van uw voorbereidingstijd in beslag zal nemen.
Nu we de mechanica van DMARC hebben uitgelegd, laten we eens praten over hoe we DMARC voor ons kunnen laten werken, wat de volgende drie stappen omvat:
Voorbereidingen treffen om DMARC-rapporten te ontvangen
Beslissen welk DMARC-beleid u voor uw domein wilt gebruiken
Uw DMARC-record publiceren
We zullen elk van deze in detail hieronder behandelen, maar we vertellen u meteen dat stap 1 hierboven ongeveer 95% van uw voorbereidingstijd in beslag zal nemen.
Nu we de mechanica van DMARC hebben uitgelegd, laten we eens praten over hoe we DMARC voor ons kunnen laten werken, wat de volgende drie stappen omvat:
Voorbereidingen treffen om DMARC-rapporten te ontvangen
Beslissen welk DMARC-beleid u voor uw domein wilt gebruiken
Uw DMARC-record publiceren
We zullen elk van deze in detail hieronder behandelen, maar we vertellen u meteen dat stap 1 hierboven ongeveer 95% van uw voorbereidingstijd in beslag zal nemen.
Voorbereiding om DMARC Reports te ontvangen
Elke domein dat een DMARC-beleid publiceert, moet zich eerst voorbereiden om rapporten te ontvangen over zijn domein. Deze rapporten worden gegenereerd door elk domein dat DMARC-validatie uitvoert en ziet e-mail die beweert van ons domein te zijn, en zullen ons op zijn minst dagelijks worden toegezonden. De rapporten komen in twee formaten:
Geaggregeerde rapporten, dit zijn XML-documenten die statistische gegevens tonen van hoeveel e-mail door de rapporteur van elke bron is gezien, wat de authenticatieresultaten waren en hoe de berichten door de rapporteur zijn behandeld. Geaggregeerde rapporten zijn ontworpen om door machines te worden geparsed, waarbij hun gegevens ergens worden opgeslagen om algehele verkeersanalyse, auditing van de berichtstromen van ons domein en mogelijk identificatie van trends in bronnen van niet-geauthenticeerde, mogelijk frauduleuze e-mail mogelijk te maken.
Forensische rapporten, dit zijn individuele kopieën van berichten die niet door de authenticatie kwamen, elk ingesloten in een volledige e-mailbericht in een formaat genaamd AFRF. De forensische rapporten behoren volledige headers en berichtinhouden te bevatten, maar veel rapporteurs verwijderen of redigeren bepaalde informatie vanwege privacyoverwegingen. Niettemin kan het forensisch rapport nog steeds nuttig zijn, zowel voor het oplossen van authenticatieproblemen van ons eigen domein als voor het identificeren, via URI's in de berichtinhouden, van kwaadaardige domeinen en websites die worden gebruikt om klanten van de domeineigenaar te bedriegen.
De voorbereiding om deze rapporten te ontvangen, omvat eerst het aanmaken van twee postvakken in ons domein om deze rapporten te behandelen, zoals agg_reports@ourdomain.com en afrf_reports@ourdomain.com. Let op dat die postvaknamen volledig willekeurig zijn, en er zijn geen vereisten voor de naamgeving van het lokale deel van het postvak; we zijn vrij om willekeurige namen te kiezen die we willen, maar houd de twee gescheiden voor gemakkelijker verwerking.
Zodra de postvaknamen zijn geselecteerd en aangemaakt in ons domein, is de volgende stap om hulpmiddelen in te zetten om deze postvakken te lezen en de gegevens te gebruiken, vooral de geaggregeerde gegevensrapporten, die opnieuw zijn ontworpen om door machines te worden geparsed, in plaats van door een mens te worden gelezen. De forensische rapporten kunnen daarentegen mogelijk beheersbaar zijn door ze zelf te lezen, maar ons vermogen om dat te doen zal afhangen van zowel het begrip van onze mailclient over hoe berichten in het AFRF-formaat weer te geven, als van het aantal rapporten dat we ontvangen.
Hoewel het voor ons mogelijk is om onze eigen hulpmiddelen te schrijven om DMARC-rapporten te verwerken, tot Bird dergelijke diensten biedt voor bird.com klanten (iets waar we over nadenken, maar nog niet beloven), raden we aan dat we gebruik maken van hulpmiddelen die al beschikbaar zijn voor de taak.
Elke domein dat een DMARC-beleid publiceert, moet zich eerst voorbereiden om rapporten te ontvangen over zijn domein. Deze rapporten worden gegenereerd door elk domein dat DMARC-validatie uitvoert en ziet e-mail die beweert van ons domein te zijn, en zullen ons op zijn minst dagelijks worden toegezonden. De rapporten komen in twee formaten:
Geaggregeerde rapporten, dit zijn XML-documenten die statistische gegevens tonen van hoeveel e-mail door de rapporteur van elke bron is gezien, wat de authenticatieresultaten waren en hoe de berichten door de rapporteur zijn behandeld. Geaggregeerde rapporten zijn ontworpen om door machines te worden geparsed, waarbij hun gegevens ergens worden opgeslagen om algehele verkeersanalyse, auditing van de berichtstromen van ons domein en mogelijk identificatie van trends in bronnen van niet-geauthenticeerde, mogelijk frauduleuze e-mail mogelijk te maken.
Forensische rapporten, dit zijn individuele kopieën van berichten die niet door de authenticatie kwamen, elk ingesloten in een volledige e-mailbericht in een formaat genaamd AFRF. De forensische rapporten behoren volledige headers en berichtinhouden te bevatten, maar veel rapporteurs verwijderen of redigeren bepaalde informatie vanwege privacyoverwegingen. Niettemin kan het forensisch rapport nog steeds nuttig zijn, zowel voor het oplossen van authenticatieproblemen van ons eigen domein als voor het identificeren, via URI's in de berichtinhouden, van kwaadaardige domeinen en websites die worden gebruikt om klanten van de domeineigenaar te bedriegen.
De voorbereiding om deze rapporten te ontvangen, omvat eerst het aanmaken van twee postvakken in ons domein om deze rapporten te behandelen, zoals agg_reports@ourdomain.com en afrf_reports@ourdomain.com. Let op dat die postvaknamen volledig willekeurig zijn, en er zijn geen vereisten voor de naamgeving van het lokale deel van het postvak; we zijn vrij om willekeurige namen te kiezen die we willen, maar houd de twee gescheiden voor gemakkelijker verwerking.
Zodra de postvaknamen zijn geselecteerd en aangemaakt in ons domein, is de volgende stap om hulpmiddelen in te zetten om deze postvakken te lezen en de gegevens te gebruiken, vooral de geaggregeerde gegevensrapporten, die opnieuw zijn ontworpen om door machines te worden geparsed, in plaats van door een mens te worden gelezen. De forensische rapporten kunnen daarentegen mogelijk beheersbaar zijn door ze zelf te lezen, maar ons vermogen om dat te doen zal afhangen van zowel het begrip van onze mailclient over hoe berichten in het AFRF-formaat weer te geven, als van het aantal rapporten dat we ontvangen.
Hoewel het voor ons mogelijk is om onze eigen hulpmiddelen te schrijven om DMARC-rapporten te verwerken, tot Bird dergelijke diensten biedt voor bird.com klanten (iets waar we over nadenken, maar nog niet beloven), raden we aan dat we gebruik maken van hulpmiddelen die al beschikbaar zijn voor de taak.
Elke domein dat een DMARC-beleid publiceert, moet zich eerst voorbereiden om rapporten te ontvangen over zijn domein. Deze rapporten worden gegenereerd door elk domein dat DMARC-validatie uitvoert en ziet e-mail die beweert van ons domein te zijn, en zullen ons op zijn minst dagelijks worden toegezonden. De rapporten komen in twee formaten:
Geaggregeerde rapporten, dit zijn XML-documenten die statistische gegevens tonen van hoeveel e-mail door de rapporteur van elke bron is gezien, wat de authenticatieresultaten waren en hoe de berichten door de rapporteur zijn behandeld. Geaggregeerde rapporten zijn ontworpen om door machines te worden geparsed, waarbij hun gegevens ergens worden opgeslagen om algehele verkeersanalyse, auditing van de berichtstromen van ons domein en mogelijk identificatie van trends in bronnen van niet-geauthenticeerde, mogelijk frauduleuze e-mail mogelijk te maken.
Forensische rapporten, dit zijn individuele kopieën van berichten die niet door de authenticatie kwamen, elk ingesloten in een volledige e-mailbericht in een formaat genaamd AFRF. De forensische rapporten behoren volledige headers en berichtinhouden te bevatten, maar veel rapporteurs verwijderen of redigeren bepaalde informatie vanwege privacyoverwegingen. Niettemin kan het forensisch rapport nog steeds nuttig zijn, zowel voor het oplossen van authenticatieproblemen van ons eigen domein als voor het identificeren, via URI's in de berichtinhouden, van kwaadaardige domeinen en websites die worden gebruikt om klanten van de domeineigenaar te bedriegen.
De voorbereiding om deze rapporten te ontvangen, omvat eerst het aanmaken van twee postvakken in ons domein om deze rapporten te behandelen, zoals agg_reports@ourdomain.com en afrf_reports@ourdomain.com. Let op dat die postvaknamen volledig willekeurig zijn, en er zijn geen vereisten voor de naamgeving van het lokale deel van het postvak; we zijn vrij om willekeurige namen te kiezen die we willen, maar houd de twee gescheiden voor gemakkelijker verwerking.
Zodra de postvaknamen zijn geselecteerd en aangemaakt in ons domein, is de volgende stap om hulpmiddelen in te zetten om deze postvakken te lezen en de gegevens te gebruiken, vooral de geaggregeerde gegevensrapporten, die opnieuw zijn ontworpen om door machines te worden geparsed, in plaats van door een mens te worden gelezen. De forensische rapporten kunnen daarentegen mogelijk beheersbaar zijn door ze zelf te lezen, maar ons vermogen om dat te doen zal afhangen van zowel het begrip van onze mailclient over hoe berichten in het AFRF-formaat weer te geven, als van het aantal rapporten dat we ontvangen.
Hoewel het voor ons mogelijk is om onze eigen hulpmiddelen te schrijven om DMARC-rapporten te verwerken, tot Bird dergelijke diensten biedt voor bird.com klanten (iets waar we over nadenken, maar nog niet beloven), raden we aan dat we gebruik maken van hulpmiddelen die al beschikbaar zijn voor de taak.
Welke DMARC Policy te gebruiken
De DMARC-specificatie biedt drie keuzes voor domeineigenaren om hun voorkeursbehandeling van e-mails die falen bij DMARC-validatiecontroles te specificeren. Deze zijn:
geen, wat betekent dat de e-mail op dezelfde manier wordt behandeld als het geval zou zijn zonder DMARC-validatiecontroles
quarantaine, wat betekent de e-mail accepteren, maar deze ergens anders dan de Inbox van de ontvanger plaatsen (meestal de spammap)
weigeren, wat betekent de boodschap volledig afwijzen
Het is belangrijk om te onthouden dat de domeineigenaar alleen een dergelijke behandeling kan verzoeken in zijn DMARC-record; het is aan de ontvanger van het bericht om te beslissen of hij het gevraagde beleid wel of niet zal honoreren. Sommigen zullen dit doen, terwijl anderen misschien wat milder zijn bij het toepassen van beleid, zoals alleen de-mail in de spammap te plaatsen wanneer het beleid van het domein is om te weigeren.
Wij raden al onze klanten aan om te beginnen met een beleid van geen, gewoon voor de zekerheid. Hoewel we vertrouwen hebben in ons vermogen om uw e-mail correct te authenticeren via DKIM-ondertekening, is het toch het beste om enige tijd te nemen om rapporten over uw domein te bekijken voordat u meer agressief wordt met uw DMARC-beleid.
De DMARC-specificatie biedt drie keuzes voor domeineigenaren om hun voorkeursbehandeling van e-mails die falen bij DMARC-validatiecontroles te specificeren. Deze zijn:
geen, wat betekent dat de e-mail op dezelfde manier wordt behandeld als het geval zou zijn zonder DMARC-validatiecontroles
quarantaine, wat betekent de e-mail accepteren, maar deze ergens anders dan de Inbox van de ontvanger plaatsen (meestal de spammap)
weigeren, wat betekent de boodschap volledig afwijzen
Het is belangrijk om te onthouden dat de domeineigenaar alleen een dergelijke behandeling kan verzoeken in zijn DMARC-record; het is aan de ontvanger van het bericht om te beslissen of hij het gevraagde beleid wel of niet zal honoreren. Sommigen zullen dit doen, terwijl anderen misschien wat milder zijn bij het toepassen van beleid, zoals alleen de-mail in de spammap te plaatsen wanneer het beleid van het domein is om te weigeren.
Wij raden al onze klanten aan om te beginnen met een beleid van geen, gewoon voor de zekerheid. Hoewel we vertrouwen hebben in ons vermogen om uw e-mail correct te authenticeren via DKIM-ondertekening, is het toch het beste om enige tijd te nemen om rapporten over uw domein te bekijken voordat u meer agressief wordt met uw DMARC-beleid.
De DMARC-specificatie biedt drie keuzes voor domeineigenaren om hun voorkeursbehandeling van e-mails die falen bij DMARC-validatiecontroles te specificeren. Deze zijn:
geen, wat betekent dat de e-mail op dezelfde manier wordt behandeld als het geval zou zijn zonder DMARC-validatiecontroles
quarantaine, wat betekent de e-mail accepteren, maar deze ergens anders dan de Inbox van de ontvanger plaatsen (meestal de spammap)
weigeren, wat betekent de boodschap volledig afwijzen
Het is belangrijk om te onthouden dat de domeineigenaar alleen een dergelijke behandeling kan verzoeken in zijn DMARC-record; het is aan de ontvanger van het bericht om te beslissen of hij het gevraagde beleid wel of niet zal honoreren. Sommigen zullen dit doen, terwijl anderen misschien wat milder zijn bij het toepassen van beleid, zoals alleen de-mail in de spammap te plaatsen wanneer het beleid van het domein is om te weigeren.
Wij raden al onze klanten aan om te beginnen met een beleid van geen, gewoon voor de zekerheid. Hoewel we vertrouwen hebben in ons vermogen om uw e-mail correct te authenticeren via DKIM-ondertekening, is het toch het beste om enige tijd te nemen om rapporten over uw domein te bekijken voordat u meer agressief wordt met uw DMARC-beleid.
Publiceren van Uw DMARC Policy
Het DMARC-beleid van een domein wordt aangekondigd door een DNS TXT-record op een specifieke plaats in de DNS-naamruimte te publiceren, namelijk “_dmarc.domainname.tld” (let op de onderstreping aan het begin). Een eenvoudig DMARC-beleidsrecord voor ons eerdere voorbeelddomein, joesbaitshop.com, kan er als volgt uitzien:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Dit record uitsplitsend, hebben we:
v=DMARC1 specificeert de DMARC-versie (1 is de enige keuze op dit moment)
p=none specificeert de voorkeur voor behandeling, of DMARC-beleid
rua=mailto:agg_reports@joesbait.com is de mailbox waarnaar samenvattende rapporten moeten worden verzonden
ruf=mailto:afrf_reports@joesbait.com is de mailbox waarnaar forensische rapporten moeten worden verzonden
pct=100 is het percentage e-mail waarop de domeineigenaar zijn beleid wil laten toepassen. Domeinen die net beginnen met DMARC, vooral die waarschijnlijk een hoog aantal rapporten genereren, willen hier misschien met een veel lager aantal beginnen om te zien hoe hun rapportafhandelingsprocessen de belasting aankunnen.
Er zijn ook andere configuratie-opties beschikbaar voor een domeineigenaar om te gebruiken in zijn DMARC-beleidsrecord, maar de tips die we hebben gegeven zouden een goed begin moeten zijn.
Het DMARC-beleid van een domein wordt aangekondigd door een DNS TXT-record op een specifieke plaats in de DNS-naamruimte te publiceren, namelijk “_dmarc.domainname.tld” (let op de onderstreping aan het begin). Een eenvoudig DMARC-beleidsrecord voor ons eerdere voorbeelddomein, joesbaitshop.com, kan er als volgt uitzien:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Dit record uitsplitsend, hebben we:
v=DMARC1 specificeert de DMARC-versie (1 is de enige keuze op dit moment)
p=none specificeert de voorkeur voor behandeling, of DMARC-beleid
rua=mailto:agg_reports@joesbait.com is de mailbox waarnaar samenvattende rapporten moeten worden verzonden
ruf=mailto:afrf_reports@joesbait.com is de mailbox waarnaar forensische rapporten moeten worden verzonden
pct=100 is het percentage e-mail waarop de domeineigenaar zijn beleid wil laten toepassen. Domeinen die net beginnen met DMARC, vooral die waarschijnlijk een hoog aantal rapporten genereren, willen hier misschien met een veel lager aantal beginnen om te zien hoe hun rapportafhandelingsprocessen de belasting aankunnen.
Er zijn ook andere configuratie-opties beschikbaar voor een domeineigenaar om te gebruiken in zijn DMARC-beleidsrecord, maar de tips die we hebben gegeven zouden een goed begin moeten zijn.
Het DMARC-beleid van een domein wordt aangekondigd door een DNS TXT-record op een specifieke plaats in de DNS-naamruimte te publiceren, namelijk “_dmarc.domainname.tld” (let op de onderstreping aan het begin). Een eenvoudig DMARC-beleidsrecord voor ons eerdere voorbeelddomein, joesbaitshop.com, kan er als volgt uitzien:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Dit record uitsplitsend, hebben we:
v=DMARC1 specificeert de DMARC-versie (1 is de enige keuze op dit moment)
p=none specificeert de voorkeur voor behandeling, of DMARC-beleid
rua=mailto:agg_reports@joesbait.com is de mailbox waarnaar samenvattende rapporten moeten worden verzonden
ruf=mailto:afrf_reports@joesbait.com is de mailbox waarnaar forensische rapporten moeten worden verzonden
pct=100 is het percentage e-mail waarop de domeineigenaar zijn beleid wil laten toepassen. Domeinen die net beginnen met DMARC, vooral die waarschijnlijk een hoog aantal rapporten genereren, willen hier misschien met een veel lager aantal beginnen om te zien hoe hun rapportafhandelingsprocessen de belasting aankunnen.
Er zijn ook andere configuratie-opties beschikbaar voor een domeineigenaar om te gebruiken in zijn DMARC-beleidsrecord, maar de tips die we hebben gegeven zouden een goed begin moeten zijn.
Samenvatting
Er is veel te ontdekken in de bovenstaande informatie! We hopen dat u de handleiding voor het maken van een DMARC-beleidsrecord nuttig vindt. We hopen ook dat onze uitleg over waarom DMARC belangrijk is, duidelijk maakt waarom u dit belangrijke hulpmiddel zou moeten gebruiken om uw e-mailreputatie te beschermen.
Natuurlijk is dit geen volledig of gezaghebbend document over het onderwerp. Als u dieper wilt ingaan of meer hulp wilt, is een geweldige plek om te beginnen de officiële DMARC FAQ. En het spreekt voor zich dat het MessageBird ondersteuningsteam klaarstaat om u te helpen uw MessageBird-account ook voor DMARC te configureren.
Bedankt voor het lezen—en begin vandaag nog met het beschermen van uw domeinen met DMARC!
Er is veel te ontdekken in de bovenstaande informatie! We hopen dat u de handleiding voor het maken van een DMARC-beleidsrecord nuttig vindt. We hopen ook dat onze uitleg over waarom DMARC belangrijk is, duidelijk maakt waarom u dit belangrijke hulpmiddel zou moeten gebruiken om uw e-mailreputatie te beschermen.
Natuurlijk is dit geen volledig of gezaghebbend document over het onderwerp. Als u dieper wilt ingaan of meer hulp wilt, is een geweldige plek om te beginnen de officiële DMARC FAQ. En het spreekt voor zich dat het MessageBird ondersteuningsteam klaarstaat om u te helpen uw MessageBird-account ook voor DMARC te configureren.
Bedankt voor het lezen—en begin vandaag nog met het beschermen van uw domeinen met DMARC!
Er is veel te ontdekken in de bovenstaande informatie! We hopen dat u de handleiding voor het maken van een DMARC-beleidsrecord nuttig vindt. We hopen ook dat onze uitleg over waarom DMARC belangrijk is, duidelijk maakt waarom u dit belangrijke hulpmiddel zou moeten gebruiken om uw e-mailreputatie te beschermen.
Natuurlijk is dit geen volledig of gezaghebbend document over het onderwerp. Als u dieper wilt ingaan of meer hulp wilt, is een geweldige plek om te beginnen de officiële DMARC FAQ. En het spreekt voor zich dat het MessageBird ondersteuningsteam klaarstaat om u te helpen uw MessageBird-account ook voor DMARC te configureren.
Bedankt voor het lezen—en begin vandaag nog met het beschermen van uw domeinen met DMARC!
