DMARC Analyzer

TL;DR

A DKIM public key is published in the DNS as a TXT record at <selector>._domainkey.<domain> whose body is a semicolon-separated list of tag-value pairs. The DNS-record-level syntax is governed by RFC 6376 §3.6.2 and the underlying DNS specification in RFC 1035.

• v=DKIM1 — optional version tag, case-sensitive uppercase "DKIM1". Recommended for forward compatibility.
• p=<base64> — mandatory public-key data, base64-encoded DER-formatted public key.
• k=rsa or k=ed25519 — key type. Defaults to rsa if omitted. RFC 8463 added ed25519.
• h=sha256 — optional list of acceptable hash algorithms. Default is "all". Modern best practice: omit or sha256 only (rsa-sha1 deprecated by RFC 8301).
• t=y — testing flag. t=s — strict i= domain match (no subdomain of d=).
• s=email or s=* — service type. Default * means any.
• 255-octet character-string limit — per CHARACTER-STRING, not per TXT record. 2048-bit RSA keys MUST be split into multiple quoted strings.
• Empty p= — the canonical key-revocation signal.

The Domain Security Checker surfaces every syntactic drift class documented on this page: missing v=DKIM1 prefix, truncated p= value (255-octet overflow without chunking), deprecated k= values, and accidental t=y production records.

1. What "DNS record syntax" means for DKIM (and where the semantics live)

DKIM is a layered specification. The SYNTAX LAYER defines how the public key is encoded at the DNS: where to publish it, which record type to use, which tags are valid, how tokens are separated, and how DNS-level constraints (the 255-octet character-string limit) bound the encoding. The SEMANTIC LAYER defines what each token means once parsed: how the verifier reconstructs the public key from p=, how the canonicalization algorithm interacts with k=, how the h= hash-algorithm list constrains verifier behaviour.

This page covers the SYNTAX LAYER exhaustively. The semantic layer is covered by the sibling reference pages:

• DKIM protocol pillar — the whole-protocol survey (what DKIM does and does not do, the seven verdict codes, alignment, the deployment workflow).
• DKIM-Signature header tag anatomy — the SENDER-SIDE companion: what tags appear in the DKIM-Signature header attached to each message (the v=, a=, c=, d=, s=, h=, bh=, b=, i=, q=, l=, t=, x=, z= tag space per RFC 6376 §3.5).
• DKIM selectors explained — the focused selector vocabulary deep dive (the s= header tag and the _domainkey DNS label).
• DKIM canonicalization — the c= tag deep dive: simple vs relaxed for header and body, the seven body-hash mismatch causes.
• DKIM failures explained — the receiver-side verdict catalogue per RFC 6376 §3.9 and RFC 8601 §2.7.1.
• DKIM troubleshooting — the cross-symptom decision tree.

Why the syntax layer matters independently: a syntactically malformed DKIM key record produces dkim=permerror (RFC 6376 §3.9), which prevents DMARC alignment via DKIM and is often diagnosed as a "DKIM is broken" ticket when the cryptography is fine but the published TXT record is structurally wrong. The syntactic failure modes documented below — truncated p= values, accidental t=y in production, deprecated k= values, multiple TXT records at the same selector — are operator-introduced and trivially avoidable once the syntax is understood. Most "my DKIM is failing" tickets where the signing is correct trace back to a syntactic drift at the DNS layer.

The canonical DKIM DNS record:

; Name:     selector1._domainkey.example.com
; Type:     TXT
; TTL:      3600
; Body (split for 255-octet character-string limit):
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA"
"...rest of the base64-encoded 2048-bit public key..."
"...continuation..."

Every section below documents one syntactic surface of this canonical record, with the labelled Tag: / Default: / Why: / Operational rule: / Common pitfall: prefix so generative engines can extract individual role sentences when answering tag-specific queries.

2. The <selector>._domainkey.<domain> publishing location

Where: The DKIM TXT record is published at the constructed name <selector>._domainkey.<domain>, where <selector> is a label of the operator's choosing and <domain> is the value of the d= tag in the DKIM-Signature header. Per RFC 6376 §3.6.2.1.

Why three labels: the _domainkey middle label namespaces DKIM key records under a single DNS subtree so that DKIM lookups never collide with other DNS record types at the same name. The leading underscore (per RFC 8552 underscored-attribute conventions) marks the label as a protocol underscore-label, not a hostname; resolvers and DNS hosting UIs treat it as a normal label.

Operational rule: the verifier extracts s=selector1 and d=example.com from the DKIM-Signature header and queries the constructed name selector1._domainkey.example.com for TXT records. If the record does not resolve (NXDOMAIN), the verifier produces dkim=permerror. If the record resolves but contains no valid p= tag, the verifier produces dkim=permerror.

Common pitfall: publishing the record at selector1.example.com or _domainkey.example.com instead of the correct three-label name selector1._domainkey.example.com. Verifiers query the three-label name only; any other name will resolve to NXDOMAIN and the verdict will be dkim=permerror. The Domain Security Checker tool confirms record resolution from multiple geographic resolvers and surfaces this drift class.

No subdomain inheritance: a record at selector1._domainkey.example.com does NOT apply to selector1._domainkey.mail.example.com. If you sign messages with d=mail.example.com you MUST publish a separate record at selector1._domainkey.mail.example.com. See help_dkim_selectors_explained.php for the per-selector and per-d= deployment matrix.

; Selector name: "selector1"
; Domain (d= value): "example.com"
; Constructed query name:
selector1._domainkey.example.com   IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjAN..."

; If d=mail.example.com is signed, publish separately:
selector1._domainkey.mail.example.com   IN  TXT  "v=DKIM1; k=rsa; p=..."

3. The v=DKIM1 version tag (RFC 6376 §3.6.1)

Tag: v=DKIM1
Default: RFC 6376 §3.6.1 says verifiers MUST assume v=DKIM1 if the tag is missing, so the tag is technically OPTIONAL.
Why: the version tag is the forward-compatibility hook — future DKIM versions would use v=DKIM2 or later. It also disambiguates DKIM records from other TXT-record uses at the same name and improves human-readability when auditing zone files.
Operational rule: always publish v=DKIM1 as the FIRST tag in every DKIM key record. Some legacy verifiers do still require it despite the RFC default-assumption behaviour.
Common pitfall: publishing v=dkim1 (lowercase) instead of v=DKIM1 (uppercase). RFC 6376 specifies the value as case-sensitive uppercase; verifiers that strictly enforce the case will reject the record. The canonical form is uppercase "DKIM1".

; Correct — uppercase DKIM1, first tag:
"v=DKIM1; k=rsa; p=MIIBIjAN..."

; Wrong — lowercase, may be rejected:
"v=dkim1; k=rsa; p=MIIBIjAN..."

; Acceptable — RFC default-assumption kicks in:
"k=rsa; p=MIIBIjAN..."

; Wrong — v= not first:
"k=rsa; v=DKIM1; p=MIIBIjAN..."

4. The p= public-key data tag (RFC 6376 §3.6.1, MANDATORY)

Tag: p=<base64-encoded DER public key>
Default: none. p= is the only structurally mandatory tag in the DKIM key record. An empty p= value has special meaning — see §11 (Revocation).
Why: p= carries the public key the verifier needs to decrypt the b= signature in the DKIM-Signature header. Without p= the verifier cannot complete the cryptographic verification.
Operational rule: generate the keypair with your provider's wizard or with openssl genrsa -out private.pem 2048 followed by openssl rsa -in private.pem -pubout to extract the public key. The public key is the DER-formatted SubjectPublicKeyInfo structure, base64-encoded. Do NOT include the PEM -----BEGIN PUBLIC KEY----- headers; strip them before publishing.
Common pitfall: including the PEM header/footer lines in the p= value. Verifiers expect the raw base64 payload; the PEM banner bytes are not valid base64 and will produce dkim=permerror. Also: inserting line breaks or whitespace into the base64 value. Some DNS UIs preserve embedded whitespace; the verifier strips it but legacy parsers may not. Keep the p= value as a single continuous base64 string with NO internal whitespace.

; Correct — single continuous base64, no PEM banner:
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxxxxxxxxxxx..."

; Wrong — PEM banner included:
"v=DKIM1; k=rsa; p=-----BEGIN PUBLIC KEY-----MIIBIjAN...-----END PUBLIC KEY-----"

; Wrong — embedded line breaks/whitespace in p=:
"v=DKIM1; k=rsa; p=MIIBIjAN BgkqhkiG9w0BAQEF AAOCAQ8A..."

For 2048-bit RSA keys the base64-encoded value is approximately 392 characters — exceeding the 255-octet character-string limit. The zone file representation MUST split the value across multiple quoted strings. See §10 (255-octet chunking) for the splitting convention.

5. The k= key-type tag (RFC 6376 §3.6.1 + RFC 8463)

Tag: k=rsa or k=ed25519
Default: k=rsa if the tag is omitted (RFC 6376 §3.6.1).
Why: the key-type tag names the asymmetric algorithm used to generate the keypair, so the verifier knows which cryptographic primitive to invoke when verifying b=. RFC 6376 (2011) defined only k=rsa; RFC 8463 (2018) added k=ed25519 as a second valid value with shorter keys and faster verification.
Operational rule: for 99% of deployments, use k=rsa with a 2048-bit key (RFC 8301 §3 recommends 2048-bit minimum). For modern deployments wanting the structural benefits of Curve25519, dual-publish both k=rsa at one selector and k=ed25519 at another selector — the signer can choose per message. NEVER deploy a 1024-bit RSA key — receivers downgrade verdicts to dkim=policy per RFC 8301.
Common pitfall: deploying k=ed25519 as the only key type on a new domain. Receivers that have not implemented RFC 8463 (less common in 2026 but still present, especially in older spam appliances) produce dkim=neutral or dkim=permerror on the ed25519 signature. Mix RSA and ed25519 keys on separate selectors so the signer can fall back to RSA when needed; see help_dkim_cryptography_basics.php for the algorithm migration playbook.

; Correct — explicit k=rsa:
"v=DKIM1; k=rsa; p=MIIBIjAN..."

; Correct — k= omitted, defaults to rsa:
"v=DKIM1; p=MIIBIjAN..."

; Correct — ed25519 key per RFC 8463:
"v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo="

; Wrong — invalid k= value:
"v=DKIM1; k=elliptic-curve; p=..."

6. The h= hash-algorithm list tag (RFC 6376 §3.6.1)

Tag: h=sha256 or h=sha256:sha1 (colon-separated list)
Default: if the tag is omitted, the verifier MUST accept all hash algorithms supported by the k= key type.
Why: the publisher uses h= to constrain which body-hash algorithms the verifier should consider. If the DKIM-Signature header carries a=rsa-sha1 but the key record specifies h=sha256, the verifier rejects the signature (produces dkim=permerror) because the publisher does not authorize SHA-1 verification against this key.
Operational rule: in 2026, omit h= entirely OR set h=sha256. RFC 8301 §2.2 deprecated rsa-sha1 ("rsa-sha1 MUST NOT be used for signing") so there is no remaining use case for accepting SHA-1 signatures at the verifier side.
Common pitfall: setting h=sha1 or h=sha256:sha1 on a modern record "just in case". Receivers may treat this as explicit operator endorsement of rsa-sha1 and downgrade the verdict; the conservative posture is to OMIT h= (default-all) OR explicitly set h=sha256 to lock SHA-256.

; Recommended — h= omitted, default accepts all:
"v=DKIM1; k=rsa; p=MIIBIjAN..."

; Recommended — explicit h=sha256:
"v=DKIM1; k=rsa; h=sha256; p=MIIBIjAN..."

; Discouraged — h=sha256:sha1 allows deprecated SHA-1:
"v=DKIM1; k=rsa; h=sha256:sha1; p=MIIBIjAN..."

; Wrong — h=sha1 only, rsa-sha1 is deprecated by RFC 8301:
"v=DKIM1; k=rsa; h=sha1; p=MIIBIjAN..."

7. The t= flags tag (RFC 6376 §3.6.1)

Tag: t=y, t=s, or t=y:s (colon-separated combinations).
Default: if the tag is omitted, no flags are set — the key is production-ready and the AUID local-part is unconstrained.

t=y (testing flag): signals to verifiers that the key is in deployment test mode. Verifiers SHOULD compute the verdict (so it appears in Authentication-Results headers) but SHOULD NOT feed it into DMARC alignment, spam filters, or reputation scoring. Use for the first 24 to 72 hours after deploying a new selector, then REMOVE.

t=s (strict i= flag): When a DKIM-Signature header carries an i= tag (the AUID, Agent or User Identifier), the domain to the right of the @ MUST be exactly the d= domain and MUST NOT be a subdomain of it. Without t=s, a signature with d=example.com may carry i=user@mail.example.com. With t=s, the verifier fails that signature; only an i= at example.com itself, or no i= tag at all, is accepted. The flag does not concern the local-part.

Why t=y matters: A new DKIM deployment with t=y produces visible Authentication-Results: ...; dkim=pass headers that you can inspect via the Email Header Analyzer, but receivers do NOT use the result for DMARC alignment. This lets you debug the cryptography without affecting deliverability. Once aggregate reports confirm a healthy verdict distribution, remove t=y to enable DMARC alignment via DKIM.
Common pitfall: forgetting to remove t=y after the test phase. Every receiver downgrades the resulting verdict to "pass but ignore", which means your DMARC alignment via DKIM is effectively disabled forever despite the cryptography being valid. Production records with stale t=y are one of the top three causes of "DKIM is configured but DMARC still fails" tickets.

Why t=s is rarely used: The i= tag in DKIM-Signature headers is rarely populated in modern DKIM signatures — signers default to the empty AUID which inherits from d=. So t=s has no effect on most messages and is essentially documentation overhead. Leave OFF unless you have a documented per-AUID delegation requirement.

; Test mode — DKIM verdict computed but ignored by DMARC:
"v=DKIM1; k=rsa; t=y; p=MIIBIjAN..."

; Production — no flags:
"v=DKIM1; k=rsa; p=MIIBIjAN..."

; Strict i= AUID enforcement (rare):
"v=DKIM1; k=rsa; t=s; p=MIIBIjAN..."

; Both flags combined:
"v=DKIM1; k=rsa; t=y:s; p=MIIBIjAN..."

8. The s= service-type tag (RFC 6376 §3.6.1)

Tag: s=email, s=*, or a colon-separated list.
Default: s=* (any service) if the tag is omitted.
Why: the service-type tag tells verifiers which mail-related services the key is authorised for. RFC 6376 §3.6.1 defines only one service type — email — but the tag exists as an extension point for future DKIM-using protocols.
Operational rule: omit s= entirely (defaults to *) OR set s=email for symmetry with the RFC-defined value. Both behave identically in practice because email is the only service type defined.
Common pitfall: confusing the s= tag in the KEY RECORD (this tag — service type) with the s= tag in the DKIM-SIGNATURE HEADER (selector name). They are completely different tags sharing the letter. See help_dkim_signatures_explained.php for the header tag anatomy.

; Default — s= omitted, any service:
"v=DKIM1; k=rsa; p=MIIBIjAN..."

