Dela via

Metodtips för stöd för avsändarautentisering i e-post för Azure Communication Services

  • Artikel

Den här artikeln innehåller metodtips för e-postsändning för DNS-poster och hur du använder metoderna för avsändarautentisering som förhindrar angripare från att skicka meddelanden som ser ut som om de kommer från din domän.

E-postautentisering och DNS-konfiguration

Att skicka ett e-postmeddelande kräver flera steg, bland annat att verifiera att avsändaren av e-postmeddelandet faktiskt äger domänen, kontrollera domänens rykte, virusgenomsökning, filtrering efter skräppost, nätfiskeförsök, skadlig kod osv. Att konfigurera korrekt e-postautentisering är en grundläggande princip för att upprätta förtroende för e-post och skydda domänens rykte. Om ett e-postmeddelande klarar autentiseringskontroller kan den mottagande domänen tillämpa principen på e-postmeddelandet i enlighet med det rykte som redan har upprättats för de identiteter som är associerade med dessa autentiseringskontroller, och mottagaren kan vara säker på att dessa identiteter är giltiga.

MX-post (Mail Exchange)

MX-posten (Mail Exchange) används för att dirigera e-post till rätt server. Den anger den e-postserver som ansvarar för att acceptera e-postmeddelanden för din domäns räkning. DNS måste uppdateras med den senaste informationen om MX-poster i din e-postdomän, annars resulterar det i vissa leveransfel.

SPF (Sender Policy Framework)

SPF RFC 7208 är en mekanism som gör det möjligt för domänägare att publicera och underhålla, via en standard-DNS TXT-post, en lista över system som har behörighet att skicka e-post för deras räkning. Den här posten används för att ange vilka e-postservrar som har behörighet att skicka e-post för din domäns räkning. Det hjälper till att förhindra förfalskning av e-post och öka e-postprodukt.

DKIM (domännycklar identifierade e-post)

Med DKIM RFC 6376 kan en organisation ta ansvar för att skicka ett meddelande på ett sätt som kan verifieras av mottagaren. Den här posten används också för att autentisera domänen som e-postmeddelandet skickas från och hjälper till att förhindra förfalskning av e-post och öka e-postprodukt.

DMARC (domänbaserad meddelandeautentisering, rapportering och överensstämmelse)

DMARC RFC 7489 är en skalbar mekanism genom vilken en e-postorganisation kan uttrycka principer och inställningar på domännivå för validering, borttagning och rapportering av meddelanden som en e-postmottagande organisation kan använda för att förbättra e-posthanteringen. Den används också för att ange hur e-postmottagare ska hantera meddelanden som misslyckas med SPF- och DKIM-kontroller. Detta förbättrar e-postprodukt och hjälper till att förhindra förfalskning av e-post.

ARC (autentiserad mottagen kedja)

ARC-protokollet RFC 8617 tillhandahåller en autentiserad kedja av vårdnad för ett meddelande, så att varje entitet som hanterar meddelandet kan identifiera vilka entiteter som hanterade det tidigare samt meddelandets autentiseringsbedömning vid varje hopp. ARC är ännu inte en Internetstandard, men implementeringen ökar.

Så här fungerar e-postautentisering

E-postautentisering verifierar att e-postmeddelanden från en avsändare (till exempel notification@contoso.com) är legitima och kommer från förväntade källor för e-postdomänen (till exempel contoso.com.) Ett e-postmeddelande kan innehålla flera ursprungsadresser eller avsändaradresser. Dessa adresser används för olika syften. Tänk till exempel på följande adresser:

  • Mail From-adressen identifierar avsändaren och anger var returmeddelanden ska skickas om det uppstår problem med leveransen av meddelandet, till exempel meddelanden om utebliven leverans. Detta visas i kuvertdelen av ett e-postmeddelande och visas inte av e-postprogrammet. Detta kallas ibland 5321.MailFrom-adressen eller adressen för omvänd sökväg.

  • Från adressen visas adressen som Från-adressen i e-postprogrammet. Den här adressen identifierar författaren till e-postmeddelandet. Det vill: postlådan för den person eller det system som ansvarar för att skriva meddelandet. Detta kallas ibland 5322.From-adressen.

  • SPF (Sender Policy Framework) hjälper till att verifiera utgående e-post som skickas från din e-post från domänen (kommer från vem den säger att den är).

  • DomainKeys Identified Mail (DKIM) hjälper till att säkerställa att mål-e-postsystem litar på meddelanden som skickas utgående från din e-post från domänen.

  • Domänbaserad meddelandeautentisering, rapportering och överensstämmelse (DMARC) fungerar med SPF (Sender Policy Framework) och DomainKeys Identified Mail (DKIM) för att autentisera e-postavsändare och se till att mål-e-postsystemen litar på meddelanden som skickas från din domän.

Implementera DMARC

Implementering av DMARC med SPF och DKIM ger omfattande skydd mot förfalskning och nätfiske via e-post. SPF använder en DNS TXT-post för att tillhandahålla en lista över auktoriserade skickande IP-adresser för en viss domän. Normalt utförs SPF-kontroller endast mot adressen 5321.MailFrom. Det innebär att adressen 5322.From inte autentiseras när du använder SPF på egen hand. Detta möjliggör ett scenario där en användare kan ta emot ett meddelande som klarar en SPF-kontroll men har en förfalskad 5322.From-avsändaradress.

Precis som DNS-posterna för SPF är posten för DMARC en TXT-post (DNS-text) som hjälper till att förhindra förfalskning och nätfiske. Du publicerar DMARC TXT-poster i DNS. DMARC TXT-poster verifierar ursprunget för e-postmeddelanden genom att verifiera IP-adressen för ett e-postmeddelandes författare mot den påstådda ägaren av den sändande domänen. DMARC TXT-posten identifierar auktoriserade utgående e-postservrar. Mål-e-postsystem kan sedan verifiera att meddelanden som de tar emot kommer från auktoriserade utgående e-postservrar. Detta tvingar fram ett matchningsfel mellan 5321.MailFrom och 5322.From-adresserna i alla e-postmeddelanden som skickas från din domän och DMARC misslyckas för det e-postmeddelandet. För att undvika detta måste du konfigurera DKIM för din domän.

Med en DMARC-princippost kan en domän meddela att deras e-post använder autentisering. ger en e-postadress för att samla in feedback om användningen av deras domän; och anger en begärd princip för hantering av meddelanden som inte klarar autentiseringskontroller. Vi rekommenderar att du

  • Principinstruktioner domäner som publicerar DMARC-poster är "p=reject" där det är möjligt, annars "p=quarantine".
  • Principsatsen "p=none", "sp=none" och pct<100 bör bara ses som övergångstillstånd, med målet att ta bort dem så snabbt som möjligt.
  • Alla publicerade DMARC-principposter bör minst innehålla en "rua"-tagg som pekar på en postlåda för att ta emot DMARC-sammanställda rapporter och bör inte skicka tillbaka några svar när du tar emot rapporter på grund av sekretessproblem.

Nästa steg

Följande dokument kan vara intressanta för dig: