Falske mails i jeres navn: sådan stopper I spoofing og phishing

Når en kunde ringer og spørger, om den mail med en faktura eller et "vundet gavekort" virkelig er fra jer, er det første spørgsmål: hvilken afsender stod der præcis? Svaret afgør, hvad I kan gøre ved det.

Den første er den, I selv kan lukke helt. Uden DMARC kan hvem som helst sende mails, der står som afsendt fra jeres domæne, og mange modtagere lader dem komme igennem. Den sidste er den farligste, fordi mailen består alle tekniske tjek. Ser det ud til, at en konto er overtaget, så læs hacket Microsoft 365 eller hacket Google Workspace først.

Spoofing er muligt, fordi en mail har to afsendere, og SMTP blev lavet uden kontrol af nogen af dem:

Svindlere sætter jeres adresse i From, deres egen i MAIL FROM og en adresse, de kontrollerer, i Reply-To.

Sikker Digital, myndighedernes vejledning til virksomheder, anbefaler at tjekke afsenderadressen nøje for små forskelle, fx en understregning i stedet for en bindestreg, og at ringe til afsenderen på et nummer, I kender, når en mail beder om betaling eller ændring af kontonummer.

De tre standarder er små tekstposter i jeres DNS, som modtagerens mailserver slår op, når den får en mail med jeres domæne som afsender. Hver af dem svarer på sit eget spørgsmål:

Det vigtige ord i DMARC er alignment, altså at domænet i den synlige afsenderadresse skal passe med det domæne, SPF (MAIL FROM) eller DKIM (signaturens d=) har godkendt. En svindler kan godt få SPF til at bestå for sit eget domæne, men ikke for jeres. Det er DMARC, der binder det sammen med den afsender, kunden ser.

En mail består DMARC, hvis mindst én af de to giver et godkendt og afstemt resultat. Alignment kan være afslappet (relaxed, standard) eller streng (strict):

Den sidste række er den klassiske fejl: nyhedsbrevssystemet bruger sit eget domæne i både MAIL FROM og signatur. SPF og DKIM består, men DMARC fejler.

Videresendelse er den anden. Den videresendende server sender fra sin egen IP-adresse, som ikke står i jeres SPF-post, så SPF fejler. DKIM overlever, fordi signaturen følger indholdet, medmindre en mailingliste ændrer emne eller tilføjer en fodnote. Derfor skal DKIM være på plads for alle afsendere: det er den del, der holder, når SPF ikke gør.

SPF eller DKIM alene stopper ikke spoofing. Det er først med DMARC på quarantine eller reject, at modtageren får besked på at lægge falske mails i spam eller afvise dem.

De store mailudbydere kræver det nu også af legitime afsendere. Google har siden 1. februar 2024 krævet SPF eller DKIM af alle, der sender til Gmail, og SPF, DKIM og DMARC af dem, der sender over 5.000 mails om dagen. Microsoft stiller siden 5. maj 2025 tilsvarende krav til afsendere, der sender 5.000 mails eller flere til Outlook.com, Hotmail og Microsofts andre forbrugertjenester: SPF og DKIM skal begge bestå, og der skal være en DMARC-post med mindst p=none. Sender I nyhedsbreve, er det altså også et spørgsmål om levering.

Det er headeren, der fortæller, hvad der er sket. En videresendt mail mister de oprindelige headers, så bed kunden om den fulde header. I Gmail er det Mere og Vis original (Show original). Messageheader i Google Admin Toolbox og Microsofts Message Header Analyzer gør den læsbar.

En spoofet mail ser typisk sådan ud. Domænerne er eksempler:

Return-Path: <bounce-7731@mailer.svindel.example>
Received-SPF: pass (mx.eksempel.dk: domain of bounce-7731@mailer.svindel.example designates 203.0.113.25 as permitted sender) client-ip=203.0.113.25; envelope-from="bounce-7731@mailer.svindel.example"; helo=mailer.svindel.example;
Authentication-Results: mx.eksempel.dk;
  spf=pass smtp.mailfrom=mailer.svindel.example;
  dkim=none;
  dmarc=fail header.from=webshop.dk
From: "Webshop.dk Kundeservice" <ordre@webshop.dk>
Reply-To: <support@webshop-dk.example>
Subject: Din ordre er sat på pause

Sådan læses felterne:

Hos Microsoft 365 indeholder linjen flere oplysninger. Microsoft dokumenterer formatet sådan her, hvor action=oreject betyder, at afsenderdomænet har p=reject, og compauth er Microsofts samlede vurdering:

Authentication-Results: spf=pass (sender IP is 198.51.100.10)
  smtp.mailfrom=bounces.adatum.com; dkim=pass (signature was verified)
  header.d=adatum.com; dmarc=fail action=oreject
  header.from=contoso.com;compauth=fail reason=000

Stol kun på den Authentication-Results-linje, jeres egen server har sat ind. Feltet er almindelig tekst, som en svindler kan forfalske. Standarden (RFC 8601) kræver, at den modtagende server fjerner felter, der udgiver sig for at komme fra den selv. Første del af linjen, fx mx.eksempel.dk, viser, hvilken server der har lavet tjekket.

Start med at finde ud af, hvem der sender mail i jeres navn. Det er næsten altid flere end man tror:

• jeres mailsystem, fx Microsoft 365 eller Google Workspace
• webshoppen, der sender ordrebekræftelser
• nyhedsbrevssystemet
• bogføringsprogrammet, der sender fakturaer
• kundeservice- eller bookingsystemet

Se først, hvad der ligger i DNS i dag. dig +short viser kun selve svaret, og på Windows giver Resolve-DnsName det samme:

dig +short TXT webshop.dk                         # SPF
dig +short TXT _dmarc.webshop.dk                  # DMARC
dig +short CNAME selector1._domainkey.webshop.dk  # DKIM, Microsoft 365
dig +short TXT google._domainkey.webshop.dk       # DKIM, Google Workspace

1. SPF. Der må kun være én SPF-post pr. domæne. Har I to, giver SPF fejlen permerror. Microsoft anbefaler fx v=spf1 include:spf.protection.outlook.com -all for et domæne, der kun bruger Microsoft 365, og Google anbefaler v=spf1 include:_spf.google.com ~all for Google Workspace. Hver ekstra tjeneste tilføjer en include:. Posten læses fra venstre mod højre, og hver del betyder:

Hold øje med grænsen på 10 DNS-opslag. Den er fastsat i SPF-standarden (RFC 7208), og går I over, giver SPF permerror for alle mails. Tæl de indlejrede opslag med: en include: der selv indeholder tre include:, koster fire. Microsoft anbefaler -all frem for ~all, når DKIM og DMARC er sat op, fordi Microsoft i praksis ser bort fra DMARC-politikken ved en blød SPF-fejl, hvis mailen heller ikke er signeret.

2. DKIM. Nøglen laves i mailsystemet og lægges i DNS:

• Microsoft 365: I Defender-portalen under Email & collaboration > Policies & rules > Threat policies > Email authentication settings, fanen DKIM. Microsoft giver to CNAME-poster, selector1._domainkey og selector2._domainkey, som skal oprettes, før signering kan slås til. To nøgler gør det muligt at skifte nøgle uden afbrydelse.
• Google Workspace: I Admin-konsollen under Apps > Google Workspace > Gmail > Authenticate email. Vælg domænet, klik Generate New Record, læg posten i DNS, og klik derefter på Start authentication. Google bruger selektoren google som standard og anbefaler 2048-bit nøgler.
• Nyhedsbrev, webshop og fakturering: Hver tjeneste har sin egen vejledning til DKIM på jeres domæne. Slå det til alle steder, ellers fejler deres mails, når DMARC strammes.

I Microsoft 365 kan det samme gøres i Exchange Online PowerShell. Get-DkimSigningConfig viser de præcise CNAME-værdier, der skal i DNS, og Set-DkimSigningConfig slår signering til, når posterne er oprettet:

Connect-ExchangeOnline -UserPrincipalName admin@webshop.dk

# Status og de CNAME-værdier, der skal oprettes i DNS
Get-DkimSigningConfig -Identity webshop.dk | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

# Slå signering til, når de to CNAME-poster er oprettet
Set-DkimSigningConfig -Identity webshop.dk -Enabled $true

Mange DNS-udbydere tilføjer selv domænet, så skriv kun selector1._domainkey som værtsnavn. Ellers bliver status ved med at være CnameMissing, advarer Microsoft.

I headeren står signaturen som DKIM-Signature med bl.a. d= (domænet, der skal passe med From), s= (selektoren), h= (signerede headers), bh= (hash af teksten) og b= (selve signaturen). Nøglen slås op på s._domainkey.d, fx selector1._domainkey.webshop.dk.

