Confirm that Gandi hosts the active zone
A domain registration at Gandi does not by itself establish that Gandi serves its authoritative DNS. Check the delegated nameservers for the domain first. Gandi says externally hosted nameservers must be managed through the external provider. This guide covers the documented Gandi LiveDNS editor, not a migration from another DNS host.
Keep mail-service configuration separate from DNS publishing. Your sending provider supplies its supported selector, key or CNAME target and any envelope-domain requirements. Gandi publishes those records; creating a DKIM TXT record does not cause an unrelated mail server to begin signing. Do not infer a universal Gandi SPF include for a domain merely because its DNS is hosted there.
Identify the DNS administrator, the sending-service owner and the person authorized to approve the domain policy. Save existing record sets for all affected names. Check whether the domain is linked to a shared zone: Gandi documents that changes to a linked zone affect every linked domain. A seemingly local authentication edit can therefore have a wider impact.
Use a bounded editor change
The documented route is Domain, the selected domain, then DNS Records. Table mode supports adding or editing individual entries; text mode edits the whole zone. For a small authentication change, individual records are easier to compare with the approved request. Use text mode only when the editor is understood and the entire proposed difference has been reviewed.
Gandi LiveDNS offers Save a backup and Restore. Take a backup before the change, but do not assume restoring it later is harmless: a full restoration can reverse unrelated edits made since that snapshot. Record a targeted recovery plan for the affected records as well. If a shared zone is involved, include the other domain owners in that plan.
Create a publication worksheet with the full intended owner, editor label, type and value. For a synthetic domain example.com, the apex is example.com, its DMARC owner is _dmarc.example.com and a DKIM owner might be rotation1._domainkey.example.com. These example labels are not provider-generated settings. Use the actual selector and domain from the sending service.
Preserve TXT boundaries and names
Gandi's TXT documentation uses @ for the bare domain and a relative label for a subdomain. Its text-zone examples represent long TXT data as multiple quoted strings within one record, each no longer than 255 characters. This is distinct from creating multiple independent TXT records.
That distinction matters for authentication. One SPF policy can consist of several character strings in a single TXT resource record, but multiple candidate SPF records at the same owner cause an SPF error. DKIM key material must also remain complete. Do not create several unrelated keys or policies to get past a text-field limit, and do not insert visual line breaks into a key without understanding how the editor serializes them.
Use the TXT record type for SPF. Use TXT or CNAME for DKIM according to the sending provider's instructions, not according to personal preference. A CNAME at a selector is an alias to another domain name, not a container for public-key text. If a requested CNAME collides with existing data at that name, resolve the collision rather than replacing another service's active selector.
Publish the intended policy, not a sample
An SPF update needs a review of all legitimate senders and DNS-lookup dependencies. Preserve necessary authorizations in one valid policy at the relevant envelope domain. A DMARC update needs a deliberate policy decision for the visible From domain and its applicable subdomains. Adding a provider is not a reason to add another DMARC policy at an owner where one already exists.
Do not copy a sample reporting address or point reports to a third party without approval. Do not replace an enforced DMARC policy with monitoring solely because an onboarding screenshot shows p=none. Determine whether the new sender has a supported aligned path before changing domain-wide protection.
If a provider requests records below a separately delegated child zone, publish them in the zone that actually has authority for that child. An attractive-looking entry in the parent editor does not override a delegation. Resolve the DNS ownership boundary before saving.
Verify at two technical layers
Query each authoritative server for the complete intended owner and record type. Preserve the answers and compare the logical TXT content, not just how quotes look in a tool. Check the whole key, the selector label, any alias target and the record-set boundaries. Only once authoritative answers are correct should you investigate cached recursive answers. A provider's broad propagation estimate is not a substitute for diagnosing an incorrect owner name.
Then activate or validate the sending service using its own workflow and send a controlled message. Record the visible From, envelope identity, each DKIM d= and s=, and trusted receiver results. SPF authenticates the envelope identity; DKIM verifies a signing identity. DMARC needs a passing path aligned with the visible From under the applicable mode.
Synthetic failure case: Gandi publishes the correct key at rotation1._domainkey.example.com, but the message uses s=rotation2 and d=example.com. The published rotation1 record cannot validate that signature. The remedy is to reconcile the sender's selector with its required publication, not to weaken DMARC or add an unrelated SPF include.
Recover and close the change
If publication breaks a route, identify the exact changed owner and restore the approved previous record set. Do not restore an entire shared zone without comparing intervening changes and affected domains. Retain previous keys for as long as the signing-service rotation plan requires; DNS deletion and signing activation must be coordinated.
Close the work only when the active zone, intended DNS answers, sending activation and observed message authentication agree. This is a documentary guide with a synthetic failure case. No Gandi account, authoritative DNS query or delivered message was used as live evidence. The administrator must collect those observations before approving production completion.
Stop a shared-zone rollback from undoing unrelated work
Written case GAN-01 assumes example.com and example.net share a zone. A later approved website record was added after a backup, while the new selector on example.com is wrong. Restoring the entire older backup would also remove that website change across the linked scope. Compare current records, identify the approved selector-only repair and confirm both domain owners before applying it. No zone, backup or restoration was inspected or executed 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.