Infomaniak SPF, DKIM and DMARC setup, step by step

For a custom domain sending through Infomaniak Mail Service, the documented SPF authorization is include:spf.infomaniak.ch. DKIM is enabled by default when Infomaniak manages the DNS zone. With external DNS, open Mail Service → your service → Global Security → DKIM → View and publish the exact record type, full name and complete value shown there. Then verify that a fresh message has a passing, domain-aligned Infomaniak DKIM signature and a trusted receiver's DMARC pass. Infomaniak DKIM · Global Security

This guide covers existing custom-domain Mail Services, including a Mail Service used within kSuite, sending through the Infomaniak Mail app or Infomaniak's official outgoing mail service. It does not configure free provider-domain addresses, a standalone Newsletter workflow, another vendor's SMTP service, or a mail server you operate yourself.

On this page: Preparation · SPF · DKIM · External DNS · DMARC · Verification · Troubleshooting · FAQ

Preparation

You need an active Mail Service for the domain, Manager access to that service's Global Security settings, and permission to edit the authoritative DNS zone. Infomaniak's automatic changes require the relevant organization/domain administrative rights. When DNS is elsewhere, involve its owner or technical administrator. A mailbox password alone is not enough to manage domain authentication. Mail Service prerequisites

Identify three things before changing a record:

• The sending route: which application or mail client submits messages to which SMTP service. A From address ending in your domain does not prove the message passed through Infomaniak.
• The DNS authority: the nameservers serving the live zone. A domain registered at Infomaniak can use an external DNS host, and a website hosted elsewhere does not necessarily mean DNS moved there.
• Existing dependencies: save the current SPF policy, DKIM selectors, _domainkey delegations and direct or inherited DMARC policy. Include other legitimate senders such as a CRM, invoices, helpdesk and marketing service.

Keep incoming mail routing separate. MX records select the incoming mail service; changing them is not a routine repair for an outgoing SPF or DKIM problem. Infomaniak's external-website procedure includes MX because it also covers restoring incoming mail, a broader task than authentication. External-service connection

SPF

Use the actual SPF owner

Infomaniak documents this default for a domain whose only authorized sending service is Infomaniak:

Owner: example.com
Type: TXT
Value: v=spf1 include:spf.infomaniak.ch -all

Replace example.com with your domain. This is a new, Infomaniak-only policy example, not a replacement for a policy that already authorizes other services. The included domain is spf.infomaniak.ch, without a leading underscore. Official SPF record and editor

SPF evaluates the SMTP envelope sender, normally reported as smtp.mailfrom in the receiver's results. It does not directly evaluate the visible From address. Inspect that identity on an actual message: if it uses a separate subdomain, the apex SPF policy does not automatically apply there. Do not invent a custom Return-Path setting or assume every Infomaniak route uses an identical envelope address.

For the apex of an example.com zone, a DNS editor may use @, an empty name, or the full name. Follow its convention and verify the resulting owner is exactly example.com. The include: value belongs inside the TXT content, not in the record's name field.

Review automatic corrections before applying them

In Manager, select the Mail Service and open Global Security. The SPF section offers editing or correction depending on the status. For Infomaniak-managed DNS, you can also open the domain's DNS Zone and inspect its TXT records. For external authoritative DNS, make the change at that provider, not in an unused Infomaniak zone.

Do not accept a suggested Infomaniak-only policy without comparing it with the current value. The Global Security documentation's SPF dialog illustrates an existing policy with another sender and a recommendation containing only Infomaniak. Automatically replacing it could deauthorize the other sender.

If a policy already exists, merge the required include:spf.infomaniak.ch into that single policy before its terminal all, retaining other justified mechanisms and the existing failure qualifier unless an intentional policy change is approved. Resolve an existing redirect= configuration with the DNS administrator rather than appending an all that silently disables the redirect. Never publish two separate TXT records beginning v=spf1 at the same owner. Leave unrelated TXT verification records untouched.

Evaluate the complete policy against SPF's maximum of ten DNS-query-causing terms, including nested includes, a, mx, exists and redirect. Ten visible includes is not the rule, and Infomaniak's nested records can change. Do not hardcode a snapshot of its IP addresses to work around a lookup error. See the SPF standard and EmailAuth's SPF explanation.

-all returns SPF fail for an otherwise unmatched sender; ~all returns softfail and ?all returns neutral. Receivers decide what to do with those results. None of these suffixes promises acceptance, rejection or inbox delivery.

DKIM

Infomaniak-managed DNS

Infomaniak says DKIM is enabled by default for Mail Services whose DNS zone it manages, with signing on messages sent through its supported mail service. Start by checking, not generating a second key:

1. Sign in to Manager and open Mail Service.
2. Select the correct service/domain.
3. Open Global Security.
4. In DKIM, select View.
5. Record the displayed DNS record type, complete owner name and complete value. Check the service's DKIM status, then validate public DNS and a delivered message as described below.

If the service is already enabled and its records are correct, no manual key upload is needed. Do not create your own key pair or request a private key as part of this managed-mail workflow. When a correction is necessary, resolve it for the selected service without removing other providers' selectors. Current DKIM procedure

Retrieve the record for external DNS

The same Global Security → DKIM → View screen supplies the record for an externally managed zone. Current Infomaniak documentation supports this branch; it is not limited to domains whose DNS is at Infomaniak. Copy your service's values, not a date-style selector or key from a screenshot. The external-service guide allows TXT or CNAME according to what the service supplies. External DNS instructions

