Infomaniak: SPF, DKIM and DMARC for mail

example.com.  TXT  "v=spf1 include:spf.infomaniak.ch ~all"

DKIM: automatic or manual

DKIM follows the same logic as the rest. When the zone is at Infomaniak, the assistant generates the key pair and publishes the DKIM record on its own; the signature produced carries d=example.com, the domain itself, and DKIM alignment is secured from the outset, even in strict mode. When the zone is managed elsewhere, Infomaniak provides the DKIM value to publish manually in the other DNS interface. The key provisioned is a robust length (2048-bit), expected by the major providers; it is a healthy default with no reason to weaken it.

Rotation follows this same split: automatic and transparent when the zone is at Infomaniak, manual otherwise — with the usual overlap principle (publish the new key before removing the old one). It is the same logic as any key renewal, step by step, with the handling added when everything is in one place.

DMARC: the starting record

The DMARC record is a TXT under the _dmarc subdomain:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:reports@example.com"

The assistant often proposes one at p=none with a reporting address. That is exactly the right start: the policy enforces nothing, but the aggregate reports begin to flow. The annotated examples, tag by tag detail the tags to adjust (sp, adkim, aspf) for what follows. Under DMARCbis, subdomain attachment is determined by the DNS tree walk, without changing how the record is published.

DMARC alignment: the favourable case

DMARC only validates a message if SPF or DKIM passes and aligns with the From domain. Infomaniak mail sits in the favourable case. On the DKIM side, the signature carries the domain itself — alignment is direct. On the SPF side, the envelope is on the domain, since Infomaniak hosts the mail: SPF aligns naturally. Two mechanisms pass aligned, and that redundancy protects if either drops along the way.

It is this double coverage that licenses aiming at a strict policy once the reports confirm it — a goal the assistant prepares but does not cross on its own.

DNS at Infomaniak or managed elsewhere

A preliminary check conditions everything else: knowing whether the DNS zone is really at Infomaniak. That determines whether the assistant can publish the records itself, or whether they must be carried over by hand into another interface. A domain registered at Infomaniak but whose name servers are delegated elsewhere will see the assistant propose values it cannot publish — and if one forgets to carry them over, authentication stays incomplete despite an interface that seems to have "done everything".

The check is quick: the domain's effective name servers read in an NS query. If they point to Infomaniak, the assistant is authoritative; otherwise, it is in the interface that really manages the zone that SPF, DKIM and DMARC must be published, using the values Infomaniak provides.

Swiss data sovereignty

Infomaniak's sovereignty argument deserves a useful nuance. Switzerland is not in the European Union, but it benefits from an adequacy decision recognising its level of data protection as equivalent — personal-data flows from the EU to Switzerland are therefore framed with no additional mechanism. For an organisation keen to keep its mail outside non-European jurisdictions, a Swiss host is a coherent option, distinct both from an intra-EU host and from an actor subject to extraterritorial access laws.

This changes nothing in the mechanics of SPF, DKIM or DMARC — alignment is reasoned about the same way everywhere — but it weighs in the choice of a host, and it is consistent with the rest of Infomaniak's positioning. The location of mail data and its associated logs is among the questions a regulated organisation must be able to settle clearly — and a host that answers it plainly makes preparing an audit that much simpler.

Common configuration mistakes

Several traps recur in the body of reports the free DMARC analyzer processes daily.

Trusting the assistant blindly without verifying. The assistant places good records, but a third-party service added afterward, or a delegated zone, escapes its view: the reports stay the arbiter.

Delegated zone: forgetting to carry over the values. DKIM "configured" on the Infomaniak side but never published in the effective zone: no valid signature.

Publishing two SPF records. Adding an ESP as a second v=spf1 instead of a merged include invalidates SPF entirely.

Believing DMARC "done" because the assistant ran. The assistant places the record at p=none: the domain is observed, not yet protected. Protection comes only with tightening, decided after reading the reports — a step the assistant, prudently, does not cross on its own.

Tightening the policy too early. Conversely, moving to p=reject before confirming through reports that all legitimate traffic aligns means rejecting one's own messages.

The final proof: RUA reports

The only proof that a configuration holds is not the Infomaniak interface, but what recipients report. Once a _dmarc record is published with a rua= address — which the assistant often proposes from the start — aggregate reports arrive within a few days and detail, source by source, what aligns and what fails. Reading the reports the receivers send back confirms that Infomaniak traffic is properly attributed to the domain, and above all reveals any source other than Infomaniak — an ESP, an application — that the assistant did not cover.

A simple cadence is enough: a first read a few days after configuration, once several recipients have reported, then a weekly glance while the policy stays at p=none. It is the confirmation that all legitimate sources align — Infomaniak and the others — that licenses tightening. Once that coverage is confirmed over several days, the move to p=reject carries no risk. The online analyzer reconstructs this state from the published records and the reports received, and places the domain on the path that leads to p=reject.