Hur vi konfigurerar DNS TXT -området för SPF, DKIM och DMARC och hur vi undviker att affärsmeddelanden ska avvisas av Gmail – Postleverans misslyckades

Administratörer för allvarlig privat e-post för företag möter ofta många problem och utmaningar. Från vågorna av Skräppost care trebuie blocate prin filtre specifice, korrespondenssäkerhet in serverul local de e-mail si serverele la distanta, Konfigurerar och övervakning av SMTP-tjänster, POP, Imma, plus många och många andra detaljer om SPF, DKIM och DMARC konfiguration att följa god praxis för att skicka säkra e-postmeddelanden.

Många problem med skicka e-postmeddelanden eller mottagare till/från dina leverantörer, visas på grund av felaktig konfiguration av området DNS, hur är det med e-posttjänsten.

För att e-post ska skickas från ett domännamn måste det vara det värd på en e-postserver korrekt konfigurerad, och domännamnet måste ha DNS-zoner för SPF, MX, DMARC OCH Dkim korrekt inställd i managern DNS TXT av domänen.

I dagens artikel kommer vi att fokusera på ett ganska vanligt problem privata e-postservrar för företag. Oförmåga att skicka e-postmeddelanden till Gmail-konton, Yahoo! eller iCloud.

Meddelanden som skickas till @Gmail.com avvisas automatiskt. “E-postleverans misslyckades: skickar meddelande till avsändaren”

Jag stötte nyligen på ett problem på en företags e-postdomän, varifrån e-postmeddelanden skickas regelbundet till andra företag och till privatpersoner, några av dem har adresser @gmail.com. Alla meddelanden som skickades till Gmail-konton returnerades omedelbart till avsändaren. “E-postleverans misslyckades: skickar meddelande till avsändaren”.

Felmeddelandet returnerades i e-postservern på EXIM ser ut så här:

1nSeUV-0005zz-De ** [email protected] R=dnslookup T=remote_smtp H=gmail-smtp-in.l.google.com [142.x.x.27] X=TLS1.2:ECDHE-ECDSA-AES128-GCM-SHA256:128 CV=yes: SMTP error from remote mail server after pipelined end of data: 550-5.7.26 This message does not have authentication information or fails to\n550-5.7.26 pass authentication checks. To best protect our users from spam, the\n550-5.7.26 message has been blocked. Please visit\n550-5.7.26  https://support.google.com/mail/answer/81126#authentication for more\n550 5.7.26 information. d3-20020adff843000000b001f1d7bdaeb7si6107985wrq.510 - gsmtp

I detta scenario är det inte något särskilt allvarligt, som t.ex inklusive avsändarens domännamn eller avsändarens IP i en SPAM-lista globalt eller o stort konfigurationsfel av e-posttjänster på sevrer (EXIM).
Även om många, när de ser detta meddelande, omedelbart tänker på SPAM eller ett SMTP-konfigurationsfel, genereras problemet av området DNS TXT av fältet. För det mesta är DKIM inte konfigurerat i DNS-zonen eller är inte korrekt angivet i domänens DNS-hanterare. Detta problem stöter ofta på av de som använder det CloudFlare som DNS Manager och glöm att passera DNS TXT: mail._domainkey (Dkim), DMARC och SPF.

Som det står i meddelandet om avslag från Gmail har äktheten och autentiseringen av avsändardomänen misslyckats. “Det här meddelandet har ingen autentiseringsinformation eller klarar inten550-5.7.26 autentiseringskontroller.”. Detta innebär att domänen inte har DNS TXT konfigurerad för att säkerställa trovärdighet för mottagande e-postserver. Gmail, i vårt scenario.

När vi lägger till en webbdomän med en aktiv e-posttjänst på cPanel eller VestaCP skapas automatiskt filerna från respektive domäns DNS-zon. DNS-zonen som också innehåller konfigurationen av e-posttjänsten: MX, SPF, Dkim, DMARC.
I den situationen då vi väljer domänen som ska vara på chefen DNS CloudFlare, DNS-zonen från domänens värdkonto, måste kopieras till CloudFlare, för att e-postdomänen ska fungera korrekt. Det var problemet i scenariot ovan. I en tredjeparts DNS-hanterare finns det ingen DKIM-post, även om den finns på den lokala serverns DNS-hanterare.

Vad är DKIM och varför avvisas e-postmeddelanden om vi inte har den här funktionen på en e-postdomän?

DomainKeys identifierade Mail (DKIM) Det är en standardlösning för autentisering av en e-postdomän, som lägger till en digital signatur till varje skickat meddelande. Destinationsservrar kan kontrollera genom DKIM om meddelandet kommer från avsändarens juridiska domän och inte från en annan domän som använder avsändarens identitet som en mask. För all del, om du har domänen abcdqwerty.com utan DKIM kan e-postmeddelanden skickas från andra servrar med ditt domännamn. Det är om man vill ha en identitetsstöld, som på fackspråk kallas e-postförfalskning.
En vanlig teknik när e-postmeddelanden skickas av phishing och skräppost.

