Konfigurera betrodda ARC-förseglare

Email autentisering hjälper till att verifiera e-post som skickas till och från din Microsoft 365-organisation för att förhindra falska avsändare som används i hot mot affärsmeddelanden (BEC), utpressningstrojaner och andra nätfiskeattacker.

Men vissa legitima e-posttjänster kan ändra meddelanden innan de levereras till din Microsoft 365-organisation. Att ändra inkommande meddelanden under överföring kan och kommer sannolikt att orsaka följande fel vid e-postautentisering i Microsoft 365:

• SPF misslyckas på grund av den nya meddelandekällan (IP-adress).
• DKIM misslyckas på grund av innehållsändring.
• DMARC misslyckas på grund av SPF- och DKIM-felen.

Autentiserad mottagen kedja (ARC) hjälper till att minska inkommande e-postautentiseringsfel från meddelandeändring av legitima e-posttjänster. ARC bevarar den ursprungliga e-postautentiseringsinformationen i e-posttjänsten. Du kan konfigurera din Microsoft 365-organisation så att den litar på tjänsten som ändrade meddelandet och att använda den ursprungliga informationen i e-postautentiseringskontroller.

När du ska använda betrodda ARC-tätningar

En Microsoft 365-organisation behöver bara identifiera betrodda ARC-förseglare när meddelanden som levereras till Microsoft 365-mottagare regelbundet påverkas på följande sätt:

• Mellanhandstjänsten ändrar meddelandehuvudet eller e-postinnehållet.
• Meddelandeändringarna gör att autentiseringen misslyckas av andra orsaker (till exempel genom att ta bort bifogade filer).

När en administratör har lagt till en betrodd ARC-förseglare i Defender-portalen använder Microsoft 365 den ursprungliga e-postautentiseringsinformationen som ARC-förseglaren tillhandahåller för att verifiera de meddelanden som skickas via tjänsten till Microsoft 365.

Tips

Lägg bara till legitima, nödvändiga tjänster som betrodda ARC-förseglare i din Microsoft 365-organisation. Att endast lägga till legitima tjänster hjälper berörda meddelanden att klara kontroller för e-postautentisering och förhindrar att legitima meddelanden hamnar i mappen Skräppost, sätts i karantän eller avvisas på grund av misslyckad e-postautentisering.

Vad behöver jag veta innan jag börjar?

• Du öppnar Microsoft Defender-portalen på https://security.microsoft.com. Om du vill gå direkt till sidan Email autentiseringsinställningar använder du https://security.microsoft.com/authentication.

• Information om hur du använder Windows PowerShell för att ansluta till Exchange Online finns i artikeln om att ansluta till Exchange Online PowerShell.

• Du måste tilldelas behörigheter innan du kan lägga till eller hantera betrodda ARC-tätningar. Du har även följande alternativ:

  • Microsoft Defender XDR Enhetlig rollbaserad åtkomstkontroll (RBAC) (Om Email & samarbete> är Defender för Office 365 behörigheter aktiv. Påverkar endast Defender-portalen, inte PowerShell): Auktorisering och inställningar/Säkerhetsinställningar/Kärnsäkerhetsinställningar (hantera) eller auktorisering och inställningar/Säkerhetsinställningar/Kärnsäkerhetsinställningar (läs).

  • Exchange Online behörigheter: Medlemskap i rollgrupperna Organisationshantering eller Säkerhetsadministratör.

  • Microsoft Entra behörigheter: Medlemskap i den globala administratören^*. Medlemmar i rollen Säkerhetsadministratör kan inte komma åt autentiseringsinställningar för e-post i Defender-portalen.

    Viktigt

    ^* Microsoft förespråkar starkt principen om lägsta behörighet. Genom att endast tilldela konton de minsta behörigheter som krävs för att utföra sina uppgifter kan du minska säkerhetsriskerna och stärka organisationens övergripande skydd. Global administratör är en mycket privilegierad roll som du bör begränsa till nödsituationsscenarier eller när du inte kan använda en annan roll.

Använd Microsoft Defender-portalen för att lägga till betrodda ARC-tätningar

