Domänskydd mot spoofing
SPF-poster hjälper till att förhindra spoofing– utskick av spammare oönskade e-postmeddelanden från din domän. För detta ändamål används teknologin Sender Policy Framework (SPF).
Eftersom spoofing ofta används av angripare, kan vissa servrar E-post kräver SPF-kontroll. E-postmeddelanden som inte klarar detta kan avvisas eller markeras som skräppost.
Använder SPF med DKIM och DMARC
Förutom SPF rekommenderar vi att du använder DomainKeys Identified Mail (DKIM) och Domain-based Message Authentication, Reporting & Conformance (DMARC) kontroller. SPF definierar intervallet av domäner från vilka du kan ta emot e-post. DKIM låter dig säkerställa att innehållet i ett meddelande inte har ändrats efter att det skickades. Och DMARC anger vad som ska göras med misstänkta meddelanden som kommer till din domän.
Hur man skapar en SPF-post för en domän
SPF-posten definierar e-postservrarna som får skicka e-post från din domän. Meddelanden från servrar som inte ingår i den här listan kan markeras som skräppost.
För att ställa in SPF-poster i Gmail, lägg till en TXT-post i ditt registrarsystem. Detta kommer inte att påverka e-postfunktionaliteten.
Om du behöver hjälp, kontakta din registrar.
Den nya SPF-posten kommer att träda i kraft inom 48 timmar.
Så här kontrollerar du din SPF-post
Du kan kontrollera din SPF-post med G Suite Toolkit.
- Gå till https://toolbox.googleapps.com/apps/checkmx/.
- Ange ditt domännamn.
- Klick Börja kolla.
- När det är klart klickar du Giltiga SPF-adressintervall.
- Kontrollera resultaten. De måste innehålla följande rader:
- _spf.google.com
- _netblocks.google.com och flera IP-adresser
- _netblocks2.google.com och flera IP-adresser
- _netblocks3.google.com och flera IP-adresser
Hur man uppdaterar SPF-posten för flera e-postservrar
Att använda flera SPF-poster kan orsaka auktoriseringsproblem. Istället rekommenderar vi att du lägger till befintlig post SPF ytterligare servrar.
Till exempel, om du har konfigurerat en gateway för utgående e-post, kommer SPF-posten att innehålla adressen Gmail-servrar och SMTP-serveradressen för denna gateway.
För att lägga till en e-postserver till en befintlig SPF-post, föregå argumentet med ~ alla IP-adress för denna server i ip4-format: adress eller ip6: adress, som visas i exemplet nedan.
Vi har nyligen satt upp en SMTP-server för vårt projekt. Frågan var: vad behöver göras för att brev som skickas till våra användare inte hamnar i skräppostmappen eller hamnar där så sällan som möjligt?
Flera intressanta och användbara artiklar om detta ämne (länkar i slutet av artikeln), på grundval av vilken allt gjordes till slut. Men i morse, efter att ha fått ytterligare ett parti utskick från ganska välkända ryskspråkiga resurser och såg att de försummade de beskrivna reglerna, bestämde jag mig för kort och på ett ställe samla in alla åtgärder som är tillräckliga för att lösa problemet. Jag hoppas att efter detta kommer antalet sajter som skickar e-post korrekt att öka.
Tipsen ovan är endast relevanta om du använder din egen SMTP-server. Vid användning av t.ex. SMTP-servrar Google har redan gjort allt för oss. Vanligtvis. I alla fall rekommenderar jag att du kontrollerar det (se underavsnitt Hur kollar man?).
Föremålen är ordnade efter betydelse. Det är bättre att inte starta nästa utan att slutföra den föregående.
Registrera omvänd DNS
Namnet talar för sig självt. Omvänd DNS-sökning - procedur omvänd DNS slå upp. Via IP-adress får vi, eller snarare användarens e-postserver, ett domännamn. Om det stämmer domän namn i fältet Från i det skickade brevet är allt i sin ordning.Hur man gör det?
I de flesta fall kommer du inte att kunna göra detta själv om du inte äger IP-adressintervallet. Det är därför det enda sättet do denna inställning- be din värdleverantör att göra detta.
Hur kollar man?
Använd någon av onlinetjänsterna för omvänd DNS-sökning. Till exempel den här. Det räcker med att ange IP-adressen till servern från vilken e-post skickas. Om resultatet visar din domän är allt bra.
I de flesta fall räcker följande post:
exempel.com. TXT v=spf1 a mx ~all
Den här posten säger att e-post kan skickas från vilken IP som helst som anges i A (AAAA) och MX-posterna för en given domän och endast från dem.
Hur kollar man?
Skicka e-post via din tjänst till valfritt Gmail-konto. Öppna det mottagna brevet och välj Visa original från åtgärdsmenyn.
Om du hittar följande rader är allt bra:
Mottagen-SPF: passera
Autentiseringsresultat: ... spf=pass
Total
De beskrivna åtgärderna bör avsevärt minska sannolikheten för att dina e-postmeddelanden hamnar i skräppost. Alla andra tekniker är relaterade till innehållet i brevet eller hur användare reagerar på det (markerar de ofta ditt meddelande som spam?). Men det är en annan historia.SPF-post - avsändarverifiering.
Som alla vet, protokollet för att skicka e-post SMTP-post, innebär att vem som helst kan anges som avsändare Brevlåda. På så sätt kan du skicka ett brev genom att ersätta ett fiktivt värde i fältet "Från". Processen med sådant e-postbedrägeri kallas e-postspoofing. För att bekämpa detta fenomen utvecklades och introducerades SPF-standarden (Sender Policy Framework).
SPF tillåter domänägaren att ange i TXT-posten för domänen en speciellt utformad sträng som anger listan över servrar som har rätt att skicka e-postmeddelanden med returadresser i denna domän.
Låt oss titta på ett enkelt exempel på en SPF-post:
exempel.org. IN TXT "v=spf1 +a +mx -all"
Låt oss nu titta på de tillgängliga alternativen mer detaljerat. Låt oss överväga mottagarens beteendealternativ, beroende på vilka alternativ som används:
- "v=spf1" är den SPF-version som används.
- “+” – ta emot korrespondens (Pass). Det här alternativet är inställt som standard. Det vill säga, om inga parametrar är inställda är det "Pass";
- "-" — Avvisa (misslyckas);
- "~" — "mjuk" avvikelse (SoftFail). Brevet kommer att accepteras, men kommer att markeras som SPAM;
- "?" - neutral attityd;
- "mx" - inkluderar alla serveradresser som anges i domänens MX-poster;
- "ip4" - alternativet låter dig ange en specifik IP-adress eller nätverk av adresser;
- "a" - indikera beteendet vid mottagande av ett brev från en specifik domän;
- "inkludera" - inkluderar värdar tillåtna av SPF-posten för den angivna domänen;
- "alla" – alla andra servrar som inte är listade i SPF-posten.
Så låt oss försöka ta reda på vad SPF-posten som anges ovan betyder.
- "+a" - tillåter mottagning av bokstäver från en nod vars IP-adress matchar IP-adressen i A-posten till exempel.org;
- "+mx" - tillåter mottagning av brev om den sändande värden är specificerad i en av MX-posterna till exempel.org;
- "-all" - alla meddelanden som inte klarar verifieringen med de listade mekanismerna ska avvisas.
För att bättre förstå hur SPF fungerar, låt oss titta på en annan, mer komplext exempel:
exempel.org. IN TXT "v=spf1 mx ip4:78.110.50.123 +a:mail.ht-systems.ru include:gmail.com ~all"
Nu mer detaljerat om de alternativ som används...
- "mx" — ta emot brev från servrar som anges i MX-poster;
- "ip4:78.110.50.123" — ta emot brev skickade från IP-adress 78.110.50.123;
- "+a:mail.ht-systems.ru" är detsamma som a:mail.ht-systems.ru. Acceptera från mail.ht-systems.ru;
- "include:gmail.com" – ta emot e-postmeddelanden från servrar tillåtna av gmail.com SPF-poster;
- "~alla" — acceptera meddelanden från alla andra servrar, men markera dem som SPAM
Låt oss nu titta på ett ännu mer "exotiskt" exempel. Beskrivningen av möjliga alternativ visade att det var möjligt att ange nätverk av IP-adresser. Det är värt att notera att detta även gäller "a" och "mx"-posterna. Tänk på följande exempel:
exempel.org. IN TXT “v=spf1 mx/24 a:hts.ru/24 -all”
"mx/24" - listan över tillåtna avsändare inkluderar alla IP-adresser som finns i samma klass C-nätverk som domänens MX;
"a:hts.ru/24" — listan över tillåtna avsändare inkluderar alla IP-adresser som finns i samma klass C-nätverk som A-posterna för hts.ru-domänen;
"-all" - alla andra avsändare är blockerade.
Ibland kan man träffas följande poster(Väldigt sällan):
"ptr" - kontrollerar PTR-posten för avsändarens IP-adress. Om den matchar den angivna domänen returnerar verifieringsmekanismen ett positivt resultat. Det vill säga att det är tillåtet att skicka till alla IP-adresser vars PTR-poster är riktade till den angivna domänen. En allvarlig nackdel med denna metod är att den genererar mycket Ett stort antal DNS-frågor;
"finns" - en kontroll görs för att se om domänen löser sig till någon IP-adress. Det vill säga att en hälsokontroll av domännamnet utförs. Förresten spelar det ingen roll vilken IP-adress domänen löser till, även om det är "gråa" nätverk (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) eller loopback (127.0.0.1) .
Användningsexempel:
exempel.org. IN TXT "v=spf1 ptr:example.org exist:example.org -all"
Det skulle också vara en bra idé att bekanta dig med följande alternativ: omdirigering och exp.
"redirect" - säger åt mottagaren att kontrollera SPF-posten för den angivna domänen, istället för den aktuella domänen. Exempel:
exempel.org. IN TXT "v=spf1 redirect:example.com ~all"
I det här exemplet kommer SPF-posten för domänen example.com att kontrolleras, inte example.org.
"exp" — med det här alternativet kan du ange ett felmeddelande som kommer att skickas till avsändaren när ett sådant inträffar. Placeras i slutet av SPF-posten, även efter alternativet allt. Låt oss ta en närmare titt på mekanismen för hur exp-alternativet fungerar.
Låt oss säga att domänen example.org har följande SPF-post:
exempel.org. IN TXT "v=spf1 +a +mx -all exp=spf.example.org"
Nu skapar vi en TXT-post för domänen spf.example.org:
spf.example.org. I TXT "Du" värd inte tillåtet e-postmeddelande till mig"
Som ett resultat av dessa shamanska handlingar kommer SPF-posten att kontrollera att e-post endast levereras från giltiga värdar, och alla andra kommer att skickas ett felmeddelande skrivet i TXT-posten för spf.example.org-domänen.
Det är också värt att notera att varje beslut att blockera eller markera ett brev som skräppost avgörs av programmet som behandlar mottagandet av e-post på servern, ibland t.o.m. utskick det gör de också.
SPF (Sender Policy Framework) är en av åtgärderna för att bekämpa SPAM. Detta är en speciell post som anger IP-adresserna och tjänsterna från vilka e-post skickas på uppdrag av din domän, samt e-postbearbetningspolicyn.
Finesser för att ställa in SPF-inspelning
SPF-posten är registrerad i DNS. Du måste gå till din DNS-värdpanel, välja en domän och gå in i dess register. Skapa sedan en ny post:
- Postnamn: domänadress med en prick i slutet. Till exempel website.ru.
- Inläggstyp: TXT
- Värde: v=spf1 ip4:133.133.133.133 include:_spf.yandex.net ~all
SPF-inspelningsparametrar
Alla inspelningsparametrar anges avgränsade med ett mellanslag:
- v=spf1 - protokollversion. Lämna det som det är
- ip4:133.133.133.133 - IP för servern från vilken e-post skickas. Om det finns flera servrar, ange dessa parametrar åtskilda av ett mellanslag
- include:_spf.yandex.net - tillåter även att skicka brev från Yandex.Mail på en domän (om du använder den här tjänsten)
- Parameter före alla:
- "-" - betyder att det är tillåtet att ta emot brev endast från de angivna tjänsterna och adresserna. Acceptera inte resten.
- "~" - det är tillåtet att ta emot brev från de angivna tjänsterna. Om brevet kom från en annan server, markera det som oönskat.
- "?" - betyder att det kan finnas andra tjänster som post skickas från.
Korrekt inställning av SPF-posten kommer att öka nivån på e-postleverans till mottagaren. Vi kan sätta upp SPF på en VPS eller dedikerad server helt gratis. Det är viktigt att lägga till domänen på denna server. Om du har några problem med att sätta upp en inspelning, kontakta gärna RigWEB-specialister. Vi ställer in din SPF-domänpost gratis.
I våra tidigare material har vi redan tittat på att sätta upp en DNS-zon för korrekt drift Mejl server, såväl som rollen för enskilda DNS-poster. Men som praxis visar, förstår inte alla administratörer korrekt mekanismen för hur e-postsystem fungerar med DNS-poster. Därför bestämde vi oss för att ägna en separat artikel till denna fråga, där vi kommer att analysera den mer på djupet och prata om jämförelsevis ny teknologi SPF
Det största problemet med modern postsystem- skräppost. Det är många olika metoder kämpa mot det, men den viktigaste är analysen av avsändaren, med tanke på att alla nödvändig information står i brevet.
Låt oss dra en analogi med vanlig post. Postkuvertet eller paketet innehåller alltid avsändarens adress, mottagarens adress och frimärken för de postkontor som den besökt. utskick. På samma sätt innehåller ett e-postmeddelande i sina rubriker information om avsändare, mottagare och märken för de e-postservrar som deltagit i behandlingen av e-postmeddelandet.
Låt oss säga att du fick ett extremt misstänkt paket på postkontoret, förmodligen från din älskade farfar Konstantin Makarovich, men av någon anledning pekar avsändarens stämpel inte på postkontoret i byn Makarovka, utan mot Gadyukino-gården på den andra sidan av landet. Kommer du att öppna ett sådant paket och riskera att hitta mjältbrandssporer istället för en burk med äpplen med paradissylt, eller kommer du att skicka tillbaka det, ur farans väg?
Det är samma sak med e-postsystem. Om du fått ett brev från din farfar [e-postskyddad] , men sändningsservern av någon anledning mail.spam.com, då är detta en anledning att inte acceptera ett sådant brev, eftersom det med största sannolikhet är spam.
Hur genomförde vi denna check? Väldigt enkelt, titta på stämpeln postkontor avsändaren och jämförde den med returadressen. Till exempel, på kuvertet står det skrivet att avsändaren är i staden Moskva, men stämpeln på sändningskontoret innehåller indexet 683000, vilket indikerar Petropavlovsk-Kamchatsky. Därför accepterar vi inte ett sådant brev, eftersom det inte har klarat avsändarverifieringen.
Situationen är liknande med via e-post, endast i stället för det sändande avdelningsindexet används det PTR-rekord. Så, efter att ha fått ett brev från farfar, kommer vi att göra det PTR-begäran och ta reda på att sändningsservern är vår mail.spam.com, medan det enligt informationen som överförs under anslutningen bör finnas mail.example.com. Allt är klart, brevet går till skräppost.
Men om rubriken indikerar att den sändande servern är vår mail.spam.com, då är ett sådant brev framgångsrikt kommer att testas Förbi PTR-rekord, trots att den sändande serverdomänen inte matchar e-postdomän brev.
Varför händer det här? För att kolla förbi PTR-rekord låter dig bara avgöra att den sändande servern verkligen är den den utger sig för att vara. Men bestämmer inte på något sätt avsändarens äkthet. De där. med hänvisning till exempel vanlig post vi kontrollerar bara det returadress och avsändarens filialindex matchar, om avreseorten är Moskva, och indexet pekar på Petropavlovk-Kamchatsky, kontrollera sedan PTR Ett sådant brev gick inte igenom, men om avgångsplatsen och indexet matchar, är allt bra och nu är din uppgift att tänka på vad din älskade farfar gör i Petropavlovsk-Kamchatsky.
Missförstånd av denna punkt leder till det faktum att PTR-rekord visar sig vara felaktigt konfigurerad och som ett resultat når det mesta av det skickade e-postmeddelandet inte till mottagaren. Detta är särskilt viktigt att förstå när du konfigurerar servrar som betjänar flera domäner. I detta fall PTR-rekord måste peka på e-postvärdnamnet (som det överför som en del av SMTP-sessionen), även om det finns i en annan domän.
Låt oss titta på ett enkelt exempel.
Server mail.example.com skickar ett e-postmeddelande för den domän den betjänar exempel.org. Den mottagande servern gör en begäran PTR-rekord och ser till att adressen 123.123.123.123 verkligen beläget mail.example.com, därför kommer ett sådant brev att accepteras, även om domänen för avsändaren av brevet och domänen för den sändande servern inte matchar.
Och nu är situationen en annan.
Administratören har konfigurerat DNS-zonen felaktigt genom att ange fel värd i PTR-rekord. Den mottagande servern har kontrollerat PTR-rekord kommer att avvisa vårt brev eftersom den sändande servern inte matchar resultatet av den omvända DNS-frågan.
Frånvaro PTR-rekord leder nästan alltid till avvisning av brevet, eftersom det finns en outtalad överenskommelse om att avsändaren i god tro har en korrekt konfigurerad returzon.
Låt oss gå tillbaka till vår farfar. Låt oss säga att han berättade att han till sommaren kommer att lämna byn Makarovka till grannbyn Ivanovka, till en viss Marfa Vasilievna, och har för avsikt att skicka korrespondens till dig därifrån. I det här fallet kommer du säkert att acceptera brev från din farfar både från Makarovka och från Ivanovka, men du kommer att vägra den förmodade farfars brev från Petropavlovsk-Kamchatsky.
En liknande teknik i e-postsystem implementeras med hjälp av teknik SPF. Kort sagt alltså denna teknik låter dig skapa en speciell DNS-post som visar vem som exakt har rätt att skicka e-post för din domäns räkning. I själva enkel version posten kommer att se ut så här:
Exempel.com. IN TXT "v=spf1 +a +mx -all"
Vad betyder det? Det faktum att e-post för domänen example.com kan skickas av noder specificerade i A-posten (+a) och MX-posterna (+mx), bör all annan e-post avvisas (-all).
Allt är dock inte så rosenrött. För det första är SPF-stöd fortfarande inte en de facto-standard och brist SPF-rekord Avsändarens domän har ingen anledning att avvisa brevet. Det andra problemet är att vidarebefordra servrar eller fall där e-post skickas av servrar som inte är listade i A- eller MX-poster, eller till och med finns i andra domäner. Detta kan bero på både arkitekturen i företagets IT-system och användningen av andras servrar för att skicka när du länkar din domän till en leverantör eller offentlig tjänst. I det senare fallet måste du vara extra försiktig och det är mycket lämpligt att rådgöra med servicesupport.
Låt oss överväga en annan situation.
Ditt företag, förutom din huvudsakliga e-postserver mail.example.com, använder tjänster tredjepartstjänster, som kan skicka post till ett företags kunder för dess räkning. Detta kan vara en expressposttjänst som kommer att meddela kunder å dina vägnar om leveransstatus etc.
I vårt exempel kommer sådan post att skickas på uppdrag av [e-postskyddad] från servern mail.web-service.com, därför att denna server inte listad i domänens MX-poster exempel.com, sedan, enligt vad vi angav i SPF-rekord Som regel kommer ett sådant brev att avvisas av mottagaren.
Dessutom kommer beteendet hos den mottagande servern att vara entydigt, eftersom vi själva tydligt har angett att e-post från andra avsändare inte ska accepteras. Därför, om du inte är säker på att all e-post kommer enbart från dina servrar, bör du ange en mjukare regel:
exempel.org. IN TXT "v=spf1 +a +mx ~all"
Till skillnad från -Allt(misslyckas) ~alla(soft fail) indikerar att andra avsändare än de som uttryckligen anges inte får skicka e-post, men innehåller inget krav på att avvisa sådan e-post. Oftast accepteras sådan post, markerad som oönskade.
Du kan också använda ett neutralt prefix:
exempel.org. IN TXT "v=spf1 +a +mx ?all"
I detta fall säger regeln att de värdar som anges i A- och MX-poster, det finns ingen information om de återstående noderna. Mottagning av e-post från uttryckligen obehöriga noder är upp till den mottagande servern som oftast accepteras utan några märken.
Vad ska vi göra i vårt fall? Mest rätt beslut kommer att läggas till SPF-inträde en regel till:
exempel.org. IN TXT "v=spf1 +a +mx +mx:web-service.com -all"
exempel.org. IN TXT "v=spf1 +a +mx +a:mail.web-service.com -all"
i det första fallet tillåter vi att e-post tas emot även från alla servrar som är listade i domänens MX-poster web-service.com, i det andra fallet endast för servern mail.web-service.com.
Låt oss slutligen överväga fallet när e-post för din domän betjänas av en server som finns på en annan domän. Till exempel mail.example.com skickar även e-post för domänen exempel.org. I den här situationen skulle det vara korrekt att använda för domänen exempel.org samma regler som för exempel.com. För att göra detta, använd en speciell typ av inspelning:
exempel.org. IN TXT "v=spf1 redirect=example.com"
Detta gör att du bara kan ändra poster en gång, om nödvändigt, för huvuddomänen och befriar administratörer för andra accepterade domäner från att behöva övervaka och göra ändringar i DNS-poster.
Taggar:
