Denne artikel forklarer, hvad DMARC-fejlen 550 5.7.509 Access denied betyder, hvorfor den opstår i forbindelse med tunnelmail via DPG Sikker Post og hvad du kan gøre for at afhjælpe den.
Kort forklaring
Når en mail sendes via DPG Sikker Post, pakkes den ind i en S/MIME-konvolut.
DKIM-signaturen placeres på denne ydre skal.
Når konvolutten dekrypteres hos modtageren, forsvinder DKIM-signaturen med den, da den er vedhæftet på S/MIME konvolutten.
Modtagerens mailmiljø kan herefter opleve at mailen fejler DMARC-validering fordi DKIM-signaturen ikke længere er til stede. Sikkerpostleverandører håndterer DKIM forskelligt, og modtagerens mailmiljø kan herefter opleve at mailen fejler DMARC-validering fordi DKIM-signaturen ikke længere er til stede.
Hvornår er denne artikel relevant for dig?
Brug denne artikel, hvis:
Du modtager en fejlbesked som denne:
Remote server returned '550 5.7.509 Access denied, sending domain [domænenavn] does not pass DMARC verification and has a DMARC policy of reject.'
Mailen kan ses i DPG Kundeportalen under Mail Flow, men alligevel ikke er nået frem til modtager.
Fejlen opstår, når mailen sendes med DPG Sikker Post, men ikke når Sikker Post er slået fra.
Hvad er DMARC?
DMARC (Domain-based Message Authentication, Reporting & Conformance) er en e-mailstandard som modtagerens mailserver bruger til at verificere, at en mail faktisk stammer fra det domæne der angives i afsenderadressen.
DMARC kontrollerer to ting:
- SPF (Sender Policy Framework): Er den IP-adresse mailen er sendt fra, godkendt til at sende på vegne af domænet?
- DKIM (DomainKeys Identified Mail): Er mailen kryptografisk signeret med en nøgle der kan verificeres mod domænets DNS-record?
Hvis ingen af delene består, og modtagerdomænet har politikken reject, afvises mailen automatisk og du modtager fejlkoden 550 5.7.509.
Sådan understøtter DPG Sikker Post e-mail-autentificering
Når mails afsendes via DPG, overholdes e-mail-autentificering på følgende måde:
| Mekanisme | Hvordan den overholdes |
|---|---|
| SPF authentication | Overholdes så længe kundens DPG IP-adresse er korrekt angivet i SPF-recorden på kundens domæne |
| SPF alignment | Overholdes fordi afsendelse sker fra kundens egen Exchange Online efter DPG-behandling |
| DKIM authentication | DPG laver en tro kopi af mailen inden DKIM-signering, så integriteten bevares. Bemærk dog at mailens indhold kan kompromitteres af mellemled efter afsendelse, fx smarthosts uden korrekt DKIM/ARC-konfiguration |
| DKIM alignment | Overholdes fordi signeringen sker fra kundens egen mailserver og sendes derfra direkte til den endelige modtager |
Det er denne kæde der brydes i tunnelmail-flowet, som beskrives nedenfor.
Sådan opstår afvisningen i tunnelmail-flowet
Når du sender en tunnelmail via DPG Sikker Post, pakkes beskeden ind i en S/MIME-konvolut. DKIM-signaturen placeres på S/MIME-konvolutten og ikke på den indre besked.
Det er en grundlæggende betingelse for tunnelmails.
Flowet ser sådan ud:
- Mailen sendes fra dit Exchange Online-miljø.
- DPG Sikker Post pakker beskeden ind i en S/MIME-konvolut med DKIM-signatur på den ydre skal og leveres tilbage til jeres mailmiljø.
- Den krypterede mail sendes videre til modtager.
- Modtagerens sikkerpostleverandør dekrypterer S/MIME-konvolutten og videresender den indre besked til modtagerens mailserver.
- Når S/MIME-skallen fjernes, forsvinder DKIM-signaturen med den. Dette sker uanset hvilken leverandør modtageren benytter.
- Modtagerens mailserver modtager nu den indre besked uden DKIM-signatur.
- Modtagerens mailmiljø udfører en DMARC-validering, DKIM-signaturen ikke er til stede (DKIM Fail). Sikkerpostleverandøren ikke nødvendigvis er godkendt til at sende på vegne af det oprindelige afsenderdomæne (SPF Fail).
- Modtager med politikken
rejectafviser mailen.
Hvis du kan se mailen i DPG Kundeportalen under Mailflow, har DPG behandlet og afsendt mailen korrekt.
Dette bekræfter at afvisningen sker hos modtager og ikke i DPG's system.Tjek afsenders SPF-record
Inden problemet undersøges hos modtager, er det en god idé at udelukke at fejlen skyldes afsenders egen konfiguration.
DPG's relay-IP fremgår typisk af afsenderdomænets SPF-record, men det kan bekræftes med fx. et online SPF-lookup-værktøj.
Kontakt DPG Service Center hvis du er i tvivl om hvilken IP der skal fremgå.
Mulig årsag og løsning
Da DKIM-signaturen forsvinder som del af den sidste del af tunnelmail-flowet, er fejlen i langt de fleste tilfælde betinget af modtagerens mailopsætning.
Vi kan ikke se denne opsætning og kan derfor ikke give en konkret løsning, men vi kan pege i den rigtige retning.
Modtagerens mailmiljø validerer mails fra sikkerpostleverandøren
Når sikkerpostleverandøren videresender den dekrypterede besked til modtageren, sker det fra leverandørens egne servere.
Hvis modtagerens mailmiljø udfører DMARC-validering på disse mails, vil det typisk fejle fordi:
- DKIM-signaturen ikke længere er til stede (den sad på S/MIME-konvolutten).
- Leverandørens server ikke er godkendt i afsenderdomænets SPF-record.
Hvad modtageren kan gøre:
Løsningen kræver at modtagerens sikkerhedsfilter whitelister de relevante IP-adresser og specifikke headers fra sikkerpostleverandøren. Dette er et krav alle leverandørerne stiller til deres egne kunder.
Modtagerens IT-afdeling eller mailudbyder skal kontaktes med henblik på at konfigurere denne whitelisting korrekt. Den præcise løsning afhænger af modtagerens setup og mailudbyder.
Eksempel fra supporthistorikken:
Brugere med VIPRE som sikkerpostleverandør har oplevet at Microsoft Exchange Online tjekker SPF forkert i dette flow. VIPRE beskriver løsningen som at aktivere Enhanced Filtering på connectoren til VIPRE i Exchange Online.
Dette er en konfiguration hos modtageren og ikke noget DPG kan foretage.
Fejlsøgningstabel
| Symptom | Hvad det sandsynligvis betyder | Hvem skal handle |
|---|---|---|
| Mailen ses i Mailflow, men afvises | DPG har afsendt korrekt og fejlen er hos modtager | Kontakt modtager |
| Fejlen opstår kun ved én specifik modtager | Modtagers mailmiljø validerer mails fra sikkerpostleverandøren | Modtagers IT-afdeling justerer konfiguration |
| Fejlen opstår for alle modtagere | Mulig fejl i afsenders SPF-record | Kontakt DPG Service Center for afklaring |
| Fejlen stoppede, da Sikker Post blev deaktiveret | Bekræfter at tunnelmail-flowet er involveret | Undersøg modtagers opsætning |
Analyser mail-headerne med et eksternt værktøj
For at identificere hvilke mailservere der har håndteret forsendelsen, kan du bruge eksterne værktøjer til analysere headers.
Du indsætter de fulde mail-headers fra fejlbeskeden og får et visuelt overblik over hele transportkæden.
Her kan du bl.a. se hvilke servere der har videresendt mailen efter dekryptering.
Det hjælper med at pege mod den rette part og giver modtagerens IT-afdeling et konkret udgangspunkt for fejlsøgning.
Næste skridt
Hvis fejlen kun rammer én modtager:
Kontakt modtagerorganisationens IT-afdeling og informer dem om at mailen afvises efter tunnelmail-dekryptering. Del gerne resultatet fra headeranalysen.
Det er modtageren der skal sikre at mails fra deres sikkerpostleverandørs servere kan leveres korrekt.
Hvis du er i tvivl eller fejlen er svær at placere:
Kontakt DPG Service Center med:
- Dit afsenderdomæne og modtager domæne (fx
@jeres-domæne.dk) - Den fulde fejlbesked fra afvisningen
- Et eksempel på en specifik afsendelse (dato, afsender og modtager)
Har du fortsat brug for hjælp?
Kontakt servicecenteret via https://servicecenter.sikker-post.dk