How to add DMARC, SPF and DKIM records on IONOS

12 June 2026 · 13 min read

IONOS (formerly 1&1 IONOS) is one of the most widely used domain registrars and hosting providers in Europe, and its DNS editor has a few quirks that catch people out when they try to publish email-authentication records. This guide walks through exactly where the records go, what to type into each field, and the IONOS-specific gotchas around the root domain, the @-versus-blank host name, TXT chunking, CNAME flattening and TTL. It is written for the modern IONOS control panel (the one with the Domains & SSL section), which is what almost everyone sees today.

The aim is not to give you a generic "add three records and you are done" recipe. SPF, DKIM and DMARC interact, and the order you publish them in decides whether you reach p=reject cleanly or start bouncing your own mail. We will cover the IONOS click path, the real record values, and the safe sequence to enforcement.

If any of the underlying concepts are unfamiliar, our glossary defines every term, and /blog/what-is-dmarc is a good primer. From here on we stay focused on doing this inside IONOS.

What IONOS actually controls (and what it does not)

A point of confusion worth clearing up first: IONOS can be three different things in your setup, and which one applies changes where your records live.

• IONOS is your registrar and your DNS host. This is the common case. You bought the domain at IONOS, and IONOS answers DNS queries for it. You edit records in the IONOS DNS panel. This guide assumes this case.
• IONOS is your registrar, but DNS is delegated elsewhere (for example to Cloudflare or Route 53). Then the IONOS DNS panel is irrelevant: you set name servers at IONOS, but you create the TXT and CNAME records wherever the name servers point. Check this first, because editing IONOS records that nothing reads is a classic time sink.
• IONOS hosts your mailboxes (IONOS Mail Business, or the free mailbox bundled with a hosting pack). This matters because IONOS-hosted mail has its own SPF include and its own DKIM mechanism, which we cover below.

To confirm IONOS is the authoritative DNS host, run your domain through our DMARC checker or any name-server lookup. If the name servers read ns1075.ui-dns.de, ns1085.ui-dns.org, ns-.ui-dns. or similar ui-dns hostnames, IONOS is authoritative and the DNS panel is where you work.

Finding the IONOS DNS editor

The DNS editor is not on the front dashboard. The reliable path is:

1. Log in at ionos.com (or your regional IONOS portal, for example ionos.de or ionos.co.uk).
2. Open Menu then Domains & SSL (older accounts call this just Domains).
3. Click the domain you want to edit.
4. On the domain overview, find the DNS tab or the Manage DNS / Adjust DNS settings link.

