Momentum#1467 document the k=ed25519 p= encoding and the SPKI compati…

[juliebin]

…bility path

• Give your PR a recognizable title. For example: "FE-123: Add new prop to component" or "Resolve Issue Create new-pricing-increases-costs #123: Fix bug in component"
• Your PR title will be visible in changelogs

What Changed

• What changes does this PR propose?
• Provide screenshots or screen recordings for any visual changes.

How To Test or Verify

• Describe any steps that may help reviewers verify changes.
• Anything beyond basic unit testing, such as assistive tech usage, or special interactions.

PR Checklist

Below are some checklists to follow for the correct procedure in different circumstance. The first list ("All PRs Checklist") should be followed for ALL PRs. The next 2 are additive to this list depending on what type of PR you are using.

For example: If you are submitting a content change to one of the support documents, your checklist would include the:

• "All PRs Checklist"
• AND the "Content Changes Checklist

If you are submitting a feature addition, enhancement, or bug fix, your checklist would include the:

• "All PRs Checklist"
• AND the "Development Changes Checklist"

All PRs Checklist

• Give your pull request a meaningful name.
• Use lowercase filenames.
• Apply at least one team label according to which team is the content expert (ie. team-FE or team-SAZ)
• Pull request approval from the FE team or content experts (see label applied above) that isn't the content creator.

Content Changes Checklist

• Check that your article looks correct in the preview here or in a Netlify deploy preview.
• Check the links in your article.
• Check the images in your article (if there are any)
• Check to make sure you are using markdown appropriately as outlined in examples/article.md in the root of the project directory and on the momentum doc's preface article
• Check to make sure the Copy and Tone Guidelines are followed.

Development Changes Checklist (some checks are automatic github actions and will not be listed here. ie. "all tests pass")

• The appropriate tests are created in cypress/ directory in the root of the project
• The lighthouse score is passing according to the FE Support Docs' Service Outline SLI/SLOs

---

Note

Low Risk
Documentation-only edits to Momentum DKIM2 support articles; no application code or runtime behavior changes.

Overview
Documentation updates across the DKIM2 overview, signing, verifying, and debugging pages clarify how RSA vs Ed25519 public keys must appear in DNS p= tags, and how Momentum handles legacy key formats.

Signing (sign.md) adds a Publishing the public key section: one TXT per sig-set, RSA p= as base64 SubjectPublicKeyInfo (with openssl/DNS splitting guidance), Ed25519 p= as base64 of the bare 32-byte key (with a DER tail extraction recipe), plus an Upgrading from an earlier 5.3 build note for deployments that published Ed25519 as SPKI.

Overview (dkim2.md) splits RSA vs Ed25519 encodings in key management, links to the new publishing section, and documents Ed25519 key generation via openssl genpkey.

Verify (verify.md) expands key_der_parse for algorithm-specific expectations and documents non-conformant Ed25519 records (Momentum still verifies SPKI-form keys from pre-fix 5.3; debug_level = "warning" surfaces a selector DWARNING).

Debug (debug.md) notes that the warning level includes tolerated non-conformant key records.

lastUpdated metadata is bumped on all touched pages.

^{Reviewed by Cursor Bugbot for commit 16b455d. Bugbot is set up for automated code reviews on this repo. Configure here.}

[netlify]

✅ Deploy Preview for support-docs ready!

Name	Link
🔨 Latest commit	16b455d
🔍 Latest deploy log	https://app.netlify.com/projects/support-docs/deploys/6a837a4ecd5cad00083af5a9
😎 Deploy Preview	https://deploy-preview-867--support-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.