Tot prin intermediul DKIM se poate asigura ca, innehållet i meddelandet ändrades inte efter att det skickats av avsändaren.

Om du har DKIM korrekt inställt på e-postsystemets värdserver och i DNS-zonen, elimineras möjligheten att dina meddelanden når mottagaren i SPAM eller inte når dem alls.

Ett exempel på DKIM är:

mail._domainkey: "v=DKIM1; k=rsa; p=MIGfMA0GCSqGfdSIb3DQEBAQUAA4GN ... ocqWffd4cwIDAQAB"

Naturligtvis DKIM-värdet som erhålls av RSA-krypteringsalgoritm det är unikt för varje domännamn och kan återskapas från värdservern för e-posttjänsten.

Att ha DKIM installerat och korrekt inställt DNS TXT chef är det mycket möjligt att lösa problemet med meddelanden som returneras till Gmail-konton. Åtminstone för felet “Postleverans misslyckades”:

“SMTP-fel från fjärr-e-postserver efter pipelined slut av data: 550-5.7.26 Detta meddelande har ingen autentiseringsinformation eller klarar inten550-5.7.26 autentiseringskontroller. För att på bästa sätt skydda våra användare från spam har meddelandetn550-5.7.26 blockerats.”

Ca o scurta recapitulare, DKIM lägger till en digital signatur till varje meddelande som skickas, vilket gör att destinationsservrarna kan verifiera avsändarens äkthet. Om meddelandet kom från ditt företag och adressen inte användes av en tredje part för att kunna använda din identitet.

Gmail (Google) kan automatiskt avvisa alla meddelanden som kommer från domäner som inte har en sådan digital DKIM-signatur.

Vad är SPF och varför är det viktigt för att skicka e-postmeddelanden på ett säkert sätt?

Samt DKIM, och SPF syftar till att förebygga meddelandenätfiske och e-postförfalskning. På så sätt kommer de skickade meddelandena inte längre att markeras som skräppost.

Sender Policy Framework (SPF)är en standardmetod för att autentisera den domän från vilken meddelandena skickas. SPF-posterna är inställda hanterar DNS TXT av din domän och i denna post kommer att anges domännamnet, IP-adressen eller domänerna som har rätt att skicka e-postmeddelanden med ditt eller din organisations domännamn.

Un domeniu fara SPF poate permite spammerilor sa trimita mesaje de e-mail de pe alte servere, använda ditt domännamn som en mask. På så sätt kan de spridas falsk information eller känsliga uppgifter kan begäras på uppdrag av din organisation

Naturligtvis kan meddelanden fortfarande skickas för din räkning från andra servrar, men de kommer att markeras som skräppost eller avvisas om den servern eller domännamnet inte anges i din domäns SPF TXT-post.

Ett SPF-värde i DNS-hanteraren ser ut så här:

@ : "v=spf1 a mx ip4:x.x.x.x ?all"

Där “ip4” representerar IPv4 för din e-postserver.

Hur ställer jag in SPF för flera domäner?

Om vi ​​vill tillåta andra domäner att skicka e-postmeddelanden på uppdrag av vår domän kommer vi att ange dem med värdet “include” i SPF TXT:

v=spf1 ip4:x.x.x.x include:example1.com include:example2.com ~all

Detta innebär att e-postmeddelanden kan skickas från vårt e-postdomännamn och från exempel1.com och exempel2.com.
Det är ett mycket användbart register om vi till exempel har en Tidskrift online på adressen “exempel1.com“, men vi vill att budskapen från nätbutiken till kunderna ska gå ifrån företagets domänadress, denna varelse “exempel.com“. I SPF TXT för “exempel.com”, som vi behöver specificera tillsammans med IP och “include:example1.com”. Så att meddelanden kan skickas på uppdrag av organisationen.

Hur ställer jag in SPF för IPv4 och IPv6?

Vi har en mailserver med båda Ipv4 såväl som med Ipv6, är det mycket viktigt att båda IP-adresserna anges i SPF TXT.

v=spf1 ip4:196.255.100.26 ip6:2001:db8:8:4::2 ~all

Nästa, efter “ip” direktiv kan användas “include” för att lägga till domäner som är auktoriserade för frakt.

Vad betyder det “~all“, “-all” och “+all” ale SPF?

Som jag sa ovan kan Internetleverantörer fortfarande ta emot e-postmeddelanden på uppdrag av din organisation även om de skickas från en domän eller IP som inte är specificerad i SPF-policyn. Märka “alla” talar om för destinationsservrar hur de ska behandla dessa meddelanden från andra domäner som inte är auktoriserade och som skickar meddelanden på uppdrag av dig eller din organisation.

~all : Om meddelandet tas emot från en domän som inte är listad i SPF TXT, kommer meddelandena att accepteras på destinationsservern, men de kommer att markeras som spam eller misstänkta. De kommer att omfattas av god praxis mot skräppostfilter från den mottagande leverantören.

-all : Det är den strängaste taggen som läggs till i en SPF-post. Om domänen inte är listad kommer meddelandet att markeras som obehörigt och kommer att avvisas av leverantören. Det kommer inte ens att levereras till spam.

