Best practice voor e-mailverificatie - optimale manieren om SPF, DKIM en DMARC te implementeren

Inleiding

Deze handleiding beschrijft drie overheersende technologieën voor e-mailverificatie die momenteel in gebruik zijn - SPF, DKIM en DMARC, en bespreekt verschillende aspecten van hun implementatie. Er worden verschillende situaties in de echte e-mailarchitectuur besproken en richtlijnen voor de implementatie ervan in de Cisco Email Security-productset. Aangezien dit een praktische handleiding voor best practices is, wordt een deel van het meer complexe materiaal weggelaten. Zo nodig kunnen bepaalde begrippen worden vereenvoudigd of ingekort om het begrip van de voorgelegde materie te vergemakkelijken.

Vereisten inzake productkennis

Deze handleiding is een document op hoog niveau. Om met het gepresenteerde materiaal door te gaan, dient de lezer productkennis van de Cisco e-mail security applicatie te bezitten op het niveau van Cisco Email Security Field Engineer-certificering. Verder moeten lezers een sterke commando hebben over DNS en SMTP en hun werking. Ervaring met de grondbeginselen van SPF, DKIM en DMARC is een pluspunt.

E-mailverificatie - een kort overzicht

Sender Policy Framework (SFP)

Sender Policy Framework werd voor het eerst gepubliceerd in 2006 als RFC4408. De huidige versie wordt gespecificeerd in RFC7208 en bijgewerkt in RFC7372. In essentie biedt het een eenvoudige manier voor een Domeineigenaar om hun legitieme e-mailbronnen te adverteren naar de Ontvangers met behulp van DNS. Hoewel SPF hoofdzakelijk het adres van het terugkeerpad (MAIL VAN) waarmerkt, adviseert de specificatie (en verstrekt mechanisme) om ook het argument van SMTP HELO/EHLO (FQDN van de gateway van de afzender zoals die tijdens gesprekken SMTP wordt overgebracht) voor authentiek te verklaren.

SPF gebruikt TXT type DNS Resource Records van vrij eenvoudige syntaxis:

spirit.com text = "v=spf1 mx a ip4:38.103.84.0/24 a:mx3.spirit.com a:mx4.spirit.com include:spf.protection.outlook.com ~all"

Het Spirit Airlines-record hierboven maakt het mogelijk om e-mail van @spirit.com-adressen te ontvangen van een bepaald /24-netwerk, twee machines die zijn geïdentificeerd door een FQDN, en Microsoft’s Office365-omgeving. De "~all" kwalificatie aan het eind draagt ontvangers op om andere bronnen als Soft Fail te beschouwen - een van de twee storingsmodi van SPF. Houd er rekening mee dat afzenders niet specificeren wat ontvangers moeten doen met falende berichten, alleen in welke mate ze zullen falen.

Delta daarentegen maakt gebruik van een ander SPF-systeem:

delta.com tekst = "v=spf1 a:smtp.hosts.delta.com include:_spf.vendor.delta.com -all"

Om het aantal vereiste DNS-vragen te minimaliseren, maakte Delta één enkele "A"-record met een lijst van alle SMTP-gateways. Ze bieden ook een aparte SPF record voor hun leveranciers in "_spf.seller.delta.com". Ze bevatten ook instructies om hard fail berichten die niet zijn geverifieerd door SPF ("-all" kwalificatie). We kunnen verder kijken naar de SPF-gegevens van de leveranciers:

_spf.seller.delta.com tekst = "v=spf1 include:_spf-delta.vrli.com include:_spf-ncr.delta.com a:delta-spf.niceondemand.com include:_spf.airfrance.fr include:_spf.qemailserver.com include:skytel.com include:epsl1.com ?all"

E-mails van afzenders @delta.com kunnen dus legitiem afkomstig zijn van, bijvoorbeeld, de e-mailgateways van Air France.

United gebruikt een veel eenvoudiger SPF-schema:

united.com tekst = "v=spf1 include:spf.enviaremails.com.br include:spf.usa.net include:coair.com ip4:161.215.0.0/16 ip4:209.87.112.0/20 ip4:74.112.71.93 ip4:74.209.251.0/24 mx ~all"

Andere dan hun eigen zakelijke mailgateways, omvatten hun e-mail marketing providers ("usa.net" en "enviaremails.com.br"), legacy Continental Air Lines gateways, evenals alles vermeld in hun MX records ("MX" mechanisme). Houd er rekening mee dat MX (een inkomende e-mailgateway voor een domein) niet hetzelfde kan zijn als uitgaand. Terwijl voor kleinere ondernemingen zij gewoonlijk het zelfde zullen zijn, zullen de grotere organisaties afzonderlijke infrastructuur die inkomende post behandelen, en afzonderlijke behandeling uitgaande levering hebben.

Ook is het de moeite waard op te merken dat alle van de bovengenoemde voorbeelden uitgebreid gebruik maken van extra DNS verwijzingen ("omvatten" mechanismen). Vanwege prestatieredenen beperkt de SPF-specificatie het totale aantal DNS-lookups dat nodig is om een definitieve record op te halen tot tien. Om het even welke SPF raadplegingen met meer dan 10 niveaus van DNS recursie zullen ontbreken.

Domain Keys Identified Mail (DKIM)

DKIM, dat in de RFC’s 5585, 6376 en 5863 wordt gespecificeerd, is een samenvoeging van twee historische voorstellen: DomainKeys van Yahoo en de geïdentificeerde internet-mail van Cisco. Het biedt een eenvoudige manier voor afzenders om uitgaande berichten cryptografisch te ondertekenen en de handtekeningen (samen met andere verificatiemetagegevens) in een e-mailheader op te nemen ("DKIM-Signature"). Afzenders publiceren hun openbare sleutel in de DNS, waardoor het voor alle ontvangers gemakkelijk is om de sleutel op te halen en handtekeningen te verifiëren. DKIM verifieert de bron van de fysieke berichten niet, maar vertrouwt op het feit dat als de bron in het bezit is van de privésleutel van de afzendende organisatie, zij impliciet gemachtigd is om namens hen een e-mail te sturen.

