altinn.no email auth: DMARC is p=none with no reporting, and M365 DKIM is not enabled

[bengtfredh]

Summary

altinn.no has the weakest email-authentication posture of the Digdir domains I checked, despite being by far the most attractive phishing target. Two separate gaps:

1. DMARC is not enforcing, and is not even reporting.

_dmarc.altinn.no      "v=DMARC1; p=none"
_dmarc.digdir.no      "v=DMARC1;p=quarantine; rua=mailto:dmarcadmin@digdir.no;"
_dmarc.altinn.cloud   "v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:dmarcaltinncloud@altinn.no"

p=none means receivers take no action on messages that fail authentication. There is also no rua=, so no aggregate reports are being collected anywhere — we have neither enforcement nor visibility. Both digdir.no and altinn.cloud are at p=quarantine with a reporting address.

2. DKIM signing is not functional.

selector1._domainkey.altinn.no  CNAME  selector1-altinn-no._domainkey.digdir.onmicrosoft.com  → NXDOMAIN
selector2._domainkey.altinn.no  CNAME  selector2-altinn-no._domainkey.digdir.onmicrosoft.com  → NXDOMAIN

Microsoft 365 publishes these selector targets only once DKIM is enabled for the custom domain in the tenant. NXDOMAIN means it is not enabled, so mail sent as @altinn.no through M365 is not DKIM-signed with these selectors.

Note this is not specific to altinn.no — digdir.no has the identical broken chain (selector1-digdir-no._domainkey.digdir.onmicrosoft.com is also NXDOMAIN). It looks tenant-wide, so the fix likely covers both domains at once.

What is working

• SPF is strict: v=spf1 a:ai-p-s1-ext.ai.basefarm.net ip4:195.43.63.191/32 ip4:195.43.63.192/32 ip4:51.13.102.144 include:spf.protection.outlook.com -all — hard fail, correctly scoped.
• Azure Communication Services DKIM is fine: selector1/2-azurecomm-prod-net._domainkey.altinn.no both chain to valid v=DKIM1 records. Transactional mail from ACS is signed.

So the exposure is specifically the M365 path plus the absence of DMARC enforcement.

Risk

altinn.no is a high-trust domain for Norwegian citizens and businesses, and a natural lure for credential phishing against ID-porten. SPF -all blocks spoofing from unauthorised envelope senders, but SPF alone does not protect the visible From: header — that is what DMARC alignment is for. With p=none, a receiver that detects a spoofed From: @altinn.no is told explicitly to do nothing about it.

Without rua=, we would also have no idea it was happening.

This connects to the phishing scenario in #3907 and #3908: those concern an attacker serving content on an altinn.no hostname; this concerns an attacker sending mail as altinn.no. A campaign combining both would be very hard for a recipient to distinguish from the real thing.

Actions

• Add a rua= reporting address to _dmarc.altinn.no and start collecting aggregate reports
• Enable DKIM for altinn.no (and digdir.no) in the M365 tenant so the selector CNAMEs resolve
• Once reports show legitimate senders are aligned, move altinn.no to p=quarantine, then p=reject, matching or exceeding digdir.no and altinn.cloud
• Add sp= to control subdomain policy explicitly, as altinn.cloud already does
• Publish a null SPF/DMARC policy on non-sending domains — altinn.studio and altinncdn.no currently have no DMARC record at all

Ownership

Filing here because it surfaced during DNS work on the altinn.no zone, but this likely belongs with whoever owns the M365 tenant and mail routing rather than platform infrastructure. Please reassign if so — the DNS half is ours, the tenant half probably is not.

Context

Found while sweeping all 44 CNAME records in the altinn.no zone after the A/AAAA cleanup in #3907. Related: #3908 (no CAA records on altinn.no), #3910 (dangling Episerver CNAMEs).