1. I Microsoft Defender portalen på https://security.microsoft.comgår du till Email & samarbetsprinciper>& regler>Hotprinciper>Email Autentiseringsinställningar i avsnittet >ARC . Om du vill gå direkt till sidan Email autentiseringsinställningar använder du https://security.microsoft.com/authentication.

2. På sidan Email autentiseringsinställningar kontrollerar du att fliken ARC är markerad och väljer sedan Lägg till.

   Tips

   Om Betrodda förseglare redan visas på arc-fliken väljer du Redigera.

3. I den utfällbara menyn Lägg till betrodda ARC-förseglare som öppnas anger du den betrodda signeringsdomänen i rutan (till exempel fabrikam.com).

   Domännamnet måste matcha domänen som visas i d-värdet i rubrikerna ARC-Seal och ARC-Message-Signature i berörda meddelanden. Använd följande metoder för att visa meddelandehuvudet:

   • Visa meddelandehuvuden på Internet i Outlook.
   • Använd Analysverktyg för meddelandehuvud på https://mha.azurewebsites.net.

   Upprepa det här steget så många gånger det behövs. Om du vill ta bort en befintlig post väljer du bredvid posten.

   När du är klar med den utfällbara menyn Lägg till betrodda ARC-förseglare väljer du Spara.

Använda Exchange Online PowerShell för att lägga till betrodda ARC-tätningar

Om du hellre vill använda PowerShell för att visa, lägga till eller ta bort betrodda ARC-förseglare ansluter du till Exchange Online PowerShell för att köra följande kommandon.

• Visa befintliga betrodda ARC-tätningar: Kör följande kommando för att kontrollera vilka betrodda ARC-tätningar som för närvarande är konfigurerade i din organisation:

  Get-ArcConfig
  

  Om inga betrodda ARC-förseglare har konfigurerats returnerar kommandot inga resultat.

• Lägga till eller ta bort betrodda ARC-förseglare

  Om du vill ersätta befintliga ARC-tätningar med de värden som du anger använder du följande syntax:

  Set-ArcConfig -Identity [TenantId\]Default -ArcTrustedSealers "Domain1","Domain2",..."DomainN"
  

  TenantId\-värdet krävs inte i din egen organisation, endast i delegerade organisationer. Det är ett GUID som visas i många url:er för administratörsportalen i Microsoft 365 ( tid= värdet). Till exempel aaaabbbb-0000-cccc-1111-dddd222eeee.

  Det här exemplet konfigurerar "cohovineyard.com" och "tailspintoys.com" som de enda betrodda ARC-förseglarna i organisationen.

  Set-ArcConfig -Identity Default -ArcTrustedSealers "cohovineyard.com","tailspintoys.com"
  

  För att bevara befintliga värden måste du inkludera ARC-tätningarna som du vill behålla tillsammans med de nya ARC-tätningarna som du vill lägga till.

  Om du vill lägga till eller ta bort ARC-tätningar utan att påverka de andra posterna kan du läsa exemplen i Set-ArcConfig.

Viktigt

ARC-tätningsdomänen är inte din organisations domän. Det är leverantörens signeringsdomän som visas i fältet i d= ARC-Seal-huvudet. Kontrollera alltid det faktiska d= värdet från ett meddelandehuvud innan du konfigurerar den betrodda förseglaren.

Konfigurera betrodda ARC-tätningar för flera leverantörer

Om din organisation använder flera e-posttjänster som lägger till ARC-tätningar ansluter du till Exchange Online PowerShell och lägger till alla leverantörsdomäner i ett enda kommando.

Viktigt

Parametern -ArcTrustedSealersersätter alla befintliga poster. Om du vill bevara befintliga betrodda förseglare inkluderar du dem i kommandot tillsammans med alla nya domäner som du vill lägga till.

Försiktighet

Lägg bara till leverantörer som du aktivt använder och litar på. Om du lägger till onödiga ARC-förseglare ökar din attackyta eftersom en komprometterad leverantör kan skicka falska meddelanden via dina autentiseringskontroller.

