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 deze post vertellen we je alles wat je moet weten over het gebruik van DMARC om je e-mailreputatie te beschermen, en geven we je tips over hoe je het voor je domeinen kunt instellen.
Een Effectieve Tool om Frauduleuze Mail te Bestrijden
Vaak genoemd in dezelfde adem als de e-mailauthenticatieprotocollen SPF en DKIM, is DMARC, of Domain-based Message Authentication, Reporting, and 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:
Aankondiging van e-mailauthenticatiepraktijken,
Verzoeken om behandeling voor e-mail die niet slaagt voor authenticatiecontroles, en
Verzoeken om rapporten over e-mail die beweert van het domein afkomstig te zijn.
DMARC kan een effectief hulpmiddel voor ons zijn in onze strijd tegen frauduleuze e-mails die onze domeinnaam targeten (bijv. phishing en spoofing), en die een hoger vertrouwen onder onze ontvangers voor onze e-mail kan bevorderen. Voor organisaties die end-to-end encryptie eisen bovenop authenticatie, biedt de implementatie van S/MIME met efficiënte methoden voor het verzamelen van openbare sleutels van ontvangers extra beveiligingslagen. Dit hogere vertrouwen zou op zijn beurt moeten leiden tot meer betrokkenheid bij onze e-mails, en e-mails die worden geopend en klikken genereren, zorgen voor verkoop en een hogere ROI voor onze e-mailcampagnes.
Naast het beschermen van ons domein, voorspellen we dat het nu implementeren van DMARC een uitstekende manier zal zijn om ons domein 'toekomstbestendig' te maken. Hier bij Bird geloven we dat naarmate de industrie overgaat op IPv6, het vrijwel zeker zal overgaan van een IP-gebaseerd reputatiemodel naar een domeingebaseerd reputatiemodel. Domeingebaseerde reputatie zal domeingebaseerde authenticatie vereisen, en DMARC, in combinatie met DKIM en SPF, zal domeinen helpen een domeingebaseerde reputatie op te bouwen lang voordat dit absoluut noodzakelijk is.
In deze post vertellen we je alles wat je moet weten over het benutten van DMARC om je e-mailreputatie te beschermen en geven we je tips over hoe je het voor je domeinen kunt instellen.
Vaak genoemd in dezelfde adem als de e-mailauthenticatieprotocollen SPF en DKIM, is DMARC, of Domain-based Message Authentication, Reporting, and 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:
Aankondiging van e-mailauthenticatiepraktijken,
Verzoeken om behandeling voor e-mail die niet slaagt voor authenticatiecontroles, en
Verzoeken om rapporten over e-mail die beweert van het domein afkomstig te zijn.
DMARC kan een effectief hulpmiddel voor ons zijn in onze strijd tegen frauduleuze e-mails die onze domeinnaam targeten (bijv. phishing en spoofing), en die een hoger vertrouwen onder onze ontvangers voor onze e-mail kan bevorderen. Voor organisaties die end-to-end encryptie eisen bovenop authenticatie, biedt de implementatie van S/MIME met efficiënte methoden voor het verzamelen van openbare sleutels van ontvangers extra beveiligingslagen. Dit hogere vertrouwen zou op zijn beurt moeten leiden tot meer betrokkenheid bij onze e-mails, en e-mails die worden geopend en klikken genereren, zorgen voor verkoop en een hogere ROI voor onze e-mailcampagnes.
Naast het beschermen van ons domein, voorspellen we dat het nu implementeren van DMARC een uitstekende manier zal zijn om ons domein 'toekomstbestendig' te maken. Hier bij Bird geloven we dat naarmate de industrie overgaat op IPv6, het vrijwel zeker zal overgaan van een IP-gebaseerd reputatiemodel naar een domeingebaseerd reputatiemodel. Domeingebaseerde reputatie zal domeingebaseerde authenticatie vereisen, en DMARC, in combinatie met DKIM en SPF, zal domeinen helpen een domeingebaseerde reputatie op te bouwen lang voordat dit absoluut noodzakelijk is.
In deze post vertellen we je alles wat je moet weten over het benutten van DMARC om je e-mailreputatie te beschermen en geven we je tips over hoe je het voor je domeinen kunt instellen.
Vaak genoemd in dezelfde adem als de e-mailauthenticatieprotocollen SPF en DKIM, is DMARC, of Domain-based Message Authentication, Reporting, and 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:
Aankondiging van e-mailauthenticatiepraktijken,
Verzoeken om behandeling voor e-mail die niet slaagt voor authenticatiecontroles, en
Verzoeken om rapporten over e-mail die beweert van het domein afkomstig te zijn.
DMARC kan een effectief hulpmiddel voor ons zijn in onze strijd tegen frauduleuze e-mails die onze domeinnaam targeten (bijv. phishing en spoofing), en die een hoger vertrouwen onder onze ontvangers voor onze e-mail kan bevorderen. Voor organisaties die end-to-end encryptie eisen bovenop authenticatie, biedt de implementatie van S/MIME met efficiënte methoden voor het verzamelen van openbare sleutels van ontvangers extra beveiligingslagen. Dit hogere vertrouwen zou op zijn beurt moeten leiden tot meer betrokkenheid bij onze e-mails, en e-mails die worden geopend en klikken genereren, zorgen voor verkoop en een hogere ROI voor onze e-mailcampagnes.
Naast het beschermen van ons domein, voorspellen we dat het nu implementeren van DMARC een uitstekende manier zal zijn om ons domein 'toekomstbestendig' te maken. Hier bij Bird geloven we dat naarmate de industrie overgaat op IPv6, het vrijwel zeker zal overgaan van een IP-gebaseerd reputatiemodel naar een domeingebaseerd reputatiemodel. Domeingebaseerde reputatie zal domeingebaseerde authenticatie vereisen, en DMARC, in combinatie met DKIM en SPF, zal domeinen helpen een domeingebaseerde reputatie op te bouwen lang voordat dit absoluut noodzakelijk is.
In deze post vertellen we je alles wat je moet weten over het benutten van DMARC om je e-mailreputatie te beschermen en geven we je tips over hoe je het voor je domeinen kunt instellen.
Termen om te weten
Voordat we beginnen met het instellen van DMARC voor uw domein, willen we ervoor zorgen dat we dezelfde taal spreken. Laten we beginnen met het definiëren van enkele termen die we door de rest van dit document zullen gebruiken.
RFC5322.From Domain
De RFC5322.From Domain is het domeindeel van het e-mailadres dat meestal 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= Domain
DKIM is een authenticatieprotocol dat een domein in staat stelt verantwoordelijkheid te nemen voor een bericht op een manier die door de ontvanger van het bericht kan worden gevalideerd; dit wordt gedaan door het gebruik van cryptografische handtekeningen die in de headers van het bericht worden ingevoegd terwijl deze het oorsprongspunt verlaten. Deze handtekeningen zijn feitelijk 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-ondertekening genoemd, en het domein dat verantwoordelijk is voor het bericht door het te ondertekenen, voegt zijn naam in de header in een sleutel-waarde tag in als "d=signingDomain", en daarom wordt het aangeduid als het DKIM d= domein.
Return-Path Domain
Het Return-Path domein, soms het RFC5321. From Domain 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 voldoende bekend is om alle headers in een bepaald bericht te bekijken.
Standaard zal alle e-mail die via bird.com wordt verzonden birdmail.com als zijn Return-Path domein hebben, zoals in het volgende voorbeeld:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Om DMARC echter te laten werken voor uw domein, wilt u profiteren van een aangepast bounce-domein, een dat zal eindigen in hetzelfde domein als uw zendende domein, bijvoorbeeld bounces.yourdomain.com wanneer u yourdomain.com als uw zendende domein gebruikt.
Organisatorisch Domein
De term "Organisatorisch Domein" verwijst naar het domein dat werd ingediend bij een registrar 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."
Ontspannen Domeinuitlijning
Twee domeinen worden gezegd een ontspannen domeinuitlijning te hebben wanneer hun organisatorische domeinen hetzelfde zijn. Bijvoorbeeld, a.mail.bird.com en b.foo.bird.com hebben een ontspannen domeinuitlijning vanwege hun gemeenschappelijke organisatorische domein, bird.com.
Strikte Domeinuitlijning
Twee domeinen worden gezegd in strikte domeinuitlijning te zijn 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 zijn foo.bird.com en bar.foo.bird.com alleen in ontspannen uitlijning.
DMARC Domeinuitlijning Eisen
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 uitlijning zijn
Voor DKIM moeten het RFC5322.From domein en het DKIM d= domein in uitlijning zijn
De uitlijning kan ontspannen of strikt zijn, gebaseerd op het gepubliceerde beleid van het zendende domein.
Voordat we beginnen met het instellen van DMARC voor uw domein, willen we ervoor zorgen dat we dezelfde taal spreken. Laten we beginnen met het definiëren van enkele termen die we door de rest van dit document zullen gebruiken.
RFC5322.From Domain
De RFC5322.From Domain is het domeindeel van het e-mailadres dat meestal 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= Domain
DKIM is een authenticatieprotocol dat een domein in staat stelt verantwoordelijkheid te nemen voor een bericht op een manier die door de ontvanger van het bericht kan worden gevalideerd; dit wordt gedaan door het gebruik van cryptografische handtekeningen die in de headers van het bericht worden ingevoegd terwijl deze het oorsprongspunt verlaten. Deze handtekeningen zijn feitelijk 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-ondertekening genoemd, en het domein dat verantwoordelijk is voor het bericht door het te ondertekenen, voegt zijn naam in de header in een sleutel-waarde tag in als "d=signingDomain", en daarom wordt het aangeduid als het DKIM d= domein.
Return-Path Domain
Het Return-Path domein, soms het RFC5321. From Domain 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 voldoende bekend is om alle headers in een bepaald bericht te bekijken.
Standaard zal alle e-mail die via bird.com wordt verzonden birdmail.com als zijn Return-Path domein hebben, zoals in het volgende voorbeeld:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Om DMARC echter te laten werken voor uw domein, wilt u profiteren van een aangepast bounce-domein, een dat zal eindigen in hetzelfde domein als uw zendende domein, bijvoorbeeld bounces.yourdomain.com wanneer u yourdomain.com als uw zendende domein gebruikt.
Organisatorisch Domein
De term "Organisatorisch Domein" verwijst naar het domein dat werd ingediend bij een registrar 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."
Ontspannen Domeinuitlijning
Twee domeinen worden gezegd een ontspannen domeinuitlijning te hebben wanneer hun organisatorische domeinen hetzelfde zijn. Bijvoorbeeld, a.mail.bird.com en b.foo.bird.com hebben een ontspannen domeinuitlijning vanwege hun gemeenschappelijke organisatorische domein, bird.com.
Strikte Domeinuitlijning
Twee domeinen worden gezegd in strikte domeinuitlijning te zijn 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 zijn foo.bird.com en bar.foo.bird.com alleen in ontspannen uitlijning.
DMARC Domeinuitlijning Eisen
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 uitlijning zijn
Voor DKIM moeten het RFC5322.From domein en het DKIM d= domein in uitlijning zijn
De uitlijning kan ontspannen of strikt zijn, gebaseerd op het gepubliceerde beleid van het zendende domein.
Voordat we beginnen met het instellen van DMARC voor uw domein, willen we ervoor zorgen dat we dezelfde taal spreken. Laten we beginnen met het definiëren van enkele termen die we door de rest van dit document zullen gebruiken.
RFC5322.From Domain
De RFC5322.From Domain is het domeindeel van het e-mailadres dat meestal 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= Domain
DKIM is een authenticatieprotocol dat een domein in staat stelt verantwoordelijkheid te nemen voor een bericht op een manier die door de ontvanger van het bericht kan worden gevalideerd; dit wordt gedaan door het gebruik van cryptografische handtekeningen die in de headers van het bericht worden ingevoegd terwijl deze het oorsprongspunt verlaten. Deze handtekeningen zijn feitelijk 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-ondertekening genoemd, en het domein dat verantwoordelijk is voor het bericht door het te ondertekenen, voegt zijn naam in de header in een sleutel-waarde tag in als "d=signingDomain", en daarom wordt het aangeduid als het DKIM d= domein.
Return-Path Domain
Het Return-Path domein, soms het RFC5321. From Domain 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 voldoende bekend is om alle headers in een bepaald bericht te bekijken.
Standaard zal alle e-mail die via bird.com wordt verzonden birdmail.com als zijn Return-Path domein hebben, zoals in het volgende voorbeeld:
Return-Path: <msprvs1=16880EmYZo7L3=bounces-2785@birdmail1.com>
Om DMARC echter te laten werken voor uw domein, wilt u profiteren van een aangepast bounce-domein, een dat zal eindigen in hetzelfde domein als uw zendende domein, bijvoorbeeld bounces.yourdomain.com wanneer u yourdomain.com als uw zendende domein gebruikt.
Organisatorisch Domein
De term "Organisatorisch Domein" verwijst naar het domein dat werd ingediend bij een registrar 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."
Ontspannen Domeinuitlijning
Twee domeinen worden gezegd een ontspannen domeinuitlijning te hebben wanneer hun organisatorische domeinen hetzelfde zijn. Bijvoorbeeld, a.mail.bird.com en b.foo.bird.com hebben een ontspannen domeinuitlijning vanwege hun gemeenschappelijke organisatorische domein, bird.com.
Strikte Domeinuitlijning
Twee domeinen worden gezegd in strikte domeinuitlijning te zijn 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 zijn foo.bird.com en bar.foo.bird.com alleen in ontspannen uitlijning.
DMARC Domeinuitlijning Eisen
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 uitlijning zijn
Voor DKIM moeten het RFC5322.From domein en het DKIM d= domein in uitlijning zijn
De uitlijning kan ontspannen of strikt zijn, gebaseerd op het gepubliceerde beleid van het zendende domein.
Hoe DMARC Werkt om Uw Emailreputatie te Beschermen
Wanneer we spreken over een mailboxprovider of een ander domein dat "DMARC controleert", of "DMARC valideert", of "DMARC-beleid toepast", 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 te laten slagen voor DMARC-validatie, moet het bericht slechts een van de twee verificatie- en uitlijningscontroles doorstaan. Dus, een bericht zal slagen voor DMARC-validatie als een van de volgende waar is:
Het bericht slaagt voor SPF-controles en het RFC5322.From-domein en het Return-Path-domein zijn in lijn, of
Het bericht slaagt voor DKIM-validatie en het RFC5322.From-domein en het DKIM d=-domein zijn in lijn, of
Beide bovenstaande zijn waar
Wanneer we spreken over een mailboxprovider of een ander domein dat "DMARC controleert", of "DMARC valideert", of "DMARC-beleid toepast", 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 te laten slagen voor DMARC-validatie, moet het bericht slechts een van de twee verificatie- en uitlijningscontroles doorstaan. Dus, een bericht zal slagen voor DMARC-validatie als een van de volgende waar is:
Het bericht slaagt voor SPF-controles en het RFC5322.From-domein en het Return-Path-domein zijn in lijn, of
Het bericht slaagt voor DKIM-validatie en het RFC5322.From-domein en het DKIM d=-domein zijn in lijn, of
Beide bovenstaande zijn waar
Wanneer we spreken over een mailboxprovider of een ander domein dat "DMARC controleert", of "DMARC valideert", of "DMARC-beleid toepast", 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 te laten slagen voor DMARC-validatie, moet het bericht slechts een van de twee verificatie- en uitlijningscontroles doorstaan. Dus, een bericht zal slagen voor DMARC-validatie als een van de volgende waar is:
Het bericht slaagt voor SPF-controles en het RFC5322.From-domein en het Return-Path-domein zijn in lijn, of
Het bericht slaagt voor DKIM-validatie en het RFC5322.From-domein en het DKIM d=-domein zijn in lijn, of
Beide bovenstaande zijn waar
DMARC Werkend Maken voor Uw Domein
Nu we de mechanica van DMARC hebben uitgelegd, laten we het hebben 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 voor je domein te gebruiken
Je DMARC-record publiceren
We zullen elk van deze hieronder in detail behandelen, maar we vertellen je direct dat stap 1 hierboven ongeveer 95% van je voorbereidingstijd zal innemen.
Nu we de mechanica van DMARC hebben uitgelegd, laten we het hebben 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 voor je domein te gebruiken
Je DMARC-record publiceren
We zullen elk van deze hieronder in detail behandelen, maar we vertellen je direct dat stap 1 hierboven ongeveer 95% van je voorbereidingstijd zal innemen.
Nu we de mechanica van DMARC hebben uitgelegd, laten we het hebben 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 voor je domein te gebruiken
Je DMARC-record publiceren
We zullen elk van deze hieronder in detail behandelen, maar we vertellen je direct dat stap 1 hierboven ongeveer 95% van je voorbereidingstijd zal innemen.
Voorbereiding voor het ontvangen van DMARC-rapporten
Elke domein dat een DMARC-beleid publiceert, moet zich eerst voorbereiden om rapporten over zijn domein te ontvangen. Deze rapporten zullen worden gegenereerd door elk domein dat DMARC-validatie uitvoert en e-mail ziet die beweert van ons domein te zijn, en zullen ons ten minste dagelijks worden toegestuurd. De rapporten zullen in twee formaten komen:
Aggregatierapporten, dit zijn XML-documenten die statistische gegevens tonen over hoeveel e-mail de verslaggever van elke bron heeft gezien, wat de authenticatieresultaten waren en hoe de berichten door de verslaggever werden behandeld. Aggregatierapporten zijn ontworpen om machinaal te worden geparsed, waarbij hun gegevens ergens worden opgeslagen om algemene verkeersanalyses, 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 authenticatie niet hebben doorstaan, elk bijgevoegd in een volledig e-mailbericht met een formaat genaamd AFRF. De forensische rapporten zouden volledige headers en berichtenlichamen moeten bevatten, maar veel verslaggevers strippen of redigeren enkele informatie vanwege privacykwesties. Desondanks kan het forensische rapport nog steeds nuttig zijn zowel voor het oplossen van authenticatieproblemen van ons eigen domein als voor het identificeren van kwaadaardige domeinen en websites die worden gebruikt om de klanten van de eigenaar van ons domein te misleiden, aan de hand van URI's in de berichtlichamen.
De voorbereiding om deze rapporten te ontvangen houdt in dat eerst twee mailboxen in ons domein worden aangemaakt om deze rapporten te verwerken, zoals agg_reports@ourdomain.com en afrf_reports@ourdomain.com. Merk op dat die mailboxnamen volledig willekeurig zijn en er geen vereisten zijn voor de naamgeving van het lokale deel van de mailbox; we zijn vrij om willekeurige namen te kiezen, maar houd ze gescheiden voor eenvoudigere verwerking.
Zodra de mailboxnamen zijn geselecteerd en aangemaakt in ons domein, is de volgende stap hier om tools op te zetten om deze mailboxen te lezen en gebruik te maken van de gegevens, vooral de aggregatiegegevensrapporten, die weer zijn ontworpen om machinaal te worden geparsed, in plaats van door een mens te worden gelezen. De forensische rapporten, aan de andere kant, kunnen mogelijk beheersbaar zijn door ze zelf te lezen, maar ons vermogen om dit te doen zal afhangen van zowel het begrip van onze mailclient over hoe berichten in het AFRF-formaat weer te geven als van het volume van de rapporten die we ontvangen.
Hoewel het mogelijk is voor ons om onze eigen tools te schrijven om DMARC-rapporten te verwerken, totdat Bird dergelijke diensten aanbiedt voor bird.com-klanten (iets waar we aan denken, maar nog niet beloven), raden we aan gebruik te maken van al beschikbare tools voor de taak.
Elke domein dat een DMARC-beleid publiceert, moet zich eerst voorbereiden om rapporten over zijn domein te ontvangen. Deze rapporten zullen worden gegenereerd door elk domein dat DMARC-validatie uitvoert en e-mail ziet die beweert van ons domein te zijn, en zullen ons ten minste dagelijks worden toegestuurd. De rapporten zullen in twee formaten komen:
Aggregatierapporten, dit zijn XML-documenten die statistische gegevens tonen over hoeveel e-mail de verslaggever van elke bron heeft gezien, wat de authenticatieresultaten waren en hoe de berichten door de verslaggever werden behandeld. Aggregatierapporten zijn ontworpen om machinaal te worden geparsed, waarbij hun gegevens ergens worden opgeslagen om algemene verkeersanalyses, 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 authenticatie niet hebben doorstaan, elk bijgevoegd in een volledig e-mailbericht met een formaat genaamd AFRF. De forensische rapporten zouden volledige headers en berichtenlichamen moeten bevatten, maar veel verslaggevers strippen of redigeren enkele informatie vanwege privacykwesties. Desondanks kan het forensische rapport nog steeds nuttig zijn zowel voor het oplossen van authenticatieproblemen van ons eigen domein als voor het identificeren van kwaadaardige domeinen en websites die worden gebruikt om de klanten van de eigenaar van ons domein te misleiden, aan de hand van URI's in de berichtlichamen.
De voorbereiding om deze rapporten te ontvangen houdt in dat eerst twee mailboxen in ons domein worden aangemaakt om deze rapporten te verwerken, zoals agg_reports@ourdomain.com en afrf_reports@ourdomain.com. Merk op dat die mailboxnamen volledig willekeurig zijn en er geen vereisten zijn voor de naamgeving van het lokale deel van de mailbox; we zijn vrij om willekeurige namen te kiezen, maar houd ze gescheiden voor eenvoudigere verwerking.
Zodra de mailboxnamen zijn geselecteerd en aangemaakt in ons domein, is de volgende stap hier om tools op te zetten om deze mailboxen te lezen en gebruik te maken van de gegevens, vooral de aggregatiegegevensrapporten, die weer zijn ontworpen om machinaal te worden geparsed, in plaats van door een mens te worden gelezen. De forensische rapporten, aan de andere kant, kunnen mogelijk beheersbaar zijn door ze zelf te lezen, maar ons vermogen om dit te doen zal afhangen van zowel het begrip van onze mailclient over hoe berichten in het AFRF-formaat weer te geven als van het volume van de rapporten die we ontvangen.
Hoewel het mogelijk is voor ons om onze eigen tools te schrijven om DMARC-rapporten te verwerken, totdat Bird dergelijke diensten aanbiedt voor bird.com-klanten (iets waar we aan denken, maar nog niet beloven), raden we aan gebruik te maken van al beschikbare tools voor de taak.
Elke domein dat een DMARC-beleid publiceert, moet zich eerst voorbereiden om rapporten over zijn domein te ontvangen. Deze rapporten zullen worden gegenereerd door elk domein dat DMARC-validatie uitvoert en e-mail ziet die beweert van ons domein te zijn, en zullen ons ten minste dagelijks worden toegestuurd. De rapporten zullen in twee formaten komen:
Aggregatierapporten, dit zijn XML-documenten die statistische gegevens tonen over hoeveel e-mail de verslaggever van elke bron heeft gezien, wat de authenticatieresultaten waren en hoe de berichten door de verslaggever werden behandeld. Aggregatierapporten zijn ontworpen om machinaal te worden geparsed, waarbij hun gegevens ergens worden opgeslagen om algemene verkeersanalyses, 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 authenticatie niet hebben doorstaan, elk bijgevoegd in een volledig e-mailbericht met een formaat genaamd AFRF. De forensische rapporten zouden volledige headers en berichtenlichamen moeten bevatten, maar veel verslaggevers strippen of redigeren enkele informatie vanwege privacykwesties. Desondanks kan het forensische rapport nog steeds nuttig zijn zowel voor het oplossen van authenticatieproblemen van ons eigen domein als voor het identificeren van kwaadaardige domeinen en websites die worden gebruikt om de klanten van de eigenaar van ons domein te misleiden, aan de hand van URI's in de berichtlichamen.
De voorbereiding om deze rapporten te ontvangen houdt in dat eerst twee mailboxen in ons domein worden aangemaakt om deze rapporten te verwerken, zoals agg_reports@ourdomain.com en afrf_reports@ourdomain.com. Merk op dat die mailboxnamen volledig willekeurig zijn en er geen vereisten zijn voor de naamgeving van het lokale deel van de mailbox; we zijn vrij om willekeurige namen te kiezen, maar houd ze gescheiden voor eenvoudigere verwerking.
Zodra de mailboxnamen zijn geselecteerd en aangemaakt in ons domein, is de volgende stap hier om tools op te zetten om deze mailboxen te lezen en gebruik te maken van de gegevens, vooral de aggregatiegegevensrapporten, die weer zijn ontworpen om machinaal te worden geparsed, in plaats van door een mens te worden gelezen. De forensische rapporten, aan de andere kant, kunnen mogelijk beheersbaar zijn door ze zelf te lezen, maar ons vermogen om dit te doen zal afhangen van zowel het begrip van onze mailclient over hoe berichten in het AFRF-formaat weer te geven als van het volume van de rapporten die we ontvangen.
Hoewel het mogelijk is voor ons om onze eigen tools te schrijven om DMARC-rapporten te verwerken, totdat Bird dergelijke diensten aanbiedt voor bird.com-klanten (iets waar we aan denken, maar nog niet beloven), raden we aan gebruik te maken van al beschikbare tools voor de taak.
Welke DMARC Policy te Gebruiken
De DMARC-specificatie biedt drie keuzes voor domeineigenaren om hun voorkeur voor de behandeling van mail die niet slaagt voor DMARC-validatiecontroles te specificeren. Deze zijn:
none, wat betekent dat de mail hetzelfde moet worden behandeld als het zou worden behandeld onafhankelijk van DMARC-validatiecontroles
quarantine, wat betekent dat de mail wordt geaccepteerd, maar ergens anders wordt geplaatst dan de Inbox van de ontvanger (meestal de spambox)
reject, wat betekent dat het bericht meteen wordt afgewezen
Het is belangrijk om in gedachten te houden dat de domeineigenaar slechts een dergelijke behandeling kan aanvragen in zijn DMARC-record; het is aan de ontvanger van het bericht om te beslissen of hij het gevraagde beleid al dan niet wil naleven. Sommigen zullen dit doen, terwijl anderen misschien wat soepeler zijn in het toepassen van beleid, zoals alleen e-mails in de spambox plaatsen wanneer het beleid van het domein reject is.
We raden al onze klanten aan om te beginnen met een beleid van none, simpelweg om veilig te zijn. Hoewel we vertrouwen hebben in onze mogelijkheid om uw mail correct te authenticeren via DKIM-ondertekening, is het nog steeds het beste om de tijd te nemen om rapporten over uw domein te onderzoeken voordat uw DMARC-beleid agressiever wordt.
De DMARC-specificatie biedt drie keuzes voor domeineigenaren om hun voorkeur voor de behandeling van mail die niet slaagt voor DMARC-validatiecontroles te specificeren. Deze zijn:
none, wat betekent dat de mail hetzelfde moet worden behandeld als het zou worden behandeld onafhankelijk van DMARC-validatiecontroles
quarantine, wat betekent dat de mail wordt geaccepteerd, maar ergens anders wordt geplaatst dan de Inbox van de ontvanger (meestal de spambox)
reject, wat betekent dat het bericht meteen wordt afgewezen
Het is belangrijk om in gedachten te houden dat de domeineigenaar slechts een dergelijke behandeling kan aanvragen in zijn DMARC-record; het is aan de ontvanger van het bericht om te beslissen of hij het gevraagde beleid al dan niet wil naleven. Sommigen zullen dit doen, terwijl anderen misschien wat soepeler zijn in het toepassen van beleid, zoals alleen e-mails in de spambox plaatsen wanneer het beleid van het domein reject is.
We raden al onze klanten aan om te beginnen met een beleid van none, simpelweg om veilig te zijn. Hoewel we vertrouwen hebben in onze mogelijkheid om uw mail correct te authenticeren via DKIM-ondertekening, is het nog steeds het beste om de tijd te nemen om rapporten over uw domein te onderzoeken voordat uw DMARC-beleid agressiever wordt.
De DMARC-specificatie biedt drie keuzes voor domeineigenaren om hun voorkeur voor de behandeling van mail die niet slaagt voor DMARC-validatiecontroles te specificeren. Deze zijn:
none, wat betekent dat de mail hetzelfde moet worden behandeld als het zou worden behandeld onafhankelijk van DMARC-validatiecontroles
quarantine, wat betekent dat de mail wordt geaccepteerd, maar ergens anders wordt geplaatst dan de Inbox van de ontvanger (meestal de spambox)
reject, wat betekent dat het bericht meteen wordt afgewezen
Het is belangrijk om in gedachten te houden dat de domeineigenaar slechts een dergelijke behandeling kan aanvragen in zijn DMARC-record; het is aan de ontvanger van het bericht om te beslissen of hij het gevraagde beleid al dan niet wil naleven. Sommigen zullen dit doen, terwijl anderen misschien wat soepeler zijn in het toepassen van beleid, zoals alleen e-mails in de spambox plaatsen wanneer het beleid van het domein reject is.
We raden al onze klanten aan om te beginnen met een beleid van none, simpelweg om veilig te zijn. Hoewel we vertrouwen hebben in onze mogelijkheid om uw mail correct te authenticeren via DKIM-ondertekening, is het nog steeds het beste om de tijd te nemen om rapporten over uw domein te onderzoeken voordat uw DMARC-beleid agressiever wordt.
Uw DMARC-beleid publiceren
Het DMARC-beleid van een domein wordt aangekondigd door een DNS TXT-record te publiceren op een specifieke plaats in de DNS-naamruimte, namelijk "_dmarc.domainname.tld" (let op de voorloopunderscore). Een eenvoudig DMARC-beleidsrecord voor ons voorbeeld-domein van eerder, joesbaitshop.com, zou er ongeveer zo uit kunnen zien:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Als we dit record opsplitsen, hebben we:
v=DMARC1 specificeert de DMARC-versie (1 is momenteel de enige keuze)
p=none specificeert de gewenste behandeling, of DMARC-beleid
rua=mailto:agg_reports@joesbait.com is de mailbox waarnaar aggregatierapporten moeten worden gestuurd
ruf=mailto:afrf_reports@joesbait.com is de mailbox waarnaar forensische rapporten moeten worden gestuurd
pct=100 is het percentage e-mail waarop de domeineigenaar zijn beleid wil toepassen. Domeinen die net beginnen met DMARC, vooral die welke waarschijnlijk een groot aantal rapporten genereren, willen hier misschien beginnen met een veel lager getal om te zien hoe hun rapportafhandelingsprocessen bestand zijn tegen de belasting.
Er zijn ook andere configuratieopties 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 te publiceren op een specifieke plaats in de DNS-naamruimte, namelijk "_dmarc.domainname.tld" (let op de voorloopunderscore). Een eenvoudig DMARC-beleidsrecord voor ons voorbeeld-domein van eerder, joesbaitshop.com, zou er ongeveer zo uit kunnen zien:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Als we dit record opsplitsen, hebben we:
v=DMARC1 specificeert de DMARC-versie (1 is momenteel de enige keuze)
p=none specificeert de gewenste behandeling, of DMARC-beleid
rua=mailto:agg_reports@joesbait.com is de mailbox waarnaar aggregatierapporten moeten worden gestuurd
ruf=mailto:afrf_reports@joesbait.com is de mailbox waarnaar forensische rapporten moeten worden gestuurd
pct=100 is het percentage e-mail waarop de domeineigenaar zijn beleid wil toepassen. Domeinen die net beginnen met DMARC, vooral die welke waarschijnlijk een groot aantal rapporten genereren, willen hier misschien beginnen met een veel lager getal om te zien hoe hun rapportafhandelingsprocessen bestand zijn tegen de belasting.
Er zijn ook andere configuratieopties 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 te publiceren op een specifieke plaats in de DNS-naamruimte, namelijk "_dmarc.domainname.tld" (let op de voorloopunderscore). Een eenvoudig DMARC-beleidsrecord voor ons voorbeeld-domein van eerder, joesbaitshop.com, zou er ongeveer zo uit kunnen zien:
_dmarc.joesbaitship.com. IN TXT "v=DMARC1; p=none; rua=mailto:agg_reports@joesbait.com; ruf=mailto:afrf_reports@joesbait.com; pct=100"
Als we dit record opsplitsen, hebben we:
v=DMARC1 specificeert de DMARC-versie (1 is momenteel de enige keuze)
p=none specificeert de gewenste behandeling, of DMARC-beleid
rua=mailto:agg_reports@joesbait.com is de mailbox waarnaar aggregatierapporten moeten worden gestuurd
ruf=mailto:afrf_reports@joesbait.com is de mailbox waarnaar forensische rapporten moeten worden gestuurd
pct=100 is het percentage e-mail waarop de domeineigenaar zijn beleid wil toepassen. Domeinen die net beginnen met DMARC, vooral die welke waarschijnlijk een groot aantal rapporten genereren, willen hier misschien beginnen met een veel lager getal om te zien hoe hun rapportafhandelingsprocessen bestand zijn tegen de belasting.
Er zijn ook andere configuratieopties 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 valt veel te ontdekken in de bovenstaande informatie! We hopen dat je 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 je dit belangrijke hulpmiddel zou moeten gaan gebruiken om je e-mailreputatie te beschermen.
Natuurlijk is dit geen volledig of gezaghebbend document over dit onderwerp. Als je dieper wilt graven of meer hulp wilt, is een geweldige plek om te beginnen de officiële DMARC FAQ. En, het spreekt voor zich dat het Bird supportteam ook klaarstaat om je te helpen je Bird-account voor DMARC te configureren.
Bedankt voor het lezen—en begin vandaag nog met het beschermen van je domeinen met DMARC!
Er valt veel te ontdekken in de bovenstaande informatie! We hopen dat je 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 je dit belangrijke hulpmiddel zou moeten gaan gebruiken om je e-mailreputatie te beschermen.
Natuurlijk is dit geen volledig of gezaghebbend document over dit onderwerp. Als je dieper wilt graven of meer hulp wilt, is een geweldige plek om te beginnen de officiële DMARC FAQ. En, het spreekt voor zich dat het Bird supportteam ook klaarstaat om je te helpen je Bird-account voor DMARC te configureren.
Bedankt voor het lezen—en begin vandaag nog met het beschermen van je domeinen met DMARC!
Er valt veel te ontdekken in de bovenstaande informatie! We hopen dat je 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 je dit belangrijke hulpmiddel zou moeten gaan gebruiken om je e-mailreputatie te beschermen.
Natuurlijk is dit geen volledig of gezaghebbend document over dit onderwerp. Als je dieper wilt graven of meer hulp wilt, is een geweldige plek om te beginnen de officiële DMARC FAQ. En, het spreekt voor zich dat het Bird supportteam ook klaarstaat om je te helpen je Bird-account voor DMARC te configureren.
Bedankt voor het lezen—en begin vandaag nog met het beschermen van je domeinen met DMARC!