Om DKIM te implementeren, zou een verzendende organisatie een of meer publieke sleutelparen genereren en de openbare sleutels publiceren in de DNS als TXT-records. Elk sleutelpaar zou door een "selector" worden bedoeld zodat DKIM verificfiers tussen sleutels kunnen onderscheiden. Uitgaande berichten worden getekend en de DKIM-Signature-header wordt ingevoegd:

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=united; d;d=news.united.com;h=MIME-Version:Content-Type:Content-Transfer-Encoding:Datum:Van:Antwoord-Aan:Onderwerp:List-Unsubscribe:Message-ID; i=MileagePlus@news.united.com; bh=IBSWR4yzI1PSRYtWLx4SRDSWII4=;

b=HrN5QINgnXwqkx+Zc/9VZys+yhikrP6wSZVu35KA0jfgYzhzSdfA2nA8D2JYIFTNLO8j4DGmKhH1MMTyYGWYQT01EwL0V8MEY1MZXTrzijklPG/sK1WZ9pBacEw1fMqt QLf3BxZ3jaYtLoJMRwxtgoWdfHU35CSFG2CNYL=

Het formaat van de handtekening is vrij eenvoudig. "a"-tag specificeert de voor de ondertekening gebruikte algoritmen, "c" specificeert de gebruikte canonicalisatieregeling(en) [1], "s" is de selecteur of sleutelreferentie, "d" is het ondertekeningsdomein. De rest van deze DKIM-Signature header is berichtspecifiek: "h" lijsten ondertekende kopregels, "i" lijsten ondertekenende gebruikersidentiteit, en ten slotte de header eindigt met twee afzonderlijke hashes: "bh" is een hash van ondertekende kopregels, terwijl "b" de hashwaarde is voor de inhoud van het bericht.

Bij het ontvangen van een DKIM-ondertekend bericht, zal de ontvanger omhoog de openbare sleutel door de volgende DNS vraag te construeren kijken:

<selector>._domein.<domein ondertekenen>

zoals gespecificeerd in de kop van de DKIM-handtekening. In het bovenstaande voorbeeld, onze query zou zijn "verenigd._domainkey.news.united.com":

united._domainkey.news.united.com tekst = "g=*\; k=rsa\; n=" "Contact" "postmaster@responsys.com" "met" "eventuele" "vragen" "over" "dit" "ondertekenen" "\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/Vh/xq+sSRL5CRU1drFTGMXX/Q2KkWgl35hO4v6dTy QMX v5AwqxLiz9d0jBaxtuvYALjlGkxmk5MemgAOcCr97GlW7Cr11eLN87qdTmyE5LevnTXxVDMjIfQJt6OFzmw6Tp1t05NPWh0PbyUohZYt4qpcbiz9Kc3UB2IDAQAB\\;"

DNS-record teruggegeven bevat de sleutel, evenals andere optionele parameters. [2]

Het grootste probleem met DKIM is dat de oorspronkelijke specificatie geen reclame toestaat die een afzender gebruikt. Dus als een bericht zonder handtekening komt, is er geen makkelijke manier voor een ontvanger om te weten dat het had moeten zijn ondertekend en dat in dat geval het waarschijnlijk niet authentiek is. Aangezien één enkele organisatie meerdere selectoren kan gebruiken (en meestal zal gebruiken), is het niet triviaal om te "raden" of een domein DKIM-enabled is. Een aparte standaard, Author Domain Signing Practices, werd ontwikkeld om dit te dekken, maar door het lage gebruik en andere problemen werd in 2013 achterhaald zonder opvolger.

Domain-gebaseerde Berichtverificatie, -rapportage en -conformiteit (DMARC)

DMARC is de jongste van de drie e-mail-authenticatie technologieën die worden bestreken en werd specifiek ontwikkeld om de tekortkomingen van zowel SPF en DKIM aan te pakken. In tegenstelling tot de andere twee, authenticeert het de Kop van een bericht en koppelingen in de eerder door de andere twee uitgevoerde controles. DMARC wordt gespecificeerd in RFC7489.

Toegevoegde waarde van DMARC over SPF en DKIM bestaat uit:

• Zorgen dat alle beschikbare identiteiten (HELO, MAIL VAN en/of DKIM-signaleringsdomein) zijn uitgelijnd (exact overeenkomen of ondergeschikt) met Van header
• Het verstrekken van een middel voor de eigenaar van het afzenderdomein om een beleid voor ontvangers te specificeren over hoe zij falende berichten moeten behandelen
• Een feedbackfaciliteit bieden zodat de eigenaren van afzenderdomeinen op de hoogte zijn van foutmeldingen, zodat het gemakkelijk wordt om phishing-campagnes of fouten in SPF/DKIM/DMARC beleidstoewijzing te identificeren

DMARC maakt ook gebruik van een eenvoudig DNS-gebaseerd beleidsdistributiemechanisme:

_dmarc.aa.com tekst = "v=DMARC1\; p=none\; fo=1\; ri=3600\; rua=mailto:american@rua.agari.com,mailto:dmarc@aa.com\; ruf=mailto:american@ruf.agari.com,mailto:dmarc@aa.com"

 De enige verplichte tag in de DMARC beleidsspecificatie is "p", dat het te gebruiken beleid op falende berichten specificeert. Het kan een van de drie zijn: geen, quarantaine, afwijzing.

