Gandi SPF, DKIM, and DMARC Setup for Sending Email

Gandi SPF DKIM DMARC setup is the DNS work that turns a domain you own into a domain that can send authenticated email. Whether you send product emails, password resets, receipts, or campaigns, publishing the right records lets receiving providers verify that your mail is authorized and has not been altered.

This guide explains how to add SPF, DKIM, DMARC, and, where applicable, a custom return-path record for a domain registered at Gandi. It uses example values throughout. Always replace those examples with the exact values shown in your sending provider’s domain-verification screen.

What you need before editing DNS

Have these items ready before opening Gandi:

• The domain you want to authenticate, such as example.com.
• Access to the Gandi account that manages the domain.
• Confirmation that the domain uses Gandi LiveDNS rather than external nameservers.
• The DNS records supplied by your email platform, including every DKIM selector and any return-path or bounce-domain record.
• A DMARC reporting mailbox, such as dmarc-reports@example.com, if you plan to receive aggregate reports.

A registrar and a DNS host are not always the same thing. You may have bought the domain from Gandi while delegating its nameservers to Cloudflare, Squarespace, Wix, a web host, or another DNS provider. In that case, Gandi is still your registrar, but its DNS editor is not authoritative for the domain. Add records wherever the active nameservers are managed instead.

Gandi documents that DNS records can be edited in its interface only when the domain uses Gandi LiveDNS. If you see external nameservers on the domain, do not add duplicate records in Gandi and expect them to work. Find the DNS provider named by those nameservers and publish the email records there.

Navigate to DNS management in Gandi

As of writing, Gandi’s documented navigation path is:

1. Sign in to your Gandi account.
2. Select Domain from the left-side navigation.
3. Select the domain name you want to configure.
4. Open the DNS Records tab or section for that domain.
5. In table mode, select Add to create a record, or use the edit icon beside an existing record.

The labels and page layout can change, so treat the path above as the current documented route rather than a promise that every account view will look identical. The important destination is the domain’s DNS Records editor, not a mail-hosting screen, forwarding screen, or nameserver overview.

Before adding anything, inspect the active nameservers. If the domain is not on LiveDNS, Gandi may show the domain but will not be the place that controls the public DNS answers. Gandi’s documentation also notes that older domains using legacy nameservers may need to be switched to LiveDNS before the current DNS-record interface can manage the zone. Do not switch nameservers casually on a production domain: changing DNS authority without copying existing web, mail, verification, and service records can interrupt live services.

In the DNS Records editor, Gandi lets you work record by record in table mode. This is usually the safest option for email authentication because you can compare each Type, Name, and Value against the values supplied by your sending platform. Gandi also offers a zone-file-oriented text mode, but that mode is better reserved for administrators comfortable with DNS syntax and zone-file changes.

The record map: Type, host, and value

The following table shows the usual shape of each record. The Host column is called Name in Gandi’s documentation and interface. Gandi appends your domain to that Name, so enter the relative host shown in the table rather than a repeated full domain name.

The examples are deliberately generic. A real sending platform may supply two or three DKIM CNAME records, a DKIM TXT record, one or more verification records, and a return-path configuration with different record types. Copy the provider’s Type, Name, and Value exactly. The general patterns help you recognize the record, but the provider’s domain-verification values are authoritative.

One important distinction: SPF, DKIM, and DMARC are not interchangeable records. SPF authorizes sending infrastructure for an envelope-sender domain. DKIM publishes a public key or delegates key lookup so a receiver can verify a cryptographic signature. DMARC checks whether SPF or DKIM passes and aligns with the domain displayed to the recipient in the visible From address. A good configuration uses all three.

The Gandi-specific mistake to avoid: repeating the domain in Name

The most common Gandi mistake is entering a fully qualified hostname in the Name field when Gandi expects the relative label.

For example, suppose you need a DMARC record at _dmarc.example.com. In Gandi, enter this:

• Type: TXT
• Name: _dmarc
• Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Do not enter _dmarc.example.com as the Name unless Gandi’s current editor explicitly shows that it accepts a full hostname without suffixing it. Gandi’s DNS documentation explains that a Name such as www is added in front of the domain. Following that model, a fully repeated name can become _dmarc.example.com.example.com, which leaves the real _dmarc.example.com lookup empty.