+all : Används mycket sällan och rekommenderas inte alls, den här taggen tillåter andra att skicka e-postmeddelanden på uppdrag av dig eller din organisation. De flesta leverantörer avvisar automatiskt alla e-postmeddelanden som kommer från domäner med SPF TXT “+all“. Just för att avsändarens äkthet inte kan verifieras, först efter en verifiering av “e-posthuvud”.

Sammanfattning: Vad är Sender Policy Framework (SPF)?

• Inaktivera & Clear DNS Cache – Windows 7, Vista & Xp
• Använd DNS -alternativa servrar för snabbare laddning av webbsidor
• Hur kan vi ändra DNS -adress i OS X
• Hur kan vi återställa DNS -cache i OS X
• Ökar surfningshastigheten på internet med Google Public DNS

Den auktoriserar, genom DNS TXT/SPF-zonen, IP:er och domännamn som kan skicka e-postmeddelanden från din eller ditt företags domän. Den tillämpar även de konsekvenser som gäller för meddelanden som skickas från obehöriga domäner.

Vad är DMARC och varför är det viktigt för e-postservern?

DMARC (Domänbaserad meddelandeautentiseringsrapportering och överensstämmelse) är nära relaterat till policystandarder SPF och Dkim.
DMARC är en valideringssystem utformad för att skydda ditt eller företagets e-postdomännamn, av metoder som e-postspoofing och nätfiskebedrägerier.

Genom att använda kontrollstandarderna SPF (Sender Policy Framework) och DKIM (Domain Keys Identified Mail) lägger DMARC till en mycket viktig funktion. rapporterar.

När en domänägare publicerar DMARC i DNS TXT-zonen kommer han att få information om vem som skickar e-postmeddelanden på hans vägnar eller på uppdrag av företaget som äger domänen skyddad med SPF och DKIM. Samtidigt kommer de mottagande leverantörerna av meddelandena att veta om och hur dessa policyer för bästa praxis övervakas av ägaren till den sändande domänen.

En DMARC-post i DNS TXT kan ha formen:

V=DMARC1; rua=mailto:[email protected]; ruf=mailto:[email protected]; p=none; sp=none; fo=0;

In DMARC se pot pot pune mai multe conditii de raportare a incidentelor cat si adresele de e-mail pe care sa ajunga analizele si rapoartele. Este indicat sa folositi adrese de e-mail dedicate pentru DMARC deoarece volumul de mesaje primite poate fi semnificativ.

Etichetele DMARC pot fi setate in functie de politica impusa de dvs. sau de organizatie:

v – versiunea protocolului DMARC existent.
p – aplica aceasta politica atunci cand nu se poate verificarea DMARC pentru mesajele e-mail. Poate avea valorea: “none“, “quarantine” eller “reject“. Se utilizeaza “none” pentru a obtine rapoarte despre fluxul mesajelor si starea acesora.
rua – Este o lista de URL-uri pe care ISP-urile pot trimite feedback in format XML. Daca adaugam aici adresa de e-mail, link-ul va fi de forma: “rua=mailto:[email protected]” .
ruf – Lista över webbadresser till vilka internetleverantörer kan skicka rapporter om cyberincidenter och brott som begåtts på uppdrag av din organisation. Adressen kommer att ha formen: “ruf=mailto:[email protected]“.
rf – Anmälningsformat för cyberbrott. Den kan formas “afrf” eller “iodef“.
pct – Ber internetleverantören/ISP att tillämpa DMARC-policyn endast på en viss procentandel av misslyckade meddelanden. Till exempel kan vi ha: “pct=50%” eller politik “quarantine” och “reject“. Det kommer aldrig att accepteras “none“.
adkim – Specificera “Justeringsläge” för DKIM digitala signaturer. Detta innebär att matchningen av den digitala signaturen för en DKIM-post med domänen kontrolleras. adkim kan ha värdena: r (Relaxed) eller s (Strict).
aspf – På samma sätt som i fallet adkim anges “Justeringsläge” för SPF och stöder samma värden. r (Relaxed) eller s (Strict).
sp – Denna policy gäller för att tillåta att underdomäner som härrör från organisationsdomänen använder domänens DMARC-värde. Detta undviker användningen av separata policyer för varje enskild domän. Det är i grunden en “jokertecken” för alla delfält.
ri – Detta värde anger intervallet för vilket XML-rapporter för DMARC kommer att tas emot. För det mesta är rapportering att föredra att göras dagligen.
fo – Alternativ för bedrägerirapportering. “Forensiska alternativ“. De kan ha värdena “0” att rapportera incidenter när både SPF- och DKIM-verifiering misslyckas, eller värdet “1” för scenariot där SPF eller DKIM inte existerar eller inte klarar kontrollen.

Så för att vara säker på att dina eller ditt företags e-postmeddelanden når mottagarna i Inkorgen är det nödvändigt att ta hänsyn till dessa tre standarder för “bästa praxis för att skicka e-postmeddelanden“. Dkim, SPF och DMARC. Alla dessa tre standarder tillhör DNS TXT och kan administreras från domänens DNS-hanterare.