Epostsikkerhet

Dagens tekst er hentet fra kapittel 19 i Cryptography and Network Security, og handler om sikkerhet i forbindelse med elektronisk post.

Det er to typer protokoller involvert når man sender epost. En type brukes for å sende epost fra kilde til destinasjon over internett; eksempler kan være Simple Mail Transfer Protocol (SMTP) og X.400. Den andre typen brukes for å overføre meldinger mellom klienter og epost-tjenere; her er IMAP og POP de mest vanlige valgene.

SMTP

SMTP er en tekstbasert klient-tjener-protokoll som kapsler en epostmelding inn i en konvolutt, og brukes til å sende de innkapslede meldingene fra kilde til destinasjon via potensielt flere meldingsoverføringsagenter (MTAer). Den var først spesifisert i 1982 som RFC 821; begrepet Extended SMTP (ESMTP) brukes ofte for å referere til senere versjoner av SMTP. Siste utgave av SMTP er RFC 5321.

STARTTLS

STARTTLS er en vesentlig sikkerhetsrelatert utvidelse av SMTP, definert i RFC 3207 (SMTP Service Extension for Secure SMTP over Transport Layer Security, Februar 2002). Den gjør det mulig å legge til konfidensialtitet og autentisering i utvekslingen som skjer mellom SMTP-agenter, som gjør SMTP-agente i stand til å beskytte deler av eller all kommunikasjon mot avlytting og aktive angripere. En fordel med STARTTLS er at tjeneren kan tilby SMTP-tjeneste på en enkelt port, i stedet for å måtte kreve separate port-numre for sikker og klartekst operasjon.

Protokoller for klient-tilgang til epost

Det finnes to protokoller som epostklienter bruker for å hente ned epost; Post Office Protocol (POP3) og Internet Mail Access Protocol (IMAP).

POP3 lar en epostklient koble til en tjener (MTA) via TCP. Etter autentisering kan brukeragenten (UA) utstede POP3-kommandoer for å hente ned og evt. slette epost. IMAP er mer komplisert enn POP, men bruker også TCP (port 143). IMAP tilbyr i utgangspunktet sterkere autentisering enn POP (men det er også mange sikkerhetsmekanismer tilgjengelige for moderne POP-implementasjoner), og tilbyr andre funksjoner som ikke støttes av POP3.

RFC 5322

RFC 5322 er en oppdatert versjon av RFC822, og definerer et format for tekstmeldinger som sendes med elektronisk post. Meldinger betraktes som å bestå av en konvolutt og innhold. Konvolutten inneholder all informasjonen som er nødvendig for å videresende og levere meldingen, mens innholdet utgjør objektet som skal leveres til mottakeren. RFC 5322 omhandler kun innholdet, men inkluderer et sett med hode-felter som epostsystemet kan bruke til å lage konvolutten.

Eksempelmelding

I det følgende vises et eksempel på hvordan innholdet i en melding kan se ut:

Date: October 8, 2009 2:15:49 PM EDT
From: “William Stallings” <ws@shore.net>
Subject: The Syntax in RFC 5322
To: Smith@Other-host.com
Cc: Jones@Yet-Another-Host.com

Hello. This section begins the actual message body, which is delimited from the message heading by a blank line.

Hele denne teksten (fra “Date:”  og utover) regnes som meldingsinnhold; men mange av feltene i SMTP-hodet vil hentes fra hodefeltene i meldingsinnholdet.

Begrensninger til SMTP/RFC5322

SMTP kan ikke sende kjørbare filer eller andre binære objekter, og kan heller ikke sende tekst som inneholder nasjonale tegn som æ, ø og å (i gamle dager da man var begrenset av 7-bits ASCII ble dette løst ved å i stedet benytte “{“, “|”, og “}” – enkelte printere kunne stilles inn til å skrive de norske tegnene i stedet for disse). SMTP-tjenere kan finne på å forkaste epostmeldinger over en gitt størrelse. SMTP-portnere som oversetter mellom ASCII og EBCDIC har ikke et konsistent sett av avbildninger, noe som fører til oversettelsesproblemer (men jeg tviler egentlig på at det fortsatt er noen som bruker EBCDIC?). Ikke overraskende kan ikke SMTP-portnere til X.400 epostnettverk håndter ikke-tekstuelle data i X.400-meldinger, og på toppen av alt følger ikke alle SMTP-implementasjonene SMTP-standardene definert i RFC 821.

Multipurpose Internet Mail Extensions (MIME)

MIME er en utvidelse av RFC5322-rammeverket som er ment å adressere noen av problemene og begrensningene i bruk av Simple Mail Transfer Protocol (SMTP), men på en måte som er kompatibel med eksisterende RFC5322-implementasjoner.

Spesifikasjonen finnes i RFC 2045 til 2049, og inneholder følgende elementer: Fem nye meldingshodefelter som har informasjon om meldingskroppen, et antall innholdsformater er definert for å standardisere representasjoner som støtter multimedia epost, og overføringsenkodinger som gjør det mulig å konvertere ethvert innholdsformat til en form som er beskyttet mot endring av postsystemet.

De fem nye hodefeltene definert av MIME

  • MIME-version: Må ha verdien 1.0, og indikerer at meldingen er konform med RFC 2045 og 2046.
  • Content-Type: Beskriver dataene som er inneholdt i kroppen med tilstrekkelige detaljer slik at den mottkende brukeragenten kan velge en passende agent eller mekanisme for å presentere dataene til brukeren, eller på annen måte håndtere dataene på passende vis.
  • Content-Transfer-Encoding: Indikerer typen transformasjon som har vært brukt til å representere meldingskroppen på en måte som er akseptabel for epost-transport.
  • Content-ID: Brukt for å identifisere MIME-entiteterpå en unik måte i flere kontekster.
  • Content-Description: En tekstlig beskrivelse av objektet som befinner seg i kroppen; dette er nyttig i de tilfellene hvor objektet ikke er lesbart.

Formater

Meldingskroppen kan overføres enten i sin originale (native) form, eller i kanonisk (canonical) form.

I original form opprettes kroppen som skal sendes i systemets eget format, med det lokale tegnsettet, og muligens også med lokale linjeavslutningskonvensjoner. Kroppen kan ha ethvert format som korresponderer med den lokal modellen for representasjon av en eller annen form for informasjon. Eksempler omfatter en UNIX-type tekstfil, et Sun raster-bilde, en VMS indeksert fil, og lyd-data i et systemavhengig format som kun er lagret i minnet.

I kanonisk form konverteres hele kroppen, inkludert ekstra informasjon som lengde på oppføringer og muligens filattributtinformasjon, til et universalt format. Den spesifikke medietypen til kroppen samt de assosierte attributtene dikterer egenskapene til den kanoniske formen som brukes. Konvertering til den riktige kanoniske formen kan omfatte oversettelse av tegnsett, transformasjon av lyddata, kompresjon, eller forskjellige andre operasjoner som er spesifikke til de forskjellige mediatypene.

Sikkerhetstrusler mot epost

Epost er utsatt for mye de samme truslene som annen form for nettverkskommunikasjon. Trusler mot autentisering kan på den ene siden medføre at uautoriserte kan få tilgang til en virksomhets epostsystem, men også at en avsender kan gi seg utfor å være noen andre. Trusler mot integritet kan medføre uautorisert endring av innhold i epost, og trusler mot konfidensialitet kan medføre uautorisert røping av sensitiv informasjon. Trusler mot tilgjengelighet kan forhindre brukere fra å sende og/eller motta epost.

Protokoller for å motvirke truslene

NIST SP 800-177 anbefaler bruk av et utvalg standardiserte protokoller for å motvirke trusler mot epost:

STARTTLS er en SMTP sikkerhetsutvidelse som tilbyr autentisering, integritet, ikke-fornektelse og konfidensialitet for hele SMTP-meldingen ved å kjøre SMTP over TLS. S/MIME tilbyr autentisering, integritet, ikke-fornekting og konfidensialitet av meldingskroppen til SMTP-meldinger. DNS Security Extensions (DNSSEC) tilbyr autentisering og integritetsbeskyttelse av DNS data, og er et underliggende verktøy som brukes av mange epostsikkerhetsprotokoller. DNS-based Authentication of Named Entities (DANE) er utviklet for å håndtere problemer med systemet for sertifiseringsautoriteter (CA) ved å tilby en alternativ kanal for å autentisere offentlige nøkler basert på DNSSEC, som resulterer i at de samme tillitsmekanismer som brukes for å sertifisere IP-adresser brukes til å sertifisere tjenere som opererer på disse adressene. Sender Policy Framework (SPF) bruker Domain Name System (DNS) for å tillate domene-eiere å lage opptegnelser som assosierer domenenavnet med et spesifikt spenn av IP-adresser for autoriserte meldingssendere. DomainKeys Identified Mail (DKIM) gjør det mulig for en MTA å signere utvalgte hodefelter og kroppen til en melding. Dette validerer kildedomenet til meldingen, og sørger også for integritet av meldingskroppen. Domain-based Message Authentication, Reporting, and Conformance (DMARC) lar avsendere vite den proporsjonale effektiviteten av deres SPF og DKIM regler, og signaliserer til mottakere hvilken aksjon som bør tas i forskjellige individuelle og mengde-angrepsscenarioer.

