IONOS: SPF, DKIM and DMARC for mail and the DNS zone

example.com.  TXT  "v=spf1 include:_spf-eu.ionos.com ~all"

DMARC: the _dmarc TXT

The DMARC record is a TXT published under the _dmarc subdomain:

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

One always starts at p=none: the policy enforces nothing, but the rua= address triggers the aggregate reports that will serve to verify everything before tightening. In the IONOS DNS interface, the name field expects the relative subdomain _dmarc — the platform completes the domain. The records broken down line by line detail the tags to keep. Under DMARCbis, subdomain attachment is determined by the DNS tree walk, without changing how the record is published at IONOS.

DMARC alignment: the favourable case

DMARC only validates a message if SPF or DKIM passes and aligns with the From domain. IONOS mail sits in the favourable case, like classic mail hosting. On the DKIM side, the signature carries the domain itself — alignment is direct. On the SPF side, the message envelope is also on the domain, since IONOS hosts that domain's mail: SPF therefore aligns naturally.

Two mechanisms pass aligned, and that redundancy protects: if a forward breaks SPF, DKIM survives, and vice versa. It is the foundation that licenses calmly aiming at a strict policy — once coverage is confirmed by the reports. Data residency plays a complementary role here: all mail processing and its associated logs stay within the European Union, a point that matters for organisations subject to localisation requirements, even if it changes nothing in the alignment mechanics.

The European positioning is not merely a compliance checkbox. For organisations whose recipients or regulators expect data to stay within the EU, keeping DNS, mail and their logs at a European host removes a whole category of questions during an audit. IONOS's alignment mechanics are the same as any host's — but the answer to "where does our mail data live?" is simpler, and that simplicity has a value of its own that a purely technical comparison misses.

DNS at IONOS or delegated elsewhere

As with any host, a preliminary check avoids the most frustrating error: making sure the domain's DNS zone is really managed by IONOS. A domain can be registered at IONOS but have its name servers delegated to another provider; in that case, IONOS's DNS interface shows a zone that is no longer authoritative, and the records added there are never served.

This check matters all the more at IONOS because automatic DKIM publication depends on it: it only publishes the record on its own if the zone is at IONOS. Zone delegated elsewhere ⇒ DKIM enabled in the mail area but a record to publish by hand in the other interface. Forgetting this step leaves a DKIM "enabled" on the IONOS side but absent from the effective DNS — a mismatch that explains many missing signatures in the reports.

IONOS mailbox or resold Microsoft 365

IONOS does not sell just one mail service. Alongside its in-house mailboxes, it resells Microsoft 365 — and the SPF include is not the same. A classic IONOS mailbox goes through _spf-eu.ionos.com; a Microsoft 365 subscribed via IONOS sends through Microsoft's infrastructure, and its include is include:spf.protection.outlook.com. Confusing the two is a variant of the legacy trap: the domain carries an include that does not match the actually sending service, and SPF fails.

The reflex is the same as for any host reselling several products: identify which is actually active — the in-house mailbox or the resold Microsoft 365 — before freezing the include. A domain migrated from one to the other without revisiting its SPF drags along an outdated include, a source of failures with no apparent cause. This case is all the more frequent because IONOS presents both offerings in the same purchase flow.

DKIM key rotation

When the zone is at IONOS, automatic DKIM enabling also simplifies rotation: IONOS handles key renewal on its side, with no manual intervention on the zone. This handling is an asset — rotation, often neglected when it requires a manual edit, becomes a non-event, and an old key does not linger.

When the zone is delegated elsewhere, however, rotation becomes manual again: each new key IONOS publishes must be carried over into the external DNS interface, following the overlap principle — publish the new one before removing the old one, so as not to open a window without a valid signature. It is the same logic as any signing-key renewal, simply done by hand rather than automatically.

Common configuration mistakes

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

Keeping the legacy 1&1 includes. _spf.perfora.net / _spf.kundenserver.de stacked with the current include bloat the record and edge toward permerror.

Enabling DKIM without publishing the key (delegated zone). DKIM ticked in the mail area, but the zone being elsewhere, the record was never placed: no valid signature.

Publishing two SPF records. Two v=spf1 invalidate SPF entirely; the includes must be merged into one.

Confusing IONOS mailbox and resold Microsoft 365. Publishing _spf-eu.ionos.com for a domain that actually sends via resold M365 (or the reverse): the include does not cover the real servers, and SPF fails.

Tightening the policy too early. Moving to p=reject before confirming through reports that all legitimate traffic aligns means rejecting one's own messages — all the more penalising when IONOS mail carries the daily business correspondence.

The final proof: RUA reports

The only proof that a configuration holds is not the IONOS area, but what recipients report. Once a _dmarc record is published with a rua= address, aggregate reports arrive within a few days and detail, source by source, what aligns and what fails. Reading the daily returns from the mailbox providers confirms that IONOS traffic is properly attributed to the domain: DKIM aligned, SPF aligned, and no source failing both.

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. One checks in particular that the chosen SPF include covers all IONOS sources and that no 1&1 legacy skews the picture. 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.