Så skyddar ni domäner som inte skickar e-post

Varför förfalskas domäner som inte skickar e-post?

De flesta organisationer äger fler domäner än de använder för e-post: gamla varumärken, landsvarianter, felstavningar som registrerats mot typosquatting och domäner som köptes till en kampanj som är avslutad. Många av dem har en webbplats eller en omdirigering, men inga SPF-, DMARC- eller MX-poster alls.

För ett mottagande e-postsystem har en domän utan DMARC-post inte gett någon instruktion om förfalskad e-post. Den som skickar ett meddelande med domänen i From-adressen bedöms bara av mottagarens egna filter. En domän som liknar er och saknar policy är ett attraktivt verktyg för nätfiske, just eftersom ingen bevakar den.

Vilka poster behöver en domän som aldrig skickar e-post?

En domän som varken skickar eller tar emot e-post behöver tre poster. Tillsammans säger de att ingen server får skicka för domänen, att mottagare ska avvisa e-post som påstår sig komma från den och att den inte tar emot e-post.

example.net. TXT "v=spf1 -all"
_dmarc.example.net. TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com"
example.net. MX 0 .

v=spf1 -all anger inga avsändare och underkänner alla andra. -all är målet för varje SPF-post; ~all är bara en svag signal, och ?all eller +all ger mottagare ingenting att agera på. p=reject ber mottagare avvisa e-post som inte klarar DMARC, och sp=reject säger detsamma för underdomäner i stället för att låta dem ärva det. Här behöver ni inte gå stegvis från p=none, eftersom en domän som inte skickar något inte har någon legitim e-post att förlora.

Behåll full styrka i policyn. Ett pct-värde under 100, eller sp=none, släpper igenom en del av den förfalskade e-posten.

Vad gör en null MX-post, och varför inte bara utelämna MX?

En null MX-post (RFC 7505) är en MX-post med prioritet 0 och en ensam punkt som värd. Den anger att domänen inte tar emot e-post. Sändande servrar som ser den ger upp direkt och returnerar meddelandet till avsändaren, i stället för att lägga det i kö och försöka igen i flera dagar.

Att utelämna MX betyder inte samma sak. När en domän saknar MX-post säger e-poststandarden att avsändare ska försöka med domänens A- eller AAAA-adress i stället, så e-post kan hamna på webbservern eller vart adressen nu pekar. En null MX stänger den vägen och gör avsikten tydlig.

En null MX måste stå ensam. Publiceras den bredvid vanliga MX-poster säger posterna emot varandra, och avsändare löser konflikten på olika sätt, så vissa levererar och andra inte. Tar domänen emot e-post tar ni bort null MX; gör den det inte tar ni bort de andra MX-posterna.

Hur ska en domän som bara skickar e-post vara uppsatt?

En domän som bara skickar, till exempel för aviseringar eller nyhetsbrev, behöver samma starka DMARC-policy, men dess SPF-post och DKIM-nycklar anger de tjänster som faktiskt skickar för den. Om den ska ha null MX avgörs av en fråga: behöver någon e-post komma fram till domänen?

• Om ingenting ska komma fram publicerar ni null MX. Svar till From-adressen studsar då direkt, vilket är rätt resultat för en no-reply-adress.
• Om svar, studsar eller annan e-post måste nå en adress på domänen publicerar ni vanliga MX-poster som pekar på en e-posttjänst ni kontrollerar.
• Studsar går till Return-Path-adressen, inte till From-adressen. Många tjänster använder en egen studsdomän, eller en av era underdomäner med en egen MX-post, och den påverkas inte av en null MX på huvuddomänen.

notify.example.com. TXT "v=spf1 include:mail-provider.example -all"
_dmarc.notify.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"
notify.example.com. MX 0 .

Till skillnad från en parkerad domän har en domän som bara skickar legitim e-post, så bekräfta i rapporterna att varje tjänst som skickar godkänns med alignment innan ni går till p=reject.

Behöver en domän som inte skickar e-post DKIM?

Nej. DKIM-nycklar finns för att en avsändare ska kunna signera sin e-post, och en domän som inte skickar något har inget att signera. SPF- och DMARC-posterna räcker: utan giltig signatur och utan godkänt SPF underkänns varje meddelande i DMARC och reject-policyn tillämpas.

Om domänen tidigare skickade e-post, leta efter gamla DKIM-poster som ligger kvar, till exempel under selektorerna för en tjänst ni inte längre använder. En giltig gammal nyckel innebär att den som fortfarande har den privata nyckeln kan signera e-post som godkänns. Ta bort posten, eller publicera den med en tom p=-tagg, som markerar nyckeln som återkallad så att signaturer gjorda med den inte längre verifieras.

old-selector._domainkey.example.net. TXT "v=DKIM1; p="

Hur skyddar vi underdomänerna till en parkerad domän?

När en mottagare inte hittar någon DMARC-post för en underdomän använder den posten för organisationsdomänen och tillämpar dess sp=-policy. Därför täcker sp=reject på den parkerade domänen e-post från namn som billing.example.net, oavsett om namnet finns i DNS eller inte. Ange den uttryckligen i stället för att förlita er på arvet från p=, så att avsikten är tydlig för den som läser posten senare.

Den uppdaterade DMARC-specifikationen (DMARCbis) lägger till taggen np= för underdomäner som inte finns alls. Den spelar bara roll när den ska skilja sig från sp=. Med sp=reject är underdomäner som inte finns redan täckta, så en parkerad domän behöver inte np=.

SPF och MX ärvs inte på samma sätt; varje namn har sina egna poster. Vissa publicerar även wildcard-poster för SPF och null MX för underdomänerna. En wildcard-post svarar bara för namn som saknar egna poster, så den kompletterar DMARC-policyn men ersätter den inte.

Ska en parkerad domän ta emot DMARC-rapporter?

Ja. Behåll en rua-adress i posten. För en domän som inte skickar något är de aggregerade rapporterna enkla att läsa: varje meddelande i dem är antingen förfalskat eller kommer från en bortglömd legitim avsändare. En plötslig mängd underkänd e-post visar att någon använder domänen i en kampanj, och en källa som godkänns visar att något fortfarande har behörighet att skicka.

Skicka rapporterna till en brevlåda på en domän som tar emot e-post, inte till den parkerade domänen själv, som har null MX. När rapportadressen ligger på en annan domän måste den domänen publicera en behörighetspost, annars skickar mottagare inte rapporterna dit.

example.net._report._dmarc.example.com. TXT "v=DMARC1;"

Parkerade domäner och skyddsregistreringar kan övervakas i DMARC Vision tillsammans med de domäner ni skickar från. Sajtens kostnadsfria kontroll av DMARC-poster granskar en post innan ni publicerar den.

Vilka är de vanligaste misstagen?

• Att ta bort alla DNS-poster när en domän avvecklas. Utan DMARC-post säger ingenting åt mottagare att stoppa förfalskad e-post, och utan MX-post faller avsändare tillbaka på domänens adress.
• Att lämna kvar en gammal SPF-include för en tjänst som inte längre används. Den som kan skicka via tjänsten, kanske även dess andra kunder, kan då klara SPF för domänen.
• En MX-post som pekar på en avvecklad server. E-post köas och studsar långsamt, och om värdnamnet eller IP-adressen senare återanvänds av någon annan kan de ta emot e-post till domänen.
• Att publicera null MX bredvid vanliga MX-poster, vilket säger emot den.
• Att lägga rua-adressen på den parkerade domänen själv, där null MX gör att inga rapporter kan komma fram.
• Att stanna vid p=none, ~all eller ett pct under 100 på en domän som inte har någon legitim e-post att skydda.
• Att glömma att en registrars parkeringstjänst kan publicera egna MX- eller SPF-poster. Kontrollera vad DNS faktiskt svarar, inte bara er egen zonfil.