Confirm the exact GoodData product and route
The first-party procedure supporting this guide is labeled GoodData Legacy Growth, Configure DKIM for Outgoing Email. It concerns white-labeled outgoing mail and requires work on both the customer's and GoodData's sides. Do not apply it automatically to current GoodData Cloud, another plan or a different notification service.
Start by confirming the product, white-labeled domain, intended From addresses and actual message workflows with the account owner. Identify the DNS administrator and the GoodData support owner handling white-label configuration. A custom application URL or branding theme is not proof that outgoing email is signed with the same domain.
The reader task is to establish a supported signing arrangement and then test the intended mail. The catalogue's broad provider label does not justify claiming that every GoodData product supports the same selector, relay or key-management process. If the documented legacy scope does not match your tenant, obtain the matching first-party procedure before changing DNS.
Choose a supported key arrangement
The Legacy Growth documentation describes using a specific private key, with a unique key generated by GoodData as an alternative, or using a GoodData shared key. In the shared-key route, Support supplies a DNS record containing the public key. In the specific-key route, the parties coordinate the selector and domain with the signing configuration. No universal selector or public-key value is supplied for customers to copy from this guide.
Prefer an arrangement that fits the organization's signing-key ownership policy and minimizes unnecessary exposure. Clarify who generates the key, who can use it, how rotation is coordinated and how the provider's signing authority will be removed when the service is retired. A public DNS record can be widely visible; a private key cannot be treated the same way.
The provider documentation describes encrypted transfer when a customer-supplied private key is used. Do not paste a private key into chat, an ordinary support comment, a public document or DNS. Have the authorized security owner verify the intended recipient and secure transfer process. Requesting or accepting a provider-generated alternative still requires understanding who holds and controls the private signing material.
Publish only the public verification material
Obtain the exact record type, complete owner, selector and public value from the supported setup. Compare them with the approved signing domain. Record the required DNS-editor label separately because a relative-name field may append the zone automatically. Check whether an existing selector already belongs to another mail service before making a change.
A DKIM signature with d=example.com and s=analytics1 looks up its key at analytics1._domainkey.example.com. This is a synthetic name-construction example, not a GoodData default. A correctly published key under a different selector or domain will not verify that signature. Preserve the complete public value and the record boundaries when the editor represents a long TXT record as multiple strings.
After publication, query authoritative DNS for the exact owner. Preserve the answers and confirm that the active delegation is serving the record you edited. Then have the support owner complete the GoodData-side configuration. DNS publication without signing activation is only half of the task.
Keep optional SPF distinct from alignment
The Legacy Growth page lists include:relays.gooddata.com as an optional SPF addition to authorize its mail relays. Confirm that this is the applicable route before using it. Do not add it solely because an unrelated GoodData workflow exists in the organization, and do not create a second SPF policy at the same owner.
Review any necessary SPF update as a whole: preserve existing approved senders, check the policy's DNS-lookup dependencies and confirm its terminal behavior. Avoid copying relay IP addresses into a static allowlist without an explicit maintenance plan. A provider-managed authorization target and a frozen list of today's answers have different operational consequences.
SPF success by itself does not demonstrate DMARC alignment. The evaluated identity is the envelope sender domain. If a message uses a provider-owned envelope while showing your domain in From, an SPF pass for that provider domain does not align with your domain. A passing DKIM signature aligned with the visible From can provide the required path.
Test a real white-labeled message
Trigger each material in-scope workflow to a controlled, authorized test mailbox. Retain the raw received message and note the workflow, sender configuration and test time. Record the visible From, envelope identity, every DKIM signing domain and selector, and trusted receiver authentication results. Do not infer these values from the white-label URL or a signed-by display alone.
Synthetic acceptance example: From is reports@example.com, the message's DKIM signature verifies with d=example.com and the receiver evaluates DMARC successfully on that aligned path. Even if SPF passes only for an unrelated envelope domain, exact aligned DKIM can provide the DMARC path. If the signature instead uses a different unrelated domain, a DKIM pass alone is not enough to support this acceptance conclusion.
Repeat the sample after key rotation or a change in mail transport. If the expected signature is absent, check GoodData-side activation and the actual workflow before adding more records. If the signature is present but invalid, compare selector, domain, public key and any message modification. If authentication passes but delivery is poor, investigate other receiver and reputation factors separately.
Plan rotation, retirement and recovery
Keep the pre-change record set and a documented owner for each part of the signing arrangement. Coordinate the time the provider starts signing with a new selector and the time the public key becomes available. Do not assume a single record deletion revokes every capability or that immediately deleting an old key is safe for already-sent mail still being delivered.
When retiring the integration, verify that no workflow still needs it before removing selectors or SPF permissions. Reconcile private-key retention and provider-side signing access under the organization's security process. If a key may have been exposed, use an incident and rotation process rather than treating the concern as a normal DNS cache delay.
This is a documentary guide for a specifically labeled legacy product. The examples are synthetic. No private key, tenant configuration, DNS change, support exchange or delivered GoodData message was accessed or tested. Production verification and any broader product-scope decision remain with the account and security owners.
Use an activation ledger before calling the route complete
Written case GD-01 assumes the tenant is confirmed Legacy Growth, the approved From is reports@example.com and the agreed illustrative selector is analytics1. The DNS owner has a stipulated public key at analytics1._domainkey.example.com, while provider-side signing activation remains unconfirmed. DNS alone cannot close the task. Ask the white-label owner to obtain confirmation of the supported signing configuration and then inspect a harmless authorized notification. A later hypothetical trusted DKIM pass with d=example.com, s=analytics1 would supply exact alignment, but until that evidence exists the message result remains unknown. No private key, support request, DNS lookup or tenant action was used here.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.