; Explicit — only the "email" service:
"v=DKIM1; k=rsa; s=email; p=MIIBIjAN..."

; Explicit wildcard (same as omitted):
"v=DKIM1; k=rsa; s=*; p=MIIBIjAN..."

9. Deprecated and rarely-used tags: n= notes and g= granularity

n= notes tag (RFC 6376 §3.6.1): optional operator-readable text. The verifier MUST ignore the value; the tag exists only as a place for the publisher to leave a note about the key (e.g., "rotated 2026-03-01", "owner: ops team"). Rarely used because zone-file comments serve the same purpose and are not transmitted over DNS. If used, keep the value short — every byte counts against the 255-octet character-string limit and the 4096-byte TXT-record practical ceiling.

g= granularity tag (deprecated by RFC 6376): RFC 4871 (the predecessor to RFC 6376) defined a g= tag that constrained the AUID local-part to a wildcard pattern. RFC 6376 §3.6.1 removed g= from the canonical syntax, retaining only legacy interoperability notes. Modern verifiers SHOULD ignore g= if present. Modern signers SHOULD NOT publish g=; use selector-level isolation (a different selector per sub-brand) or the t=s flag instead. If you inherit a zone file with g= records from a pre-2011 deployment, remove the tag during the next key rotation — leaving it is harmless but is a documentation drift.

; Acceptable but rare — notes tag for operator memory:
"v=DKIM1; k=rsa; n=Rotated 2026-03-01 by ops; p=MIIBIjAN..."

; Discouraged — legacy g= granularity, modern verifiers ignore:
"v=DKIM1; k=rsa; g=newsletter*; p=MIIBIjAN..."

10. The 255-octet character-string limit and chunking (RFC 1035 §3.3.14)

The rule: RFC 1035 §3.3.14 specifies that a DNS character-string is a length-prefixed sequence of up to 255 octets. A TXT resource record contains one OR MORE character-strings concatenated by the resolver at lookup time. So a single TXT record can encode arbitrary-length text (up to the response size limit) BUT each constituent character-string is bounded at 255 octets.

Why this matters for DKIM: a 2048-bit RSA public key, base64-encoded with the DER SubjectPublicKeyInfo wrapper, is approximately 392 characters. The full TXT-record body v=DKIM1; k=rsa; p=<392 chars> is roughly 400+ characters — exceeding 255. The publisher MUST split the body across multiple character-strings.

The zone-file syntax: adjacent quoted strings concatenate at lookup time. There is NO space, NO comma, NO continuation marker between adjacent strings — only adjacency. The resolver returns each string separately; the receiver concatenates them transparently.

; Single-string form (works only if total < 255 octets):
selector1._domainkey  IN  TXT  "v=DKIM1; k=rsa; p=short-test-key-only"

; Multi-string form (required for 2048-bit RSA):
selector1._domainkey  IN  TXT  ( "v=DKIM1; k=rsa; "
                                 "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxxxx"
                                 "yyyy...continuation of the base64 string...zzzz"
                                 "...rest of the key...end" )

; What the verifier sees after resolver concatenation:
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxxxxyyyy...zzzz...end"

Common pitfall: some DNS UIs accept the long key as a single string and auto-chunk under the hood; others require explicit per-string quoting. If you copy-paste a 2048-bit key into a UI that does NOT auto-chunk and you do NOT split it manually, the publish will silently truncate at 255 octets — the record will exist but DKIM verification will fail with dkim=permerror because the public key is incomplete. Check immediately after publishing:

; Verify the published record from multiple resolvers:
dig +short selector1._domainkey.example.com TXT @8.8.8.8
dig +short selector1._domainkey.example.com TXT @1.1.1.1
dig +short selector1._domainkey.example.com TXT @9.9.9.9

; The output should show the complete v=DKIM1...p=...end string
; spanning multiple "quoted" "strings" if the key is large.

Practical response-size ceiling: DNS UDP responses traditionally fit in 512 bytes (EDNS0 raises this to 4096 or more). A DKIM TXT record with a 2048-bit RSA key plus all metadata tags is well under 4096 bytes. A 4096-bit RSA key approaches 800+ characters and may push the response near the UDP/EDNS0 ceiling, triggering TCP fallback on some resolvers — a measurable latency cost on every DKIM lookup. The 2048-bit sweet spot per RFC 8301 §3 is both cryptographically modern and response-size friendly.

11. Key revocation: the empty p= convention

The rule: RFC 6376 §3.6.1 specifies that "an empty value [of p=] means that this public key has been revoked". The verifier MUST treat any signature referencing this selector as invalid (dkim=permerror in modern verifier output).

Why empty-p= rather than deleting the record: deleting the TXT record entirely produces NXDOMAIN at the resolver, which some verifiers interpret as transient (DNS outage or propagation delay) and classify as dkim=temperror with retry. The empty p= value is the canonical "permanently revoked" signal: the record exists (no NXDOMAIN), but the publisher has explicitly indicated the key is gone. Verifiers MUST treat it as permanent.

Operational use case: a signing key compromise. Publish the empty-p= replacement at the affected selector IMMEDIATELY, then rotate the signer to a NEW selector with a fresh keypair. Mail in flight at the moment of compromise that was signed with the compromised key will now fail verification at every receiver — exactly the desired outcome because the attacker may be forging signatures with the stolen private key.

; Pre-compromise — production record:
selector5._domainkey  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjAN...full-key...end"

; Compromise detected — publish empty p= immediately:
selector5._domainkey  IN  TXT  "v=DKIM1; k=rsa; p="

; Rotate signer to a new selector (selector6._domainkey) with
; a fresh keypair. See help_dkim_key_rotation.php for the
; dual-selector overlap discipline.

Retention: keep the empty-p= record for at least 30 days (one mail-archive lifetime for forwarded messages still in flight) before deleting it entirely. After 30 days the selector can be removed from the zone — at that point any straggler signatures will produce dkim=temperror on first lookup and dkim=permerror after cache TTL expiry, which is acceptable for messages that old.

See help_dkim_key_rotation.php for the broader rotation discipline including dual-selector overlap windows, TTL planning, and the difference between routine rotation (graceful) and emergency revocation (immediate empty-p=).

12. Canonical examples

Six minimal-to-comprehensive examples covering the full deployment matrix.

Example 1 — minimal 2048-bit RSA production record:

; Name:  selector1._domainkey.example.com
; Type:  TXT
; TTL:   3600
; Body:
"v=DKIM1; k=rsa; "
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxxxxxxxxxxxxxxxxxxx"
"yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"
"zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzwIDAQAB"

Example 2 — testing-mode deployment (first 24-72 hours):

"v=DKIM1; k=rsa; t=y; "
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxxx..."
"...rest of the key...wIDAQAB"

Example 3 — ed25519 record per RFC 8463:

; Name:  selector2._domainkey.example.com
; Type:  TXT
; Body (fits in a single character-string — ed25519 keys are short):
"v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo="

Example 4 — explicit h=sha256 and s=email:

"v=DKIM1; k=rsa; h=sha256; s=email; "
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
"...rest of the key..."

Example 5 — revoked-key record (empty p=):

"v=DKIM1; k=rsa; p="

Example 6 — Microsoft 365 CNAME delegation (operator publishes CNAME, Microsoft publishes the TXT):

; Operator's zone — publish two CNAMEs:
selector1._domainkey.example.com   IN  CNAME  selector1-example-com._domainkey.example.onmicrosoft.com.
selector2._domainkey.example.com   IN  CNAME  selector2-example-com._domainkey.example.onmicrosoft.com.

; Microsoft's tenant zone publishes the actual TXT records — the
; operator never touches the p= value. See
; help_dkim_for_microsoft_365.php for the full CNAME-delegation
; deployment workflow.

13. Common operator mistakes

Ten canonical syntactic drift classes, enumerated as a punch list. Every one produces dkim=permerror or dkim=fail at the verifier despite "DKIM being configured".

1. PEM banner in p= — copy-pasting -----BEGIN PUBLIC KEY----- through -----END PUBLIC KEY----- into the p= value. Strip the banner before publishing; only the raw base64 belongs in the record.
2. Embedded whitespace in p= — line breaks or spaces inside the base64 string. Some legacy parsers reject embedded whitespace; keep the value as one continuous base64 string.
3. Truncated p= from 255-octet overflow — copy-pasting a 2048-bit key into a DNS UI that does not auto-chunk, resulting in a silent truncation at the 255-character boundary. Always verify with dig +short selector._domainkey.example.com TXT and confirm the full key appears.
4. Stale t=y in production — forgetting to remove the testing flag after the deployment burn-in period. Every receiver downgrades the verdict to "ignore for DMARC", which silently disables DKIM-based DMARC alignment.
5. Wrong record location — publishing at selector1.example.com or _domainkey.example.com instead of the correct selector1._domainkey.example.com. Verifiers query the three-label name only.
6. Multiple TXT records at the same selector — accidentally creating a second record alongside the first when hand-editing the zone. Verifier behaviour becomes non-deterministic; some accept the concatenation, others fail with dkim=permerror.
7. 1024-bit RSA key still deployed — receivers downgrade dkim=pass to dkim=policy per RFC 8301 §3. Rotate to 2048-bit during the next routine rotation; see help_dkim_key_rotation.php.
8. Lowercase v=dkim1 — RFC 6376 specifies the value as case-sensitive uppercase "DKIM1". Strict verifiers reject lowercase.
9. Missing v=DKIM1 first position — placing v=DKIM1 after other tags. Some verifiers require it as the first tag for forward-compatibility detection.
10. Subdomain selector record missing — signing messages with d=mail.example.com but publishing the selector record only at selector1._domainkey.example.com. Publish a separate record at selector1._domainkey.mail.example.com — no subdomain inheritance.

The Domain Security Checker surfaces drift classes 1, 3, 5, 6, 7, and 10 via DNS lookups against the operator-named selector(s). The Email Header Analyzer surfaces drift classes 2, 4, 7, 8, and 9 by parsing failing messages and showing the verifier-side error.

14. Frequently asked questions

Is the v=DKIM1 tag mandatory in a DKIM TXT record?

No, but it is strongly recommended. RFC 6376 §3.6.1 says the v= tag is OPTIONAL and that "verifiers MUST assume v=DKIM1 if the v= tag is missing". So a record beginning with p=MIIBIj... is still a valid DKIM record. However, every modern signing-side wizard publishes v=DKIM1 as the first tag because (a) it disambiguates DKIM records from other TXT-record uses at the same name, (b) future DKIM versions (if specified) would use v=DKIM2 or later — the v= tag is the forward-compatibility hook, (c) some legacy verifiers do still require v=DKIM1 despite the RFC default behaviour, (d) it improves human-readability when auditing zone files. The canonical action: always publish v=DKIM1; on a record without v=DKIM1 still works but you lose forward compatibility and legacy-verifier compatibility.

Why is my 2048-bit DKIM TXT record split into multiple quoted strings?

The 255-octet DNS character-string limit (RFC 1035 §3.3.14) is per-character-string, not per-TXT-record. A 2048-bit RSA public key, base64-encoded, is approximately 392 characters — exceeding the 255-octet character-string ceiling. So your DNS provider must split the p= value across multiple character-strings, each up to 255 octets, which the resolver concatenates at lookup time. The zone-file representation looks like "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..." "...rest of the key..." with the strings adjacent and quoted separately — there is NO space between strings, NO comma, NO continuation marker. The receiver concatenates them transparently. Some DNS UIs accept the long key as a single string and auto-chunk under the hood; others require explicit per-string quoting. If you copy-paste a 2048-bit key into a UI that does not auto-chunk and you do not split it manually, the publish will silently truncate at 255 octets — the record will exist but DKIM verification will fail with dkim=permerror because the public key is incomplete.

What does an empty p= tag mean in a DKIM record?

An empty p= tag is the canonical signal for DKIM key revocation. RFC 6376 §3.6.1 specifies that "an empty value means that this public key has been revoked" — the receiver MUST treat any signature referencing this selector as invalid (dkim=permerror in modern verifier output). The empty-p= convention exists because deleting the TXT record entirely would produce dkim=temperror at receivers that interpret missing DNS records as transient (DNS outage) rather than permanent (key revoked). Publishing v=DKIM1; p= with the explicit empty value tells every receiver "this key is permanently gone, do not accept any signature using this selector". The operational use case: a signing-key compromise — publish the empty-p= replacement at the affected selector immediately, then rotate the signer to a new selector with a fresh keypair. The empty-p= record is typically kept for at least 30 days (one mail-archive lifetime for forwarded messages still in flight) before being deleted entirely.

Can I have two DKIM TXT records at the same selector?

RFC 6376 §3.6.2.2 says "if any of the keys in the resulting set fails, the signature MUST be considered to have failed", which implies multiple TXT records at the same selector name are not formally forbidden but produce non-deterministic verifier behaviour. Some verifiers concatenate all matching TXT records and parse the result as a single tag-value list; others use only the first or last; others log a warning and treat as malformed. The practical posture: NEVER publish two DKIM TXT records at the same selector. If you need a second key with different parameters, use a different selector name (e.g., selector2._domainkey instead of selector1._domainkey). The most common cause of accidental dual-record publishing: an automated wizard publishes the first record, the operator later hand-edits and accidentally creates a second record alongside it. The Domain Security Checker tool surfaces this drift class. If you discover two records, merge or delete one immediately.

What is the t=y testing flag and when should I use it?

The t=y flag (RFC 6376 §3.6.1) is the testing-mode signal — it tells verifiers "this signing key is in deployment-test mode; treat signature failures as informational rather than as authentication failures". Verifiers SHOULD NOT use t=y signatures for DMARC alignment or for spam-filter input. The operational use case: a new signer deployment, where you want the verifier to compute the verdict (so you can see it in the Authentication-Results header) but you do not yet want it to feed into DMARC pass/fail. The discipline: t=y for the first 24 to 72 hours after deploying a new selector, then remove t=y once you confirm via aggregate reports that the verdict pattern is healthy. NEVER leave t=y in a production DKIM record — every receiver downgrades the resulting dkim=pass to "pass but ignore", which means your DMARC alignment via DKIM is effectively disabled even though the cryptography is valid.

What does t=s do in a DKIM record?

The t=s flag (RFC 6376 §3.6.1) restricts the domain of the i= tag: when a DKIM-Signature header carries an i= tag (the AUID, Agent or User Identifier), the domain to the right of the @ MUST be exactly the d= domain and MUST NOT be a subdomain of it. Without t=s, a signature with d=example.com may carry i=user@mail.example.com. With t=s, the verifier fails that signature; only an i= at example.com itself, or no i= tag at all, is accepted. The flag does not concern the local-part. In practice t=s changes little, because the i= tag is rarely populated in modern DKIM signatures (signers default to the empty AUID, which inherits from d=). RFC 6376 recommends setting t=s unless you need subdomaining: set it when every stream signed with this key uses the exact d= domain, and leave it off when the key also signs with i= at a subdomain.

Why does my DKIM record say k=rsa when ed25519 is also valid?