The same problem appears often with DKIM. If a provider gives you this required hostname:

mta1._domainkey.example.com

enter mta1._domainkey in Gandi’s Name field, not the complete hostname. Gandi will associate that label with example.com.

Be careful with CNAME targets too

The Name field is relative to your domain, but the Value of a CNAME is a destination hostname. That destination is often outside your domain, such as mta1.provider-dkim.example.net. Enter the provider’s destination exactly as supplied.

Gandi’s own CNAME examples instruct users to use a trailing period for a fully qualified CNAME destination in DNS-style entry. If the provider supplies a target ending in a dot, keep it. If Gandi’s current form normalizes or displays the completed destination differently after saving, compare the resulting public DNS answer rather than trying to rewrite a value based on guesswork.

A helpful mental model is:

• Name tells Gandi where under your domain to publish the record.
• Value tells DNS what the record contains or where it points.
• A CNAME Value is usually a provider-controlled hostname, not your own domain with an extra suffix.

Add and merge your SPF record

SPF is a DNS TXT policy that identifies which mail systems are allowed to send for a domain used in the SMTP envelope sender, often reflected in the Return-Path header. The policy starts with v=spf1 and then lists authorization mechanisms, commonly include, ip4, ip6, a, or mx.

Although some DNS products still display an SPF record type, publish modern SPF as a TXT record. The dedicated SPF DNS resource-record type was deprecated; RFC 7208 specifies TXT as the practical deployment method. In Gandi, choose TXT for SPF.

Start by finding your existing SPF policy

Before adding a new SPF entry, search the root domain’s current TXT records for a value beginning with v=spf1. If one exists, edit and merge it. Do not create a second independent SPF policy at the same hostname.

For example, imagine your root-domain SPF policy is already:

v=spf1 include:_spf.google.com ~all

Your email-sending platform then tells you to add:

include:spf.email-provider.example

The result should be one merged value:

v=spf1 include:_spf.google.com include:spf.email-provider.example ~all

Do not publish both values as separate TXT records. Multiple SPF records at one host can cause receivers to return a permanent SPF error instead of selecting one policy.

Choose the right host for SPF

For a typical sending domain where mail uses addresses like hello@example.com, SPF is often published at the root:

• Type: TXT
• Name: @ or blank, depending on Gandi’s root-domain representation
• Value: one complete v=spf1 ... policy

However, some email platforms use a custom envelope-sender or return-path subdomain such as bounce.example.com. In that architecture, the provider may ask for SPF at bounce, not at the root. Follow its instructions exactly. An SPF record at example.com does not automatically become an SPF record at bounce.example.com.

Do not end with -all until you know every sender

SPF qualifiers matter. -all expresses a hard fail for infrastructure not authorized by the policy; ~all is a soft fail; ?all is neutral. The best end state depends on whether you have inventoried every system sending mail using that envelope domain.

Common senders people forget include:

• Google Workspace or Microsoft 365.
• Website contact-form plugins and ecommerce platforms.
• Customer-support systems and help desks.
• Invoice, HR, CRM, and scheduling tools.
• Legacy SMTP relays used by application servers.
• Transactional and campaign-email providers.

A restrictive SPF record can be correct, but only after the sender inventory is correct. Adding a sending platform without reviewing the existing policy can create a problem just as easily as leaving it out.

Watch the SPF DNS lookup limit

Each include can lead to further DNS lookups. SPF evaluation has a limit of ten DNS-mechanism lookups. Large organizations often exceed that limit by accumulating SaaS providers over time. When that happens, SPF may return a permanent error, and an otherwise legitimate message may fail SPF.

This is another reason not to bolt on a new record every time a tool is added. Maintain one intentional SPF policy, remove former providers, and evaluate whether every include is still required. DKIM alignment can give DMARC a second route to pass, but it does not make an invalid SPF policy harmless.

Add DKIM records without confusing TXT and CNAME

DKIM signs an email with a private key and lets receivers retrieve the matching public key from DNS. The signature includes a signing domain, usually shown in a d= tag, and a selector, shown in an s= tag. A receiver combines those values to look up a record under the _domainkey namespace.

