Gandi SPF, DKIM and DMARC setup, step by step

In Gandi LiveDNS, publish the records supplied by the actual mail service, not a generic “Gandi” recipe. GandiMail's documented mailbox authorization is include:_mailcust.gandi.net, and its DKIM delegation uses all three gm1, gm2 and gm3 CNAMEs. The newer Email menu uses a mailbox Status screen; the older Domain → Email workflow has a DKIM switch. Establish which workflow you have before changing anything. Gandi SPF, DKIM and new mailbox setup

This guide covers DNS publication in Gandi and the documented GandiMail branches. It distinguishes mailbox sending, Gandi Web Hosting messages and a third-party sender using Gandi only for DNS. It is not a mailbox-migration procedure or a universal recipe for reseller and self-managed servers.

Determine which Gandi role you are configuring

A domain registered at Gandi may use external nameservers. Gandi LiveDNS may host records for email delivered by another company. Conversely, Gandi mail can need records published in an external DNS zone. Check the active nameservers and actual outgoing mail service before choosing the editor. Gandi DNS management

Record the visible From domain, the application that sends, the SMTP submission account, the envelope MAIL FROM domain and the intended DKIM signing domain. Include each alias, child domain and website form that matters. A forwarding destination describes incoming delivery, not an independent outbound mail service. Gandi's older FAQ warns that sending “from” a forwarding-only address can cause problems; use an actual supported mailbox or sender route rather than assuming forwarding supplies authentication. Gandi email FAQ

Gandi now documents two interfaces. The newer mailbox setup page includes external nameservers, domains without management rights and domains not registered with Gandi. Do not apply the older FAQ's external-domain restriction indiscriminately to this newer workflow. Use the instructions for the mailbox product and interface actually shown in your account.

Back up LiveDNS and keep the change narrow

In the domain's DNS Records area, use Save a backup before editing. Gandi documents per-record editing with the pencil, Add for new records, and an Advanced view that can edit the entire zone. Prefer a bounded record change for an authentication repair. Full-zone replacement carries unnecessary risk when several services share DNS. LiveDNS editing and backups

Retain MX, website records, verification TXT values and working selectors for other senders. Save the current SPF and DMARC values in the change note with timestamps and ownership. If another administrator edits the zone during the work, compare changes before restoring anything.

In zone-file notation, @ means the apex; a relative name such as gm1._domainkey is under that zone. Gandi's advanced syntax uses a trailing dot for a fully qualified CNAME target. In a form with separate fields, enter the host, type, value and TTL into their proper fields rather than pasting a complete zone-file line into Value.

For example.com, _dmarc.news means _dmarc.news.example.com. If news.example.com is itself a delegated zone, use names relative to that zone instead. Check the final full owner to catch a doubled suffix. A CNAME cannot share its owner with a conflicting TXT record; resolve an existing dependency rather than deleting another sender's key.

Use the correct SPF authorization for each sending route

For ordinary GandiMail mailbox sending, Gandi's SPF reference gives:

v=spf1 include:_mailcust.gandi.net ~all

For a site sending through the documented Gandi Web Hosting mail route, it gives:

v=spf1 include:_spf.gpaas.net ~all

For both routes at the same SPF owner, its combined example is:

v=spf1 include:_mailcust.gandi.net include:_spf.gpaas.net ~all

These are route-specific examples. A website merely hosted at Gandi but sending through an independent SMTP provider needs that provider's instructions instead. Do not copy reseller includes or IP addresses from a different Gandi product. Official mailbox and Web Hosting SPF branches

The terminal qualifier differs between Gandi documents. The SPF reference above uses ~all, while the newer mailbox Status illustration and older anti-spoofing guide show ?all. The new-screen example is:

v=spf1 include:_mailcust.gandi.net ?all

?all returns neutral for an unmatched sender; ~all returns softfail. Neither is pass. Follow the applicable account instruction for a new setup, and do not silently loosen an established -all or ~all policy while adding a sender. The difference is a policy choice, not a reason to publish both records. New mailbox Status SPF illustration and Gandi anti-spoofing instructions

Maintain one SPF TXT policy at each owner. Merge needed authorization before the terminal all, preserve approved senders and evaluate nested includes against the ten DNS-lookup-causing-term limit. Do not add a second v=spf1, authorize everybody with +all, or assume a root policy automatically covers child MAIL FROM domains. SPF rules

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

SPF authenticates the SMTP envelope identity, not simply the address shown to the recipient. Compare the actual receiver-reported smtp.mailfrom with the DNS owner you changed. If a third-party system uses its own envelope domain, editing your apex does not make that provider identity align with your visible From.

Enable GandiMail DKIM using the applicable interface

Older Domain → Email mailbox workflow

For the documented Gandi-hosted domain and mailbox on LiveDNS, open Domain → Email, then the security/settings section's Manage control. Enable DKIM Signature and click Update. The older documentation labels the section slightly differently; match the account's actual control. Gandi's DKIM activation procedure

For manual publication, including an external DNS host, the documented CNAME mappings are:

gm1._domainkey CNAME gm1.gandimail.net.
gm2._domainkey CNAME gm2.gandimail.net.
gm3._domainkey CNAME gm3.gandimail.net.

Publish all three, not only the selector you happen to see on one message. Gandi explains that the set accommodates key rollover. These shared delegation targets replace the need for you to generate a private/public key pair for this managed mailbox route. All three selectors and rollover

Where the actual authoritative DNS host offers these controls, use DNS-only aliases, not HTTP proxying or redirects, and keep a literal CNAME answer to each required target. Turn the relevant per-record Flatten option off when available, and ensure applicable zone-wide settings do not conceal the issued aliases. For Cloudflare specifically, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are Cloudflare behaviors, not assumed controls in another provider’s panel. If mandatory behavior or shared settings prevent the required CNAME answer, stop and coordinate a supported configuration without breaking dependent records. Do not blindly change the whole zone or remove an NS delegation; publish at the delegated authority when appropriate. Cloudflare CNAME verification, flattening controls. For an issued signing domain such as news.example.com, the illustrative full owner is gm1._domainkey.news.example.com. In an editor relative to the parent example.com zone use gm1._domainkey.news; in a separately delegated news.example.com zone use gm1._domainkey; in a delegated _domainkey.news.example.com zone use only gm1. Repeat for gm2 and gm3 and preserve all current account-confirmed CNAME targets. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

Newer Email → mailbox → Status workflow

Create or identify the intended mailbox, then open its Status tab from the Email menu. Where records are required externally or you lack domain-management rights, Add displays the technical records to publish or give to the DNS administrator. Copy any account-specific verification TXT token from that screen; the official illustration deliberately obscures the token, so it cannot supply a usable customer value. New mailbox setup

The current page's DKIM illustration shows the same three gm CNAME destinations, with a 1200-second TTL, while the older DKIM guide shows 10800 seconds. Use the applicable screen's TTL and record instructions, not a blend of two interfaces. Do not invent a DKIM switch in the new Status flow merely because one exists in the older interface.

The automatic setup branch can replace existing MX records. Gandi explicitly warns that managed-domain technical validation replaces the previous mail configuration. Do not use it as a harmless SPF repair when inbound mail must remain with another provider. Separate an authorized mailbox migration from a limited authentication change.

After publishing externally, revisit Status and inspect the result. A green configuration screen is useful evidence of record recognition, but it does not establish that every real message is signed and aligned. Fresh delivered-message checks remain necessary for both interfaces.

Gandi DNS with another sender

Use the third-party sender's own generated selector, TXT public key or CNAME destination and its signing activation procedure. Do not substitute the GandiMail gm records for that sender. For example, SMTP2GO authentication requires its own sender-domain setup and verification even when DNS is in Gandi.

Publish DMARC without changing the owner's protection accidentally

Inspect the existing DMARC record at the visible From domain and any applicable parent policy. Keep its enforcement, reporting destinations and alignment settings unless the domain owner approves a change. Gandi's anti-spoofing page contains a p=reject example; do not copy that into an unassessed multi-sender domain.

For an approved first monitoring deployment with no existing applicable policy, an illustrative value is:

