Hvor tit kommer rapporterne?

Normalt én gang i døgnet fra hver udbyder, der har modtaget mail fra jer: Google, Microsoft, Yahoo, Comcast og mange mindre. Små domæner kan gå flere dage uden rapporter, hvis der ikke er sendt mail til de udbydere.

Hvorfor fejler SPF, når mailen er fra os?

Den hyppigste grund er videresendelse: når en modtager videresender mailen, kommer den fra deres server, som ikke står i jeres SPF. Derfor er DKIM vigtigst — signaturen overlever videresendelse. Den næsthyppigste grund er et system, der mangler i SPF-posten.

Hvad er forskellen på policy_evaluated og auth_results?

auth_results viser de rå resultater af SPF og DKIM, uanset hvilket domæne der blev tjekket. policy_evaluated viser, om de bestod med et domæne, der passer til afsenderen — det er dét, DMARC bruger. En mail kan bestå SPF i auth_results og alligevel fejle DMARC.

Indeholder rapporterne personoplysninger?

Aggregerede rapporter indeholder ip-adresser og navne på de servere, der har sendt, og antal mails — ikke indhold, emner eller modtageradresser. Fejlrapporter (ruf) kan indeholde mere, men sendes kun af få udbydere.

Sådan læser I DMARC-rapporter

Hvor kommer rapporterne fra?

Når jeres DMARC-post har en rua=-adresse, sender de store mailudbydere en rapport om dagen til den. Rapporten kommer som en vedhæftet, pakket XML-fil (.zip eller .gz) med et emne som Report domain: jeresdomæne.dk Submitter: google.com. Hver rapport dækker den mail, netop den udbyder har modtaget fra jer i perioden.

Opbygningen

En rapport har tre dele. Her er et forkortet eksempel:

<report_metadata>
  <org_name>google.com</org_name>
  <date_range><begin>1791590400</begin><end>1791676799</end></date_range>
</report_metadata>
<policy_published>
  <domain>jeresdomæne.dk</domain><p>quarantine</p>
</policy_published>
<record>
  <row>
    <source_ip>40.107.22.105</source_ip>
    <count>148</count>
    <policy_evaluated>
      <disposition>none</disposition><dkim>pass</dkim><spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers><header_from>jeresdomæne.dk</header_from></identifiers>
  <auth_results>
    <dkim><domain>jeresdomæne.dk</domain><selector>selector1</selector><result>pass</result></dkim>
    <spf><domain>jeresdomæne.dk</domain><result>pass</result></spf>
  </auth_results>
</record>

report_metadata: hvem der har sendt rapporten, og hvilken periode den dækker (som Unix-tid).
policy_published: den DMARC-post, udbyderen så hos jer.
record: én pr. afsender-ip. Der kan være hundredvis.

Sådan læser I en record

source_ip og count: hvilken server der har sendt, og hvor mange mails.
policy_evaluated: DMARC-resultatet. dkim og spf er pass, hvis de bestod med et domæne, der passer til afsenderen. disposition er, hvad modtageren gjorde: none (leveret), quarantine (spam) eller reject (afvist).
header_from: domænet i feltet „Fra“, som modtageren ser.
auth_results: de rå SPF- og DKIM-resultater med de domæner, der faktisk blev tjekket. Her ser I fx, at et nyhedsbrev signerer med udbyderens domæne i stedet for jeres.

Hvad skal I kigge efter?

I ser	Det betyder typisk	Gør
Jeres egen mailudbyder, DMARC pass	Alt i orden	Ingenting
Et system I kender (CRM, nyhedsbrev, faktura), DMARC fail	Systemet er ikke sat op med jeres domæne	Slå DKIM til med jeres domæne hos leverandøren, eller tilføj det i SPF
Jeres egen udbyder, SPF fail men DKIM pass	Videresendt mail	Ingenting — DKIM redder den
Ukendte ip'er i udlandet, alt fail	Forfalskning eller spam med jeres adresse	Det er dem, `p=reject` stopper
Mange mails fra en ukendt ip, DMARC pass	Et system, I ikke kendte — eller en hacket konto	Find ud af, hvem ip'en tilhører

Hvorfor ikke bare læse dem selv?

Det kan man, men det bliver hurtigt uoverskueligt: en mellemstor virksomhed får 10–30 rapporter om dagen med ip-adresser, der skal slås op én ad gangen. DomGuard samler alle rapporterne, slår op, hvem ip-adresserne tilhører (fx „Microsoft 365“ eller „Mailchimp“), og viser kun det, der kræver handling. Se også DMARC trin for trin.