Secure/Multipurpose Internet Mail Extension (S/MIME)

S/MIME er en sikkerhetsutvidelse av internett epoststandarden MIME, basert på teknologi fra RSA Data Security. De viktigste dokumentene relatert til S/MIME omfatter:

  • RFC 5750, S/MIME Version 3.2 Certificate Handling
  • RFC 5751, S/MIME Version 3.2 Message Specification
  • RFC 4134, Examples of S/MIME Messages
  • RFC 2634, Enhanced Security Services for S/MIME
  • RFC 5652, Cryptographic Message Syntax (CMS)
  • RFC 3370, CMS Algorithms
  • RFC 5752, Multiple Signatures in CMS
  • RFC 1847, Security Multiparts for MIME – Multipart/Signed and Multipart/Encrypted

S/MIME sikrer en MIME-entitet med en signatur, kryptering, eller begge deler. MIME-entiteten gjøres klar i henhold til reglene for konstruksjon av MIME-meldinger; den prosesseres sammen med nødvendige sikkerhetsrelaterte data, slik som algoritme-identifikatorer og sertifikater, og ender opp som det vi kaller et PKCS-objekt. Dette objektet behandles så som meldingsinnhold, og pakkes inn i MIME. I alle tilfeller vil meldingen som sendes oversettes til kanonisk form.

Autentisering

Autentisering tilbys vha. digital signatur: Avsenderen lager en melding, og bruker SHA-256 for å generere en 256-bit hash av meldingen. Hashen krypteres vha.  RSA med avsenderens private nøkkel, og resultatet hektes ved meldingen.  I tillegg legges det ved identifiserende informasjon om avsenderen, som vil gjøre mottakeren i stand til å få tak i avsenderens offentlige nøkkel. Mottakeren bruker RSA med avsenderens offentlige nøkkel for å gjenvinne hashen, og sammenligner denne med hashen som den selv genererer fra meldingsteksten. Hvis de to er like, er avsenderen autentisk.

Det er støtte for frakoblede signaturer som kan sendes og lagres uavhengig fra meldingene de har signert.

Konfidensialitet

S/MIME sørger for konfidensialitet ved å kryptere meldinger, vanligvis vha. AES med en 128-bit nøkkel i CBC-modus. Denne nøkkelen krypteres også, typisk vha. RSA med mottakerens offentlige nøkkel. Hver symmetriske nøkkel, som kalles innholdskrypteringsnøkkel, brukes bare en gang; en ny nøkkel genereres som et tilfeldig tall for hver nye melding. Ettersom den bare brukes en gang, er innholdskrypteringsnøkkelen bundet til meldingen og sendes med den. Denne kombinasjonen av symmetrisk og asymmetrisk kryptering kalles hybrid kryptering, og er en vanlig metode for å redusere krypteringstid. Det er kun mottakeren som er i stand til å gjenvinne sesjonsnøkkelen som er bundet til meldingen.

Epostkompatibilitet

Mange epostsystemer støttet opprinnelig kun bruk av blokker som består av ASCII tekst. For å ta høyde for denne begrensningen tilbyr S/MIME en tjeneste som konverterer en rå 8-bit binær strøm til en strøm av utskriftbare ASCII-tegn. Metoden som brukes til dette kalles Base-64 konvertering, og er illustrert under. Hver gruppe av tre oktetter fordeles på 4 6-bits verdier som hver konverteres til ett ASCII-tegn, etter en bestemt tabell (000000 blir til A, 000001 til B, osv.) Konverteringen gjøres blindt, selv om dataene i utgangspunktet skulle finne på å være ASCII tekst. RFC 5751 anbefaler at selv om ytre 7-bits koding ikke brukes, så bør det originale MIME-innholdet kodes med Base-64.