For a TXT record, preserve the entire tagged value shown in Manager, including v=DKIM1, p= and any other supplied tags. The long string after p= is only the public-key data, not the entire DNS value. Preserve every character; never publish a private key.

External DNS

Map the complete owner, including _domainkey

The following names are illustrative, not an Infomaniak-issued selector:

Use the full owner from Manager to determine which case applies. A generic DNS editor does not infer the DKIM _domainkey label merely because you enter a bare selector. If it accepts a fully qualified name, confirm it will not append the domain again.

Cloudflare caution: Infomaniak's Cloudflare FAQ currently contains abbreviated name/value instructions that conflict with its own Manager screenshot. Use the exact Manager record, including the _domainkey owner and complete tagged TXT value, in Cloudflare's ordinary DNS record form. Do not enter only the selector and only the characters after p=. TXT records are not proxied, so there is no TXT proxy switch to disable. Infomaniak's displayed record · Cloudflare record creation · DKIM DNS format

A long TXT value can be stored as multiple quoted character strings inside one TXT record. Those strings concatenate to one value. Do not create multiple separate TXT records containing fragments of the key, and do not add display quotes as literal content unless the editor requires zone-file syntax.

Preserve delegations and literal CNAMEs

An existing NS delegation at _domainkey.example.com sends queries for its selectors to the delegated nameservers. A new selector placed only in the parent zone may therefore be invisible to receivers. Publish through the actual authority or plan a complete migration with the DNS administrator. Do not delete a delegation just to follow a generic setup shortcut: it may serve Infomaniak keys and other senders. DNS delegation

If Manager specifically supplies a CNAME, keep that record type and exact target. Do not replace it with a copied target TXT key. Use DNS-only behavior, not an HTTP proxy, and ensure neither per-record nor zone-wide CNAME flattening hides the required alias. Do not change a shared zone-wide setting without checking its other dependencies. A CNAME owner cannot also hold an unrelated TXT or address record; investigate a collision before replacing anything. These CNAME safeguards do not require changing ordinary TXT records. Cloudflare flattening controls

DMARC

Inspect the current policy before using Global Security's DMARC assistant. Preserve an existing record, its alignment settings, subdomain policy and reporting recipients. For a sending subdomain, also check applicable parent-policy inheritance. Absence of a direct _dmarc record at the subdomain does not prove there is no policy.

Only when no direct or inherited policy applies, a deliberate first, non-enforcing policy for example.com can be:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none

In an example.com zone, the relative owner is _dmarc; for mail from mail.example.com, a direct policy owner is _dmarc.mail.example.com, entered as _dmarc.mail in the parent zone or _dmarc in a separate mail.example.com zone. Publish at most one DMARC policy TXT record at the selected owner. This example does not request reports and is not an instruction to weaken existing enforcement.

Add rua only after selecting an authorized reporting destination and approving its access, retention and privacy arrangements. Aggregate reports expose sending infrastructure and authentication activity. An external destination with a different organizational domain needs the report receiver's DNS authorization; obtain its exact onboarding instructions. Do not use an arbitrary example mailbox or enable failure reports by default. DMARC policy · External report authorization

Verification

Check authoritative DNS and a public resolver

Replace all example names and SELECTOR below. Query the actual authoritative nameserver as well as a normal recursive resolver; an online DNS lookup can perform the same checks.

dig +short NS example.com
dig +short TXT example.com
dig +short TXT SELECTOR._domainkey.example.com
dig +short CNAME SELECTOR._domainkey.example.com
dig +short TXT _dmarc.example.com

Expect one complete SPF policy at the actual envelope domain, the Manager-issued DKIM record at the exact selector owner, and the intended DMARC policy. For a CNAME, also resolve the target's public key. If _domainkey is delegated, check the delegated authority rather than treating a parent-zone edit as publication. Compare cached answers after the previous TTL expires. Infomaniak warns DNS changes may take up to 48 hours, but waiting cannot correct a wrong owner or missing tag.

Prove the intended signature works

Send a fresh message through the Infomaniak Mail app and separately through each production client/SMTP route you need to validate. Keep the intended visible From address unchanged. Inspect raw headers at a receiving system you control or trust:

• Record the visible From domain and SPF's smtp.mailfrom domain and result.
• Find the Infomaniak-generated signature's d= signing domain and s= selector. Confirm the receiver reports DKIM pass for that signature, not merely another signature added by a gateway.
• Check that d= aligns with the From domain under the applicable adkim mode. Relaxed alignment permits the same organizational domain; strict alignment requires an exact match.
• Require the trusted receiver's DMARC pass for that From domain. DMARC needs a passing aligned SPF or DKIM path, but a pass supplied only by SPF does not prove this DKIM setup is complete.

A valid SPF result for an unaligned envelope domain cannot supply DMARC's SPF path. Conversely, actual spf=fail, temperror or permerror still needs investigation even when aligned DKIM passes. Diagnose the sending IP, evaluated domain, policy and DNS error instead of calling every SPF problem an alignment limitation.

Trust only authentication results genuinely added inside the receiving infrastructure's trust boundary. Attackers can prepend Authentication-Results, including a plausible authserv-id. If the receiver cannot distinguish or remove untrusted fields, use an independent trusted mailbox or administrator's trace. Authentication-Results trust requirements

Troubleshooting

Infomaniak's DMARC troubleshooting guide specifically distinguishes wrong outgoing SMTP settings from domain-record problems. Keep a sanitized header sample, sending time, selected service, DNS answers and error text for investigation. Do not share mailbox credentials, private keys or unnecessary message content.