Så går ni från p=none till p=reject utan risk

Varför räcker inte p=none?

Med p=none levererar mottagare e-post som inte klarar DMARC som om posten inte fanns. Den som skickar e-post med er domän i From-adressen når fortfarande inkorgen, om inte mottagarens egna filter stoppar den.

p=none är rätt startpunkt, eftersom ni då kan se vem som skickar e-post i er domäns namn utan risk. Det är däremot inte ett läge att stanna i. Många organisationer publicerar p=none för att uppfylla kraven från Google, Yahoo och Microsoft och går sedan aldrig vidare, vilket lämnar domänen öppen för förfalskning.

Hur hittar vi alla legitima avsändare för vår domän?

Börja med de aggregerade rapporterna (rua). Samla in minst några veckors rapporter innan ni ändrar något. Gruppera avsändarna efter IP-adress och efter domänerna för DKIM och SPF, och markera var och en som er egen, en tjänst ni använder eller okänd.

• Er egen e-postplattform, till exempel Microsoft 365 eller Google Workspace.
• Plattformar för marknadsföring och nyhetsbrev.
• CRM- och säljverktyg som skickar för personalens räkning.
• Ärendehanterings- och kundtjänstsystem.
• System för fakturering, lön och ekonomi.
• Webbformulär, bokningssystem, skrivare och skannrar samt egna servrar.

Fråga varje avdelning vilka tjänster som skickar e-post åt dem. Rapporterna visar bara avsändare som har skickat e-post under perioden, så en tjänst som skickar en gång i månaden eller en gång per kvartal kan missas.

Hur rättar vi alignment för SPF och DKIM hos tredjepartsavsändare?

Varje legitim avsändare måste klara SPF eller DKIM med en domän som är i linje med er From-domän. DKIM är det bättre valet, eftersom det klarar vidarebefordring och inte påverkas av SPF:s gräns på tio DNS-uppslag.

1. Leta i tjänstens inställningar efter autentisering med egen domän eller DKIM för er domän. Publicera de DKIM-nycklar eller CNAME-poster som tjänsten anger.
2. Om tjänsten stöder en egen Return-Path- eller bounce-domän på en av era underdomäner, ställ in den så att även SPF är i linje.
3. Lägg bara till tjänsten i er SPF-post om SPF-alignment behövs, och kontrollera att posten håller sig inom tio uppslag.
4. Följ de kommande rapporterna och bekräfta att tjänsten nu visar godkända resultat i linje.

Om en tjänst inte kan signera med er domän kan ni låta den skicka från en egen underdomän, eller byta tjänst. E-post från den kommer att underkännas när ni når p=reject.

Vad gör p=quarantine med pct?

När rapporterna visar att all legitim e-post godkänns går ni vidare till p=quarantine. Med taggen pct= kan ni tillämpa policyn på en andel av den e-post som underkänns. Med pct=25 tillämpar mottagare quarantine på ungefär en fjärdedel av de underkända meddelandena och behandlar resten som p=none.

pct har brett stöd i dag, men den uppdaterade DMARC-specifikationen (DMARCbis) tar bort den. Den ersätts av en testflagga, t=, där t=y betyder att policyn är publicerad men inte ska tillämpas fullt ut. Mottagare kommer att gå över till den nya taggen med tiden, så se pct som ett användbart steg i dag och inte som något att förlita sig på.

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@example.com
v=DMARC1; p=reject; pct=25; rua=mailto:dmarc-reports@example.com
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

När pct är lägre än 100 med p=reject sätts meddelandena utanför andelen i karantän i stället. Att utelämna pct är detsamma som pct=100.

Hur länge ska vi vänta mellan stegen?

Det finns ingen fast regel. Det är en bedömning utifrån vad rapporterna visar. Det är vanligt att vänta några veckor vid varje steg och bara gå vidare när rapporterna har varit rena under den tiden.

Se till att varje period omfattar minst en hel månadscykel. Lön, fakturering och månadsbokslut skickar ofta bara en gång i månaden, och det är de avsändarna som oftast missas. Om ni hittar en ny legitim avsändare rättar ni den och ger den tid att visa rena resultat före nästa steg.

Hur skyddar vi underdomäner och parkerade domäner?

Underdomäner ärver huvudpolicyn om ni inte anger sp=. Ni kan använda sp=reject tidigt för underdomäner som inte skickar e-post, medan huvuddomänen fortfarande har p=none eller p=quarantine. Om en underdomän skickar e-post ger ni den en egen DMARC-post eller tar med den i inventeringen.

Domäner som aldrig skickar e-post bör låsas direkt. Publicera alla tre posterna på varje parkerad domän:

_dmarc.parked-example.com. TXT "v=DMARC1; p=reject;"
parked-example.com. TXT "v=spf1 -all"
parked-example.com. MX 0 .

SPF-posten säger att ingen server får skicka för domänen. Null MX-posten (RFC 7505) säger att domänen inte tar emot e-post. Lägger ni till en rua=-adress i den parkerade domänens DMARC-post kan ni se om någon försöker använda den.

Vad ska vi övervaka när vi har nått p=reject?

• Nya avsändare i de aggregerade rapporterna, särskilt tjänster som börjar underkännas.
• Förändringar i DKIM-resultaten efter nyckelbyte eller byte av e-postplattform.
• SPF-poster som växer förbi tio DNS-uppslag när tjänster läggs till.
• Signaler från personal eller kunder om e-post som inte kommer fram.
• Nya tjänster som andra avdelningar köper in, och som bör gå igenom samma kontroll av alignment innan de börjar skicka.

Behåll rua-adressen i posten. Rapporterna är lika användbara med p=reject, eftersom de visar både förfalskningsförsök och legitim e-post som har börjat underkännas. DMARC Vision samlar in och förklarar rapporterna, och sajtens kostnadsfria kontroll av DMARC-poster och e-postsäkerhetskontroll hjälper er att kontrollera er konfiguration.

Hur backar vi om legitim e-post underkänns?

Om en legitim avsändare börjar underkännas backar ni ett steg i stället för att ta bort posten. Gå från p=reject till p=quarantine, eller sänk pct, medan ni rättar avsändaren. Ta inte bort DMARC-posten, eftersom ni då förlorar både skyddet och rapporterna.

DNS-ändringar slår igenom när cachar löper ut, så håll TTL för _dmarc-posten kort medan ni gör ändringar. När avsändaren godkänns igen går ni tillbaka till den tidigare policyn.