Komprimering

S/MIME tilbyr muligheten til å komprimere en melding; dette har fordelen å spare plass både for sending av epost og lagring av filer. Komprimering kan gjøres i vilkårlig rekkefølge med hensyn på signering og meldingskryptering. RFC 5751 advarer måt å komprimere binært kodet krypterte data, ettersom det er usannsynlig at man vil oppnå signifikant komprimering. Base-64-kodet krypterte data vil sannsynligvis kunne komprimeres, men da er det jo ikke Base-64 lenger. Hvis man bruker en kompresjonsalgoritme med tap i forbindelse med signering, må man komprimere først, og deretter signere.

S/MIME Meldingsinnholdtyper

Innholdet i S/MIME-meldinger er definert i RFC 5652, Cryptographic Message Syntax, og omfatter:

  • Data: Refererer til det indre MIME-kodede meldingsinnholdet, som igjen kan være innkapslet i en SignedData, EnvelopedData, eller CompressedData innholdstype
  • SignedData: Brukt for å legge en digital signatur på meldingen.
  • EnvelopedData: Dette består av kryptert innhold av enhver type, og kryptert innholdskrypteringsnøkkel for en eller flere mottakere.
  • CompressedData: Brukt for å anvende komprimering på en melding.

EnvelopedData

For å lage et EnvelopedData element må man først generere en pseudorandom sesjonsnøkkel for en bestemt symmetrisk krypteringsalgoritme, og deretter kryptere denne sesjonsnøkkelen med den offentlige RSA-nøkkelen til hver mottaker. For hver mottaker vil man også opprette en blokk kalt RecipientInfo som inneholder en identifikator for mottakerens offentlig-nøkkel-sertifikat, en identifikator for algoritmen brukt til å kryptere sesjonsnøkkelen (RSA i dette eksempelet), og den krypterte sesjonsnøkkelen. Til slutt krypterer man meldingsinnholdet med sesjonsnøkkelen.

SignedData

For å lage et SignedData element må man først velge en hash-algoritme (f.eks. SHA-3), og deretter beregne hashen av meldingen som skal signeres. For signaturalgoritmer av samme type som RSA vil man kryptere hashverdien med avsenderens private nøkkel, og resultatet er signaturen. Til slutt vil man lage en blokk kalt SignerInfo som inneholder avsenderens offentlig-nøkkel-sertifikat, en identifikator for hash-funksjonen, en identifikator for signaturalgoritmen (RSA i vårt eksempel), og til slutt selve signaturen.

S/MIME har mulighet for klartekstsignering, hvor den digitale signaturen og selve meldingen utgjør en flerdelt MIME-melding. Dette betyr at meldingen kan leses, og signaturen verifiseres (manuelt) av epostlesere som ikke har implementert S/MIME.

S/MIME sertifikatprosessering

S/MIME bruker offentlig-nøkkel-sertifikater som retter seg etter versjon 3 av X.509. Administratorer og/eller brukere må konfigurere hver klient med en liste tiltrodde nøkler og med sertifikatrevokeringslister (CRL), ansvaret for å vedlikeholde sertifikater for å verifisere innkommende signaturer og for å kryptere utgående meldinger er plassert lokalt. Sertifikatene er signert av sertifiseringsautotiteter (CA).

Brukeragentrollen

En S/MIME-bruker har flere nøkkeladministrasjonsfunksjoner å utføre:

  • Nøkkelgenerering: Brukeren av et relatert administrativt verktøy må være i stand til å generere separate Diffie-Hellman og DSS nøkkelpar, og burde også være i stand til å generere RSA nøkkelpar. Brukeragenten skulle generere RSA nøkkelpar med lenge 768 til 1024 bit, og ikke kortere enn 512 bit (disse størrelsene er åpenbart noe foreldede; i dag ville vi vel forventet minst 2048 bits RSA-nøkler, og helst 3072 bit)
  • Registrering: En brukers offentlige nøkkel må være registrert hos en sertifiseringsautoritet (CA) for å motta et X.509 offentlig-nøkkel-sertifikat.
  • Lagring og uthenting av sertifikater: Brukeren trenger tilgang til en lokal liste av sertifikater for å verifisere innkommende signaturer og kryptere utgående meldinger.

Forbedrede sikkerhetstjenester

RFC 2634 definerer fire forbedrede sikkerhetstjenester for S/MIME:

  • Signert kvittering: Ved å returnere en signert kvittering gir man avsenderen et bevis for leveranse, noe som gjør avsenderen i stand til å bevise for en tredjepart at mottakeren har mottatt meldingen.
  • Sikkerhetsmerkelapper (gradering): Et sett med sikkerhetsinformasjon som angir sensitiviteten til informasjonen som er beskyttet av S/MIME-innkapsling.
  • Sikre epostlister: En S/MIME Mail List Agent (MLA) kan ta en enkelt innkommende melding, foreta mottaker-spesifikk kryptering for hver mottaker, og videresende meldingen.
  • Signeringssertifikat: Denne tjenesten brukes for å binde avsenderens sertifikat til dennes signatur gjennom en signeringssertifikat attributt.

Pretty Good Privacy (PGP)

PGP er en alternativ sikkerhetsløsning som i tillegg til frittstående funksjonalitet også tilbyr essensielt den samme funksjonaliteten som S/MIME. PGP ble implementert av Phil Zimmerman, og ble først sluppet som et produkt i 1991. Det var gratis tilgjengelig, og ble populært for personlig bruk tidlig på 90-tallet.  Protokollen var først av proprietær karakter, og brukte noen krypteringsalgoritmer med rettighetsbegrensinger (RSA kunne f.eks. ikke brukes fritt i USA på dette tidspunktet). En åpen-kildekode-variant kalt OpenPGP (RFC 3156 og RFC 4880) ble utviklet basert på PGP versjon 5.x, denne finnes bl.a. i Gnu Privacy Guard (GPG).

Det er to signifikante forskjeller mellom S/MIME og OpenGPG: Nøkkelsertifisering og nøkkeldistribusjon. OpenPGP baser seg ikke på noen sentrale aktører, men bruker i stedet noe kalt “nett av tillit” (web of trust). NIST SP 800-177 anbefaler bruk av S/MIME snarere enn PGP pga. at de har større tiltro til CA-systemet for verifisering av offentlige nøkler.

Domain Name System (DNS)

DNS er et katalogtjeneste som tilbyr en avbildning mellom navnet til en vert på internett og dens numeriske IP-adresse. Denne tjenesten er fundamental for at internett slik vi kjenner det skal fungere, og MUAer og MTAer bruker den for å finne adressen til den neste tjeneren i kjeden når epost skal leveres.

DNS består av fire elementer: Domenenavn-rommet (domain name space), DNS-databasen, navnetjenere, og oppklarere (resolvers).

DNS Databasen

DNS er basert på en hierarkisk database som inneholder ressursoppføringer (resource records) (RRs) son inkluderer navn, IP-addresse, og annen informasjon om verter. Nøkkelegenskaper for databasen omfatter et navnehierarki av variabel dybde, den er distribuert, og distribusjonen er kontrollert av databasen. Ved hjelp av denne databasen tilbyr DNS-tjenere en navn-til-adresse katalogtjeneste for nettverksapplikasjoner som trenger å lokalisere bestemte tjenere.

DNSSEC

DNSSEC er sikkerhetsutvidelser til DNS som tilbyr ende-til-ende beskyttelse vha. digitale signaturer som genereres av administratorer av responderende soner, og som verifiseres av mottakerens oppklarer-programvare. Dette gjør at man unngår å måtte stole på navnetjenere og oppklarere underveis som hurtiglagrer eller omdirigerer DNS-oppføringene som kommer fra den responderende sone-administratoren før de når kilden for forespørselen.

DNSEC består av et nytt sett av ressursoppføringstyper (RR) og modifikasjoner av den eksisterende DNS-protokollen, og er definert i disse dokumentene:

  • RFC 4033, DNS Security Introduction and Requirements
  • RFC 4034, Resource Records for the DNS Security Extensions
  • RFC 4035, Protocol Modifications for the DNS Security Extensions

Essensen av DNSSEC er at den skal beskytte DNS-klienter fra å akseptere forfalskede eller modifiserte DNS ressursoppføringer (RRer). Dette gjør den ved å bruke digitale signaturer for å gi autentisering av opphav (forsikrer at en RR kommer fra den oppgitte kilden) og integritetsbekreftelse (forsikrer at innholdet i RR ikke har blitt endret).