If the selector is mta1 and the signing domain is example.com, the lookup name is:

mta1._domainkey.example.com

That is why Gandi’s Name field normally receives mta1._domainkey rather than the full hostname.

Direct DKIM TXT records

Some services give you a long TXT value like this:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

For that form, create:

• Type: TXT
• Name: <selector>._domainkey
• Value: the complete DKIM value supplied by the service

Do not add quotation marks unless Gandi’s editor inserts them as part of its own display. Do not insert spaces, line breaks, or copied smart quotes into the public-key value. DNS software can represent long TXT values in chunks, but you should paste the content into Gandi exactly as the service provides it and let the DNS interface handle storage formatting.

DKIM CNAME delegation

Many email platforms ask for DKIM CNAME records rather than a long public-key TXT record. This delegates the selector location to the provider, which can make key management and rotation easier for the provider.

A provider might give instructions conceptually like:

• Type: CNAME
• Host: mta1._domainkey
• Value: mta1.example.provider-dkim.net.

In Gandi, add a CNAME with Name mta1._domainkey, then paste the target in Value. If the provider gives three DKIM selectors, create all three. One missing selector can leave part of a provider’s signing setup unverified, especially during key rotation.

Never create both a TXT and CNAME record at the same DKIM hostname. A CNAME cannot coexist with other record types at that exact name. If the provider says CNAME, use CNAME. If it says TXT, use TXT.

DKIM alignment is what makes it useful for DMARC

A DKIM signature can pass cryptographically but still not satisfy DMARC if the signing domain does not align with the visible From domain. For mail sent as billing@example.com, a DKIM d= domain of example.com aligns. A signature from only provider-mail.example generally does not align with example.com.

This is why domain verification in an email platform should result in DKIM records under your domain. It lets the provider sign as your domain or an aligned subdomain, rather than only with its shared infrastructure domain.

Publish a DMARC policy safely

DMARC is a TXT record published at _dmarc that tells receiving systems how to evaluate mail claiming to be from your domain. It relies on SPF and DKIM results, but its key feature is alignment with the visible From address that recipients see.

For example.com, a basic monitoring record is:

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

In Gandi, publish it as:

• Type: TXT
• Name: _dmarc
• Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

The p=none policy asks receivers to monitor and report rather than quarantine or reject mail solely because it fails DMARC. It is the right starting point for many domains because it creates visibility before enforcement.

A practical DMARC rollout

DMARC is safest as a measured rollout, not a copy-and-paste trip directly to p=reject.

1. Publish p=none and ensure aggregate reports are delivered to a mailbox or reporting service you can actually monitor.
2. Review which domains and IP addresses send mail using your From domain.
3. Fix legitimate sources that lack aligned SPF or DKIM.
4. Remove or investigate unauthorized sources.
5. Move to p=quarantine when you understand the traffic.
6. Move to p=reject when legitimate mail is consistently passing aligned authentication.

A stricter DMARC policy can reduce spoofing, but it can also cause legitimate mail to be filtered or rejected if forgotten systems are still sending. The policy is a deployment decision, not merely a DNS formatting choice.

Use a mailbox you control for rua

The rua tag requests aggregate reports. These reports are XML files sent by participating receivers, often daily. They can be useful, but they are not easy to read manually at scale. A dedicated mailbox or reporting service prevents them from burying operational mail.

If dmarc-reports@example.com is at the same domain as the DMARC policy, no separate authorization is normally needed for that reporting destination. If you send reports to an address on another domain, DMARC may require an additional external-reporting authorization record on the destination domain. Keep the first rollout simple by using a mailbox on the same domain, or use a purpose-built DMARC reporting service that explains the required authorization records.

One DMARC record per host

As with SPF, publish one valid DMARC record at _dmarc.example.com. Do not split separate policies across several TXT records, such as one record containing p=none and another containing rua=.... DMARC expects one policy record that begins with v=DMARC1.

If a website builder, security service, or previous administrator already created a DMARC record, edit it deliberately. Preserve tags you understand and remove duplicates rather than layering a second policy on top.

