DKIM and DMARC alignment

DKIM proves that a domain took responsibility for a cryptographic signature on a message. DMARC connects authenticated identities to the domain visible to the recipient in the From: field and lets a domain owner publish handling and reporting preferences.

Passing DKIM is not the same as passing DMARC. The signature must verify and its d= domain must align with the visible From domain, unless aligned SPF provides the DMARC pass instead.

DKIM: signing and verification

A DKIM signature identifies a signing domain in d= and a selector in s=. A receiver retrieves the public key from:

selector._domainkey.signing-domain

The corresponding private key stays with the signing system. A third-party sender should offer custom DKIM so that it signs with a domain controlled by the customer rather than only its own provider domain.

Current DKIM cryptographic guidance requires RSA keys of at least 1024 bits and recommends at least 2048 bits. It also permits Ed25519-SHA256. Provider capability and DNS publishing constraints still need to be checked before choosing an algorithm or key size.

Selectors make planned replacement possible. Rotate a key when its confidentiality is in doubt, when a provider or policy requires it, or according to a documented local lifecycle. There is no universal annual rotation interval in the DKIM standard. Keep an old public key available until messages signed with it can no longer be in transit or legitimately re-evaluated.

DMARC alignment

DMARC evaluates the domain in the RFC 5322 From: field, called the Author Domain in the current specification.

DKIM alignment compares that domain with the domain of a passing DKIM signature. SPF alignment compares it with the domain authenticated by SPF, normally the envelope sender.

In relaxed alignment, the relevant organizational domains must match. For example:

From: accounts@example.com
DKIM d=mail.example.com

can align in relaxed mode. In strict mode the domains must match exactly.

DMARC passes when at least one of these paths succeeds:

SPF passes and its authenticated domain aligns with the Author Domain; or
DKIM passes and its signing domain aligns with the Author Domain.

DKIM is usually the more durable path through simple forwarding because the connecting IP changes and SPF commonly fails. Forwarders or mailing systems can still invalidate DKIM by modifying signed content or headers.

A practical signing model

For each system that sends mail using your From domain, record:

the visible From domain;
the envelope sender domain;
the DKIM signing domain and selector;
the expected sending hosts;
the person or provider responsible for the key.

Prefer a small, intentional set of signing subdomains. Relaxed alignment is the DMARC default and supports this model. Strict alignment is useful only where exact matching is an explicit requirement; it is not a mandatory final stage.

DMARC policy

A DMARC record is published as TXT at _dmarc.example.com. A minimal monitoring record is:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

The principal policies are:

p=none: request monitoring without a quarantine or rejection disposition;
p=quarantine: request treatment associated with suspicious mail;
p=reject: request rejection of messages that fail DMARC.

These are requests to receivers, not guarantees of final placement or disposition.

sp= supplies a policy for subdomains. adkim= and aspf= select relaxed (r) or strict (s) alignment; both default to relaxed.

The 2026 DMARC revision

RFC 9989 replaced RFC 7489 in May 2026, with aggregate and failure reporting defined separately by RFC 9990 and RFC 9991.

The pct tag was removed. The standards group found that percentages other than 0 or 100 were applied inconsistently. Current DMARC instead defines t=y as a testing signal corresponding to part of the former pct=0 behaviour. It is not a request to enforce policy on an arbitrary percentage of messages.

The revision also removed the ri and rf tags and added np, psd and t. Ordinary domain owners will most often use v, p, sp, adkim, aspf, rua and, where there is a justified need, ruf and fo.

Reporting

rua= requests aggregate reports. These summarize authentication and disposition observations and are normally the safest basis for discovering legitimate sources before enforcement. If reports go to a domain outside the policy domain, that destination must publish the authorization record defined by RFC 9990.

ruf= requests per-message failure reports. Receivers choose whether to generate them, and the reports can expose message data. Use a secured destination and a documented retention policy. fo= only affects requested failure-report conditions and has no useful effect without ruf.

Moving from observation to enforcement

Blue Canoe’s operating practice is:

Inventory every legitimate sender before changing policy.
Publish reporting and confirm that expected streams pass and align.
Correct or isolate sources that cannot align.
Choose quarantine or reject only after reviewing representative traffic and business failure paths.
Recheck after every vendor, DNS or mail-routing change.

Do not use an unsupported percentage rollout as a substitute for understanding the sources. Where a controlled rollout is needed, separate traffic by subdomain or sending system so that policy boundaries are explicit.

Primary references

Reviewed against these sources on 27 August 2026.