Tillit til den offentlige nøkkelen til kilden oppnås ved å starte fra en tiltrodd sone og etablere kjeden av tillit ned til den gjeldende kilden til svaret gjennom gjentatte verifikasjoner av signaturen til en offentlig nøkkel av dens “forelder”. Den offentlige nøkkelen til den tiltrodde sonen kalles “tillitsanker”.

Resssursoppføringer (RR) for DNSSEC

RFC 4034 definerer fire nye DNS ressursoppføringer:

  • DNSKEY – inneholder en offentlig nøkkel
  • RRSIG – en RR digitalsignatur
  • NSEC – en autentisert oppføring som avkrefter at noe finnes (denial of existence)
  • DS – delegeringssignerer

DNSSEC avhenger av å etablere ektheten av DNS-hierarkiet som fører til det aktuelle domenenavnet, og følgelig avhenger den av å starte bruken av kryptografiske digitale signaturer i rot-sonen. DS ressursoppføringen fasiliterer nøkkelsignering og autentisering mellom DNS-soner for å opprette en autentiseringskjede fra roten av DNS-treet ned til det spesifikke domenenavnet. For å beskytte alle DNS-oppslag bruker DNSSEC NSEC ressursoppføringen for å autentisere negative svar på forespørsler. NSEC brukes for å identifisere spennet av DNS-navn eller ressursoppføringstyper som ikke finnes blant sekvensen av domenenavn i en sone.

DANE

DNS-basert Autentisering av Navngitte Entiteter (DANE) er en protokoll for å tillate binding av X.509 sertifikater (som vanligvis brukes for TLS) til DNS-navn vha. DNSSEC. Det er foreslått i RFC 6698 som en måte å autentisere en TLS-klient og -tjener uten å bruke en sertifikatautoritet (CA). Hensikten med DANE er å erstatte avhengigheten av sikkerheten til CAen med å stole på sikkerheten som tilbys av DNSSEC.

Sender Policy Framework (SPF)

SPF er den standardiserte måten for et sendende domene å identifisere og bekrefte epostavsenderne for et gitt domene. SPF er definert i RFC 7208, og tilbyr en protokoll som administrative styringsdomener (administrative management domain – ADMD) kan autorisere verter med slik at de kan bruke deres domenenavn i “MAIL FROM” eller “HELLO” identitetene. SPF fungerer ved å sjekke senderens IP-adresse mot retningslinjene som finnes kodet i enhver SPF-oppføring som finnes hos domenet det sendes fra. Dette betyr at SPF-sjekkene kan utføres før meldingsinnholdet mottas fra avsenderen.

DomainKeys Identified Mail (DKIM)

DKIM (RFC 6376) er en spesifikasjon for kryptografisk signering av epostmeldinger, som tillater at et signerende domene påtar seg ansvaret for en melding i epoststrømmen. Meldingsmottakere kan verifisere signaturen ved å sende en forespørsel direkte til den signerendes domene for å hente den korresponderende offentlige nøkkelen, og kan følgelig bekrefte at meldingen er gått god for av en part som har den private nøkkelen for det signerende domene i sin besittelse. DKIM har blitt bredt antatt av en rekke epostleverandører og internett-tjeneste-leverandører (ISPer).

Epost-trusler

RFC 4686 (Analysis of Threats Motivating DomainKeys Identified Mail) beskriver truslene som adresseres av DKIM i henhold til karakteristika, evner og plassering av potensielle angripere. Det karakteriseres på tre trusselnivåer: I den lave enden av spekteret har vi angripere som ganske enkelt ønsker å sende epost som mottakeren ikke har lyst til å motta.  Det neste nivået er profesjonelle avsendere av engros søppelpost (spam), som ofte opptrer som kommersielle foretak og sender meldinger på vegne av tredjeparter. De mest sofistikerte og finansielt motiverte avsendere av meldinger er de som er i posisjon til å motta betydelig økonomisk gevinst, slik som fra et epostbasert svindelopplegg.

DMARC

Domenebasert MeldingsAutentisering, Rapportering og Konformitet (DMARC) tillater epostavsendere å spesifisere retningslinjer for hvordan deres epost skal behandles, hvilke typer rapporter mottakerne kan sende tilbake, og hvor ofte slike rapporter skal sendes. DMARC er definert i RFC 7489 (Domain-based Message Authentication, Reporting, and Conformance, Mars 2015).