Konfigurera SPF för att identifiera giltiga e-postkällor för din Microsoft 365-domän
Tips
Visste du att du kan prova funktionerna i Microsoft Defender för Office 365 Plan 2 kostnadsfritt? Använd den 90 dagar långa Defender för Office 365 utvärderingsversionen på Microsoft Defender portalens utvärderingshubb. Lär dig mer om vem som kan registrera dig och utvärderingsvillkor på Try Microsoft Defender för Office 365.
SPF (Sender Policy Framework) är en metod för e-postautentisering som hjälper till att verifiera e-post som skickas från din Microsoft 365-organisation för att förhindra falska avsändare som används i kompropromisser för affärsmeddelanden (BEC), utpressningstrojaner och andra nätfiskeattacker.
Det primära syftet med SPF är att verifiera e-postkällor för en domän. Mer specifikt använder SPF en TXT-post i DNS för att identifiera giltiga e-postkällor för domänen. Mottagande e-postsystem använder SPF TXT-posten för att verifiera att e-post från avsändaradressen som användes under SMTP-överföringen av meddelandet (kallas MAIL FROM-adress, 5321.MailFrom
adress, P1-avsändare eller kuvertsändare) kommer från en känd, angiven e-postkälla för den domänen.
Om din e-postdomän i Microsoft 365 till exempel är contoso.com skapar du en SPF TXT-post i DNS för den contoso.com domänen för att identifiera Microsoft 365 som en auktoriserad e-postkälla från contoso.com. Mål-e-postsystem kontrollerar SPF TXT-posten i contoso.com för att avgöra om meddelandet kom från en auktoriserad källa för contoso.com e-post.
Innan vi börjar måste du veta följande om SPF i Microsoft 365 baserat på din e-postdomän:
Om du bara använder MOERA-domänen (Microsoft Online Email Routing Address) för e-post (till exempel contoso.onmicrosoft.com): Du behöver inte göra något. SPF TXT-posten har redan konfigurerats åt dig. Microsoft äger onmicrosoft.com domän, så vi ansvarar för att skapa och underhålla DNS-posterna i den domänen och underdomänerna. Mer information om *.onmicrosoft.com domäner finns i Varför har jag en "onmicrosoft.com"-domän?.
Om du använder en eller flera anpassade domäner för e-post (till exempel contoso.com): Microsoft 365-registreringsprocessen kräver redan att du skapar eller ändrar SPF TXT-posten i DNS för din anpassade domän för att identifiera Microsoft 365 som en auktoriserad e-postkälla. Men du har fortfarande mer att göra för maximalt e-postskydd:
Överväganden för underdomäner:
För e-posttjänster som inte kontrolleras direkt (till exempel massutskickstjänster) rekommenderar vi att du använder en underdomän (till exempel marketing.contoso.com) i stället för din huvudsakliga e-postdomän (till exempel contoso.com). Du vill inte att problem med e-post som skickas från dessa e-posttjänster ska påverka ryktet för e-post som skickas av anställda i din huvudsakliga e-postdomän. Mer information om hur du lägger till underdomäner finns i Kan jag lägga till anpassade underdomäner eller flera domäner i Microsoft 365?.
Varje underdomän som du använder för att skicka e-post från Microsoft 365 kräver en egen SPF TXT-post. SPF TXT-posten för contoso.com omfattar till exempel inte marketing.contoso.com. marketing.contoso.com behöver en egen SPF TXT-post.
Tips
Email autentiseringsskydd för odefinierade underdomäner omfattas av DMARC. Alla underdomäner (definierade eller inte) ärver DMARC-inställningarna för den överordnade domänen (som kan åsidosättas per underdomän). Mer information finns i Konfigurera DMARC för att verifiera från-adressdomänen för avsändare i Microsoft 365.
Om du äger registrerade men oanvända domäner: Om du äger registrerade domäner som inte används för e-post eller något alls (kallas även parkerade domäner) konfigurerar du SPF TXT-poster för att indikera att ingen e-post någonsin ska komma från dessa domäner enligt beskrivningen senare i den här artikeln.
Enbart SPF räcker inte. För den bästa nivån av e-postskydd för dina anpassade domäner måste du också konfigurera DKIM och DMARC som en del av din övergripande strategi för e-postautentisering . Mer information finns i avsnittet Nästa steg i slutet av den här artikeln.
Viktigt
I komplexa organisationer där det är svårt att identifiera alla giltiga e-postkällor för domänen är det viktigt att du snabbt konfigurerar DKIM-signering och DMARC (i läget "vidta inga åtgärder" för domänen. En DMARC-rapporteringstjänst är till stor hjälp för att identifiera e-postkällor och SPF-fel för domänen.
Resten av den här artikeln beskriver de SPF TXT-poster som du behöver skapa för anpassade domäner i Microsoft 365.
Tips
Det finns inga administratörsportaler eller PowerShell-cmdletar i Microsoft 365 som du kan hantera SPF-poster i din domän. I stället skapar du SPF TXT-posten hos din domänregistrator eller DNS-värdtjänst (ofta samma företag).
Vi tillhandahåller instruktioner för att skapa bevis på TXT-post för domänägarskap för Microsoft 365 hos många domänregistratorer. Du kan använda de här anvisningarna som utgångspunkt för att skapa SPF TXT-postvärdet. Mer information finns i Lägga till DNS-poster för att ansluta din domän.
Om du inte känner till DNS-konfigurationen kontaktar du domänregistratorn och ber om hjälp.
Syntax för SPF TXT-poster
SPF TXT-poster beskrivs utförligt i RFC 7208.
Den grundläggande syntaxen för SPF TX-posten för en anpassad domän i Microsoft 365 är:
v=spf1 <valid mail sources> <enforcement rule>
Eller:
v=spf1 [<ip4>|<ip6>:<PublicIPAddress1> <ip4>|<ip6>:<PublicIPAddress2>... <ip4>|<ip6>:<PublicIPAddressN>] [include:<DomainName1> include:<DomainName1>... include:<DomainNameN>] <-all | ~all>
Till exempel:
v=spf1 ip4:192.168.0.10 ip4:192.168.0.12 include:spf.protection.outlook.com -all
v=spf1
identifierar TXT-posten som en SPF TXT-post.Giltiga e-postkällor: Angivna giltiga e-postkällor för domänen. Använder domäner, IP-adresser eller båda:
Domäner:
include:
värden anger andra tjänster eller domäner som giltiga e-postkällor från den ursprungliga domänen. Dessa värden leder slutligen till en IP-adress med DNS-sökningar.De flesta Microsoft 365-organisationer behöver
include:spf.protection.outlook.com
I SPF TXT-posten för domänen. Andra e-posttjänster från tredje part kräver ofta ett ytterligareinclude:
värde för att identifiera tjänsten som en giltig e-postkälla från den ursprungliga domänen.IP-adresser: Ett IP-adressvärde innehåller båda följande element:
- Värdet
ip4:
ellerip6:
för att identifiera typen av IP-adress. - Den offentligt matchbara IP-adressen för käll-e-postsystemet. Till exempel:
- En enskild IP-adress (till exempel 192.168.0.10).
- Ett IP-adressintervall med CIDR-notation (Classless Inter-Domain Routing) (till exempel 192.168.0.1/26). Se till att intervallet inte är för stort eller för litet.
I Microsoft 365 använder du vanligtvis IP-adresser i SPF TXT-posten endast om du har lokala e-postservrar som skickar e-post från Microsoft 365-domänen (till exempel Exchange Server hybriddistributioner). Vissa e-posttjänster från tredje part kan också använda ett IP-adressintervall i stället för ett
include:
värde i SPF TXT-posten.- Värdet
Tvingande regel: Meddelar mål-e-postsystem vad de ska göra med meddelanden från källor som inte har angetts i SPF TXT-posten för domänen. Giltiga värden är:
-all
(svårt fel): Källor som inte anges i SPF TXT-posten har inte behörighet att skicka e-post för domänen, så meddelandena bör avvisas. Vad som faktiskt händer med meddelandet beror på målets e-postsystem, men meddelandena ignoreras vanligtvis.För Microsoft 365-domäner rekommenderar
-all
vi (hårt fel) eftersom vi även rekommenderar DKIM och DMARC för domänen. DMARC-principen anger vad du ska göra med meddelanden som misslyckas med SPF eller DKIM, och DMARC-rapporter gör att du kan verifiera resultaten.Tips
Som tidigare nämnts hjälper DMARC som konfigurerats med en DMARC-rapporteringstjänst mycket till att identifiera e-postkällor och SPF-fel för domänen.
~all
(mjukt fel): Källor som inte anges i SPF TXT-posten har förmodligen inte behörighet att skicka e-post för domänen, så meddelandena bör godkännas men markeras. Vad som faktiskt händer med meddelandet beror på målets e-postsystem. Meddelandet kan till exempel placeras i karantän som skräppost, levereras till mappen Junk Email eller levereras till inkorgen med en identifierare som lagts till i ämnes- eller meddelandetexten.Eftersom vi också rekommenderar DKIM och DMARC för Microsoft 365-domäner elimineras skillnaderna mellan
-all
(hårt fel) och~all
(mjukt fel) effektivt (DMARC behandlar båda resultaten som ett SPF-fel). DMARC använder SPF för att bekräfta att domänerna i MAIL FROM- och From-adresserna justeras och meddelandet kommer från en giltig källa för domänen From.
Tips
?all
(neutral) är också tillgängligt för att föreslå att inga specifika åtgärder vidtas på meddelanden från oidentifierade källor. Det här värdet används för testning och vi rekommenderar inte det här värdet i produktionsmiljöer.
Viktiga saker att komma ihåg:
- Varje definierad domän eller underdomän i DNS kräver en SPF TXT-post, och endast en SPF-post tillåts per domän eller underdomän. Email autentiseringsskydd för odefinierade underdomäner hanteras bäst av DMARC.
- Du kan inte ändra den befintliga SPF TXT-posten för domänen *.onmicrosoft.com.
- När mål-e-postsystemet kontrollerar giltiga e-postkällor i SPF-posten misslyckas SPF-verifieringen om kontrollen kräver för många DNS-sökningar. Mer information finns i avsnittet Felsöka SPF TXT-poster senare i den här artikeln.
SPF TXT-poster för anpassade domäner i Microsoft 365
Tips
Som tidigare nämnts i den här artikeln skapar du SPF TXT-posten för en domän eller underdomän hos domänregistratorn för domänen. Ingen SPF TXT-postkonfiguration är tillgänglig i Microsoft 365.
Scenario: Du använder contoso.com för e-post i Microsoft 365 och Microsoft 365 är den enda källan till e-post från contoso.com.
SPF TXT-post för contoso.com i Microsoft 365 och Microsoft 365 Government Community Cloud (GCC):
v=spf1 include:spf.protection.outlook.com -all
SPF TXT-post för contoso.com i Microsoft 365 Government Community Cloud High (GCC High) och Microsoft 365 Department of Defense (DoD):
v=spf1 include:spf.protection.office365.us -all
SPF TXT-post för contoso.com i Microsoft 365 som drivs av 21Vianet
v=spf1 include:spf.protection.partner.outlook.cn -all
Scenario: Du använder contoso.com för e-post i Microsoft 365 och du har redan konfigurerat SPF TXT-posten i contoso.com med alla e-postkällor från domänen. Du äger även domänerna contoso.net och contoso.org, men du använder dem inte för e-post. Du vill ange att ingen har behörighet att skicka e-post från contoso.net eller contoso.org.
SPF TXT-post för contoso.net:
v=spf1 -all
SPF TXT-post för contoso.org:
v=spf1 -all
Scenario: Du använder contoso.com för e-post i Microsoft 365. Du planerar att skicka e-post från följande källor:
- En lokal e-postserver med den externa e-postadressen 192.168.0.10. Eftersom du har direkt kontroll över den här e-postkällan anser vi att det är OK att använda servern för avsändare i contoso.com domän.
- Massutskickstjänsten Adatum. Eftersom du inte har direkt kontroll över den här e-postkällan rekommenderar vi att du använder en underdomän, så du skapar marketing.contoso.com för det ändamålet. Enligt Adatum-tjänstdokumentationen måste du lägga
include:servers.adatum.com
till I SPF TXT-posten för din domän.
SPF TXT-post för contoso.com:
v=spf1 ip4:192.168.0.10 include:spf.protection.outlook.com -all
SPF TXT-post för marketing.contoso.com:
v=spf1 include:servers.adatum.com include:spf.protection.outlook.com -all
Felsöka SPF TXT-poster
En SPF-post per domän eller underdomän: Flera SPF TXT-poster för samma domän eller underdomän orsakar en DNS-sökningsloop som gör att SPF misslyckas, så använd bara en SPF-post per domän eller underdomän.
Mindre än 10 DNS-sökningar: När mål-e-postsystem frågar SPF TXT-posten efter giltiga källor för MAIL FROM-adressdomänen söker frågan igenom IP-adresserna och
include:
-uttrycken i posten tills meddelandekällan (slutligen en IP-adress) matchar en av de angivna källorna. Om antalet DNS-sökningar (som kan skilja sig från antalet DNS-frågor) är större än 10 misslyckas SPF med ett permanent fel (kallas även för ).permerror
Mål-e-postsystemet avvisar meddelandet i en rapport om utebliven leverans (kallas även NDR eller studsmeddelande) med något av följande fel:- Meddelandet överskred antalet hopp.
- Meddelandet krävde för många sökningar.
I SPF TXT-posten orsakar inte enskilda IP-adresser eller IP-adressintervall DNS-sökningar. Varje
include:
instruktion kräver minst en DNS-sökning och fler sökningar kan krävas ominclude:
värdet pekar på kapslade resurser. Med andra ord garanterar färre än 10include:
instruktioner inte mindre än 10 DNS-sökningar.Tänk också på att mål-e-postsystem utvärderar källorna i SPF TXT-posten från vänster till höger. Utvärderingen stoppas när meddelandekällan har verifierats och inga fler källor kontrolleras. Därför kan en SPF TXT-post innehålla tillräckligt med information för att orsaka mer än 10 DNS-sökningar, men verifieringen av vissa e-postkällor av vissa mål går inte tillräckligt djupt i posten för att resultera i ett fel.
Förutom att bevara ryktet för din huvudsakliga e-postdomän är inte mer än antalet DNS-sökningar en annan anledning att använda underdomäner för andra e-posttjänster som du inte styr.
Du kan använda kostnadsfria onlineverktyg för att visa din SPF TXT-post och andra DNS-poster för din domän. Vissa verktyg beräknar till och med antalet DNS-postsökningar som din SPF TXT-post kräver.
Nästa steg
Som beskrivs i Hur SPF, DKIM och DMARC fungerar tillsammans för att autentisera avsändare av e-postmeddelanden räcker det inte med enbart SPF för att förhindra förfalskning av din Microsoft 365-domän. Du måste också konfigurera DKIM och DMARC för bästa möjliga skydd. Du hittar anvisningar i:
- Använda DKIM för att validera utgående e-post som skickas från din anpassade domän
- Använda DMARC för att validera e-post
För e-post som kommer till Microsoft 365 kan du också behöva konfigurera betrodda ARC-förseglare om du använder tjänster som ändrar meddelanden under överföring före leverans till din organisation. Mer information finns i Konfigurera betrodda ARC-förseglare.