3. DMARC. Opret en TXT-post på _dmarc.jeresdomæne.dk. Google anbefaler at vente mindst 48 timer efter SPF og DKIM og starte sådan her:

v=DMARC1; p=none; rua=mailto:dmarc@jeresdomæne.dk

Adressen i rua får dagligt rapporter fra modtagerne om, hvilke servere der sender mail i jeres navn, og om de består. Posten kan indeholde flere felter. De gælder efter den nye DMARC-standard, RFC 9989:

Mange modtagere sender ikke fejlrapporter (ruf), Microsoft 365 slet ikke, så start med rua. Ligger rapportadressen på et andet domæne, skal det domæne udgive v=DMARC1 som TXT på webshop.dk._report._dmarc.rapportdomæne, ellers sendes rapporterne ikke.

Har I domæner, som slet ikke sender mail, så luk dem helt med v=spf1 -all og en DMARC-post med p=reject. Ellers er de oplagte at spoofe.

p=none beskytter ikke mod noget. Den beder kun om rapporter. Det er et nødvendigt første trin, men mange virksomheder bliver stående der i årevis. Planen bør se sådan ud:

Google anbefaler at følge rapporterne dagligt i overvågningsfasen og først gå videre, når der har været mindst en uge uden problemer. Gå ikke videre, før alle de tjenester, I fandt i trin 1, består DMARC. Ellers er det jeres egne ordrebekræftelser og fakturaer, der ender i spam. Microsoft anbefaler at starte med et underdomæne med lav volumen og tage hoveddomænet til sidst.

Tidligere brugte man tagget pct til at stramme gradvist, fx pct=5 for kun at ramme fem procent af mailene, og Google og Microsoft viser det stadig. I maj 2026 udkom den nye DMARC-standard, RFC 9989, og her er pct fjernet, fordi modtagerne brugte den meget forskelligt. I stedet er der et testflag, t=y, som beder modtageren om ikke at anvende politikken endnu, mens rapporterne fortsætter. Gamle poster med pct er ikke forkerte, men det er ikke en pålidelig måde at trappe op på.

Sådan ser posten ud før og efter:

; Fase 1: kun rapporter
_dmarc.webshop.dk.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@webshop.dk"

; Fase 3: afvisning, og underdomæner, der ikke findes, afvises også
_dmarc.webshop.dk.  3600  IN  TXT  "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@webshop.dk"

np=reject lukker for opfundne underdomæner som faktura.webshop.dk. Modtagere, der kun kender den gamle standard, ignorerer ukendte tags og bruger sp og p.

Reject er målet. Det er først her, svindlere ikke længere kan bruge jeres præcise domæne. Google nævner selv, at afviste mails aldrig leveres, så sørg for, at rapporterne er rene, før I tager skridtet.

De samlede rapporter kommer typisk én gang i døgnet fra hver modtager som en komprimeret XML-fil. En forkortet rapport ser sådan ud:

<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
  <report_metadata>
    <org_name>modtager.example</org_name>
    <report_id>2026-10-20-webshop.dk</report_id>
    <date_range><begin>1792454400</begin><end>1792540800</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>webshop.dk</domain>
    <p>none</p>
    <adkim>r</adkim>
    <aspf>r</aspf>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.40</source_ip>
      <count>1840</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>webshop.dk</header_from>
      <envelope_from>bounce.nyhedsbrevstjeneste.example</envelope_from>
    </identifiers>
    <auth_results>
      <dkim><domain>nyhedsbrevstjeneste.example</domain><selector>s1</selector><result>pass</result></dkim>
      <spf><domain>bounce.nyhedsbrevstjeneste.example</domain><result>pass</result></spf>
    </auth_results>
  </record>
</feedback>

Hver record dækker én afsender-IP. De vigtigste felter er:

Det vigtigste mønster er forskellen mellem auth_results og policy_evaluated. I eksemplet består både SPF og DKIM, men kun for nyhedsbrevstjenestens domæne. Under policy_evaluated står der derfor fail begge steder. Det er en legitim afsender, der mangler DKIM på jeres domæne, og den skal rettes, før I går til quarantine. En ukendt IP-adresse med stor volumen, hvor alt fejler, er derimod præcis det, DMARC skal stoppe.

En hurtig oversigt over afsender-IP'er og antal mails i en enkelt rapport kan laves i terminalen, før I vælger en rapporteringstjeneste:

gunzip -c rapport.xml.gz | grep -oE "<(source_ip|count)>[^<]+" | sed "s/<[a-z_]*>//" | paste - - | sort -k2 -rn

BIMI (Brand Indicators for Message Identification) er en DNS-post, der får jeres logo vist ved siden af mails fra jer i understøttede indbakker. Det beskytter ikke i sig selv, men det giver kunderne et visuelt tegn på, at mailen er ægte.

Kravene ifølge BIMI Group og Google:

• DMARC skal være håndhævet, altså p=quarantine eller p=reject, også for underdomæner. p=none er ikke nok, og Google kræver, at politikken gælder 100 procent af mailene.
• Logoet skal være en SVG i formatet SVG Tiny PS, kvadratisk og uden scripts eller eksterne filer. Gmail kræver mindst 96 gange 96 pixels.
• Gmail kræver et certifikat, enten et Verified Mark Certificate (VMC), der bygger på et registreret varemærke, eller et Common Mark Certificate (CMC) til logoer uden varemærke. Gmail viser et flueben ved afsendere med VMC. Apple kræver også et certifikat, og det skal fornyes mindst en gang om året.
• Yahoo kan vise logoet uden certifikat for afsendere med store mængder mail og et godt omdømme.

Selve posten ligger på default._bimi og peger på logoet og certifikatet:

default._bimi.webshop.dk.  3600  IN  TXT  "v=BIMI1; l=https://www.webshop.dk/bimi/logo.svg; a=https://www.webshop.dk/bimi/certifikat.pem"

MTA-STS løser et andet problem. Mailservere krypterer med STARTTLS, men kun hvis begge tilbyder det, og en angriber på netværket kan fjerne tilbuddet. MTA-STS (RFC 8461) siger, at mail til jeres domæne kun må leveres krypteret og kun til de servere, I angiver. Det består af en TXT-post og en fil på en fast HTTPS-adresse:

_mta-sts.webshop.dk.  3600  IN  TXT  "v=STSv1; id=20261021T120000"
_smtp._tls.webshop.dk.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-rapporter@webshop.dk"

# https://mta-sts.webshop.dk/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: mail.webshop.dk
max_age: 604800

mode: testing leverer, selv om tjekket fejler, mens enforce afviser. max_age er i sekunder, og id skal ændres, når filen ændres. Den anden post slår TLS-RPT (RFC 8460) til, som sender daglige JSON-rapporter om fejlede forbindelser. Start med testing, og skift til enforce, når rapporterne er rene.

BIMI er sjældent det første, der skal på plads, men kan være værd at se på for webshops med varemærke og mange nyhedsbreve. MTA-STS er gratis, men kræver et gyldigt certifikat på mta-sts-adressen.

DMARC stopper kun mails fra jeres eget domæne. Svindlere omgår det ved at registrere et domæne, der ligner, og ofte bygger de også en kopi af webshoppen med jeres logo, billeder og produkter. Typiske varianter er:

• en anden endelse, fx .com, .shop eller .store i stedet for .dk
• ord tilføjet, fx "-shop", "-outlet", "-dk" eller "-tilbud"
• et bogstav byttet, fjernet eller fordoblet
• æ, ø og å skrevet om, så det næsten ligner

Find dem. Søg jævnligt efter jeres firmanavn og vigtigste varemærker i Google, og hold øje med henvendelser fra kunder om "jeres anden shop". Der findes også værktøjer, som overvåger nye domæneregistreringer, der ligner jeres.

Få dem lukket. Find ud af, hvor domænet er registreret og hostet. Sikker Digital anbefaler at slå op i WHOIS, og for .dk-domæner kan det gøres hos Punktum dk. For andre endelser bruger I ICANN Lookup, som viser registraren og ofte en adresse til misbrug. dig +short NS og dig +short A viser, hvilken DNS- og hostingudbyder der skal have en anmeldelse. Send så en dokumenteret anmeldelse til både registraren og hostingudbyderen med:

• domænet og de konkrete webadresser
• skærmbilleder med dato
• de falske mails med fuld header
• en kort forklaring af, hvordan siden udgiver sig for at være jer