Configure the return-path or bounce domain when your sender requires it

The return-path is associated with the SMTP envelope sender. It is where delivery-status notifications, such as bounces, are directed. Recipients usually see the friendly From address, while the return-path is part of the message’s delivery mechanics.

A custom return-path can improve identity consistency and can allow SPF to align with the visible From domain for DMARC. For example, mail displayed as updates@example.com might use an envelope sender under bounce.example.com. Because bounce.example.com is a subdomain of example.com, relaxed SPF alignment can succeed when SPF passes for that bounce domain.

The exact DNS requirements vary by provider. Some platforms use a CNAME to route a bounce subdomain to provider infrastructure. Others require an MX record and a TXT SPF record for a custom MAIL FROM domain. Do not assume all return-path setups use a CNAME just because DKIM commonly does.

Typical CNAME-shaped return-path setup

If your provider instructs you to map a bounce host by CNAME, the record usually looks like this:

• Type: CNAME
• Name: bounce
• Value: a provider hostname, such as bounce.provider-mail.example.

This creates bounce.example.com, provided the domain is example.com. Do not type bounce.example.com in Gandi’s Name field if the editor is appending the zone automatically.

Avoid conflicting records on the bounce host

A hostname that is a CNAME cannot also have TXT, MX, A, or other records at the same exact hostname. If you already use bounce.example.com for something else, choose a different unused subdomain only if your provider permits a custom label.

Likewise, do not place the return-path CNAME at the root domain. CNAME records are for subdomains, and the root normally needs other records such as NS, SOA, MX, and TXT. Gandi’s own documentation notes that CNAME cannot be used at the bare domain.

Save, wait, and verify the public DNS result

After adding each record, save it in Gandi and verify what public DNS resolvers can see. Gandi states that newly created LiveDNS records are updated in its zone in real time, but internet-wide visibility still depends on DNS caching and the record TTL. Treat successful saving in the dashboard as the start of verification, not the final proof.

Use your email platform’s domain-verification tool first, because it checks the exact names and record types it expects. If it still shows a record as missing, verify these basics:

• You edited the DNS provider serving the active nameservers.
• The Gandi Name field contains the relative host, not the full domain repeated twice.
• The record Type matches the provider instruction exactly.
• A DKIM CNAME does not conflict with a TXT record at the same host.
• The CNAME target was copied exactly, including a final dot where the provider or Gandi’s DNS-style examples require it.
• The SPF policy is one combined record, not several v=spf1 records.
• The DMARC record is at _dmarc, not at the root domain.
• You saved the record and are looking at the public domain, not a typo or a different environment domain.

You can also inspect a received test message. In a mailbox that exposes original headers, look for authentication results such as spf=pass, dkim=pass, and dmarc=pass. The results should correspond to the domain used in your visible From address. A provider dashboard may show DNS verification as successful before a specific message has been sent with the final intended From domain, so send a real test after verification completes.

For application-specific domain verification and sending details, consult the email API setup documentation alongside this DNS guide.

Troubleshoot common Gandi DNS and email-authentication failures

The provider says the DKIM record is missing

First compare the requested hostname with the hostname you actually published. If the required name is s1._domainkey.example.com and Gandi shows s1._domainkey.example.com.example.com, the Name field was entered as a full hostname instead of s1._domainkey.

Next compare types. A TXT DKIM key and a CNAME DKIM delegation are different configurations. Publishing the right text value under the wrong Type does not satisfy a CNAME lookup, and publishing a CNAME where the provider expects a direct TXT public key does not satisfy a TXT lookup.

SPF fails after adding a new sending service

Look for multiple root-domain TXT records beginning with v=spf1. Consolidate the applicable mechanisms into one policy. Then check whether the new service sends using the root domain or a custom return-path subdomain; the SPF policy must exist at the domain the service uses in the envelope sender.

Also inspect the policy’s lookup complexity. Excessive nested includes can lead to SPF permanent errors. Remove obsolete providers rather than treating the SPF record as an unlimited list.

DKIM passes but DMARC still fails

This usually means alignment is missing. Read the message headers or the sending platform’s event details to identify the DKIM signing domain in d=. It needs to align with the visible From domain under the chosen DMARC alignment mode.