You will land on a table of existing records with an Add record button. The dropdown there lets you choose the record type: A, AAAA, CNAME, MX, TXT and others. SPF and DMARC are TXT records. DKIM is usually a TXT record too, though some setups (including parts of IONOS's own DKIM and most third-party senders) hand you a CNAME instead. We will be explicit about which is which.

The IONOS host-name gotcha: root, @ and blank

This is the single biggest source of mistakes on IONOS, so read it carefully before you add anything.

When you add a record, IONOS shows a Host name field (sometimes labelled Name or Subdomain). What you put there decides where the record attaches.

• To attach a record to the root of your domain (yourdomain.com itself), IONOS expects the host-name field to be left blank or set to @. In most current IONOS forms, leaving it empty is what targets the root. The interface frequently displays your domain next to the field as a suffix, so a blank box literally means yourdomain.com.
• To attach a record to a subdomain or a specific label (for example the _dmarc part of _dmarc.yourdomain.com), you type only the label prefix, not the full hostname. So for a DMARC record you enter _dmarc, and IONOS appends .yourdomain.com for you.

The classic error is typing the full name into the host field, for example _dmarc.yourdomain.com, which produces the doubled-up record _dmarc.yourdomain.com.yourdomain.com. That record exists, resolves to nothing useful, and your DMARC will read as "not found" everywhere. If a checker says your record is missing even though you just added it, suspect this first.

A quick reference for the three records:

• SPF goes on the root: host field blank (or @).
• DMARC goes on _dmarc: host field _dmarc.
• DKIM goes on selector._domainkey: host field is the selector plus ._domainkey, for example s1._domainkey or dkim._domainkey. Never the full domain.

Step 1: Publish SPF (one TXT record on the root)

SPF declares which servers are allowed to send mail using your domain in the envelope sender (the MAIL FROM / return-path). It is a single TXT record on the root of your domain, and you may have only one SPF record. Multiple v=spf1 records is a permanent error that breaks SPF entirely.

In IONOS, click Add record, choose TXT, and fill in:

• Host name / Name: leave blank (this is the root).
• Value / Points to: your SPF string, for example:

v=spf1 include:_spf.perfora.net include:_spf.kundenserver.de -all

That example is the SPF record for mailboxes hosted on IONOS Mail itself: _spf.perfora.net and _spf.kundenserver.de are IONOS's outbound mail systems. If IONOS hosts your mail, those two includes are what you need. If you send through other services, you add their includes too. For example, a domain on IONOS mail that also sends marketing through a separate provider might publish:

v=spf1 include:_spf.perfora.net include:_spf.kundenserver.de include:servers.mcsv.net -all

A few IONOS-specific points:

• Do not wrap the value in quotation marks yourself. Some DNS panels want you to add quotes; IONOS does not. Paste the bare string. IONOS stores it correctly and presents it with quotes to resolvers internally.
• End with -all (hard fail) or ~all (soft fail). While you are still testing alignment, ~all is more forgiving. Once you are confident every legitimate sender is listed, tighten to -all.
• Watch the ten-lookup limit. SPF allows a maximum of ten DNS lookups across all your include, a, mx and redirect mechanisms. Each include can trigger several. Add three or four sending services and you can quietly blow past ten, at which point SPF returns permerror and fails. The IONOS panel will happily save an over-limit record; it does no validation. Test the finished record with our SPF checker, which counts the lookups for you. If you are over, see /blog/spf-permerror-10-lookups, and consider SPF flattening, explained in /docs/how-spf-flattening-works.

If you already have an SPF record on the domain, edit the existing one rather than adding a second. Merge the new includes into the single record.

Step 2: Publish DKIM (selector record, TXT or CNAME)

DKIM adds a cryptographic signature to each message that receivers verify against a public key you publish in DNS. The key lives at a selector under the special _domainkey zone. The selector name is chosen by whoever signs your mail, so you take it from your provider, not from a template.

If IONOS signs your mail

IONOS Mail can sign outbound mail with DKIM, but in many IONOS plans this is enabled from the Email area of the control panel rather than typed by hand into DNS. Look in Email then your mailbox or domain settings for a DKIM or Email authentication toggle. When IONOS manages both your mail and your DNS, switching DKIM on there often publishes the required record into your zone automatically. After enabling it, confirm the record actually appeared by checking the selector with our DKIM checker.

If a third party signs your mail

Most external senders (Google Workspace, Microsoft 365, Mailchimp, SendGrid, Brevo and so on) give you DKIM as one of two shapes:

• A TXT record containing the public key, like:

Host:  s1._domainkey
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...long base64...IDAQAB

• A pair of CNAME records that point at the provider's hosted keys, like:

Host:  s1._domainkey       Points to: s1.domainkey.u123456.wl.sendgrid.net
Host:  s2._domainkey       Points to: s2.domainkey.u123456.wl.sendgrid.net

In the IONOS Host name field you enter only the selector prefix, for example s1._domainkey, never the full s1._domainkey.yourdomain.com. IONOS appends the domain.

Two IONOS quirks bite here:

• CNAME values must be exact and usually end in a trailing dot upstream. IONOS generally manages the trailing dot for you, so paste the target host exactly as your provider gives it and do not add or remove a dot unless the resulting record fails to resolve. Verify with the DKIM checker once propagation completes.
• A record cannot be both CNAME and anything else at the same name. If IONOS already auto-created something at s1._domainkey (for instance from an earlier mail setup), adding a CNAME there will conflict. Remove the stale record first.

On selectors generally, /blog/dkim-selectors-explained explains why every sender uses its own, and why you will often end up with several DKIM records living side by side. That is normal and correct: each sending service signs with its own selector.

Step 3: The TXT chunking gotcha (long DKIM keys)

DNS has a hard rule that a single character string inside a TXT record cannot exceed 255 characters. A 2048-bit DKIM public key is longer than that, so it must be split into multiple quoted chunks that resolvers stitch back together.

Where this bites on IONOS: if you ever export or hand-edit a long TXT value, you must present it as concatenated quoted strings, like:

"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...first 255 chars..."
"...remaining base64...IDAQAB"

In practice, IONOS's web form accepts the full key as one continuous value and handles the 255-character splitting internally, so for a key entered through the panel you do not need to insert the quotes or line breaks yourself. The problem appears when you paste a key that already contains quotes, spaces or newlines copied from a provider's instructions. Those stray characters become part of the stored value and corrupt the key. The fix is to paste one clean unbroken base64 string with no internal quotes and no line wrapping. If your DKIM verifies as "key not found" or "syntax error" after publishing, this is the most likely cause. Re-copy the key, strip any whitespace, and re-enter it.

This 255-character limit is also why DKIM is increasingly handed out as a CNAME: the provider holds the long key on its own infrastructure and you publish only a short pointer. If your provider offers a CNAME option, it sidesteps chunking entirely and is the easier route on IONOS.

Step 4: Publish DMARC, starting at p=none

DMARC ties SPF and DKIM to the domain your recipients actually see in the From address, and tells receivers what to do when a message fails. Crucially, it is also how you get reports, which you need before you ever tighten the policy.

Add it as a TXT record:

• Host name / Name: _dmarc
• Value:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com; fo=1

Start at p=none. This is monitor-only: it changes nothing about delivery, but it switches on the daily aggregate reports (rua) from Gmail, Yahoo, Microsoft and the rest, so you can see every source sending as your domain before you enforce anything. Moving straight to p=reject without first reading reports is how legitimate mail gets blocked. /blog/p-none-false-security explains why p=none is a starting line and not a destination.

IONOS notes for this record:

• The host field is _dmarc, not _dmarc.yourdomain.com. (Same root-versus-label rule as everywhere on IONOS.)
• The rua and ruf addresses can be at any domain. If you want them at a different domain from the one you are protecting, that other domain must publish an authorisation record. A monitoring service handles this for you; if you point reports at our platform you do not manage that authorisation by hand.
• Aggregate reports are XML and arrive daily. They are not meant to be read by eye. Feed them to our DMARC report analyzer, or set up emailed monitoring at [/monitor] so the parsing and the change alerts happen for you. /blog/reading-your-first-dmarc-report shows what to look for.

Generate a correct DMARC string for your domain with our DMARC generator if you would rather not hand-write the tags.

Step 5: The TTL question on IONOS

TTL (time to live) is how long resolvers cache a record before re-checking. IONOS lets you set TTL per record, often via an advanced or expert view on the add-record form; some plans hide it and default to one hour (3600 seconds).

Practical guidance specific to this work:

• While you are still changing records, a low TTL (300 to 600 seconds, that is 5 to 10 minutes) is your friend. It means a mistake propagates out and a fix propagates back quickly. If IONOS only exposes a default, that default is usually short enough not to cause real pain.
• Once everything is verified and stable, you can raise TTL (3600 seconds or higher) to reduce lookups, but there is little practical benefit for these small records, so leaving it at the default is perfectly fine.
• TTL affects how long you wait, not whether the record is right. After you save, IONOS DNS typically reflects changes within minutes, but global propagation can take up to the old TTL plus IONOS's own update interval. If a checker still shows the old value, give it the TTL window before assuming something is wrong. You can watch propagation with our DNS propagation checker.

One IONOS-specific timing wrinkle: changes made in the IONOS panel sometimes take a little longer to become authoritative than the per-record TTL implies, because IONOS rebuilds the zone on its own schedule. If you have triple-checked the values and a checker disagrees, wait an hour before changing anything else. Repeatedly re-editing a correct record only resets the clock.

Step 6: The safe sequence to p=reject

Publishing the records is the easy part. Reaching enforcement without breaking mail is the part that takes discipline. The order matters:

1. Publish SPF and DKIM first, and verify both pass and align. Use the SPF checker and DKIM checker. Alignment, not just "pass", is what DMARC cares about: see /blog/dmarc-alignment-explained.
2. Publish DMARC at p=none and collect reports for two to four weeks. Every real sender (your mailbox provider, your CRM, your invoicing tool, your helpdesk) should appear and should be passing.
3. Fix the gaps the reports reveal. Add missing SPF includes, enable DKIM on services that lack it, and resolve forwarding and alignment issues. Forwarding in particular can make SPF fail legitimately; /blog/forwarding-and-dmarc covers why and what to do.
4. Move to p=quarantine, optionally with pct= sampling to ramp gradually. Watch the reports for a fortnight.
5. Move to p=reject once the reports are clean. At this point unauthorised mail using your domain is rejected outright.

This is the same journey we describe in /docs/the-enforcement-journey and /blog/reach-p-reject-without-breaking-email. The mechanics inside IONOS are simple; the patience to read reports between each step is what protects your mail.

Common IONOS-specific failures, and how to spot them

• "Record not found" right after adding it. Almost always the doubled-domain host-name error (_dmarc.yourdomain.com typed into the host field). Re-create it with just _dmarc.
• Two SPF records. IONOS does not stop you adding a second v=spf1 TXT. Delete the duplicate and merge into one. Confirm with the SPF checker.
• DKIM "syntax error" or "key not found". Stray quotes, spaces or newlines pasted into the key, or a CNAME conflicting with an existing record at the same selector. Re-paste a clean key, or remove the conflicting record.
• SPF permerror. Too many includes pushing you over ten DNS lookups. See /blog/fix-spf-permerror and consider flattening.
• Everything looks right but DMARC still fails. This is usually alignment, not the record itself. A service can pass SPF for its own domain while failing DMARC for yours. /blog/spf-vs-dkim-which-aligns explains which mechanism to lean on.
• Changes not showing. TTL plus IONOS's zone-rebuild interval. Wait it out before editing again.

The practical takeaway

On IONOS the three records themselves are straightforward: one SPF TXT on the root (host field blank), one DKIM record per sending service under selector._domainkey, and one DMARC TXT under _dmarc. The IONOS-specific traps are the host-name field (blank or @ for the root, label-only for subdomains), the lack of any validation on what you save (so duplicate SPF and over-limit lookups slip through), and the way pasted keys pick up stray characters. Get those right, verify each record before moving on, and walk the policy from p=none to p=reject while reading the reports.

When you are ready, run the finished setup through our DMARC checker to confirm every record resolves and aligns. If reading aggregate reports and babysitting the journey to p=reject is not how you want to spend the next month, our managed DMARC service does the heavy lifting: we take a domain on IONOS from p=none to p=reject with no email outage, host the moving parts, and send you change alerts the moment a record drifts. Either way, [/monitor] keeps an eye on the records once they are live so a silent change never costs you your deliverability.