Meest gebruikte optionele parameters hebben te maken met rapportage: "rua" geeft een URL aan (een mailto: of een http:// URL met de POST methode) om dagelijks geaggregeerde rapporten te verzenden over alle falende berichten die vanuit een bepaald domein komen. "ruf" geeft een URL aan om direct gedetailleerde foutrapporten in te dienen over elk defect bericht.

Volgens de specificatie moet een ontvanger zich houden aan het geadverteerde beleid. Als ze dat niet doen, moeten ze de eigenaar van het afzenderdomein in het samengevoegde rapport op de hoogte brengen.

Het centrale concept van DMARC is de zogenaamde identificatoruitlijning. Identificatie-uitlijning definieert hoe een bericht DMARC-verificatie kan doorstaan. SPF- en DKIM-identifiers worden afzonderlijk uitgelijnd, en een bericht moet een van hen doorgeven om DMARC over te gaan. Er is echter een DMARC-beleidsoptie waarbij de afzender kan vragen dat een foutrapport wordt gegenereerd zelfs als de ene uitlijning wordt doorgegeven, maar de andere niet. We zien dit in het bovenstaande voorbeeld, waarbij de "fo" tag is ingesteld op "1".

Er zijn twee manieren voor berichten om zich te houden aan of DKIM of SPF herkenningsuitlijning, strikt en ontspannen. Strikte naleving betekent dat FQDN van Kop Van volledig moet overeenkomen met de Signing Domain ID ("d"-tag) van DKIM-handtekening of FQDN van MAIL VAN SMTP-opdracht voor SFP. Relaxed, aan de andere kant, staat Kop van FQDN toe om een subdomein van de bovengenoemde twee te zijn.  Dit heeft belangrijke implicaties bij het delegeren van uw e-mailverkeer aan derden, wat later in het document zal worden besproken.

Overwegingen bij SPF-implementatie

SFP voor ontvangers

SPF-verificatie is onbelangrijk om te configureren op de virtuele applicaties van Cisco Email Security of Cloud Email Security. Voor de rest van dit document zal elke verwijzing naar het ESA ook CES omvatten.

SPF-verificatie is ingesteld in Mail Flow Policies - de eenvoudigste manier om het wereldwijd uit te voeren is door het in te schakelen in het gedeelte Default Policy Parameters van de juiste luisteraar(s). Als u dezelfde luisteraar gebruikt voor het ophalen van inkomende en uitgaande e-mail, zorg er dan voor dat uw "RELAYED" Mail Flow Policy SPF-verificatie heeft ingesteld op "Uit".

Aangezien SPF niet toelaat dat beleidsactie wordt gespecificeerd, controleert SPF-verificatie (evenals DKIM, zoals we later zullen zien) alleen het bericht en voegt een set kopregels in voor elke uitgevoerde SPF-controle:

Received-SPF: Pass (mx1.hc4-93.c3s2.smtpi.com: domein van

  united.5765@envfrm.rsys2.com wijst 12.130.136.195 aan als

  toegelaten afzender) identiteits=mailfrom;

  client-ip=12.130.136.195; ontvanger=mx1.hc4-93.c3s2.smtpi.com;

  envelop-from="united.5765@envfrm.rsys2.com";

  x-sender="united.5765@envfrm.rsys2.com";

  x-conformance=sidf_compatible; x-record-type="v=spf1"

Ontvangen-SPF: Geen (mx1.hc4-93.c3s2.smtpi.com: geen afzender

  authenticiteitsinformatie beschikbaar op het domein van

  postmaster@omp.news.united.com) identiteits=helo;

  client-ip=12.130.136.195; ontvanger=mx1.hc4-93.c3s2.smtpi.com;

  envelop-from="united.5765@envfrm.rsys2.com";

  x-sender="postmaster@omp.news.united.com";

  x-conformiteit=sidf_compatibel

Houd er rekening mee dat voor dit bericht twee "identiteiten" werden geverifieerd door SPF: "mailfrom" zoals voorgeschreven door de specificatie, en "helo" zoals aanbevolen door dezelfde. Het bericht zal formeel SPF overgaan, omdat alleen de eerste relevant is voor SPF-naleving, maar sommige ontvangers kunnen afzenders die niet SPF-records voor hun HELO-identiteiten ook omvatten sanctioneren. Daarom is het een goede gewoonte om de hostnamen van uw uitgaande mailgateways op te nemen in uw SPF-records.

Zodra Mail Flow Policies een bericht verifiëren, is het aan lokale beheerders om een actie te configureren die moet worden uitgevoerd. Dit gebeurt met behulp van Berichtfilter regel SPF-status() [3], of door het maken van een Inkomende Content Filter met behulp van hetzelfde en het toepassen op de juiste Inkomende Mail Policies.

Foto 1: SPF Verification Content Filter Condition

Aanbevolen filteracties zijn om berichten die mislukken ("-alle" in de SPF-record) en quarantaineberichten die Softfail ("~alle" in de SPF-record) in een Policy Quarantaine te laten vallen, maar dit kan variëren afhankelijk van uw beveiligingsvereisten. Sommige ontvangers labelen alleen foutieve berichten, of voeren geen zichtbare actie, maar melden het aan de beheerders.

Onlangs is er een aanzienlijke stijging in SPF populariteit, maar veel domeinen publiceren onvolledige of onjuiste SPF-records. Om aan de veilige kant te zijn, kunt u alle SPF-falende berichten in quarantaine willen plaatsen, en de quarantaine een tijdje controleren, om ervoor te zorgen dat er geen "vals positieven" zijn.

Als u e-mailservices levert voor andere domeinen of derden

Als u e-maillevering of hostingdiensten voor derden levert, zullen zij hostnamen en IP-adressen moeten toevoegen die u gebruikt om hun berichten te leveren aan hun eigen SPF-records. De eenvoudigste manier om dit te doen is door de provider een "paraplu" SPF record te maken, en het gebruik van klanten "opnemen" mechanisme in hun SPF records.

suncountry.com text = "v=spf1 mx ip4:207.238.249.242 ip4:146.88.177.148 ip4:146.88.177.149 ip4:67.109.66.68 ip4:198.179.134.238 ip4:107.20 ip4:207.87.182.66 ip4:199.66.248.0/22 omvat:cust-spf.exacttarget.com ~all"

Zoals we kunnen zien, heeft Sun Country een aantal van hun e-mails onder hun eigen controle, maar hun marketing e-mail wordt uitbesteed aan een derde partij. Het uitbreiden van de genoemde record onthult een lijst van huidige IP-adressen die door hun marketingmailingprovider worden gebruikt:

cust-spf.exacttarget.com tekst = " v=spf1 ip4:64.132.92.0/24 ip4:64.132.88.0/23 ip4:66.231.80.0/20 ip4:68.232.192.0/20 ip4:199.122.120.0/21 ip4:207.67.38.0/24 ip4:207.67.98.192/27 ip4:207.250.68.0/24 ip4:209.43.22.0/28 ip4:198.245.80.0/20 ip4:136.147.128.0/20 ip4:136.147.176.0/20 111.0.0/18-all"

Deze flexibiliteit staat e-mailserviceproviders toe te schalen zonder dat ze elke klant hoeven te bereiken om hun DNS-records aan te passen.

Als u e-mailservices van derden gebruikt

Op dezelfde manier als de vorige paragraaf, als u gebruik maakt van een e-maildienst van derden, en wilt u volledig SPF-geverifieerde e-mailstroom instellen, moet u hun eigen SPF-records in uw.

jetblue.com beschrijvende tekst "v=spf1 include:_spf.qualtrics.com ?all"

JetBlue maakt gebruik van Qualtrics analytics service, en het enige wat ze hoeven te doen is een correcte SPF record van Qualtrics. Evenzo bieden de meeste andere ESP’s SPF-records die in de gegevens van hun klanten moeten worden opgenomen.

Als uw ESP- of e-mailmarketeer geen SPF-records aanbiedt, moet u hun uitgaande mailgateways rechtstreeks in uw browser opnemen. Het is echter uw verantwoordelijkheid om die records nauwkeurig te houden, en als de provider extra gateways toevoegt of IP-adressen of hostnamen wijzigt, kan uw mailflow in gevaar komen.

Bijkomend gevaar van derden die niet SPF-bewust zijn, komt van het delen van bronnen: Als een ESP hetzelfde IP-adres gebruikt om e-mail van meerdere klanten te leveren, is het technisch mogelijk voor één klant om SPF-geldig bericht te genereren alsof het een andere klant is die via dezelfde interface levert. Dit is waarom, alvorens om het even welke SPF beperkingen op te stellen, u uw veiligheidsbeleid van MSP en voorlichting van e-mailauthentificatie zou moeten onderzoeken. Als zij geen antwoorden op uw vragen hebben, gezien hoe SPF een van de basismechanismen van vertrouwen op het internet is, wordt u sterk aangeraden om uw keuze van MSP te heroverwegen. Het gaat niet alleen om veiligheid - SPF, DKIM, DMARC en andere afzenders beste praktijken [4] die door MSP’s worden gebruikt, zijn een garantie van leverbaarheid. Als uw MSP hen niet volgt of hen niet correct volgt, zal dat hun betrouwbaarheid met grote ontvangstsystemen verminderen en mogelijk uw berichten vertragen of zelfs blokkeren.

(Sub)Domeinen zonder e-mailverkeer

De meeste organisaties bezitten vandaag verscheidene domeinen voor marketing doeleinden maar gebruiken slechts actief één voor collectief e-mailverkeer. Zelfs als SPF correct op het productiedomein wordt ingezet, kunnen slechte actoren nog steeds andere domeinen gebruiken die niet actief worden gebruikt voor een e-mail om de identiteit van een organisatie te parodiëren. SPF kan voorkomen dat dit gebeurt via een speciale "deny all" SPF-record - voor elk van uw domeinen (en subdomeinen!) die geen e-mailverkeer genereren, publiceer "v=spf1 -all" in de DNS. Een uitstekend voorbeeld is openspf.org - de Website van de SPF Raad.

Aangezien SPF-delegatie alleen geldig is voor één domein, is het van cruciaal belang om ook "deny all" SPF-records te publiceren voor eventuele subdomeinen die u mogelijk gebruikt die geen e-mail genereren. Zelfs als uw productiedomein een "reguliere" SPF-record heeft, doe dan een extra inspanning om "ontkennen alle" records aan uw subdomeinen toe te voegen zonder verkeer. En nogmaals - vergeet niet dat ontvangen niet hetzelfde is als verzenden: een domein kan heel goed e-mail ontvangen, maar zal nooit een bron zijn. Dit geldt voor kortetermijnmarketingdomeinen (bijvoorbeeld evenementen, promoties met beperkte tijd, productlanceringen...), waarbij e-mails die binnenkomen op die domeinen aan uw productiedomein worden geleverd, en eventuele reacties op die e-mails worden geleverd vanuit het productiedomein. Deze kortetermijndomeinen zullen een geldig MX record hebben, maar moeten een SPF record hebben dat hen identificeert als geen bron van e-mail ook.

Overwegingen bij DKIM-implementatie

DKIM voor ontvangers

De DKIM-verificatie op de ESA configureren lijkt op de SPF-verificatie. In de Default Policy Parameters van Mail Flow Policies, zet u DKIM Verification gewoon op "Aan". Nogmaals, aangezien DKIM geen beleidsspecificatie toestaat, zal dit enkel de handtekening verifiëren en een "verificatie-resultaten"-header invoegen:

Verificatieresultaten: mx1.hc4-93.c3s2.smtpi.com; dkim=pass (handtekening geverifieerd) header.i=MileagePlus@news.united.com

Alle acties op basis van DKIM-verificatieresultaten moeten worden uitgevoerd door Content Filters:

Foto 2: DKIM-verificatie contentfilter

In tegenstelling tot SPF, die ongecompliceerd is, manipuleert DKIM de daadwerkelijke berichttekst, zodat sommige parameters kunnen worden beperkt. U kunt desgewenst DKIM-verificatieprofielen maken en verschillende verificatieprofielen toewijzen aan verschillende Mail Flow-beleidsregels. Ze stellen u in staat om de sleutelgrootte van handtekeningen te beperken die u zal accepteren, stellen sleutelherstellingstoringsacties in en configureren van de diepte van DKIM-verificatie.

Aangezien een bericht meerdere gateways passeert, kan het meerdere malen worden ondertekend en dus meerdere handtekeningen dragen. Voor een bericht om DKIM-verificatie door te voeren, moeten alle handtekeningen worden geverifieerd. ESA zal standaard tot vijf handtekeningen verifiëren.

Door de historische openheid van SMTP en e-mail en de terughoudendheid van het internet om zich aan te passen aan (positieve) veranderingen, zijn er nog steeds verschillende situaties waarin DKIM-handtekeningen legitiem kunnen mislukken, zoals wanneer mailinglist managers direct relay maar wijzigen berichten, of wanneer berichten rechtstreeks worden doorgestuurd in plaats van als bijlagen bij nieuwe berichten. Dit is waarom, in het algemeen, de beste praktijk voor berichten die niet DKIM zijn zou nog steeds quarantaine of markering, in plaats van hen te laten vallen.

Voorbereiden op tekenen met DKIM

Voordat u DKIM-signalering kunt inschakelen in uw Releasebeleid voor e-mailstromen, moet u de sleutels genereren/importeren, DKIM-signaleringsprofiel(en) maken en de openbare sleutel(s) in het DNS publiceren.

Als u voor één domein ondertekent, is het proces eenvoudig. Genereer het sleutelpaar, maak uw enig Ondertekenend Profiel in de sectie van de Sleutels van het Domein van het Beleid van de Post, en klik de "Generate"optie onder "DNS Tekstverslag"zodra uw profiel klaar is. Publiceer de sleutel zoals die in uw DNS wordt geproduceerd. Tot slot, schakel DKIM Signing in uw Mail Flow Policy in.

Het wordt ingewikkelder als je voor meerdere verschillende domeinen tekent. In dat geval hebt u twee opties:

1. Gebruik één enkel Signing Profiel om voor alle domeinen te ondertekenen. U slaat de (enkele) openbare sleutel op in de DNS-zone van het "primaire" domein, en uw DKIM-handtekeningen verwijzen naar die sleutel. Deze techniek werd in het verleden vaak toegepast door ESP’s, waardoor zij op grote schaal konden ondertekenen zonder dat zij met de DNS-ruimte van individuele klanten hoefden te interageren [5].
2. Maak een afzonderlijk ondertekeningsprofiel voor elk domein waarvoor u ondertekent. Dit maakt de initiële configuratie complexer, maar biedt veel meer flexibiliteit in de toekomst. Maak een sleutelpaar voor elk domein, maak een profiel dat slechts één domein (en zijn subdomeinen) in de sectie "Profielgebruikers" specificeert, en publiceer de relevante openbare sleutel in de DNS-zone van dat specifieke domein.

Hoewel optie #1 makkelijker is om mee te beginnen, onthoud dat het uiteindelijk zal breken DMARC. Aangezien DMARC vereist dat Signing Domain ID wordt uitgelijnd met Header From, zal uw ID-uitlijning met DKIM mislukken. U kunt er misschien mee wegkomen als u uw SPF correct configureren, en vertrouwen op SPF identifier uitlijning om DMARC verificatie door te geven.

Echter, door optie #2 vanaf het begin te implementeren, hoeft u zich geen zorgen te maken over DMARC en het is vrij eenvoudig om de ondertekeningsservice voor slechts één domein in te trekken of opnieuw te configureren.  Ook, als u sommige e-maildiensten voor een derdendomein verstrekt, zult u zeer waarschijnlijk de sleutel moeten krijgen om van hen te gebruiken (en het in uw ESA te importeren). Die sleutel zal domeinspecifiek zijn, dus u zult een afzonderlijk profiel moeten maken.

Als u e-mailservices van derden gebruikt

Over het algemeen, als u DKIM-ondertekening gebruikt en een deel van uw e-mailverwerking (bijv. marketing e-mails) naar een derde partij offload, wilt u niet dat ze dezelfde sleutels gebruiken die u in productie gebruikt. Dit is een van de belangrijkste redenen voor het bestaan van Selectors in DKIM. In plaats daarvan, zou u een nieuw zeer belangrijk paar moeten produceren, het openbare gedeelte in uw DNS streek publiceren en de geheime sleutel aan de andere partij leveren. Dit zal u ook in staat stellen om snel die bepaalde sleutel in geval van problemen in te trekken terwijl uw productie DKIM infrastructuur onaangeroerd blijft.

Hoewel het niet noodzakelijk is voor DKIM (berichten voor hetzelfde domein kunnen worden ondertekend met meerdere verschillende sleutels), is het een goede praktijk om een afzonderlijk subdomein te bieden voor elke e-mail die wordt verwerkt door een derde partij. Het zal het volgen van de berichten vergemakkelijken, en zal voor veel schonere implementatie van DMARC later toestaan. Neem bijvoorbeeld deze vijf DKIM-Signature-headers uit verschillende berichten van Lufthansa:

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa; d=newsletter.milesandmore.com;

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa2; d=newsletter.lufthansa.com;

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa3; d=lh.lufthansa.com;

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa4; d=e.milesandmore.com

DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=lufthansa5; d=fly-lh.lufthansa.com;  

We zien dat Lufthansa vijf verschillende sleutels (selectoren) gebruikt, verdeeld over vijf verschillende subdomeinen van twee primaire productiedomeinen (lufthansa.com en milesandmore.com). Dit betekent dat elk van deze zaken onafhankelijk kan worden gecontroleerd en elk ervan kan worden uitbesteed aan een andere berichtendienstverlener.

Overwegingen bij DMARC-implementatie

DMARC voor ontvangers

De DMARC-verificatie van de ESE is op een profiel gebaseerd, maar in tegenstelling tot de DKIM moet het standaardprofiel worden bewerkt om te voldoen aan de specificatie. Het standaardgedrag van de ESA is om nooit berichten te laten vallen tenzij expliciet geïnstrueerd door de klant, dus standaard DMARC-verificatieprofiel heeft alle acties ingesteld op "Geen actie". Bovendien, om correcte rapportgeneratie toe te laten, zult u "Mondiale Montages"van de DMARC sectie van "het Beleid van de Post moeten uitgeven".

Zodra een profiel is ingesteld, wordt DMARC verificatie, net als de andere twee, ingesteld in de sectie Default Policy Settings van Mail Flow Policies. Controleer het vakje om samengestelde feedback rapporten te verzenden - dit is waarschijnlijk het belangrijkste kenmerk van DMARC voor de afzender. Op het moment van schrijven ondersteunt ESA het genereren van meldingen van mislukkingen ("ruf" tag van het DMARC-beleid) niet.

Aangezien DMARC-beleidsacties worden geadviseerd door de afzender, in tegenstelling tot SPF of DKIM, zijn er geen specifieke acties configureerbaar buiten de profielconfiguratie. Het is niet nodig om inhoudsfilters te maken.

DMARC-verificatie voegt extra velden toe aan de kop van de verificatieresultaten:

Verificatieresultaten: mx1.hc4-93.c3s2.smtpi.com; dkim=pass (handtekening geverifieerd) header.i=MileagePlus@news.united.com; dmarc=pass (p=none dis=none) d=news.united.com

In het bovenstaande voorbeeld zien we dat DMARC is geverifieerd op basis van DKIM-identificatiecode uitlijning, en de afzender verzocht om een beleid van "geen". Dit geeft aan dat zij momenteel in de "monitor"-fase van de DMARC-invoering verkeren.

Als u e-mailservices levert voor andere domeinen of derden

De grootste zorg van ESP's voor de naleving van DMARC is het bereiken van een juiste identificatie. Bij het plannen voor DMARC, zorg ervoor dat uw SPF correct is opgezet, dat alle relevante andere domeinen uw uitgaande gateways in uw SPF-records hebben en dat ze geen berichten verzenden die geen uitlijning zullen veroorzaken, voornamelijk door het gebruik van verschillende domeinen voor MAIL VAN en Kop van identiteit. Deze fout wordt meestal gemaakt door toepassingen die e-mailberichten of waarschuwingen verzenden omdat de auteurs van de toepassing zich meestal niet bewust zijn van de gevolgen van de inconsistentie van hun e-mailidentiteiten.

Zoals eerder beschreven, zorg ervoor dat u voor elk domein een afzonderlijk DKIM-ondertekeningsprofiel gebruikt en dat uw ondertekeningsprofiel naar behoren verwijst naar het domein waarvoor u ondertekent, zoals gebruikt in Kop van. Als u uw eigen subdomeinen gebruikt, kunt u met één enkele sleutel ondertekenen, maar zorg ervoor dat u uw naleving van DKIM in het DMARC-beleid ("adkim="r") ontspannen.

In het algemeen, als u e-maildiensten aanbiedt voor een groter aantal derden waarover u geen directe controle hebt, is het een goede praktijk om een richtsnoerdocument te schrijven over hoe u een e-mail kunt verzenden die waarschijnlijk zal leveren. Aangezien user-to-user e-mail zich over het algemeen goed gedraagt, zal dit meestal dienen als een beleidsdocument voor applicatieauteurs in de hierboven genoemde voorbeelden.

Als u e-mailservices van derden gebruikt

Als u gebruik maakt van derden om een deel van uw e-mailverkeer te leveren, is de optimale manier om een afzonderlijk subdomein (of een volledig ander domein) te delegeren aan de externe provider. Op deze manier kunnen ze de SPF-records beheren zoals nodig, hebben afzonderlijke DKIM-ondertekeningsinfrastructuur en interfereren ze niet met uw productieverkeer. Dan kan het DMARC-beleid voor uitbesteed e-mail anders zijn dan voor intern. Zoals reeds vermeld, wanneer het overwegen van de derde geleverde e-mail, altijd ervoor zorgen dat uw herkenningstekens zullen richten, en uw naleving van DKIM en SPF wordt geplaatst geschikt in uw beleid DMARC.

(Sub)Domeinen zonder e-mailverkeer

Een andere verbetering van DMARC ten opzichte van eerdere e-mail authenticatie technologieën is hoe het subdomeinen verwerkt. Standaard is het DMARC-beleid van een bepaald domein van toepassing op al zijn subdomeinen. Bij het ophalen van DMARC-beleidsrecords, als er geen record kan worden gevonden op Header From FQDN-niveau, zijn ontvangers verplicht om het Organisatorisch Domein [6] van de afzender en het zoeken naar een beleidsrecord daar te bepalen.

Echter, DMARC beleid voor een Organisatorisch Domein kan ook een afzonderlijke Subdomain Policy ("sp" -tag van een DMARC-record) specificeren die van toepassing zal zijn op alle subdomeinen die geen expliciet DMARC-beleid gepubliceerd hebben.

In het scenario dat eerder in het SPF-hoofdstuk wordt besproken, zou u:

1. Publiceer een expliciete DMARC record voor subdomeinen die legitieme bronnen van e-mail zijn.
2. Publiceer een Subdomeinbeleid van "afwijzen" in uw Organisatorische Domeinbeleidsrecord om automatisch alle e-mails te verwerpen die niet-verzendende domeinen paren

Dit soort structurering van uw e-mailauthenticatie zorgt voor de best mogelijke bescherming van uw infrastructuur en merk.

DMARC-specifieke problemen

Er zijn verschillende potentiële problemen met DMARC, die allemaal voortvloeien uit de aard en tekortkomingen van andere authenticatietechnologieën waar het op vertrouwt. Het probleem is dat DMARC deze problemen aan de oppervlakte bracht door actief een beleid te duwen om de e-mail te verwerpen, en door alle verschillende afzender identificatoren in een bericht te correleren.

De meeste problemen doen zich voor met mailinglijsten en mailinglijstbeheersoftware. Wanneer een e-mail wordt verzonden naar een mailinglijst, wordt deze opnieuw gedistribueerd naar alle ontvangers. De resulterende e-mail, met een afzenderadres van de oorspronkelijke afzender, zal echter worden afgeleverd door de hosting-infrastructuur van de mailinglist manager, waardoor SPF-controles voor Kop Van (de meeste mailinglist managers gebruiken het lijstadres als Envelope From (MAIL FROM) en het adres van de oorspronkelijke afzender als Kop Van) niet mogelijk zijn.

Aangezien DMARC zal falen voor SPF, kunnen we vertrouwen op DKIM, maar de meeste mailing list managers ook voetregels aan berichten toevoegen, of onderwerpen met de lijstnaam labelen, dus het breken van DKIM handtekeningverificatie.

Auteurs van DKIM stellen verschillende oplossingen voor het probleem voor, die allemaal neerkomen op de mailinglist managers die het adres van de lijst in alle From-adressen moeten gebruiken, en die het oorspronkelijke afzenderadres op een andere manier aangeven.

Gelijkaardige problemen ontstaan uit berichten die door enkel het kopiëren van het oorspronkelijke bericht over SMTP aan de nieuwe ontvanger worden verstuurd. De meeste Mail User Agents die vandaag in gebruik zijn, vormen echter op juiste wijze een nieuw bericht en bevatten het doorgezonden bericht ofwel inline ofwel als bijlage bij het nieuwe bericht. Berichten die op deze manier worden doorgestuurd zullen DMARC passeren als de doorzendende gebruiker passeert (natuurlijk kan de authenticiteit van het oorspronkelijke bericht niet worden vastgesteld).

Steekproefactieplan voor implementatie van e-mailverificatie

Hoewel de technologieën zelf eenvoudig zijn, kan de weg om een volledige e-mail authenticatie infrastructuur te implementeren lang en kronkelend zijn. Voor kleinere organisaties en degenen met gecontroleerde mailstromen zal het vrij eenvoudig zijn, terwijl grotere omgevingen het bijzonder uitdagend kunnen vinden. Het is niet ongebruikelijk voor grote ondernemingen om adviesdiensten in te huren om het implementatieproject te beheren.,

Stap 1: DKIM

DKIM is relatief onopdringerig omdat niet-ondertekende berichten niet zullen worden afgekeurd. Rekening houden met alle eerder genoemde punten alvorens tot daadwerkelijke tenuitvoerlegging over te gaan. Neem contact op met derden die u kunt delegeren aan ondertekening, zorg ervoor dat uw derden DKIM-ondertekening ondersteunen en overweeg uw selector management strategie. Sommige organisaties zouden afzonderlijke sleutels (selectoren) voor verschillende organisatorische eenheden bewaren. U kunt de periodieke rotatie van sleutels overwegen voor extra veiligheid - maar zorg ervoor dat u niet uw oude sleutels wissen tot al uw berichten in transit worden geleverd.

Speciale aandacht dient te worden besteed aan de sleutelgrootten. Hoewel in het algemeen "meer is beter", moet u er rekening mee houden dat het maken van twee digitale handtekeningen per bericht (inclusief canonicalisatie, etc.) een zeer CPU-dure taak is en de prestaties van uitgaande mail gateways kan beïnvloeden. Vanwege de overhead van de berekeningen, 2048 bits is de grootste praktische sleutelgrootte die kan worden gebruikt, maar voor de meeste implementaties maken 1024-bits sleutels een goed compromis tussen prestaties en beveiliging.

Voor de succesvolle volgende implementatie van DMARC, dient u:

1. identificeer alle domeinen die u als, met inbegrip van subdomeinen verzendt
2. DKIM-sleutels genereren en ondertekenprofielen maken voor elk domein
3. relevante privésleutels aan derden te verstrekken
4. alle openbare sleutels in relevante DNS-zones publiceren
5. controleren of derden klaar zijn om te beginnen met ondertekenen
6. DKIM-ondertekening inschakelen in RELAYED Mail Flow Policy voor al uw ESA’s
7. derde partijen in kennis stellen van de start van de ondertekening

Stap 2: SPF

Correcte implementatie van SPF zal waarschijnlijk het meest tijdrovende en lastige deel van elke e-mail authenticatie infrastructuur implementatie. Omdat de e-mail heel eenvoudig te gebruiken en te beheren was, en volledig open vanuit het oogpunt van veiligheid en toegang, hebben organisaties historisch gezien geen strikt beleid afgedwongen over wie en hoe het kan gebruiken. Dit resulteerde er vandaag de dag in dat de meeste organisaties geen compleet overzicht hebben van alle verschillende e-mailbronnen, zowel van binnen als van buiten. Het grootste probleem van de implementatie van SPF is te ontdekken wie momenteel legaal e-mails verstuurt namens jou.

Wat u kunt zoeken:

1. duidelijke doelen - Exchange- of andere groupware-servers of uitgaande mailgateways
2. DLP-oplossingen of andere e-mailverwerkingssystemen die externe meldingen kunnen genereren
3. CRM-systemen die informatie verzenden die interageert met klanten
4. diverse toepassingen van derden die e-mail kunnen verzenden
5. lab, test of andere servers die e-mail kunnen versturen
6. pc's en apparaten geconfigureerd om direct een externe e-mail te versturen

De bovenstaande lijst is niet volledig, aangezien organisaties verschillende omgevingen hebben, maar dient te worden beschouwd als een algemene leidraad voor wat te zoeken. Zodra (de meeste) uw e-mailbronnen zijn geïdentificeerd, kunt u een stap terug willen doen, en in plaats van elke bestaande bron te autoriseren, de lijst op te schonen. Idealiter worden al uw uitgaande e-mails geleverd via uw uitgaande mail gateways met een paar gerechtvaardigde uitzonderingen. Als u uw eigen of gebruik van een derde marketing mail oplossing, moet u afzonderlijke infrastructuur gebruiken dan productie e-mail gateways. Als uw postbezorgingsnetwerk uitzonderlijk gecompliceerd is, kunt u doorgaan met het documenteren van de huidige status in uw SPF, maar neemt u de tijd om de situatie in de toekomst op te schonen.

Als u meerdere domeinen via dezelfde infrastructuur bedient, kunt u een universele SPF-record maken en deze in afzonderlijke domeinen met behulp van het "opnemen"-mechanisme doorverwijzen. Zorg ervoor dat uw SPF-records niet te breed zijn; bijvoorbeeld als slechts vijf machines in een /24-netwerk SMTP verzenden, voeg die vijf individuele IP-adressen toe aan uw SPF, in plaats van het gehele netwerk. Probeer uw records zo specifiek mogelijk te maken om de kans op kwaadaardige e-mails die uw identiteit aantasten te minimaliseren.

Begin met een softfailoptie voor niet-passende afzenders ("~all"). Verander het alleen naar hardfail (-all) als je 100% zeker bent dat je al je e-mailbronnen hebt geïdentificeerd, anders riskeer je het verliezen van productie e-mail. Later, na het implementeren van DMARC en het uitvoeren van het in monitormodus voor een tijdje, zult u in staat om alle systemen die u gemist hebt te identificeren en uw SPF-records te actualiseren om volledig te zijn. Alleen dan zal het veilig zijn om uw SPF op hardfail in te stellen.

Stap 3: DMARC

Zodra uw DKIM en SPF zo volledig mogelijk zijn ingesteld, is het tijd om uw DMARC-beleid te maken. Overweeg alle verschillende situaties die in eerdere hoofdstukken zijn genoemd en bereid u voor om meer dan één DMARC-record te implementeren als u een complexe e-mail-infrastructuur hebt.

Maak e-mailaliassen die rapporten zullen ontvangen, of maak een Web applicatie die ze kan opnemen. Hiervoor zijn geen strikt gedefinieerde e-mailadressen te gebruiken, maar het helpt als ze beschrijvend zijn, bijvoorbeeld rua@domain.com, dmarc.rua@domain.com, mailauth-rua@domain.com, etc. Zorg ervoor dat u over een proces beschikt waarmee een operator deze adressen kan controleren en de SPF-, DKIM- en DMARC-configuratie kan wijzigen, of het beveiligingsteam kan waarschuwen in het geval van een spoofingcampagne. Aanvankelijk, zal de werkbelasting substantieel zijn aangezien u de verslagen knuffelt om het even wat te behandelen u tijdens SPF en configuratie DKIM zou kunnen gemist hebben. Na enige tijd zullen rapporten waarschijnlijk alleen duiden op pogingen tot spoofing.

Stel eerst uw DMARC-beleid in op "geen" en uw forensische optie om rapporten te verzenden voor eventuele falende controles ("fo=1") - dit zal snel alle fouten in uw SPF en DKIM ontdekken zonder het verkeer te beïnvloeden. Zodra u tevreden bent met de inhoud van de ingediende rapporten, verander het beleid naar "quarantaine" of "afwijzen", afhankelijk van uw beveiligingsbeleid en voorkeur. Zorg er ook voor dat u medewerkers voortdurend uw ontvangen DMARC-rapporten analyseert voor eventuele valse positieven.

Het volledig en correct implementeren van DMARC is geen kleine of korte taak. Hoewel sommige resultaten (en formele "implementatie" van DMARC) kunnen worden verkregen door het publiceren van een onvolledige reeks records en een beleid van "niets", is het in het beste belang van zowel de afzender organisatie en het internet als geheel dat iedereen implementeert in de volle omvang van zijn mogelijkheden.

Wat betreft de tijdlijnen, hier is een zeer ruwe schets van individuele stappen voor een typisch project. Aangezien elke organisatie anders is, zijn deze verre van nauwkeurig:

1. DKIM-planning en -voorbereiding	2-4 weken
2. DKIM-testruns	2 weken
3. SPF - legitieme identificatie van de afzender	2-4 weken
4. DMARC-beleidsvoorbereiding	2 weken
5. SPF- en DMARC-records van testrun	4-8 weken
6. SPF-test met hardfail	2 weken
7. DMARC-test met quarantaine/afwijzing	4 weken
8. Toezicht op DMARC-rapporten en overeenkomstige aanpassing van de SPF/DKIM	doorlopend

De kleinere organisaties zullen waarschijnlijk een kortere duur van de meeste stappen ervaren, vooral Stap 3 en 4. Ongeacht hoe eenvoudig uw e-mail infrastructuur die u denkt kan zijn, altijd ruim voldoende tijd toewijzen tijdens de tests, en feedback rapporten nauwkeurig controleren voor alles wat je hebt gemist.

Grotere organisaties kunnen een nog langere duur van dezelfde stappen ervaren, met strengere testvereisten. Het is niet ongewoon voor bedrijven met een complexe e-mail infrastructuur om externe hulp in te huren, niet alleen voor het technische aspect van e-mail authenticatie implementatie, maar ook om het gehele project te beheren en te coördineren tussen teams en afdelingen.

Aanvullende referenties

• De referentiesite voor SFP: http://www.openspf.org
• De DKIM-Raad: http://www.dkim.org
• Hoofdwebsite van DMARC, beheerd door The Trusted Domain Project: http://www.dmarc.org
• Dmarcian - een help en resources site gerund door Tim Draegen, een van de auteurs van DMARC. Ga naar het gedeelte "Tools": http://www.dmarcian.com
• Online Trust Alliance’s Recordvalidator: https://otalliance.org/resources/spf-dmarc-record-validator
• DMARC Record Assistant - nog een handige tool waarmee u uw DMARC-records kunt maken: http://www.kitterman.com/dmarc/assistant.html
• SPF Record testtools: http://www.kitterman.com/spf/validate.html
• "Don’t Be a Phish: Deep Dive Into Email Authentication Techniques", een Cisco Live 2014 presentatie BRKSEC-3770: https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=76627

[1] Canonicalisatie valt buiten het toepassingsgebied van dit document. Raadpleeg materiaal in het gedeelte "Aanvullende referenties" voor meer informatie over DKIM-canonicalisatie.

[2] DKIM DNS-recordparameters vallen ook buiten het bereik van dit document.

[3] Het maken van berichtfilters valt buiten het bereik van dit document. Raadpleeg AsyncOS voor e-mailgebruikershandleidingen voor hulp.

[4] M3AAWG heeft een uitstekende reeks best practices vastgesteld die door het grootste deel van de sector worden toegepast en geëerd. Hun document over de beste praktijken van de afzender is beschikbaar op https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Senders_BCP_Ver3-2015-02.pdf

[5] Dit gedrag maakt gebruik van het feit dat DKIM oorspronkelijk de berichtbron niet verifieert zoals vermeld in MAIL VAN of Kop van allen. Het verifieert alleen dat de Signing Domain ID ("d"-parameter van DKIM Signature, en "Domain Name"-parameter in uw Signing Profile) inderdaad de openbare sleutel van het paar ontvangt dat wordt gebruikt om het bericht te ondertekenen. De authenticiteit van de afzender wordt geïmpliceerd door de "Van"-header te laten ondertekenen. Zorg er alleen voor dat u alle domeinen (en subdomeinen) die u ondertekent, opsomt in de sectie "Profielgebruikers".

[6] Gewoonlijk een domein dat één niveau lager ligt dan de TLD of een relevant ccTLD-prefix (nl.ac.uk, .com.sg...)