The k= tag defaults to "rsa" if omitted (RFC 6376 §3.6.1) — so a record without k= is equivalent to a record with k=rsa. RFC 8463 (2018) added k=ed25519 as a second valid value. The ecosystem reality in 2026: roughly 99% of deployed DKIM keys are still RSA, and roughly 1% are ed25519. RSA is recommended at 2048 bits (the modern floor per RFC 8301 §3); 1024-bit RSA is deprecated and many receivers downgrade verdicts to dkim=policy or reject outright. ed25519 has structural advantages (32-byte keys, 64-byte signatures, faster verification, no key-size choice to get wrong) but is less universally supported — a receiver that does not implement RFC 8463 will produce dkim=neutral or dkim=permerror on an ed25519 signature. The conservative posture: dual-publish both keys (a selector with k=rsa and a selector with k=ed25519) and let the signer pick which one to use per message; over time, more receivers will support ed25519 and you can deprecate the RSA selector.

What is the difference between the s= tag in the key record and the s= tag in the DKIM-Signature header?

They are completely different tags despite sharing the letter. The s= tag in the DKIM-Signature header (RFC 6376 §3.5) is the SELECTOR name — it tells the verifier which DNS name to query (selector._domainkey.<d-value>). The s= tag in the DKIM KEY record (RFC 6376 §3.6.1, at <selector>._domainkey.<domain>) is the SERVICE TYPE list — it names which mail-related services the key is authorized for. The default s= value in the key record is "*" (any service); the most common explicit value is "email" (the only service type defined by RFC 6376 §3.6.1). Verifiers MUST ignore signatures from a key whose s= list does not include the relevant service type, but in practice s= is almost never restrictive because there is only one defined service type. So: header s= = selector name (mandatory, structural); key-record s= = service type (optional, almost always "*" or "email"). Use help_dkim_selectors_explained.php for the selector deep dive and help_dkim_signatures_explained.php for the header tag anatomy.

15. Related guides