Publish the conditional first DMARC policy as a TXT record at the correct full owner and relative name described below; preserve any direct or inherited policy instead of adding a weaker child override.

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the address with an approved reporting destination that is ready to receive reports. In the domain’s own example.com zone, the full owner _dmarc.example.com maps to _dmarc. For an intentional policy at news.example.com, the full owner _dmarc.news.example.com maps to _dmarc.news in the example.com zone, or to _dmarc in a separately delegated news.example.com zone. A child policy can alter inherited protection, so review it with the parent-domain owner. DMARC policy and discovery

DMARC passes with either aligned SPF pass or aligned DKIM pass. Relaxed alignment compares organizational domains; strict alignment requires exact equality. A provider-domain signature that passes cryptographically is not automatically aligned with your branded From.

Before sending reports externally, confirm the recipient and the reporting service's external-authorization records where needed. Avoid copied tenant addresses and unsolicited failure reporting. Review aggregate reports across the whole sending inventory before moving toward quarantine or reject; a single successful mailbox test is not enough. DMARC reporting safeguards

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Verify DNS, then the actual message

Replace uppercase placeholders in these read-only patterns:

dig +short NS DNS_ZONE
dig +short TXT MAIL_FROM_DOMAIN
dig +short CNAME gm1._domainkey.SIGNING_DOMAIN
dig +short CNAME gm2._domainkey.SIGNING_DOMAIN
dig +short CNAME gm3._domainkey.SIGNING_DOMAIN
dig +short TXT gm1._domainkey.SIGNING_DOMAIN
dig +short TXT _dmarc.FROM_DOMAIN
dig @AUTHORITATIVE_NS TXT MAIL_FROM_DOMAIN

For GandiMail, expect the intended single SPF policy and all three matching CNAME targets. Follow the actual signing selector to its public key, repeating the TXT lookup for gm2 or gm3 when appropriate. For an external sender, replace these selectors with its actual values. Check any required account-verification TXT separately without publishing the token in a public support post.

Compare authoritative DNS with cached resolver answers. Gandi's DNS guide gives an average update time, not a universal deadline; TTLs and negative caches can affect observations. Record where and when you queried. If you edited an inactive DNS zone or a misspelled owner, waiting will not repair it.

After DNS is correct, an authorized administrator should send a new message from the actual Gandi mailbox route to a controlled external mailbox. Repeat for important aliases and applications. Test the Web Hosting route separately if its SPF authorization was changed. Read the receiving service's trusted Authentication-Results, keeping the visible From, smtp.mailfrom, DKIM header.d, selector and all three authentication outcomes. Trusted header interpretation

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

Accept the branded DKIM setup only when the intended GandiMail signature passes for the intended signing domain and selector and aligns as required. Also require DMARC pass and verify SPF pass for the intended direct sending route. A DMARC pass through SPF alone does not excuse a missing branded DKIM signature. If SPF fails, investigate rather than hiding the failure behind a passing DKIM result. Store sanitized header evidence alongside the DNS observations; authentication is not a promise of inbox placement.

Troubleshooting and safe recovery

• SPF permerror: inspect duplicate policies, syntax, broken includes and nested lookup-term limits. Fix the cause before accepting the route.
• SPF temperror: investigate DNS availability or timeout errors and repeat the check after recovery. Do not remove controls for a transient lookup failure.
• SPF neutral or softfail: confirm whether the message matched an authorized mechanism or merely reached ?all or ~all. Check the actual envelope domain and distinguish mailbox, Web Hosting and external relay traffic.
• DKIM missing: confirm the relevant interface, older-flow switch if applicable, all three CNAMEs and the real sending route. Correct public DNS is not proof of active signing.
• DKIM failure: inspect the signature's exact selector and domain, missing delegation, CNAME owner conflicts or alterations after signing. Compare a direct message with a forwarded one before blaming the key.
• Status remains orange: check the exact records requested by the new mailbox screen, authoritative DNS and management rights. Do not use automatic setup just to force a green status while ignoring its MX effect.
• DMARC failure despite SPF/DKIM pass: compare the passing identities with the visible From and actual strict or relaxed policy.

Restore only the affected record when correcting a mistake, after comparing the current zone with your snapshot. A full shared-zone restore may reverse legitimate intervening work. Keep old DKIM selectors for as long as the provider's rollover or in-flight message requirements need them; do not remove them simply because another selector is currently active.