Set-ArcConfig -Identity Default -ArcTrustedSealers "Domain1.com","Domain2.com","Domain3.com","Domain4.com"

Hitta leverantörens ARC-förseglardomän

Använd följande steg för att identifiera rätt ARC-förseglingsdomän:

1. Skicka ett testmeddelande via mellanhandstjänsten till en Microsoft 365-postlåda.
2. Öppna meddelandehuvudena (i Outlook: Filegenskaper>>Internethuvuden eller använd analysverktyget för meddelanderubrik).
3. Sök ARC-Seal: efter i rubrikerna.
4. Anteckna värdet d= . Det här värdet är domänen som ska läggas till som en betrodd ARC-förseglare.

Verifiera en betrodd ARC-förseglare

Om det finns en ARC-tätning från en tjänst innan meddelandet når Microsoft 365 kontrollerar du meddelandehuvudet för de senaste ARC-huvudena när meddelandet har levererats.

Leta efter och arc=passi det senaste oda=1. Dessa värden anger:

• Den tidigare ARC har verifierats.
• Den tidigare ARC-förseglaren är betrodd.
• Det tidigare passresultatet kan användas för att åsidosätta det aktuella DMARC-felet.

I följande exempel visas en ARC-Authentication-Results-rubrik där arc=pass och oda=1 bekräftar en betrodd ARC-tätning:

ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
172.17.17.17) smtp.rcpttodomain=microsoft.com
smtp.mailfrom=sampledoamin.onmicrosoft.com; dmarc=bestguesspass action=none
header.from=sampledoamin.onmicrosoft.com; dkim=none (message not signed);
arc=pass (0 oda=1 ltdi=1
spf=[1,1,smtp.mailfrom=sampledoamin.onmicrosoft.com]
dkim=[1,1,header.d=sampledoamin.onmicrosoft.com]
dmarc=[1,1,header.from=sampledoamin.onmicrosoft.com])

Om du vill kontrollera om ARC-resultatet användes för att åsidosätta ett DMARC-fel letar compauth=pass du upp och reason=130 i det senaste autentiseringsresultathuvudet . Följande exempel visar rubriken Authentication-Results där kombinerad autentisering godkändes på grund av en betrodd ARC-signerare (reason=130):

Authentication-Results: spf=fail (sender IP is 10.10.10.10)
smtp.mailfrom=contoso.com; dkim=fail (body hash did not verify)
header.d=contoso.com;dmarc=fail action=none
header.from=contoso.com;compauth=pass reason=130

Obs!

ARC-resultatpasset från en betrodd ARC-tätning kan potentiellt åsidosätta fel i SPF, DKIM eller DMARC som orsakas av meddelandeändring under överföring. Den slutliga förfalskningsbestämningen baseras dock på resultatet för sammansatt autentisering (CompAuth). Meddelanden som misslyckas med ARC kan fortfarande levereras om de klarar utvärderingar av SPF, DKIM, DMARC och sammansatt autentisering.

E-postflödesdiagram för betrodda ARC-förseglare

Diagrammen i det här avsnittet kontrasterar e-postflödet och effekten på e-postautentiseringsresultat med och utan en betrodd ARC-förseglare. I båda diagrammen använder Microsoft 365-organisationen en legitim e-posttjänst som ändrar inkommande e-post innan den levereras till Microsoft 365. Den här ändringen avbryter e-postflödet, vilket kan orsaka fel vid e-postautentisering genom att ändra käll-IP-adressen och uppdatera e-postmeddelandets sidhuvud.

Följande diagram över e-postflödet visar resultatet utan en betrodd ARC-signerare:

Följande e-postflödesdiagram visar resultatet med en betrodd ARC-förseglare:

Vanliga ARC-felscenarier

När ARC inte fungerar som förväntat använder du följande felsökningsreferens.

Snabbreferens: ARC-felsymptom

I följande tabell visas vanliga ARC-felsymptom, deras troliga orsaker och rekommenderade lösningar.