Er det et .dk-domæne, kan I anmelde misbrug direkte til Punktum dk via deres kontaktformular. Punktum dk vurderer, om der er rimelig mistanke om DNS-misbrug som phishing eller malware, og kan derefter undersøge registrantens oplysninger. Kan de ikke bekræftes, bliver domænet suspenderet og slettet efter 30 dage. Punktum dk kan også suspendere et domæne efter en klage, hvis det giver en åbenlys risiko for økonomisk kriminalitet eller phishing, kan forveksles med jeres navn eller varemærke, og sagen ikke kan vente på Domæneklagenævnet eller domstolene.

Anmeld også siden til Google Safe Browsing, så Chrome og andre browsere advarer, før kunderne når at taste noget ind. Er det jeres eget domæne, der er blevet overtaget eller ændret i DNS, er det en anden sag, og så skal I se på hacket domæne og DNS.

Der er flere steder at anmelde, og de har hver deres rolle:

Politiets side Anmeld økonomisk svindel på nettet og digital kriminalitet har en særlig indgang for virksomheder og foreninger, der bl.a. dækker mail-, sms- og telefonsvindel. Ifølge Sikker Digital kan I på 114 på hverdage mellem kl. 7 og 20 blive stillet videre til medarbejdere med særlig viden om cyberangreb. Politiet efterforsker ikke altid den enkelte sag, men anmeldelserne bruges i deres efterretningsarbejde. Vedlæg den fulde header, for det er IP-adresserne i den, der kan spores.

Har I brug for at tale med nogen om, hvad I skal gøre, kan I ringe til Cyberhotline på 33 37 00 37. Den har åbent 8 til 20 på hverdage og 10 til 16 i weekender og på helligdage.

Er der allerede overført penge, så ring til banken med det samme. Det gælder både, hvis det er jer, og hvis det er en kunde, der har betalt til svindlerne.

Kunderne skal høre det fra jer, før de hører det fra hinanden. Sikker Digital anbefaler at advare på hjemmesiden, på sociale medier og i nyhedsbrevet med konkrete eksempler på de falske mails, at være let at komme i kontakt med og at give det samme svar i alle kanaler.

Et forslag til en kort tekst:

Vi er blevet opmærksomme på falske mails, der ser ud til at komme fra os. De har emnet "Din ordre er sat på pause" og et link til at betale igen. Mailene er ikke fra os. Vi beder aldrig om kortoplysninger eller betaling via et link i en mail. Ægte mails fra os kommer altid fra @jeresdomæne.dk. Har du klikket på linket eller indtastet oplysninger, så kontakt din bank, og skift adgangskode, hvis du har brugt den samme andre steder. Skriv til os på kundeservice@jeresdomæne.dk, hvis du er i tvivl.

Hold teksten faktuel og uden skyld. Sikker Digital anbefaler at skrive, at kunden har været udsat for svindel, ikke at de er "hoppet i fælden". Henvis også gerne til Cyberhotline, hvis kunderne har brug for hjælp til deres egen sikkerhed.

Opdater teksten, hvis svindlerne skifter emne eller afsender. Sender I aldrig betalingslinks, så skriv det et fast sted på sitet, fx i bunden af ordrebekræftelsen.

En webshop er et oplagt mål, fordi kunderne er vant til at få mails om ordrer, levering og betaling. En falsk "betaling fejlede" eller "pakken venter på told" ligner det, de plejer at få.

Det betyder konkret:

• Ordre- og forsendelsesmails skal bestå DMARC. Ellers ender de i spam, når I strammer politikken, og så kan kunderne ikke længere kende forskel på ægte og falsk.
• Nyhedsbreve kræver det i forvejen. Med over 5.000 mails om dagen stiller både Google og Microsoft krav om SPF, DKIM og DMARC. Microsoft anbefaler et underdomæne til den slags, fx nyhed.webshop.dk.
• Webshoppens egen mail skal med. Sender shoppen direkte fra webserveren, skal serverens IP i SPF, eller mailen skal gå gennem en tjeneste med DKIM på jeres domæne.
• Kundeservice får flere henvendelser. Giv dem en fast tekst og en intern procedure, så alle svarer det samme.
• Falske shops koster salg og anmeldelser. Kunder, der har betalt i en falsk shop, skriver ofte deres klage om jer.

Lav en kort procedure, før det sker: hvem holder øje med DMARC-rapporterne, hvem anmelder, hvem skriver til kunderne, og hvor ligger den faste tekst. Vi hjælper med opsætningen under mail- og DNS-sikkerhed.

De fejl, vi oftest ser:

• To SPF-poster på samme domæne. Så fejler SPF for alle mails.
• Over 10 DNS-opslag i SPF. Hver ny tjeneste med include: koster mindst ét opslag, og ved 11 fejler alt.
• At blive stående på p=none. Det giver rapporter, men ingen beskyttelse.
• At gå direkte til reject. Så forsvinder fakturaer og ordrebekræftelser fra tjenester, I havde glemt.
• At glemme DKIM i nyhedsbrevs- og bogføringssystemet. De sender i jeres navn og skal også bestå, og SPF alene fejler ved videresendelse.
• At ingen læser rapporterne. En rua-adresse, som ingen åbner, er ikke overvågning.
• At glemme de domæner, der ikke sender mail. Uden SPF og DMARC er de lette at spoofe.
• At svare kunderne forskelligt. Det skaber mere usikkerhed end selve svindlen.

Tjekliste:

1. Lav en liste over alle systemer, der sender mail i jeres navn.
2. Saml SPF i én post under 10 DNS-opslag, og afslut med -all.
3. Slå DKIM til i mailsystemet og i alle tjenester med jeres eget domæne i d=.
4. Opret DMARC med p=none og en rua-adresse.
5. Gennemgå rapporterne, til alle legitime afsendere består med alignment.
6. Skift til p=quarantine, og derefter til p=reject med sp og np.
7. Luk domæner, der ikke sender mail, med v=spf1 -all og p=reject.
8. Overvåg look-alike domæner og falske shops.
9. Hav en fast tekst klar til kunderne og en anmeldelsesprocedure.
10. Overvej MTA-STS og TLS-RPT, og BIMI, når DMARC er håndhævet.

Kan vi stoppe falske mails helt? Fra jeres eget domæne, ja, med DMARC på reject hos de modtagere, der følger standarden, og det gør de store udbydere. Mails fra domæner, der ligner jeres, kan I ikke stoppe teknisk, men I kan få domænerne lukket.

Hvor lang tid tager det at nå reject? Det afhænger af, hvor mange systemer der sender i jeres navn. Google anbefaler mindst en uges overvågning, før man strammer. For en webshop med flere tjenester tager det typisk længere, fordi hver tjeneste skal sættes op og bekræftes i rapporterne.

Skal vi anmelde falske mails til politiet? Det er ikke et krav, men politiet anbefaler, at virksomheder anmelder. Brug politi.dk eller 114, og vedlæg mails med fuld header og skærmbilleder.

Kan Punktum dk lukke en falsk .dk-shop? Ja, hvis der er tale om phishing eller anden DNS-misbrug, og registrantens oplysninger ikke kan bekræftes, eller hvis kriterierne for suspendering efter en klage er opfyldt.

Er det et databrud, når nogen spoofer os? Nej, ikke i sig selv, fordi jeres egne data ikke er berørt. Det bliver det først, hvis en mailkonto er overtaget, eller hvis kundedata er lækket.

Hvad koster det? SPF, DKIM, DMARC og MTA-STS er gratis DNS-poster. Det, der tager tid, er at finde alle afsendere og læse rapporterne. BIMI kræver et betalt certifikat hos Gmail og Apple.

Vil I have hjælp til at komme fra p=none til reject uden at miste mails, eller til at få en falsk shop lukket, så skriv til os.

Kilder

• Google: Retningslinjer for afsendere
• Google: Anbefalet udrulning af DMARC
• Google: Konfigurer SPF
• Google: Konfigurer DKIM
• Google: Konfigurer BIMI
• Gmail: Se den fulde header
• Microsoft: SPF i Microsoft 365
• Microsoft: DKIM i Microsoft 365
• Microsoft: DMARC i Microsoft 365
• Microsoft: Anti-spam message headers
• Microsoft: Connect to Exchange Online PowerShell
• Microsoft: Krav til afsendere med høj volumen
• Microsoft Postmaster: Policies
• RFC 7208: SPF
• RFC 6376: DKIM
• RFC 9989: DMARC
• RFC 9990: DMARC-rapporter
• RFC 8601: Authentication-Results
• RFC 8461: MTA-STS
• RFC 8460: TLS-RPT
• BIMI Group
• BIMI Group: Implementation guide
• Punktum dk: Klage over indhold på hjemmesider
• Punktum dk: Suspendering af domæner
• Politiet: Anmeld økonomisk svindel på nettet
• Sikker Digital: Brandmisbrug
• Sikker Digital: Cyberhotline