Selected DKIM public-key value has unsupported base64 characters
ShipReady found a plausible DKIM record at a supported selector whose non-empty p= value did not match its base64-character pattern.
Why it matters
A public-key value with clearly unsupported characters is a DNS record condition worth reviewing. The scanner checks a restricted character pattern only, so this page does not treat the result as complete cryptographic validation.
How ShipReady detects it
What it inspects
ShipReady identifies a recognised SPF provider fragment, queries that provider's fixed supported selectors, and evaluates the first plausible DKIM TXT record it finds.
What triggers a finding
The rule triggers when the non-empty trimmed p= value does not match ShipReady's base64 character pattern: letters, digits, +, /, and up to two trailing = characters. Valid unpadded base64-looking values do not trigger.
What the evidence shows
The selected p= value failed ShipReady's bounded base64-character pattern.
Limits of this check
ShipReady does not decode the key, validate its length or algorithm, verify DNS concatenation, enumerate selectors, send mail, or establish that a receiver rejects a real message or that deliverability is affected.
How to fix it
Retrieve the current provider value
Use the actual sending provider account to obtain the current DKIM selector and TXT value; do not reconstruct a key from this finding alone.
Republish the record accurately
Correct the deployed TXT value using the provider's instructions, preserving its intended DNS-string handling and avoiding inserted whitespace or characters.
How to verify the change
Verify the record and controlled messages
Query the actual selector after DNS propagation and inspect DKIM authentication results on controlled messages.
Expected: The intended provider record is present and controlled messages show the expected result.