Symptom	Trolig orsak	Åtgärd
arc=fail i ARC-Authentication-Results	ARC-tätningsdomänen har inte lagts till som betrodd eller fel domän konfigurerad.	Kontrollera värdet d= i ARC-Seal-huvudet och lägg till det i betrodda förseglare.
arc=none i ARC-Authentication-Results	Mellanliggande tjänst lägger inte till ARC-huvuden.	Kontakta leverantören för att aktivera ARC-signering.
oda=0 Trots arc=pass	ARC-tätningsdomänen finns inte med i listan över betrodda förseglare.	Lägg till rätt domän med hjälp av Set-ArcConfig.
compauth=fail reason=000 trots betrodd tätning	ARC-kedjevalidering misslyckades (bruten kedja).	Sök efter problem med kedjeintegritet (se Bruten ARC-kedja).
dmarc=fail och inga ARC-huvuden finns	Meddelandet gick inte igenom en ARC-kompatibel mellanhand.	ARC kan inte hjälpa. Åtgärda SPF/DKIM vid källan.
Meddelanden i karantän trots ARC-pass	Principåtgärd mot skräppost som överskrider ARC-resultatet.	Granska karantänprincipen. ARC åsidosätter endast DMARC, inte skräppostfiltrering.

Fel ARC-tätningsdomän har konfigurerats

Problem: Du har lagt till en egen domän (till exempel contoso.com) i stället för leverantörens ARC-tätningsdomän.

Meddelanderubrikerna visar leverantörens faktiska ARC-tätningsdomän. Kontrollera värdet d= i ARC-Seal rubriken för att identifiera rätt domän som ska konfigureras som en betrodd försegling:

ARC-Seal: i=1; a=rsa-sha256; d=pphosted.com; s=arcselector;
  cv=none; b=<signature>

Men när du kör Get-ArcConfig i Exchange Online PowerShell visar utdata att din egen domän har konfigurerats i stället för leverantörens ARC-tätningsdomän:

ArcTrustedSealers : {contoso.com}

Lösning: Använd leverantörens ARC-tätningsdomän. Till exempel:

Set-ArcConfig -Identity Default -ArcTrustedSealers "pphosted.com"

Mellanliggande tjänst lägger inte till ARC-huvuden

Problem: Meddelanden passerar din gateway men innehåller inga ARC-huvuden. Mellanhandstjänsten stöder antingen inte ARC eller så är ARC inte aktiverat.

Diagnos: Sök meddelandehuvuden för ARC-Seal:. Om det inte finns någon ARC-Seal huvud är mellanhanden inte förseglad.

Lösning: Aktivera ARC-inloggning i leverantörens hanteringskonsol:

Leverantör	Så här aktiverar du ARC
Proofpoint	Aktivera ARC i Email Protection>Email inställningar för utgående routning>.
Mimecast	Aktivera viaadministrationsgatewayprinciper>>>Definitioner>FÖR ARC-signering.
Barracuda	ARC är aktiverat som standard i Email Gateway Defense. Kontrollera i Inkommande inställningar>Skydd mot nätfiske.
Sophos	Aktivera i Sophos Central>Email Säkerhetsinställningar>>ARC.

Viktigt

Om leverantören inte stöder ARC kan du överväga alternativa lösningar:

• Konfigurera en Exchange-e-postflödesregel (transportregel) för att hoppa över skräppostfiltrering för meddelanden från tjänstens IP-adresser.
• Lägg till tjänstens skickande IP-adresser till listan över tillåtna IP-adresser för anslutningsfiltret.
• Använd Utökad filtrering för anslutningsappar (hoppa över lista) för att bevara den ursprungliga autentiseringen.

Bruten ARC-kedja (cv=fail)

Problem: ARC-kedjevalidering visar cv=fail, vilket innebär att en tidigare ARC-tätning i kedjan inte kunde verifieras.

I följande exempel visas en ARC-Seal-rubrik där cv=fail anger en bruten ARC-kedja:

ARC-Seal: i=2; a=rsa-sha256; d=mimecast.com; s=arc-2018;
  cv=fail; b=<signature>

Det här felet har vanligtvis följande orsaker:

• En tidigare mellanhand ändrade meddelandet efter att ha lagt till sin ARC-tätning (bryta kedjan).
• DNS-problem förhindrade sökning av ARC-förseglarens offentliga nyckel.
• Den offentliga ARC-nyckeln roterades men cachelagrade DNS-poster har inte upphört att gälla.

Lösning: Använd följande steg för att diagnostisera och åtgärda den brutna kedjan:

1. Kontrollera värdet cv= vid varje ARC-instans (i=1, i=2osv.) för att identifiera var kedjan bröts.
2. Kontrollera att ARC-förseglarens offentliga nyckel har publicerats i DNS. Använd till exempel nslookup -type=TXT arcselector._domainkey.pphosted.com för att fråga nyckelposten.
3. Om DNS inte returnerar något resultat kontaktar du leverantören om deras ARC-nyckelpublikation.
4. Om kedjan bryts mellan två tjänster som du kontrollerar kontrollerar du att meddelandeändringar sker före ARC-tätningen, inte efter.

ARC skickas men meddelanden går fortfarande till Junk Email

Problem: ARC-validering godkänns (arc=pass, compauth=pass reason=130), men meddelanden levereras fortfarande till mappen Junk Email.

Förklaring: ARC åsidosätter endast DMARC-autentiseringsfel. Den kringgår inte:

• Spamfiltrering (innehållsfiltrering).
• Massfiltrering av e-post (BCL-tröskelvärde).
• Principåtgärder för skräppostskydd.
• Åtgärder för e-postflödesregel.
• Listor över betrodda/blockerade avsändare.

Diagnos: Granska X-Forefront-Antispam-Report rubriken för att avgöra om innehållsbaserad skräppostfiltrering gjorde att meddelandet gick till Skräppost oberoende av ARC:

X-Forefront-Antispam-Report: CIP:10.10.10.10; CTRY:US; LANG:en;
  SFV:SPM; H:mail.fabrikam.com; PTR:mail.fabrikam.com; CAT:SPM;

Om något av värdena CAT:SPM, CAT:HSPM, eller SFV:SPM förekommer, identifierade spamfiltrering (innehållsfiltrering) meddelandet som spam eller högkonfidensspam, vilket är oberoende av ARC.

Lösning: Prova följande alternativ för att lösa skräppostfiltreringen:

• Skapa en e-postflödesregel, kringgå spamfiltrering för meddelanden från betrodda avsändare eller IP-adresser.
• Lägg till avsändardomänen i en lista över tillåtna principer för skräppostskydd.
• Skicka meddelandet som en falsk positiv identifiering via Microsoft Defender-portalen.

Referens för CompAuth-orsakskoder

I följande tabell sammanfattas de sammansatta autentiseringsorsakskoderna (CompAuth) som visas i rubriken Authentication-Results .

Orsakskod	Beskrivning
000	Meddelandet misslyckades med sammansatt autentisering (explicit fel).
001	Meddelandet misslyckades med sammansatt autentisering (implicit fel).
002	Meddelandet har en explicit SPF/DKIM-förbikoppling som förhindrar sammansatt autentiseringsutvärdering.
010	Meddelandet exkluderades från DMARC-filtrering (till exempel skickat till sig själv).
1xx	Meddelandet misslyckades DMARC med åtgärden som bestäms av DMARC-principen.
130	Åsidosättning av ARC: sammansatt autentisering godkändes på grund av en betrodd ARC-tätning.
2xx	Mjuk godkänd sammansatt autentisering (källan var misstänkt).
3xx	Sammansatt autentisering har inte markerats.
4xx	Kompositautentisering har kringgåts.

Tips

När du har lagt till eller modifierat betrodda ARC-förseglare kan det ta upp till 30 minuter innan konfigurationen börjar gälla. Testa med nya meddelanden som skickas efter den här perioden.

Nästa steg

Kontrollera DINA ARC-huvuden med Message Header Analyzer på https://mha.azurewebsites.net.

Konfigurera SPF, DKIM och DMARC för din domän.

Information om hur du diagnostiserar och åtgärdar fel med e-postautentisering finns i Felsöka e-postautentisering i Microsoft 365.