A second possibility is that the From address uses a different domain than the verified sending domain. For example, verifying example.com does not automatically make example.co or an unrelated brand domain aligned.

DMARC reports do not arrive

Check that the rua address is spelled correctly and can receive mail. Remember that not every receiver sends reports, reports can arrive on a delayed cadence, and XML attachments may be filtered or routed unexpectedly.

If the reporting destination is on a different domain, investigate the external report authorization requirement. A simpler first configuration is an rua mailbox at the same organizational domain as the DMARC record.

Your website or inbound mail stopped working after DNS edits

Email-authentication records should be additive. They should not require replacing your website A or CNAME records, your inbound-mail MX records, or other unrelated DNS entries. If a service stopped working, review recent changes for an overwritten record or an accidental CNAME conflict.

This risk is highest when changing nameservers or editing a whole zone in text mode. Restore only the specific affected record after confirming its intended value; do not delete records broadly in an attempt to make an email platform’s verification screen turn green.

A clean operating model for authenticated sending

The durable goal is not merely to pass a one-time domain check. It is to maintain a clear model of which systems may send as your domain, which domains they use for return paths, and which DKIM selectors they control.

Keep a small DNS change log with the date, platform, record names, purpose, and owner. This makes future migrations and incident response much easier. A DKIM selector such as mta1._domainkey may look meaningless six months later, but it can be a live production dependency for an application, marketing platform, or support desk.

Review the configuration whenever you add or remove a sender. When removing a vendor, first stop sending through it, confirm it no longer signs or uses the return-path domain, and then remove its SPF include, DKIM selectors, and provider-specific verification records if they are no longer needed. Removing DNS records too early can cause active mail to fail authentication; leaving them forever can create clutter and uncertainty about who is authorized to send.

For the strongest DMARC posture, aim for legitimate email to pass aligned DKIM even if SPF is complicated by forwarding or a custom envelope-sender design. Keep SPF accurate, but treat DKIM as the dependable cryptographic identity layer for each sending platform and use DMARC reporting to confirm real-world behavior.

Final checklist

Before considering your Gandi SPF DKIM DMARC setup complete, confirm all of the following:

• Your active nameservers point to Gandi LiveDNS, or you published the records at the actual external DNS provider.
• You reached the correct Gandi screen through Domain → your domain → DNS Records.
• SPF is published as one TXT policy at the correct envelope-sender domain.
• Every provider-required DKIM record exists with the correct selector, Type, and Value.
• DKIM CNAME names use relative labels in Gandi, such as s1._domainkey.
• Your DMARC TXT record is at _dmarc and begins with v=DMARC1.
• Your DMARC policy starts in monitoring mode unless you have audited all legitimate senders.
• Any custom return-path record follows the exact Type and hostname pattern required by the sending platform.
• The provider’s verification screen recognizes the public DNS records.
• A real test message shows aligned authentication results, ideally including dkim=pass and dmarc=pass.

FAQ

Where do I find DNS records in Gandi?

As of writing, sign in to Gandi, choose Domain in the left navigation, select your domain, and open DNS Records. This works when the domain uses Gandi LiveDNS; if it uses external nameservers, edit DNS with that external provider instead.

Should SPF be a TXT record or an SPF record in Gandi?

Use a TXT record. SPF policies begin with v=spf1, but the separate DNS SPF record type is deprecated. Keep one combined SPF policy at each hostname.

What do I enter in Gandi’s Name field for a DKIM record?

Enter the relative DKIM hostname, such as selector._domainkey. Gandi appends your domain, producing selector._domainkey.example.com. Avoid entering the full hostname unless Gandi’s current interface explicitly indicates otherwise.

Can I have more than one DKIM record?

Yes. Multiple DKIM selectors are normal, especially when several sending platforms or key rotations are involved. Each selector uses a distinct hostname. Do not publish a TXT and CNAME record at the same selector hostname.

Should I set DMARC to reject immediately?

Usually no. Start with p=none, review aggregate reports, fix legitimate sources that do not pass aligned SPF or DKIM, then move gradually to quarantine and reject when the domain’s sending inventory is understood.