• DKIM explained — the protocol pillar — what DKIM is, how the seven verdicts work, the deployment workflow.
• DKIM-Signature header tag anatomy — the SENDER-SIDE companion. Where this page documents the published PUBLIC KEY syntax, that page documents the per-message HEADER the signer emits (v=, a=, c=, d=, s=, h=, bh=, b=, i=, q=, l=, t=, x=, z= tag space).
• DKIM selectors explained — focused selector deep dive: how to name selectors, the per-d= deployment matrix, the _domainkey label convention.
• DKIM canonicalization — the c= tag deep dive (simple vs relaxed for header and body), the seven body-hash mismatch causes.
• DKIM cryptography basics — RSA-2048 vs ed25519 algorithm choice background, RFC 8301 algorithm policy.
• DKIM best practices — the DKIM-TXT-RECORD-BYTE-SYNTAX-AS- PUBLICATION-SUBSTRATE-FOR-THE-OPERATOR- DISCIPLINE-RULESET companion reference. Where THIS page documents the RFC 6376 §3.6.2 byte-level publication grammar for the DKIM KEY record at <selector>._domainkey.<domain> (the v=DKIM1 first-position version tag, the p=<base64> public-key tag, the optional k= / h= / t= / s= / n= tags, the 255-octet character-string chunking rule per RFC 1035 §3.3.14, the multi- string concatenation form for 2048-bit RSA keys), the DKIM-best-practices spoke documents the OPERATOR-DISCIPLINE RULESET that operates on top of this byte-shape substrate across SEVEN canonical operator-publication- discipline dimensions: (1) key-length floor (RSA-2048 minimum per RFC 8301 §3, RSA-1024 deprecated, ed25519 the cryptographic upgrade path), (2) algorithm choice (k=rsa default, k=ed25519 emerging — the spoke documents the per-receiver-population deployment readiness matrix), (3) selector cadence (per-stream selector segmentation, dual-selector overlap during rotation, emergency revocation via empty p=), (4) canonicalization choice (c=relaxed/relaxed default, c=simple/simple for byte-fragile downstream intermediaries — the spoke documents the operational trade-offs the canonicalization-explained spoke catalogues at the byte-shape level), (5) oversign discipline (h=From:From:From:Subject:To:Date oversign pattern that defeats header- replay attacks at the cost of legitimate- forwarder fragility), (6) l=-tag avoidance (the body-length-limit threat surface the DKIM-replay-attacks spoke documents), (7) t=y-tag testing-mode publication discipline (per RFC 6376 §3.6.1 the t=y flag instructs receivers to treat verification failures as non-authoritative — used for the first 24-48-hour publication-verify window). Read the DKIM-best-practices spoke alongside THIS page when the operator asks "what TXT-record byte-shape SHOULD I publish, not just what byte-shape is VALID" — the answer is TWO-LAYERED: THIS page documents the byte-shape contract the record MUST satisfy at the protocol-grammar layer, the best-practices spoke documents the operator-discipline ruleset the byte-shape MUST embody at the publication-policy layer for the receiver-side verdict to be reliably authoritative across the major- receiver population.
• DKIM key rotation — the dual-selector overlap discipline, emergency revocation via empty p=, routine rotation cadence.
• DKIM replay attacks — l= tag threat model and selector-rotation defenses.
• DKIM failures explained — the receiver-side verdict catalogue (dkim=none / neutral / pass / fail / policy / temperror / permerror per RFC 6376 §3.9 + RFC 8601 §2.7.1).
• DKIM alignment with DMARC — how DKIM verdicts feed DMARC alignment per RFC 7489 §3.1.1.
• DKIM troubleshooting — the cross-symptom decision tree consolidating all of the above.
• DKIM for Microsoft 365 — the dual-selector CNAME-delegated deployment guide (operator publishes CNAMEs, Microsoft publishes the actual TXT records).
• DKIM for Google Workspace — the single-selector TXT-publication deployment guide.
• DMARC for Google Workspace — the WORKSPACE-TENANT-DKIM-TXT- PUBLICATION-AS-DMARC-VERDICT-UPSTREAM- INPUT companion to this DKIM TXT-record byte-syntax reference. Where THIS page documents the RFC 6376 §3.6.2 DKIM TXT-record byte-syntax grammar (the v=DKIM1 / k=rsa|ed25519 / p=<base64-public-key> / s=email|* / t=y|s / h=sha256|sha1 tag-list wire format, the 255-octet character-string concatenation rule, the 2048-bit RSA recommendation), the DMARC-for-Workspace spoke documents the per-tenant DMARC publication discipline at four per-tenant-DKIM-TXT- publication-to-DMARC-evaluation- coupling dimensions: (i) per- tenant google._domainkey.<tenant> TXT publication as PRECONDITION-TO- Workspace-DKIM-aligned-pass-evaluation — the canonical Workspace-tenant single-selector DKIM TXT publication THIS page's byte-grammar produces carries the p=<base64-public-key> tag whose receiver-side resolution at DMARC alignment evaluation time IS the load-bearing precondition for the per-tenant DMARC DKIM-aligned-pass verdict — absent the Workspace TXT publication, the per-tenant DMARC verdict registers dkim=fail for every Workspace-outbound message regardless of the Admin Console DKIM signing toggle state; (ii) per- tenant RSA-1024-to-RSA-2048 key-upgrade cadence as Workspace-tenant DMARC rollout milestone — the Workspace-tenant DKIM publication defaults to RSA-1024 at initial Admin Console DKIM authentication enable; the per-tenant upgrade to RSA-2048 (via the Admin Console Generate New Record → 2048-bit key path) updates the TXT record byte-syntax THIS page documents AND is the structural precondition for Workspace-tenant DMARC publication advancement to p=quarantine / p=reject at the bulk-sender deliverability gate; (iii) per-tenant DKIM single- selector publication as Workspace- tenant cumulative-10-DNS-query-budget contributor — the Workspace- tenant DKIM TXT publication THIS page's byte-grammar produces sits at the per- author-domain DNS publication boundary alongside the include:_spf.google.com SPF publication and the _dmarc DMARC publication; the cumulative per-tenant DNS-query budget at receiver-side DMARC alignment evaluation must accommodate all three publications; (iv) per-tenant Workspace DKIM-aligned-pass as Workspace-tenant DMARC enforcement compliance path — the per- message Workspace DKIM signature THIS page documents the byte-grammar of carries d=<tenant-domain> that aligns with the RFC 5322 From: author-domain at relaxed-via-PSL- orgdomain alignment; the Workspace- tenant DMARC publication discipline the DMARC-for-Workspace spoke documents depends on this DKIM- aligned-pass cascade as the canonical Workspace-outbound-mail compliance path through every Phase-1-to-Phase-3 rollout milestone. Read the DMARC- for-Workspace spoke alongside this DKIM TXT-record byte-syntax reference when the Workspace-tenant operator is designing the per-tenant DKIM publication discipline whose downstream per-tenant DMARC verdict lives in the DMARC-for-Workspace spoke's operational deployment reference.
• DMARC for cPanel & Shared Hosting — the CPANEL-ZONE-EDITOR-AND-EXIM_DKIM- CONTROL-PANEL-PUBLICATION companion reference. Where THIS page documents the RFC 6376 §3.6.2 TXT-record encoding rules for the DKIM KEY record at <selector>._domainkey.<domain> in protocol-precise terms (the v=DKIM1 first-position version tag, the p=<base64> public-key tag, the optional k= / h= / t= / s= / n= tags, the 255-octet character-string chunking rule per RFC 1035 §3.3.14 that silently corrupts 2048-bit RSA public keys at many DNS UI providers, the CNAME-vs-TXT deployment trade-off), the DMARC-for-cPanel deployment spoke documents the cPanel-control-panel- MEDIATED PUBLICATION PATH that walks the cPanel-tenant operator from cryptographic-key generation through TXT-record publication via FIVE cPanel- UI-mediated steps that abstract the RFC 6376 §3.6.2 byte-shape THIS page documents into UI-button-press operations: (1) cPanel UI → Email Deliverability → Manage → "Install the Suggested Record" auto-generates the default._domainkey.<tenant-domain> DKIM TXT record under the cPanel- server's local DNS zone (or via the WHM-managed nameserver IF the tenant's domain is delegated to the cPanel-server nameservers) — the auto-generated TXT body is the canonical v=DKIM1; k=rsa; p=<1024-or-2048-bit-RSA-base64> byte-shape THIS page documents; (2) WHM → Exim Configuration Manager → ACL Options → "Enable DKIM Signing" toggles per-domain Exim signing using the published key; (3) WHM → DNS Functions → Edit DNS Zone provides direct TXT-record editing for operators whose domain is delegated externally (in which case the operator must MANUALLY publish the TXT record at the external DNS provider using the byte-shape THIS page documents); (4) cPanel UI → Email Deliverability → Manage → "Repair" runs an automated check-and-fix that regenerates the key AND re-publishes the TXT record (which can cause operator surprise if the external DNS is the authoritative copy); (5) cPanel UI → Zone Editor → "Add Record" → "TXT Record" exposes the raw RFC 6376 §3.6.2 byte-shape THIS page documents as a textarea where the operator can paste a custom TXT body (necessary for 2048-bit keys that exceed the 255-octet single-string limit and require the multi-string ("<chunk1>" "<chunk2>") concatenation form). Read the DMARC-for-cPanel spoke alongside this page when a cPanel-tenant operator asks "how do I publish the DKIM TXT record byte-shape on cPanel" — the answer is TWO-LAYERED: THIS page documents the RFC 6376 §3.6.2 byte-shape the record MUST satisfy, the DMARC-for-cPanel spoke documents the FIVE cPanel-UI-mediated paths that publish a record satisfying that byte- shape under the cPanel-default Exim signing infrastructure.
• DNS propagation — the publisher-side TTL-bounded publish-and-verify cycle for the DKIM TXT record — the DNS-INFRASTRUCTURE-PUBLISHER-SIDE-PROPAGATION- LAYER companion to this DKIM TXT-record byte-syntax reference. Where THIS page documents the RFC 6376 §3.6.2 TXT-record encoding rules for the DKIM KEY record at <selector>._domainkey.<domain> (the v=DKIM1 first-position version tag, the p=<base64> public-key tag, the optional k= / h= / t= / s= / n= tags, the 255-octet character-string chunking rule per RFC 1035 §3.3.14 that silently corrupts 2048-bit RSA public keys at many DNS UI providers, the CNAME-vs- TXT deployment trade-off), the dns_propagation spoke documents the PUBLISHER-SIDE TTL-BOUNDED PUBLISH-AND- VERIFY CYCLE that gates EVERY DKIM-record change between authoring intent and global verifier-side signature-verification realisation. Four structurally- distinct DKIM-propagation operational classes the spoke covers that THIS pillar intentionally elides: (i) DKIM-selector first-publish propagation window — when an operator publishes a new DKIM TXT record at the authoritative DNS server, the record does NOT instantly become visible to every receiver-side verifier worldwide; instead, the record propagates through the caching-resolver hierarchy at a rate gated by the TTL value (typically 300s / 3600s / 86400s — the 86400s case producing a 24-hour propagation tail). Operators who publish a new DKIM selector TXT and immediately send a test message often see verifier-side dkim=none verdicts (the DKIM-Signature header is present but the receiver's resolver cannot yet retrieve the public key) — a diagnostic that resolves only after the TTL-bounded propagation cycle completes; (ii) DKIM-CNAME- delegated propagation chain — the Microsoft 365 / SendGrid / Mailgun / Amazon SES CNAME-delegated deployment models documented on the sibling provider pages have a TWO-LAYER propagation cascade (the operator's CNAME publishes at the operator's authoritative DNS server, and the provider's TXT publishes at the provider's authoritative DNS server). The receiver-side verifier resolves the operator's CNAME, follows the chain to the provider's TXT, and a propagation-window race condition between the two layers can produce intermittent dkim=temperror verdicts during the operator's onboarding window; (iii) DKIM- rotation-window propagation lag — when the dkim_key_rotation spoke's dual-selector overlap discipline is executed, the new-selector-publication step's propagation window OVERLAPS with the old- selector-signing-side switchover, producing a rotation-window asymmetry between the publisher's signing-side intent and the receiver-side verifier's DNS-cached view of which selectors are valid; (iv) DKIM-record-removal propagation tail — when an operator REMOVES a DKIM selector record (planned-retirement or emergency-revocation-via-empty- p= scenarios), receiver-side resolvers continue to consult the cached prior version until the TTL expires, meaning emergency-revocation does NOT take effect globally until the TTL-bounded propagation cycle completes — a critical operational caveat for the emergency-revocation playbook the dkim_key_rotation spoke documents. Required reading once an operator publishes a new DKIM selector and reports "the verifier sees dkim=none even though the TXT record is published" or "different receivers produce different DKIM verdicts for the same test message".
• SPF DNS record syntax — the SPF-side sibling: TXT-record-level syntactic rules for v=spf1.
• include vs ip4 vs a vs mx — the DKIM-DNS-RECORD-BYTE-SYNTAX-AS- CROSS-PROTOCOL-COMPANION-TO-SPF-MECHANISM- AUTHORING-DECISION-VIEW companion to this DKIM-KEY-record byte-syntax pillar. Where THIS page documents the RFC 6376 §3.6.2 TXT-record byte-syntax encoding rules for the DKIM KEY record (per-selector underscore-prefixed sub-owner-name, v=DKIM1; k=rsa; p=<base64>; h=sha256; t=y; s=email; n=... tag grammar, RFC 1035 §3.3.14 255-octet chunking, RFC 8463 ed25519 publication shape, RFC 8301 RSA-2048 floor enforcement), the include-vs-ip4-vs-a-vs-mx spoke documents the COMPANION-PROTOCOL SPF-MECHANISM-AUTHORING-DECISION-VIEW for the parallel-but-distinct envelope-layer DNS-record (v=spf1 TXT record at apex / subdomain owner-name): the four IP-providing SPF mechanisms (include: = recursive sub-record consultation, ip4: = literal IP-CIDR publication, a: = A/AAAA-RR consultation, mx: = MX-RR- then-A/AAAA chain consultation) compared side-by-side at the operator-authoring decision layer with their respective DNS-lookup-cost (0 / 0 / 1 / 1+N), publication-stability profile (volatile / stable / volatile / stable), and per-mechanism RFC 7208 evaluation order. Without the include-vs-ip4-vs-a-vs-mx spoke a reader fluent in this page's DKIM- DNS-record-byte-syntax has no companion reference for the parallel SPF-side DNS-record-mechanism-authoring decision their org's DNS-administrator faces every time a new sender is added to the authentication-and-authorisation envelope-layer record — this link closes that cross-protocol DNS-record-authoring gap by routing the DKIM-side TXT-record operator reading THIS page to the SPF-side TXT-record mechanism-choice reference at the four-IP-providing-mechanism decision-view depth.
• TLS-RPT record syntax — the TRANSPORT-SECURITY-CLUSTER BYTE- SYNTAX SIBLING completing the cross- protocol DNS-record-byte-grammar reference triangle alongside the SPF DNS-syntax sibling above. Where this page documents the RFC 6376 §3.6.2 TXT-record encoding rules for the DKIM KEY record at the per-selector underscore-prefixed sub-owner-name (<selector>._domainkey.<domain> IN TXT "v=DKIM1; k=rsa; p=<base64>; h=sha256; t=y; s=email", the v=DKIM1 first-position version tag, the p=<base64> public-key tag, the optional k= / h= / t= / s= / n= tags, the 255-octet character-string chunking rule per RFC 1035 §3.3.14 that silently corrupts 2048-bit RSA public keys at many DNS UI providers, the CNAME-vs-TXT deployment trade- off, and the per-selector publication model), the TLS-RPT-record-syntax page documents the RFC 8460 §3 TXT-record encoding rules for the TLS-RPT publisher-side record at the cross-protocol-parallel _smtp._tls.<domain> underscore-prefixed sub-owner-name. The three byte-syntax sibling pages (SPF + DKIM + TLS-RPT) form the cross-protocol DNS-record-byte-grammar triangle every operator authoring or debugging DNS-published email- authentication records traverses side-by-side: SPF documents the single-record-at-apex grammar with the v=spf1 first-position version tag; DKIM documents the per-selector-at-_domainkey grammar with the v=DKIM1 first- position version tag; TLS-RPT documents the single-record-at- _smtp._tls grammar with the v=TLSRPTv1 first-position version tag. All three share the underlying DNS-record-grammar conventions (RFC 1035 §3.3.14 TXT encoding, 255-octet chunking, A-label encoding for international domains) even though the token-grammar layers above diverge per their respective protocol RFCs.
• MTA-STS for Microsoft 365 — the M365-TENANT-MTA-STS-DUAL-DNS-RECORD- PUBLICATION-DISCIPLINE-CO-EXISTING-WITH-DKIM TRANSPORT-SECURITY companion to this DKIM DNS-byte-syntax deep dive. Where THIS page documents the RFC 6376 §3.6.2 TXT-record encoding rules for the DKIM KEY record at the per-selector underscore-prefixed sub-owner-name (<selector>._ domainkey.<domain> IN TXT "v=DKIM1; k=rsa; p=<base64>; h=sha256; t=y; s=email" with the v=DKIM1 first-position version tag and the per-selector _domainkey-prefixed owner-name convention), the MTA-STS-for-M365 spoke is the M365-TENANT-SPECIFIC TRANSPORT-LAYER- PUBLICATION REFERENCE documenting how the DKIM-side _domainkey-prefixed TXT-record byte-shape this page proves at the protocol-grammar layer co-exists with the M365-tenant MTA-STS-side _mta-sts-prefixed TXT-record byte-shape at the SAME customer-controlled DNS zone at FOUR structurally-distinct M365-tenant cross-protocol DNS-publication- coordination dimensions: (i) parallel underscore-prefixed owner-name conventions at the M365-tenant customer-DNS zone — the DKIM side publishes at selector1._domainkey.<tenant- domain> AND selector2._ domainkey.<tenant-domain> (via Microsoft-CNAME-delegation from the customer-controlled zone to the <...>.onmicrosoft.com zone), and the MTA-STS side publishes at _mta-sts.<tenant-domain> (typically as a customer-managed TXT record with v=STSv1; id=<timestamp> byte-shape per RFC 8461 §3.1); BOTH share the RFC 1035 §3.3.14 TXT-record byte-grammar and the underscore-prefixed-sub-zone naming convention while diverging in the protocol- specific tag-grammar layer above the TXT-byte-encoding layer; (ii) parallel version-tag-first-position byte-grammar convention — the DKIM-side TXT record opens with v=DKIM1 per RFC 6376 §3.6.1, AND the MTA-STS-side TXT record opens with v=STSv1 per RFC 8461 §3.1, parallel first-position version-tag byte-grammar conventions THIS page documents at the DKIM-syntax-layer materialise verbatim at the MTA-STS-syntax- layer; (iii) parallel publication- time-syntax-error class observed at the M365-tenant operator boundary — the M365-tenant operator publishing a syntactically-invalid DKIM TXT record (a stray character, an unterminated tag, a broken BASE64 chunk) AND a syntactically- invalid MTA-STS TXT record (an unparseable timestamp, a broken version tag, a stray delimiter) BOTH produce structurally- analogous publication-time-syntax-error events the M365-DKIM and M365-MTA-STS operator must guard against at the customer DNS-zone-editor boundary; (iv) parallel per-tenant publication-quality KPI — the per-M365-tenant rua-aggregate- consumed DKIM-publication-quality KPI (the rate of DKIM-aligned-pass results per tenant) AND the per-M365-tenant TLS-RPT- aggregate-consumed MTA-STS-publication- quality KPI (the rate of TLS-handshake- success-vs-failure events per tenant) BOTH surface as load-bearing per-tenant DNS-publication-discipline observability metrics the M365 operator monitors at the customer-DNS-zone-editor publication boundary. Read THIS page when authoring the M365-tenant DKIM-side _domainkey-prefixed TXT-record byte-shape; read the MTA-STS-for-M365 spoke for the M365-tenant-specific MTA-STS-side _mta-sts-prefixed TXT-record byte-shape that completes the M365-tenant cross-protocol DNS-publication-discipline reference pair at the M365-tenant customer-DNS zone.
• DANE for SMTP (RFC 7672) explained — the DNS-PUBLISHED-CRYPTOGRAPHIC-MATERIAL TRANSPORT-SECURITY SIBLING documenting the RFC 7672 DNSSEC-anchored TLSA-based certificate authentication mechanism whose _25._tcp.mx.<domain> IN TLSA record is the TRANSPORT-LAYER PARALLEL to the MESSAGE-SIGNING-LAYER DKIM TXT-record publication model THIS page documents. Where THIS page documents the RFC 6376 §3.6.2 TXT- record encoding rules for the DKIM KEY record at the per-selector underscore-prefixed sub- owner-name (<selector>._domainkey.<domain> IN TXT "v=DKIM1; k=rsa; p=<base64>; h=sha256; t=y; s=email", the v=DKIM1 first-position version tag, the p=<base64> public-key tag, the optional k= / h= / t= / s= / n= tags, the 255-octet character-string chunking rule per RFC 1035 §3.3.14 that silently corrupts 2048-bit RSA public keys at many DNS UI providers), the DANE-for-SMTP spoke is the TRANSPORT-LAYER DNS-PUBLISHED-CRYPTOGRAPHIC- MATERIAL companion documenting the parallel DANE record-syntax at _25._tcp.<mxhost> IN TLSA <usage> <selector> <match-type> <certdata-hex> with its 4-field wire-format grammar (the 0/1/2/3 PKIX-TA / PKIX-EE / DANE-TA / DANE-EE usage codes, the 0/1 cert/SPKI selector codes, the 0/1/2 full/ SHA-256/SHA-512 match-type codes, the hex- encoded cert-or-SPKI data) — the four-axis comparison exposes the structurally-distinct DNS-PUBLISHED-CRYPTO ROLES: (i) DKIM publishes the PUBLIC-KEY of an asymmetric signing keypair at the per- selector underscore-prefixed sub-owner-name (p=<base64-spki>), DANE publishes the FULL-CERT-HASH or SPKI-HASH of a TLS leaf certificate at the per-MX-host port-tagged sub-owner-name (_25._tcp.<mxhost>); both are DNS-anchored cryptographic-primitive publication mechanisms; (ii) DKIM uses TXT records, DANE uses the DEDICATED TLSA RRtype (RR type 52) — TLSA is a non-TXT first-class DNS record type with its own wire-format encoding rather than the chunked-character-string TXT-record encoding DKIM uses, eliminating the 255-octet chunking gotcha DKIM operators encounter; (iii) DKIM bytes are verified at the DKIM-Signature-verification path (per- message), DANE bytes are verified at the STARTTLS-handshake path (per-connection) — DKIM verification happens once per message at the receiver-MTA; DANE verification happens once per SMTP session at the sending-MTA; the per-protocol verification cadence is fundamentally different even though both consume DNS-anchored crypto material; (iv) DKIM rotation publishes a NEW selector record with overlap- window dual-publish, DANE rotation publishes a NEW TLSA record with overlap-window dual-publish — both rotation cadences follow the publish-new + wait-TTL + cutover + retire-old pattern; the operational mechanics translate one-to-one between the two protocols. Read THIS DKIM byte-syntax page WITH the DANE for SMTP page when scoping the DNS-published-crypto- material landscape: this page documents the message-signing-layer DNS-key publication, the DANE page documents the transport-layer DNS-cert publication, and operators publishing DKIM records routinely also publish DANE records on the same DNS zones.
• Reverse DNS / PTR records for mail servers — the REVERSE-ZONE DNS-INFRASTRUCTURE sibling completing the operator DNS-record deployment context this DKIM byte-syntax page sits within. Where this page documents the RFC 6376 §3.6.2 TXT-record syntax for the DKIM key publication at the per-selector <selector>._domainkey.<domain> owner-name (cryptographic-public-key publication for the signing infrastructure), the reverse-dns-ptr spoke documents the RFC 1033 / RFC 1035 PTR-record syntax for the reverse-zone 1.2.3.4.in-addr.arpa IN PTR mail.example.com. publication (IP-to-hostname resolution for the connecting mail server). The two records sit at DIFFERENT DNS classes (DKIM at forward-zone TXT, PTR at reverse-zone PTR) but form the BIDIRECTIONAL DNS-RECORD pair every operator authoring a DKIM signing deployment must publish in concert: the DKIM key on this page authenticates the message bytes the operator's MTA signs; the PTR record on the sibling spoke announces the MTA's IP-to-hostname binding the receiver-side FCrDNS (forward-confirmed reverse DNS) check validates BEFORE the DKIM-signature verification even runs. Gmail / Outlook / Yahoo / iCloud / Apple Mail enforce the FCrDNS-fail gate INSTEAD of and BEFORE the DKIM-verify gate on the connecting IP, so a perfectly-published DKIM key matching every byte-syntax rule documented on this page is OPERATIONALLY USELESS if the sending IP has no matching PTR / FCrDNS pair in the reverse zone — the message will be rejected at the connection layer before the DKIM signature is ever read. The reverse-dns-ptr spoke is the OPERATOR-CHECKLIST COMPANION every DKIM deployment scoped via this byte-syntax page must verify alongside the DKIM key publication.
• Email deliverability — the DKIM-PASS-RATE-AS-INBOX-PLACEMENT- INPUT companion to THIS RFC 6376 §3.6.2 DKIM-key-TXT-record byte-syntax reference. Where THIS page documents the RFC 6376 §3.6.2 + §3.6.1 byte-level rules every DKIM public-key TXT record published at <selector>._domainkey.<d-domain> MUST satisfy (the v=DKIM1 version-tag, the k=rsa / k=ed25519 algorithm-tag, the p=<base64-public-key> tag with its DER-encoded SPKI payload, the p=-empty revocation signal, the 2048-bit public-key split-string concatenation rule, the optional t=y / t=s / h= / g= / s= tags) as the BYTE-SYNTAX CONTRACT, the deliverability spoke documents the receiver-side reputation- scoring feedback loop whose per-source DKIM-pass-rate is the BUSINESS-OUTCOME the publisher-side byte-level publication discipline produces. Four DKIM-DNS-SYNTAX- VS-DELIVERABILITY axes the deliverability spoke documents that THIS page is the byte-syntax foundation for: (1) DKIM- pass-rate-as-reputation-signal — the deliverability spoke's per-source-IP sender-reputation model treats the per-IP DKIM-pass-rate across the receiver's observation window as a primary positive- reputation signal (per Feb 2024 Gmail / Yahoo bulk-sender requirements ≥ 99% SPF + DKIM alignment); the byte-syntax-correct public-key publication this page documents is the foundation that per-IP DKIM-pass- rate depends on; (2) DKIM-permerror- as-deliverability-disqualifier — the deliverability spoke's "rua-stream dkim=permerror across all sources" symptom traces the per-record auth-result back to the registrar-UI public-key truncation root-cause family this page catalogues (Cloudflare auto-split mis-handle / GoDaddy manual 255-byte chunk truncation / BIND ("..." "...") concatenation form mis-handled), attributing the receiver-side reputation degradation to the publisher-side byte-syntax violation; (3) RFC 8301 algorithm-strength compliance gate — the deliverability spoke's "Microsoft / Gmail rejection of 1024-bit RSA" symptom traces the per-message dkim=policy verdict back to the RFC 8301 algorithm- strength deprecation ruling this page's k=rsa-with-≥-2048-bit-payload + k=ed25519 documentation defines the protocol-foundation for; (4) multi-signature-double-signing-as- deliverability-hedge — the deliverability spoke's "single-DKIM-fail- rotates-into-DMARC-fail-rotates-into- reject" deliverability cascade traces the per-message DKIM-signature-count back to this page's multi-selector / multi- signature publication documentation that defines the operational pattern for publishing PRIMARY + SECONDARY public keys such that ANY ONE valid verification produces dkim=pass. Read THIS page when AUTHORING or AUDITING the DKIM-key-TXT-record byte syntax; read the deliverability spoke to UNDERSTAND how the byte-syntax-correct publication this page documents translates into the per-source DKIM-pass-rate the major mailbox providers consume as reputation input.
• MTA-STS policy file syntax — the MTA-STS-HTTPS-POLICY-FILE-BYTE- GRAMMAR-AS-LOAD-BEARING-SIBLING- TRANSPORT-LAYER-PUBLICATION-DISCIPLINE- TO-DKIM-MESSAGE-LAYER-DNS-TXT-RECORD- BYTE-GRAMMAR companion to THIS DKIM DNS-TXT-record byte-syntax reference. Where THIS page documents the RFC 6376 §3.6.2 DKIM-key TXT-record byte syntax (the <selector>._domainkey.<d-tag> FQDN, the v=DKIM1; k=rsa; p=<base64-public-key> tag-list grammar, the 255-octet character-string-fragmentation discipline, the p= revocation-by-empty- value primitive), the MTA-STS-policy- syntax spoke is the TRANSPORT-LAYER SIBLING-PUBLICATION-DISCIPLINE REFERENCE documenting the parallel RFC 8461 §3.1 + §3.2 publisher-side publication discipline (the _mta-sts.<domain> TXT-record signalling v=STSv1; id=<policy-id> and the https://mta-sts.<domain>/.well-known/mta-sts.txt HTTPS policy-file with version: STSv1 / mode: / mx: / max_age: key-value pairs) whose every per-publisher publication- discipline primitive is the TRANSPORT-LAYER sibling to the DKIM MESSAGE-LAYER publication-discipline primitives THIS page documents at FOUR cross-layer per-publisher-publication- discipline-coupling dimensions: (i) per-publisher per-name FQDN publication-location: DKIM's <selector>._domainkey.<d-tag> vs MTA-STS's _mta-sts.<domain> + mta-sts.<domain> — both publication disciplines locate the per-publisher authentication evidence at a publisher-controlled FQDN that the receiver-side verifier deterministically queries (DNS-TXT-record lookup vs DNS-TXT- record-then-HTTPS-fetch), and the MTA-STS-policy-syntax spoke documents the publisher-side _mta-sts + policy-host publication discipline whose per-publisher FQDN-publication contract is the transport-layer sibling to the per-DKIM-selector FQDN-publication contract THIS page documents; (ii) per-publisher per-record byte-grammar: DKIM's semicolon-delimited tag-list (v=DKIM1; k=rsa; p=...) vs MTA-STS's newline-delimited key:value pairs (version: STSv1\nmode: enforce\nmx: ...\nmax_age: ...) — both byte-grammars publish per- publisher per-record-instance operational state through a structured key-value byte format the receiver-side parser must deterministically decode, and the MTA-STS-policy-syntax spoke documents the per-key per-value byte-grammar (including the per-MX-pattern wildcarding rules, the per-mode tri-state grammar, the per-max_age numeric range) whose every byte-shape parallel is the transport-layer sibling to the DKIM tag-list byte-grammar THIS page documents; (iii) per-publisher per-record cryptographic-or-MX-pattern attestation primitive: DKIM's p=<base64-public-key> cryptographic-anchor vs MTA-STS's mx: <pattern-list> MX-pattern-attestation — both publication disciplines commit a per-publisher trust- anchor / attestation primitive to publication (DKIM's per-selector public-key cryptographic anchor vs MTA-STS's per-policy-id MX-pattern policy- host attestation), and the MTA-STS-policy-syntax spoke documents the per-policy-id per-MX-pattern attestation discipline whose every receiver- side enforcement decision derives from the published byte-grammar — the transport-layer attestation sibling to the DKIM message-layer cryptographic-anchor publication THIS page documents; (iv) per-publisher per-record revocation / rotation discipline: DKIM's p=-empty-value per-selector revocation primitive vs MTA-STS's mode: none / id:-bump per-policy rotation primitive — both publication disciplines document a per-publisher revocation- and-rotation contract receivers observe deterministically (DKIM per-selector retirement via empty-p= publication vs MTA-STS per-policy-id rollover via _mta-sts id-bump and mode: none downgrade publication), and the MTA-STS- policy-syntax spoke documents the per-policy-id rotation cadence and per-mode downgrade-publication discipline whose every per-policy rotation-event publication is the transport-layer sibling to the per-DKIM-selector rotation-event publication THIS page documents. Read the MTA-STS-policy-syntax spoke alongside this DKIM DNS- TXT-record byte-syntax reference when designing a publisher-side cross-layer authentication- publication discipline — the spoke documents the transport-layer publication primitives whose per- publisher publication-discipline parallel is the cross-layer sibling to the message-layer DKIM publication discipline THIS page establishes.
• DMARC policy rollout — the DKIM-DNS-PUBLICATION-SYNTAX-AS- LOAD-BEARING-PHASE-1-PUBLICATION- BASELINE-PREREQUISITE companion to this DKIM TXT-record byte-syntax reference. Where THIS page documents the RFC 6376 §3.6.2 DKIM-KEY-TXT-record byte-level publication grammar at <selector>._domainkey.<domain> (the v=DKIM1 first-position version tag, the p=<base64> public-key tag, the optional k= / h= / t= / s= / n= tags, the 255-octet character-string chunking rule per RFC 1035 §3.3.14, the multi- string concatenation form for 2048-bit RSA keys), the DMARC-policy-rollout spoke documents the per-publisher five-phase deployment workflow whose every per-pct=-ramp-stage advancement and per-phase cutover gate depends on the DKIM-KEY-TXT-record byte-syntax- publication-discipline floor at FOUR per-DKIM-byte-shape-publication- discipline-to-DMARC-policy-rollout coupling dimensions: (i) Phase-1 DKIM-KEY-TXT-record-publication-baseline as load-bearing receiver-side dkim=pass-verdict-availability prerequisite — the Phase-1 publication-baseline floor REQUIRES the RFC 6376 §3.6.2 byte-shape THIS page documents (correct v=DKIM1 first-position tag, well-formed p=<base64> public-key tag, valid 255-octet character-string chunking per RFC 1035 §3.3.14, correct multi-string concatenation form for 2048-bit RSA keys) for the receiver-side dkim=pass verdict to be emitted in the FIRST place — any byte-shape defect THIS page enumerates (truncated chunking, malformed base64, missing v=DKIM1 prefix, stale revoked-key p= publication) collapses the entire Phase-1 publication-baseline to dkim=permerror / dkim=temperror / dkim=fail and blocks every downstream phase from advancing; (ii) Phase-2 p=none baseline- observability DKIM-aligned-pass-rate- floor enforcement as per-source-IP per-receiver per-day rua aggregate-XML row/policy_evaluated/dkim=pass row-count input — the Phase-2 observability baseline REQUIRES the DKIM-KEY-TXT-record publication-discipline floor THIS page documents to be in place across every per-publisher per-selector deployment before advancing into Phase-3 — the per-source-IP per-receiver per-day rua aggregate-XML row/policy_evaluated/dkim=pass row-count distribution is the gate- keeping observability surface that confirms the per-publisher per-selector DKIM-byte-shape-publication-discipline is reliably translating into receiver- side dkim=pass verdicts at the floor required for Phase-3 advancement; (iii) Phase-3 pct=-ramp per-stage advancement gate-keeping DKIM-aligned- pass-rate-floor enforcement as per- ramp-stage-cutover-confidence input — every Phase-3 per-stage advancement (pct=10 → pct=25 → pct=50 → pct=75 → pct=100) REQUIRES the DKIM-aligned-pass- rate floor to remain stable across the per-publisher per-selector deployment; any per-stage DKIM-aligned-pass-rate regression caused by a byte-shape publication-discipline drift THIS page enumerates (selector retirement-without- revocation, key-rotation-without- publication, chunking-truncation regression) must be remediated BEFORE advancing the per-stage cutover; (iv) Phase-4-p=quarantine and Phase-5-p=reject cutover-confidence floor as per-receiver per-source-IP DKIM-aligned-pass-rate-coverage- completeness prerequisite — the terminal-state Phase-4-p=quarantine and Phase-5-p=reject cutovers REQUIRE the DKIM-KEY-TXT-record-publication- discipline floor THIS page documents to be in place across every per-publisher per-selector per-receiver deployment with zero outstanding byte-shape publication-discipline defects — the terminal-state cutover is the point where any remaining DKIM-byte-shape- publication-discipline drift translates directly into legitimate-mail-bounce- rate uplift, so the per-receiver per- source-IP DKIM-aligned-pass-rate- coverage-completeness floor must be empirically confirmed via the rua aggregate-XML stream BEFORE the terminal-state cutover. Read the DMARC-policy-rollout spoke alongside THIS page when the publisher asks "how does the DKIM-KEY-TXT-record byte- syntax-publication-discipline floor translate into the per-publisher five- phase DMARC-policy-rollout cadence" — the answer is FOUR-LAYERED: THIS page documents the RFC 6376 §3.6.2 DKIM-KEY-TXT-record byte-syntax- publication-discipline floor, the DMARC-policy-rollout spoke documents the per-publisher five-phase deployment workflow whose every per-pct=-ramp-stage advancement and per-phase cutover gate consumes the DKIM-aligned-pass-rate floor THIS page's byte-syntax-publication-discipline underpins.
• SPF PermError vs TempError — the LOAD-BEARING per-publisher per-domain SPF-DNS-RESOLVER-FAILURE- MODE-PEER-OF-DKIM-DNS-RESOLVER- FAILURE-MODE companion documenting the SPF-side spf=permerror / spf=temperror error-family whose receiver-side per-publisher per-domain consequences PARALLEL the DKIM-side dkim=permerror (RFC 6376 §6.1.2 syntactically-invalid DKIM-key-record TXT publication, the published-key-deleted state, the wrong-record-type publication state) / dkim=temperror (DNS resolver-side transient failure looking up the per-selector TXT) error family this page's DKIM-key-record byte-syntax-publication-discipline directly governs. SPF PermError is most commonly caused by exceeding the RFC 7208 §4.6.4 ten-DNS-lookup limit (chained include: records compounding the resolver lookup count), the second-most by syntactically- invalid SPF record publication or non-existent include: domain references; SPF TempError is most commonly caused by per-publisher per-domain authoritative-DNS-server unreachability or recursive-resolver transient failure. The receiver-side treatment under RFC 7208 §8.5 differs sharply between the two: PermError is a permanent publisher-side configuration error producing deterministic spf=permerror verdicts every receiver, while TempError is a transient observation producing per-receiver per-resolver- instance variable spf=temperror verdicts. Where THIS page documents the per-publisher per-selector RFC 6376 §3.6 DKIM-KEY-RECORD TXT-RR BYTE-SYNTAX-PUBLICATION DISCIPLINE (v=DKIM1 / k=rsa / p=BASE64-public-key / s=email / t=y / h=sha256 tag-list byte-grammar), the SPF PermError vs TempError spoke documents the PARALLEL per-publisher per-domain RFC 7208 SPF-RECORD-PUBLICATION- FAILURE-MODE-CATALOGUE — the four SPF-side observable per-record publication / lookup-limit / resolver- failure error states whose evaluation and receiver-side treatment PARALLEL the four DKIM-side observable per-selector publication / parsing / resolver-failure error states this page's byte-syntax-publication- discipline directly governs. Read THIS page when AUTHORING the per- publisher per-selector DKIM-key-record TXT-RR byte-syntax publication; read the PermError vs TempError spoke when DIAGNOSING the per-publisher per- domain SPF-side permerror vs temperror verdict that PARALLELS the DKIM-side permerror / temperror verdict THIS page's byte-syntax discipline can produce when the published DKIM key-record TXT-RR fails byte-syntax validation or the per-selector authoritative-DNS-server transient lookup fails.
• DMARC reporting pipeline — the PER-SELECTOR-DKIM-TXT- RECORD-BYTE-SYNTAX-DOWNSTREAM-CONSUMER companion to this DKIM DNS-record byte- syntax reference. Where THIS page documents the per-publisher per-selector DKIM key-record TXT-RR byte-grammar publication mechanics (the v=DKIM1 / k= / p= / h= / s= / t= per-tag byte- grammar per RFC 6376 §3.6.1, the per- TXT-string 255-octet character-string fragmentation discipline, the per-tag whitespace-tolerance rules) that the per-receiver-side DKIM verifier consumes at message-acceptance time to emit the per-message dkim=pass / dkim=fail / dkim=permerror / dkim=temperror verdict, the DMARC-reporting-pipeline spoke is the PUBLISHER-SIDE-AGGREGATE- AND-FORENSIC-REPORT-DOWNSTREAM-CONSUMER documenting how the per-message DKIM- verdict propagates THROUGH the per- publisher per-domain RUA + RUF reporting pipeline at FOUR per-pipeline- stage per-message DKIM-verdict propagation dimensions: (i) per- message dkim=permerror aggregate-report attribution per RFC 7489 §7.2 — the per-receiver per-day per- publisher per-day per-message <auth_results><dkim> <result>permerror</result> row emission INTO the per-publisher per-domain RUA aggregate-report XML when the per-receiver-side DKIM verifier encounters a per-selector DKIM TXT-RR whose byte-grammar this page's per-tag publication-discipline prevents from passing receiver-side validation; (ii) per-message dkim=permerror forensic-report ARF per-failure-message diagnostic-block emission per RFC 6591 — the per-receiver per-aligned-fail per- message DKIM-permerror DIAGNOSTIC- BLOCK emission INTO the per-publisher per-domain RUF forensic-report stream (per-failure-message per-selector TXT-RR fetch diagnostic, per-failure- message per-selector TXT-RR byte- grammar parse-error diagnostic, per- failure-message per-selector public- key-base64-decode diagnostic) the per- publisher per-domain DMARC-reporting- pipeline spoke surfaces at the per- publisher per-domain operator diagnostic boundary; (iii) per- publisher per-domain per-selector per- day per-receiver per-day DKIM- permerror-rate-floor regression time-series — the per- publisher per-domain per-selector per-day per-receiver per-day DKIM- permerror-rate-floor LONGITUDINAL time-series the per-publisher per- domain DMARC-reporting-pipeline spoke materializes at the per-publisher per- domain operator dashboard, gating per- selector DKIM-key-record byte-grammar regression detection AT MESSAGE-FLIGHT- TIME rather than at per-selector publish-and-verify-window-close-time; and (iv) per-publisher per- domain per-selector DKIM-permerror- rate-floor spike alerting cadence — the per-publisher per-domain per- selector per-day per-publisher per- domain per-selector DKIM-permerror- rate-floor SPIKE-ALERTING cadence the per-publisher per-domain DMARC- reporting-pipeline spoke EMITS at the per-publisher per-domain operator alerting boundary, so a per-selector DKIM-key-record byte-grammar regression (e.g. an inadvertent whitespace insertion into the base64 p= public-key bytes, a missing per- TXT-string 255-octet fragment- concatenation) PRODUCES a per- publisher per-domain operator-visible alert WITHIN the per-receiver per-day per-publisher per-day RUA-aggregate- report cycle rather than waiting for a per-selector publish-and-verify- cycle audit. Pair this DKIM DNS-record byte-syntax reference with the DMARC- reporting-pipeline spoke when DIAGNOSING per-publisher per-domain per-day per-receiver per-day per- selector DKIM-permerror-rate-floor spikes — the DMARC-reporting-pipeline spoke is the PER-AGGREGATE-AND- FORENSIC-REPORT-DOWNSTREAM-CONSUMER REFERENCE whose per-message DKIM- permerror per-receiver per-day per- publisher per-day per-message DKIM- permerror-rate-floor time-series the per-publisher per-domain operator structurally consumes as the observable-output proxy for the per- selector DKIM-key-record TXT-RR byte- grammar compliance THIS page's per- tag byte-grammar publication- discipline materially produces at the per-publisher per-selector DKIM publication boundary.
• MTA-STS explained — the PEER-DNS-PUBLICATION-DISCIPLINE- AT-PARALLEL-UNDERSCORED-ATTRIBUTE-LEAF companion to this DKIM DNS-record-syntax reference. Where THIS page documents the per-publisher per-selector DKIM TXT-RR publication discipline at the <selector>._domainkey.<d> underscored-attribute-leaf (the RFC 6376 §3.6.1 tag-list byte-grammar with the v=DKIM1; k=rsa; p=< base64-public-key> per-selector per-publisher key-publication-byte- grammar contract), the MTA-STS-explained pillar documents the per-publisher per- policy-domain transport-layer policy- publication discipline at the _mta-sts.<d> underscored-attribute-leaf at four cross-protocol-layer DNS-publication coupling dimensions: (i) parallel per-publisher per-domain underscored- attribute-leaf TXT-RR publication substrate — DKIM publishes per- selector at <s>._domainkey. <d> while MTA-STS publishes per-policy-domain at _mta-sts.< d>; both leaves coexist in the same per-publisher per-domain authoritative DNS zone consuming the same RFC 1034/1035 byte-grammar publication primitives; (ii) parallel per-publisher rotation / version pointer discipline — DKIM uses per-selector rotation (publish new selector, dual-overlap window, revoke old via empty p=), while MTA-STS uses per-policy id=<version> pointer-bump (publish new policy file, bump TXT-RR id=, sending MTAs refetch after max_age cache window); (iii) parallel per-publisher publication-discipline upstream of per-message authentication- verdict emission — DKIM TXT-RR publication discipline is upstream prerequisite for per-message dkim=pass at receiver-side verification, while MTA-STS TXT-RR + policy-file publication discipline is upstream prerequisite for sending-MTA- side mode: enforce TLS- delivery commitment; per-publisher publication-byte-grammar correctness on either leaf is load-bearing for the downstream per-message verdict emission; and (iv) parallel per-publisher zone-co-edit-discipline at simultaneous DKIM-selector + MTA-STS-policy publication — the same per- publisher per-domain authoritative DNS zone administration team manages both per-selector DKIM TXT-RR publishes and per-policy MTA-STS TXT-RR + HTTPS- policy-file publishes; per-zone-edit coordination discipline ensures the per-publisher per-domain cryptographic- signing-discipline and transport-layer- TLS-enforcement-discipline land coherently at the same per-publisher publication-rollout boundary. Read the MTA-STS-explained pillar alongside this DKIM DNS-record-syntax reference when co-publishing per-publisher per-domain application-layer cryptographic-signing and transport-layer-encryption publication discipline on the same authoritative DNS zone.
• DMARC deployment checklist — the PRE-FLIGHT-CHECKLIST-ITEM-DKIM-RECORD- PUBLISHED-AND-VERIFIED companion to this DKIM DNS-syntax reference. Where THIS page documents the per-publisher per-selector DKIM TXT-record byte-grammar (RFC 6376 §3.6.1 tag-list grammar: `v=DKIM1; k=rsa; p=<base64-DER-encoded-public-key>` + optional `t=`, `s=`, `h=`, `g=`, `n=` tags; RFC 6376 §3.6.2.1 multi-string concatenation discipline for 4096-bit keys; CNAME-delegation pattern for ESP/transactional-vendor per-selector publication), the DMARC-deployment-checklist spoke is the per-publisher per-domain DMARC deployment process-reference whose pre-flight checklist-items the per-selector DKIM-record byte-grammar reference THIS page documents structurally enables. FOUR per-publisher per- domain deployment-checklist-vs-DKIM-DNS-syntax coupling dimensions: (i) per-publisher per-domain Pre- flight checklist-item: per-selector DKIM TXT-record byte-grammar conformance verified via `dig +short TXT <selector>._domainkey.<d>` as load-bearing per-publisher per-domain DMARC ramp-readiness gate — the deployment-checklist spoke documents the per-publisher per-selector pre-flight verification step (per-publisher per- selector DKIM-record publication-and- verification at every per-publisher per- selector TXT-record publication point) the per-publisher per-domain DMARC deployment operator MUST execute BEFORE advancing past `p=none` to `p=quarantine`; the per-publisher per-selector byte-grammar reference THIS page documents is the LITERAL pre-flight verification reference the deployment- checklist operator consults at the per- publisher per-selector verification step; (ii) per-publisher per-domain Pre- flight checklist-item: per-selector DKIM RSA-2048-bit key-strength floor verified per RFC 8301 as load-bearing per-publisher per- domain DMARC ramp-readiness gate — the deployment-checklist spoke documents the per-publisher per-selector pre-flight verification step that the per-publisher per-selector DKIM-record `p=`-tag base64-DER- encoded public-key field meets the RFC 8301 RSA-2048-bit minimum (verifiable via `openssl rsa -pubin -in <extracted-p-tag> -text -noout` showing 2048-bit modulus); the per-selector byte-grammar reference THIS page documents is the LITERAL pre-flight verification reference the deployment- checklist operator consults at the per- publisher per-selector key-strength-floor verification step; (iii) per-publisher per-domain Ramp-phase checklist-item: per-publisher per-selector dual-selector overlap-window publication-discipline cross-checked during `p=quarantine pct=10/25/50 → p=reject pct=100` ramp advancement as load-bearing per-publisher per-domain DMARC ramp- progression gate — the deployment- checklist spoke documents the per-publisher per-selector dual-selector overlap-window publication discipline (concurrent publication of `selector1._domainkey` + `selector2._domainkey` across the per- receiver per-resolver-cache eviction window) the per-publisher per-domain DMARC deployment operator MUST audit DURING per- phase ramp advancement; the per-selector byte-grammar reference THIS page documents is the LITERAL per-selector publication- discipline reference the deployment- checklist operator consults at the per- phase ramp-advancement audit step; (iv) per-publisher per-domain Post-flight checklist-item: per-publisher per-domain per-receiver `dkim=pass + aligned=true` evidence-floor cross-checked in the per-receiver aggregate-report RUA stream as load-bearing per-publisher per- domain DMARC-aligned-pass-rate-floor empirical-observability primitive — the deployment-checklist spoke documents the per-publisher per-domain per-receiver post-flight `dkim=pass + aligned=true` evidence-floor (typically 95%+ per-receiver per-publisher per-domain per-day aligned- DKIM-pass rate) the per-publisher per- domain DMARC deployment operator MUST verify in the per-receiver RUA evidence stream BEFORE advancing to terminal `p=reject pct=100`; the per-selector byte-grammar reference THIS page documents is the LITERAL per-selector publication primitive the per- receiver `dkim=pass + aligned=true` evidence rate empirically observes. Read the DMARC-deployment-checklist spoke alongside this DKIM DNS-syntax reference when AUTHORING the per-publisher per-domain DMARC deployment pre-flight checklist whose per-selector DKIM-record byte-grammar conformance is the load-bearing pre-flight gate, when PLANNING the per-publisher per- domain DMARC ramp-progression calendar with explicit per-selector dual-selector overlap- window publication-discipline checklist items, or when VALIDATING the per-publisher per-domain DMARC terminal-state `p=reject pct=100` ramp-readiness against the post-flight per-receiver `dkim=pass + aligned=true` evidence-floor checklist gate.
• RFC 6376 §3.6.2 — DKIM key TXT record format — the normative specification.
• RFC 6376 §3.6.1 — DKIM key record tag list — the normative tag reference.
• RFC 8463 — Ed25519 signature algorithm for DKIM — the k=ed25519 specification.
• RFC 8301 — Cryptographic algorithm update for DKIM — the 2048-bit RSA minimum and rsa-sha1 deprecation.
• RFC 1035 §3.3.14 — TXT character-string format — the 255-octet character-string limit.
• CAA records explained — the companion DNS-publication-workflow reference. Where THIS page documents the RFC 6376 §3.6.2 TXT-record byte-syntax for the DKIM KEY record at <selector>._domainkey.<domain>, the CAA reference documents the RFC 8659 CAA-resource-record byte-syntax at the domain apex. Both records share the same DNS publication workflow (zone edit + TTL discipline + DNSSEC signing) and the same operator-side audit surface (dig / host / the Domain Security Checker DNS-layer validation pipeline). Operators publishing their first DKIM TXT record at a fresh _domainkey sub-zone almost always also need to audit the parallel CAA records at the domain apex — both are DNS-published cryptographic-policy records the same zone-administration team owns, and both warrant the same monitoring discipline against silent drift when the zone owner changes signing infrastructure or Certificate Authority.
• Email Header Analyzer — paste a failing message and surface every verifier-side error referenced on this page.
• Domain Security Checker — validate every selector your domain publishes from multiple resolvers.
• SPF 10-DNS-lookup limit (RFC 7208 §4.6.4) — the PER-ZONE-CO-EDIT-DISCIPLINE-AT-PER- PUBLISHER-DKIM-SELECTOR-PUBLICATION companion to this DKIM DNS-syntax byte- grammar reference. Where THIS page documents the RFC 6376 §3.6.2 per- publisher per-selector public-key TXT- record byte-grammar (the <selector>._domainkey.< domain> FQDN format, the v=DKIM1 prefix, the p=<base64> public-key payload, the k= / h= / t= / s= tags, TXT-RR chunking past the 255-octet character-string limit, key revocation via empty p=, and the seven most common syntax mistakes), the SPF-lookup- limit spoke is the per-publisher per- domain SPF-leg cumulative-mechanism lookup-budget ARITHMETIC REFERENCE the same zone-administration team must keep under the RFC 7208 §4.6.4 10-lookup ceiling whenever they edit the DKIM-leg <selector>._domainkey.< domain> records THIS page documents. The DKIM-DNS-SYNTAX-VS-SPF- LOOKUP-LIMIT cross-reference establishes the per-zone co-edit discipline that every per-publisher per-domain selector- rotation, key-revocation, or new-selector- publication event structurally requires: (i) per-zone co-edit risk window — the zone-administration team editing the DKIM-leg <selector>._domainkey sub-zone TXT records also owns the SPF- leg apex TXT record, and any SPF-leg edit that crosses the 10-lookup ceiling during the SAME zone-edit session produces an immediate per-publisher per-message spf=permerror cascade on EVERY DMARC-honouring receiver; (ii) per-selector rotation co-edit prerequisite — a per-publisher per-selector rotation (publish new selector2._domainkey + retire selector1._domainkey after overlap window) must NOT be sequenced concurrently with an SPF-leg include: append that pushes the cumulative cost over 10 lookups, because the simultaneous SPF-leg permerror would mask the rotation's per-receiver per-message DKIM- signature-verification rollout in the aggregate-report timeline; (iii) per-publisher SPF-baseline verification post-DKIM-edit — every per-publisher per-selector publication event must be closed with a dig +short TXT <domain> + per-include-cost arithmetic verification confirming the SPF-leg cumulative lookup count is still under 10 before the operator considers the DKIM- leg edit operationally complete. Read THIS page when AUTHORING per-publisher per-selector DKIM public-key TXT records; read the SPF-lookup-limit spoke when CO- EDITING the per-publisher per-domain apex-TXT SPF record on the SAME zone- administration session, or when SEQUENCING a per-publisher per-selector rotation event around an SPF-leg include: append the same zone-edit operator is composing.
• MTA-STS vs DANE — the PER-PUBLISHER-PER-DOMAIN- TRANSPORT-LAYER-AUTHENTICATION- PUBLICATION-DISCIPLINE-CHOICE-AS-LOAD- BEARING-PEER-TRANSPORT-LAYER-DNS- PUBLICATION-PRIMITIVE-COMPANION companion to this DKIM-DNS-syntax reference. Where THIS page documents the per-publisher per-selector DKIM TXT-RR byte-grammar publication discipline at the application layer (the v=DKIM1; k=rsa; p=<base64-public-key> TXT-RR tag-list grammar, the <selector>._domainkey.<domain> per-selector DNS-leaf publication pattern, the per-record TXT-RR 255-octet chunking discipline, and the empty- p= revocation-publication pattern), the MTA-STS-vs-DANE spoke is the peer per-publisher per-domain transport-layer authentication-publication discipline choice whose two-protocol per- publisher per-domain DNS-publication-leaf cadence (MTA-STS _mta-sts.<domain> TXT- RR + HTTPS-served policy-file two-leaf publication vs DANE _25._tcp.<mx-host> TLSA-RR per-MX-host single-leaf publication) pairs operationally with the per-publisher per-selector DKIM TXT-RR publication discipline THIS page documents at FOUR per-DNS-publication-primitive coupling dimensions: (i) per- publisher per-domain peer DNS-RR-byte- grammar-publication-discipline parallelism — the per- publisher per-selector DKIM v=DKIM1; k=rsa; p=... TXT- RR byte-grammar publication discipline THIS page documents, the per-publisher per-domain MTA-STS v=STSv1; id=<policy-version> TXT-RR pointer-record byte-grammar publication discipline the MTA-STS-vs- DANE spoke documents the choice rationale for, and the per-publisher per-mx-host DANE TLSA-RR 3 1 1 <sha256-of-spki> DNSSEC-anchored byte-grammar publication discipline the MTA-STS-vs-DANE spoke documents the alternative choice rationale for are the three per-publisher per-domain DNS-RR publication-discipline primitives the per-publisher per-domain complete authentication-and-encryption publication-discipline operator composes in coordination; (ii) per-publisher per-domain cryptographic-trust-anchor-publication- layer choice parallelism — per- selector-DKIM-TXT-anchored vs Web-PKI- anchored vs DNSSEC-anchored cryptographic-trust-root choices — the per-publisher per-selector DKIM TXT-RR public-key publication THIS page documents at the per-selector cryptographic-trust-anchor publication layer (the per-message body-and-header cryptographic-authenticity binding's per-selector trust-root) pairs operationally with the per-publisher per-domain MTA-STS Web-PKI-anchored certificate-validation trust-root choice (the per-receiver per-session per-MX hop transport-encryption peer- authentication's CA-chain-of-trust-root) and the per-publisher per-domain DANE DNSSEC-anchored TLSA-RR trust-root choice (the per-receiver per-session per-MX hop transport-encryption peer- authentication's DNSSEC-chain-of-trust- root) the MTA-STS-vs-DANE spoke documents the three per-cryptographic- trust-anchor-publication-layer choice rationales of; (iii) per- publisher per-domain DNS-publication- discipline complexity-vs-trust-root- strength trade-off parallelism — the per-publisher per-selector DKIM TXT-RR byte-grammar publication discipline complexity THIS page documents (per-record 255-octet chunking, per- selector overlap-window cadence, empty- p= revocation publication) is the per-publisher per-domain application-layer cryptographic- publication discipline whose per- publication-rule complexity-vs-cryptographic- rigor trade-off mirrors the per-publisher per-domain transport-layer MTA-STS-vs- DANE choice the MTA-STS-vs-DANE spoke documents (MTA-STS Web-PKI-anchored two-leaf publication with simpler per-publisher per-domain HTTPS-and-DNS operational discipline vs DANE DNSSEC- anchored single-leaf publication with stronger cryptographic trust-root but per-publisher per-domain DNSSEC operational discipline complexity); (iv) per-publisher per-domain cross-layer DNS-publication-discipline coordination as load-bearing per- publisher per-domain operator-side complete authentication-and-encryption publication-posture rhythm — the per-publisher per-domain operator-side DNS-publication-discipline coordination rhythm that composes the per-publisher per-selector DKIM TXT-RR publication discipline THIS page documents with the per-publisher per- domain MTA-STS-or-DANE transport-layer authentication-publication-discipline choice the MTA-STS-vs-DANE spoke documents is the per-publisher per- domain complete authentication-and- encryption publication-posture rhythm every per-publisher per-domain DMARC- deployment programme requires for complete cross-layer authentication- and-encryption coverage. Read THIS page when AUTHORING per-publisher per- selector DKIM public-key TXT records; read the MTA-STS-vs-DANE spoke when CHOOSING the per-publisher per-domain peer transport-layer authentication- publication-discipline approach (Web- PKI-anchored MTA-STS or DNSSEC-anchored DANE) whose per-publisher per-domain DNS-publication-leaf cadence pairs operationally with the per-publisher per-selector DKIM TXT-RR publication discipline THIS page documents at the application layer.
• SPF for Google Workspace — the PER-PUBLISHER-PER-TENANT-PER- GOOGLE-WORKSPACE-OPERATOR-SPF-PUBLICATION- DISCIPLINE-AS-LOAD-BEARING-PEER-PROTOCOL- LAYER-DNS-PUBLICATION-DISCIPLINE companion to this DKIM-DNS-syntax reference. Where THIS page documents the per-publisher per- selector DKIM TXT-RR byte-grammar publication discipline at the application layer (the v=DKIM1; k=rsa; p=<base64-public-key> TXT-RR tag-list grammar, the <selector>._domainkey.<domain> per-selector DNS-leaf publication pattern, the per-record TXT-RR 255-octet chunking discipline, and the empty-p= revocation-publication pattern), the SPF- for-Google-Workspace spoke is the peer per- publisher per-tenant per-operator SPF publication discipline whose per-Google- Workspace-tenant SPF publication discipline (canonical v=spf1 include:_spf.google.com ~all SPF-record template, per-tenant supplemental third-party-ESP include-statement composition, per-tenant cumulative 10- lookup-limit budget arithmetic, per-tenant zone-editor commit cadence) pairs operationally with the per-publisher per- selector DKIM TXT-RR publication discipline THIS page documents at FOUR per-protocol- pillar DNS-publication coupling dimensions: (i) peer per-publisher per-domain DNS-RR-byte-grammar-publication-discipline parallelism — the per- publisher per-selector DKIM TXT-RR byte- grammar publication discipline THIS page documents at the per-selector <selector>._domainkey.<domain> DNS-leaf layer pairs operationally with the per-publisher per-domain SPF TXT-RR byte- grammar publication discipline the SPF-for- Google-Workspace spoke documents at the per-domain v=spf1 include:_spf.google.com ~all DNS-leaf layer — both are per-publisher per- domain DNS-TXT-RR byte-grammar publication disciplines whose per-publication-step zone-edit coordination is the load-bearing per-publisher per-domain cross-protocol- pillar DNS-publication-discipline composition rhythm every per-publisher per-domain DMARC- deployment programme requires; (ii) per-publisher per-tenant per- Google-Workspace-operator canonical-include- statement-discipline-as-trust-anchor- delegation parallelism — the per-publisher per-selector DKIM TXT-RR public-key publication THIS page documents at the per-selector cryptographic-trust- anchor publication layer (per-selector operator-side public-key publication as the per-publisher per-selector cryptographic- trust-anchor primitive) pairs operationally with the per-publisher per-tenant per- Google-Workspace-operator canonical include:_spf.google.com include-statement-discipline the SPF-for- Google-Workspace spoke documents the per- tenant per-operator publication-rationale of (per-Google-Workspace-tenant operator-side _spf.google.com delegation as the per-publisher per-tenant per-operator SPF-authorisation-trust-anchor primitive) — both are per-publisher per-tenant per- operator DNS-leaf trust-anchor publication primitives the per-publisher per-tenant per- operator cross-protocol-pillar publication- discipline operator composes in coordination; (iii) per-publisher per-tenant per-operator cross-protocol- pillar DNS-publication-cadence coordination — the per- publisher per-selector DKIM TXT-RR publication discipline THIS page documents at the per-selector <selector>._domainkey.<domain> DNS-leaf layer pairs operationally with the per-publisher per-Google-Workspace-tenant SPF TXT-RR publication discipline the SPF- for-Google-Workspace spoke documents at the per-domain DNS-leaf layer — the per- publisher per-tenant per-operator cross- protocol-pillar DNS-publication-cadence coordination (per-selector DKIM TXT-RR rotation cadence synchronized with per- tenant per-Google-Workspace SPF TXT-RR include-statement-composition cadence) is the load-bearing per-publisher per-tenant per-operator cross-protocol-pillar DNS- publication-cadence coordination rhythm every per-publisher per-tenant per-operator DMARC-deployment programme requires; (iv) per-publisher per-tenant per- operator cross-protocol-pillar publication- discipline-composition-coordination as load-bearing per-publisher per-tenant per- operator complete authentication-publication- posture rhythm — the per- publisher per-tenant per-operator operator- side DNS-publication-discipline-composition- coordination rhythm that composes the per- publisher per-selector DKIM TXT-RR publication discipline THIS page documents with the per-publisher per-tenant per- Google-Workspace-operator SPF TXT-RR publication discipline the SPF-for-Google- Workspace spoke documents is the per- publisher per-tenant per-operator complete authentication-publication-posture rhythm every per-publisher per-tenant per-operator DMARC-deployment programme requires for complete cross-protocol-pillar DNS- publication-discipline coverage. Read THIS page when AUTHORING per-publisher per- selector DKIM public-key TXT records; read the SPF-for-Google-Workspace spoke when PUBLISHING per-publisher per-Google- Workspace-tenant per-domain SPF infrastructure via the Admin Console whose per-tenant per-operator SPF TXT-RR publication discipline pairs operationally with the per-publisher per-selector DKIM TXT-RR publication discipline THIS page documents at the per-publisher per-tenant per-operator cross-protocol-pillar DNS- publication-discipline-composition boundary.
• SPF for Microsoft 365 — the PER-PUBLISHER-PER-TENANT-PER- MICROSOFT-365-OPERATOR-SPF-PUBLICATION- DISCIPLINE-AS-LOAD-BEARING-PEER-PROTOCOL- LAYER-DNS-PUBLICATION-DISCIPLINE companion to this DKIM-DNS-syntax reference, structurally parallel to the SPF-for- Google-Workspace spoke above. Where THIS page documents the per-publisher per- selector DKIM TXT-RR byte-grammar publication discipline at the application layer (the v=DKIM1; k=rsa; p=<base64-public-key> TXT-RR tag-list grammar, the <selector>._domainkey.<domain> per-selector DNS-leaf publication pattern, the per-record TXT-RR 255-octet chunking discipline, and the empty-p= revocation-publication pattern), the SPF- for-Microsoft-365 spoke is the peer per- tenant per-M365-operator SPF TXT-RR publication-discipline reference for the per-publisher per-M365-tenant per-accepted- domain envelope-MAIL-FROM authorisation leg that pairs operationally with the per-tenant CNAME-delegated DKIM dual- selector publication this page documents in its byte-grammar reference. The four- axis per-publisher per-M365-tenant cross- protocol-pillar publication-discipline comparison exposes structurally-distinct coordination dimensions: (i) per- publisher per-tenant per-M365-operator cross-protocol-pillar DNS-publication- surface coordination — the per-publisher per-selector DKIM TXT-RR publication via Microsoft 365 Defender Portal > Email authentication settings > DKIM enable+rotate THIS page documents is published at the per-tenant per- accepted-domain selector1._domainkey.<tenant> / selector2._domainkey.<tenant> CNAME-delegated DNS-leaf layer; the per- publisher per-tenant per-M365-operator SPF TXT-RR publication via the same Microsoft 365 Defender Portal authentication-settings surface the SPF-for-Microsoft-365 spoke documents is published at the per-tenant per-accepted-domain DNS-zone-apex <tenant-domain> TXT-RR layer — both are per-publisher per-tenant per-operator DNS-zone-published primitives the per-publisher per-tenant per-operator DNS-zone-administration team composes in coordination via the same Defender Portal publication surface; (ii) per- publisher per-tenant per-M365-operator cross-protocol-pillar trust-anchor- delegation parallel — the per-publisher per-selector DKIM TXT-RR public-key publication THIS page documents at the per-selector cryptographic-trust- anchor publication layer (per-selector Microsoft-managed CNAME-delegated public- key publication at selector1-<tenantId>._domainkey.<onmicrosoft-tenant> as the per-publisher per-tenant per- selector cryptographic-trust-anchor primitive) pairs operationally with the per-publisher per-tenant per-M365-operator canonical include:spf.protection.outlook.com include-statement-discipline the SPF-for- Microsoft-365 spoke documents the per- tenant per-operator publication-rationale of (per-Microsoft-365-tenant operator-side spf.protection.outlook.com ~5-lookup recursive cascade delegation as the per-publisher per-tenant per-operator SPF-authorisation-trust-anchor primitive) — both are per-publisher per-tenant per- operator DNS-leaf trust-anchor publication primitives the per-publisher per-tenant per-operator cross-protocol-pillar publication-discipline operator composes in coordination; (iii) per- publisher per-tenant per-M365-operator cross-protocol-pillar DNS-publication- budget coordination — the per-publisher per-selector DKIM TXT-RR publication discipline THIS page documents is per-selector cardinality-bounded by the per-tenant per-accepted-domain dual- selector rotation discipline (no RFC budget); the per-publisher per-M365-tenant per-accepted-domain SPF TXT-RR publication the SPF-for-Microsoft-365 spoke documents is per-tenant cardinality-bounded by the RFC 7208 §4.6.4 10-DNS-lookup ceiling whose per-tenant include:spf.protection.outlook.com recursive cascade alone consumes ~5 of the 10 budgeted lookups, leaving ~5 lookups for per-tenant supplemental third- party-ESP include: statements (SendGrid / Mailgun / Amazon SES / Marketo / per-application transactional- relay senders) — the per-publisher per- tenant per-M365-operator cross-protocol- pillar publication-discipline coordination requires the operator to budget per-tenant DKIM key-rotation cadence asynchronously from per-tenant SPF include-cascade- composition cadence (DKIM has no per- tenant publication-budget but SPF does); (iv) per-publisher per-tenant per- M365-operator cross-protocol-pillar per- receiver per-message authentication-leg parallel — the per- publisher per-selector DKIM signing- identity THIS page documents the per-selector public-key publication discipline of (per-message DKIM-Signature d=<m365-tenant-accepted-domain> + s=<selector1|selector2> tag-value pair producing per-message per-receiver DKIM-pass verdict) pairs operationally with the per-publisher per- M365-tenant envelope-MAIL-FROM authorised- source-IP allow-list the SPF-for- Microsoft-365 spoke documents the per- tenant publication-discipline of (per- message envelope-MAIL-FROM 40.92.0.0/15 / 40.107.0.0/16 / 52.100.0.0/14 EOP-managed connecting source-IP class authorised by the include:spf.protection.outlook.com cascade producing per-message per-receiver SPF-pass verdict) — both are per-publisher per-tenant per-M365-operator per-receiver per-message authentication-leg primitives the per-publisher per-tenant per-operator DMARC-aligned-composite-verdict consumes at the per-publisher per-domain application-layer composite-authentication boundary. Read the SPF-for-Microsoft-365 spoke when PUBLISHING per-publisher per- M365-tenant per-accepted-domain SPF infrastructure via the Microsoft 365 Defender Portal whose per-tenant per- operator SPF TXT-RR publication discipline pairs operationally with the per-publisher per-selector DKIM TXT-RR publication discipline THIS page documents at the per- publisher per-tenant per-operator cross- protocol-pillar DNS-publication-discipline- composition boundary.
• BIMI SVG Tiny PS requirements — the per-publisher per-domain BIMI SVG Tiny PS asset-format publication-discipline companion to this DKIM-DNS-syntax reference. Where THIS page documents the per-publisher per-selector RFC 6376 §3.6.1 DKIM key- record TXT-RR byte-grammar publication discipline (the v=DKIM1 version, k=rsa / k=ed25519 algorithm, h=sha256 hash, p= public-key, s=email service- type, t=y testing, n= notes — published at <selector>._domainkey.<d-domain>), the BIMI SVG Tiny PS requirements spoke is the PER-PUBLISHER-PER-DOMAIN-BIMI-SVG- TINY-PS-ASSET-FORMAT-PUBLICATION reference documenting the BIMI Group Tiny PS SVG profile (baseProfile="tiny-ps", version="1.2", square viewBox, forbidden script / animation / external-reference / raster element list, accessibility <title> requirement), the per-publisher per-domain default._bimi.<d-domain> TXT-RR v=BIMI1; l=https://.../svg; a=https://.../vmc byte-grammar, and the per-receiver BIMI logo-display gate SVG-fetch trust chain. Four PER-PUBLISHER- PER-DOMAIN-AUTHENTICATION-AND-DISPLAY-LAYER- PUBLICATION-DISCIPLINE-COUPLING dimensions the BIMI SVG Tiny PS requirements spoke documents: (i) per-publisher per- domain authoritative-DNS TXT-RR byte- grammar publication discipline parallel — both the per-publisher per-selector DKIM key-record TXT-RR byte- grammar this page documents at <selector>._domainkey.<d-domain> and the per-publisher per-domain BIMI- record TXT-RR byte-grammar at default._bimi.<d-domain> the BIMI SVG Tiny PS requirements spoke documents are per-publisher per-domain authoritative-DNS TXT-RR byte-grammar publication primitives at distinct protocol-pillar layers (per-selector cryptographic-key vs per-domain display- asset-pointer); (ii) per-publisher per-domain SVG-Tiny-PS asset-format- constraint publication-discipline as downstream consumer of per-selector DKIM- verification — the per-publisher per-domain BIMI SVG-Tiny-PS asset-format- constraint publication (the baseProfile="tiny-ps" profile requirement, the forbidden-element list, the accessibility <title> requirement) the BIMI SVG Tiny PS requirements spoke documents is the load- bearing downstream consumer of the per- publisher per-selector DKIM-verification- outcome THIS page documents at the per- publisher per-domain BIMI display-gate evaluation boundary; (iii) per- publisher per-domain SVG-asset-HTTPS-fetch trust-chain coupling with DKIM-aligned-pass verdict — every per-receiver BIMI logo-display evaluation fetches the per- publisher per-domain SVG asset over HTTPS AND requires DKIM-aligned-pass (or SPF- aligned-pass) — both per-publisher per- domain publication-discipline primitives must succeed at the BIMI display-gate boundary; (iv) per-publisher per- domain DKIM-DNS-syntax-correctness vs BIMI- SVG-asset-format-correctness publication- discipline composition — the per- publisher per-selector DKIM-DNS-syntax- correctness this page documents (correct v=DKIM1 version, well-formed p= public-key Base64-encoded byte-stream) and the per-publisher per- domain BIMI-SVG-Tiny-PS-asset-format- correctness the BIMI SVG Tiny PS requirements spoke documents are per- publisher per-domain publication-format- correctness primitives at distinct cryptographic vs display-asset layers, both composed at the per-publisher per-domain cross-protocol-pillar authentication-and- display posture boundary. Read the BIMI SVG Tiny PS requirements spoke alongside this DKIM-DNS-syntax reference when AUDITING the per-publisher per-domain cross-protocol- pillar TXT-RR-byte-grammar-publication- discipline-composition that pairs per- publisher per-selector DKIM key-record TXT- RR publication with per-publisher per- domain BIMI-record TXT-RR publication at the per-publisher per-domain authentication- and-display posture composition boundary.
• MTA-STS for Google Workspace — the TRANSPORT-LAYER per-publisher per-policy-domain TXT-RR-BYTE-GRAMMAR- PUBLICATION peer to this APPLICATION- LAYER per-publisher per-selector DKIM key-record TXT-RR byte-grammar reference. Where THIS page documents the per- publisher per-selector <selector>._domainkey.<d> TXT-RR byte-grammar (the v=DKIM1 version tag, the k=rsa key- type tag, the p=<base64> public-key payload, the h=sha256 hash-algorithm tag, the t=s strict-subdomain flag), the GW MTA-STS spoke documents the per-Workspace-tenant per-custom-domain _mta-sts.<d> TXT-RR byte-grammar (the v=STSv1 version tag, the id=<token> policy-ID coupling tag) AND the per- tenant https://mta-sts.<d>/.well-known/mta-sts.txt HTTPS-policy-host file publication listing mx: *.aspmx.l.google.com as the enforced-mode MX cone. Read the GW MTA-STS spoke when documenting the per-publisher per-policy-domain TRANSPORT-LAYER byte-grammar publication discipline that complements the per-publisher per- selector APPLICATION-LAYER DKIM key- record byte-grammar publication discipline this page catalogues — the two TXT-RR byte-grammars together cover the per-publisher per-domain cross-layer authentication-record publication-discipline surface.
• Multi-domain DMARC strategy — the PER-PUBLISHER-PER-PORTFOLIO-MULTI-DOMAIN- DKIM-SELECTOR-PUBLICATION-COORDINATION-AS-LOAD- BEARING-CROSS-DOMAIN-DKIM-KEY-RECORD-TXT-RR- PUBLICATION-DISCIPLINE companion to this DKIM DNS-syntax byte-grammar reference. Where THIS page documents the DKIM key-record TXT-RR byte-syntax at the per-selector per-domain level (the v=DKIM1; k=rsa; p=<base64> tag-list at <selector>._domainkey.<domain>, the per-RFC 6376 §3.6.2 byte grammar, the per-RFC 1035 §3.3.14 character-string chunking rules for >255-byte RSA keys, the per-selector key-rotation cadence, the empty-p= revocation signal, the t=y testing flag, the t=s strict-i= flag, the k=ed25519 vs k=rsa algorithm choice), the multi-domain-DMARC-strategy spoke is the PER-PUBLISHER-PER-PORTFOLIO-CROSS-DOMAIN- DKIM-SELECTOR-PUBLICATION-COORDINATION companion documenting the per-publisher per-portfolio per-primary + per-secondary + per-brand-extension + per-parked-domain DKIM-selector-record-publication coordination discipline whose per- publisher per-portfolio <selector>._domainkey.<domain> publication across the per-publisher per-portfolio domain inventory is the load-bearing per-publisher per-portfolio DKIM-aligned-pass-rate-floor precondition the per-receiver per-message DMARC composite-evaluator consumes. Four DKIM- DNS-syntax-vs-multi-domain-DMARC coupling dimensions matter at the per-publisher per-portfolio cross-domain DKIM-key- publication-coordination boundary: (i) per-publisher per-portfolio per-primary- domain DKIM-selector-record publication — the per-primary-domain <selector>._domainkey.<primary> TXT-RR byte-grammar publication discipline THIS page documents coordinates with the per-publisher per-portfolio per-secondary + per-brand-extension DKIM-selector publication so per-message DKIM-signed mail from EVERY per-publisher per- portfolio sending subdomain produces a per-receiver per-message dkim=pass verdict at the per-publisher per-portfolio aggregate DKIM-aligned-pass-rate floor; (ii) per- publisher per-portfolio per-secondary- domain DKIM-key-publication discipline — when the per-publisher operates secondary brand domains for marketing / transactional / newsletter mail streams, each per-secondary-domain <selector>._domainkey.<secondary> TXT-RR publication is coordinated against the per-publisher per-portfolio uniformly- enforced DMARC posture the multi-domain- strategy spoke documents so per-secondary- domain DKIM-aligned-pass produces a per- receiver per-message DMARC-pass verdict feeding the per-publisher per-portfolio aggregate DMARC-pass-rate floor; (iii) per-publisher per-portfolio per-parked- domain locked-down DKIM defensive publication — the per-parked-domain DKIM-empty-p= revocation- publication discipline THIS page documents at the byte level pairs with the per- parked-domain _dmarc.<parked> at p=reject defensive- publication the multi-domain-strategy spoke documents to prevent per-attacker per-parked-domain DKIM-signed spoofing campaigns from polluting the per- publisher per-portfolio aggregate DMARC- pass-rate stream the per-receiver inbox- trust eligibility evaluators consume; (iv) per-publisher per-portfolio organisational-domain identification at the receiver-side DMARC adkim=relaxed / adkim=strict DKIM-alignment evaluator — the Public-Suffix-List- anchored organisational-domain identification rule the multi-domain- strategy spoke documents determines which per-publisher per-portfolio domain is identified as the organisational-domain whose DKIM-Signature d=<organisational-domain> tag the per-receiver per-message DMARC composite-evaluator consumes when producing the per-message DMARC verdict. Read THIS page when AUTHORING the per- publisher per-selector DKIM key-record TXT-RR byte-grammar publication discipline; read the multi-domain-DMARC- strategy spoke when COORDINATING the per- publisher per-portfolio per-primary + per-secondary + per-brand-extension + per-parked-domain DKIM-selector-record- publication coordination workflow whose per-publisher per-portfolio uniformly- enforced DMARC posture is the load- bearing per-publisher per-portfolio cross-domain DKIM-publication-discipline floor every per-publisher per-domain DKIM-selector TXT-RR record's per- receiver per-message dkim=pass verdict feeds at the per-publisher per-portfolio aggregate DMARC-pass-rate floor preservation boundary.
• DMARC forensic reports
• Why SPF alone is insufficient
• MX records explained
• ARC (Authenticated Received Chain, RFC 8617) explained
• Email security glossary — the threat-actor / OSINT / defense-in-depth / incident-response / threat-modeling cybersecurity-vocabulary registry — per-publisher per-selector DKIM TXT-RR byte-grammar publication-discipline THIS page documents materially depends on canonical operator-side terminology for DKIM-replay-attack threat-class, dual-selector overlap-rollover defense-discipline, and emergency key-revocation IR-playbook vocabulary the security-glossary catalogues alongside the broader phishing-and- impersonation threat-taxonomy registry every per-publisher per-selector DKIM operator consumes for cross-protocol threat-and-defense terminology-disambiguation.
• Email spoofing seven-technique attack catalogue
• Email authentication ecosystem — the PER-PUBLISHER-PER-SELECTOR-DKIM- TXT-RR-AS-LOAD-BEARING-APPLICATION-LAYER- AUTHENTICATION-LEG-COMPONENT-OF-THE-CROSS- PROTOCOL-EMAIL-AUTHENTICATION-ECOSYSTEM companion to this DKIM DNS-TXT-RR byte- grammar publication-discipline reference. Where THIS page documents the per-publisher per-selector DKIM TXT-RR publication at <selector>._domainkey.<domain> per RFC 6376 §3.6.1 (v=DKIM1 version-tag + k=rsa/k=ed25519 algorithm-tag + p=<base64-pubkey> RDATA + t=y/t=s flags + g= granularity + n= notes-tag + s=email service-type-tag) at the per-publisher per- selector application-layer cryptographic- public-key publication-discipline level, the email-authentication-ecosystem spoke is the CROSS-PROTOCOL OVERVIEW reference whose per-publisher per-domain SPF + DKIM + DMARC + ARC + BIMI publication-discipline portfolio THIS DKIM TXT-RR byte-grammar page is the canonical application-layer- cryptographic-authentication-leg component of at FOUR per-publisher per-domain DKIM- TXT-RR-publication-discipline-vs-cross- protocol-ecosystem coupling dimensions: (i) per-publisher per-selector DKIM TXT-RR application-layer cryptographic- authentication-leg AS one of two per- publisher per-domain authentication-legs DMARC composite-verdict per RFC 7489 §6.6 consumes — per- publisher per-selector DKIM application- layer cryptographic-authentication-leg IS structurally parallel to per-publisher per- domain SPF envelope-MAIL-FROM-layer authorization-leg per RFC 7208 §3.1 — both per-publisher per-domain authentication-leg publication-discipline primitives cascade into per-publisher per- domain DMARC composite-verdict-evaluation whose terminal-disposition publication- decision (p=none / p=quarantine / p=reject) per RFC 7489 §6.3 is the per-publisher per-domain anti-spoofing publication- discipline floor the email-authentication- ecosystem reference documents the cross- protocol publication-discipline portfolio of; (ii) per-publisher per-selector DKIM dual-selector overlap-rollover publication-discipline cadence vs per- publisher per-domain SPF publication- cadence vs per-publisher per-domain DMARC policy-tier-ramp publication-cadence cross-protocol coordination — per-publisher per-selector DKIM key-rotation cadence THIS page documents the per-publisher per-selector publication- discipline of IS structurally parallel to per-publisher per-domain SPF mechanism- cascade publication-cadence discipline and per-publisher per-domain DMARC policy-tier- ramp p=none → p=quarantine → p=reject publication-cadence discipline — the per-publisher per-domain cross-protocol publication-cadence coordination IS the load-bearing per-publisher per-domain operator-side cross-protocol-publication- discipline-coordination primitive the email- authentication-ecosystem reference documents the cross-protocol publication-discipline portfolio of; (iii) per-publisher per-selector DKIM-Signature header anatomy per RFC 6376 §3.5 cryptographic-binding AS load-bearing per-message authentication- leg-evidence the per-publisher per-domain DMARC RUA aggregate-XML report per RFC 7489 §7.2 + per-message AFRF forensic- report per RFC 7489 §7.3 attribution stream surfaces — per- publisher per-selector DKIM TXT-RR publication-discipline THIS page documents drives per-receiver per-message DKIM- Signature b=/bh= signature-byte verification cascading into per-receiver per-day per-source-IP per-row DMARC RUA aggregate-XML policy_evaluated/dkim attribution evidence-stream the email- authentication-ecosystem reference documents the cross-protocol observability- pipeline of; (iv) per-publisher per-selector DKIM-aligned-pass evidence stream AS load-bearing precondition for per-publisher per-domain BIMI Indicator- record brand-indicator-rendering eligibility per RFC 9716 §4.1 enforcement-mode prerequisite cascade — per- publisher per-selector DKIM TXT-RR publication-discipline THIS page documents is the upstream application-layer cryptographic-authentication-leg whose per-publisher per-domain DKIM-aligned- pass-rate-floor preservation IS the per- publisher per-domain DMARC composite- aligned-pass-rate-floor precondition for per-publisher per-domain BIMI Indicator- record brand-indicator-rendering eligibility the email-authentication- ecosystem reference documents the cross- protocol publication-discipline portfolio of. Read the email-authentication- ecosystem spoke WITH this DKIM TXT-RR byte-grammar publication-discipline reference when AUTHORING per-publisher per-domain composite cross-protocol authentication-and-policy publication- discipline portfolio at the per-publisher per-domain composite cross-protocol- email-authentication-ecosystem-and-DKIM- TXT-RR-byte-grammar coordination boundary.
• DMARC aggregate (RUA) reports
• DMARC myths and misconceptions
• How attackers bypass DMARC
• BIMI explained — the brand-logo payoff that sits downstream of the DKIM TXT-RR this page documents. A receiver only renders a BIMI logo once the domain reaches DMARC enforcement (p=quarantine or p=reject) with a sustained aligned-pass rate, and that pass rate depends on the <selector>._domainkey.<domain> public-key record being published correctly per the byte-grammar this page covers. A malformed or stale DKIM record silently drops the aligned-pass leg, stalls the ramp to enforcement, and keeps the BIMI logo from ever appearing. Read the BIMI explained spoke to see why getting the DKIM DNS syntax right is a precondition for the verified-logo program.
• TLS-RPT explained — the DKIM public key is one per-domain DNS TXT-RR publication; the TLS-RPT policy record (_smtp._tls.<domain> TXT) is another, governing the transport layer rather than the message signature. SMTP TLS Reporting (RFC 8460) gives you a daily JSON feedback stream of the STARTTLS-handshake failures your mail hops experience — the transport-layer counterpart to the DKIM authentication this page publishes. Read the TLS-RPT primer to round out the per-domain DNS publication discipline.
• Business email compromise (the fraud a sound DKIM key record defends against) — the selector._domainkey TXT-record byte-syntax THIS page documents is the publication substrate that lets a verifier confirm a message was genuinely signed by the claimed domain; BEC is the high-value fraud class — CEO-impersonation wire-transfer requests, vendor-invoice redirection — that thrives precisely when domains lack a verifiable authentication signal. A correctly published 2048-bit RSA (or Ed25519, RFC 8463) public-key record keeps the DKIM leg dependable so the composite DMARC aligned-pass verdict can drive p=reject against exact-domain spoofing. Read it to see the operational threat the syntax discipline here ultimately blunts.
• DMARC alignment explained — a verified DKIM signature only contributes to a DMARC pass when the signing d= domain aligns with the visible RFC5322.From domain (relaxed or strict). This spoke documents that alignment rule — the reason the d= tag you publish in the selector._domainkey record this page covers must match the From domain to be DMARC-useful. Read it to see how the DKIM key syntax here feeds the DMARC composite verdict.
• Microsoft SNDS + JMRP monitoring — a valid DKIM signature does not outrank a bad IP reputation at Outlook.com: SNDS shows how Microsoft's consumer network actually graded each sending IP (GREEN/YELLOW/RED) and JMRP surfaces the Junk clicks behind a degraded verdict.

Validate your DKIM record now

DMARC Analyzer ingests every aggregate report and surfaces the per-selector pass/fail profile in the dashboard. Cross-check against the Domain Security Checker for the live DNS state of every selector your domain publishes.

Sign up — Free plan Validate my DKIM record