IONOS SPF, DKIM and DMARC setup, step by step

If IONOS hosts your DNS, publish the authentication records supplied by the service that actually sends your email. For IONOS Mail, check the existing SPF preset and three DKIM CNAMEs before adding anything. External DNS needs the applicable regional SPF value and the same documented DKIM delegation. A domain bought from IONOS, formerly 1&1, does not establish that IONOS sends its mail. IONOS SPF instructions and IONOS DKIM instructions

This guide covers DNS publication in IONOS and the documented IONOS mailbox configuration. Microsoft 365, hosted Exchange, an independent SMTP relay and website-generated messages need their own sending-route checks. Do not apply a mailbox recipe to every product carrying the IONOS name.

Identify the DNS host and the sending service

Create a short worksheet before opening an editor:

• The domain shown in the visible From address, including any sending subdomain.
• The mailbox or application that submits the message and the relay that delivers it externally.
• The envelope MAIL FROM domain, observed as smtp.mailfrom in trusted receiver results.
• The intended DKIM signing domain and selector.
• The authoritative DNS host and the person responsible for existing DMARC policy.

Check delegated nameservers, not the company on the domain-renewal invoice. If DNS is hosted elsewhere, make the change there. If IONOS is only the DNS host, obtain the exact TXT or CNAME instructions from the mail provider. A Microsoft or Google DKIM key does not become an IONOS key because you publish it in the IONOS panel.

For Mail Basic and Mail Business, the sender domain must match the domain of the account used for SMTP submission. The local part before @ can differ, but a different-domain address can produce Sender address is not allowed. This submission restriction is separate from SPF and DMARC; adding DNS records will not override it. IONOS sender-address requirements

Preserve the zone before changing authentication

Save the current record list with names, types, complete values and TTLs. Identify every service using the same SPF owner before merging its policy. Preserve unrelated TXT verification tokens, existing DKIM selectors, MX records and working DMARC settings. This procedure does not require a nameserver change or an incoming-mail migration.

In IONOS, open Domains & SSL, select the domain's Actions → DNS option, and inspect existing records. Use the record's edit action for an existing TXT policy, or Add Record → TXT for a genuinely new one. Enter the required host and value, then save. IONOS TXT management

@ represents the zone apex, not a wildcard SPF policy for every child domain. For example.com, an SPF record at @ does not automatically authorize MAIL FROM addresses under news.example.com. Confirm the actual saved owner and avoid a repeated suffix such as selector._domainkey.example.com.example.com.

If an intended DKIM owner already has a CNAME or another service's key, stop and resolve that dependency. Do not publish TXT beside an existing CNAME, overwrite another sender's selector, or reset the zone to defaults. When two administrators are editing, compare the current zone with your saved copy immediately before saving.

Configure SPF for the actual IONOS mail region

IONOS documents SPF as enabled by default for its hosted domains. If the IONOS authorization is missing, its supported workflow is Add Record → IONOS SPF (TXT) → Save. The preset is documented to supplement an existing SPF policy. Inspect the result anyway: other legitimate senders must remain authorized in one policy, not disappear behind a new IONOS-only record. IONOS SPF preset

For external DNS, the U.S. help center supplies this complete IONOS-only example:

v=spf1 include:_spf-us.ionos.com ~all

The UK help center supplies a different example:

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

Use the value applicable to your regional service, confirmed through its current account guidance. Do not choose by the recipient's location or add both because you are uncertain. These examples are not universal authorizations for hosted Exchange or third-party senders. U.S. SPF value and UK SPF value

Where a policy already exists, incorporate the applicable include: before its terminal all, retaining approved mechanisms and the established qualifier. Do not paste a second v=spf1 into it. Keep one SPF TXT policy per owner and check the full evaluation path against the ten DNS-lookup-causing-term limit, including nested includes. ~all means softfail for unmatched senders; it is not pass. Never use +all as a repair. SPF evaluation rules

SPF evaluates the envelope identity, not the visible From field. If the actual MAIL FROM is under another provider's domain, adding IONOS to your apex cannot turn that unrelated identity into an aligned one. Establish the sending route from message evidence before changing more DNS.

Publish all three IONOS DKIM CNAMEs

IONOS's current mailbox guide documents automatic DKIM configuration when its nameservers are used. For missing records or external DNS, it specifies these three CNAMEs, with a one-hour TTL:

s1-ionos._domainkey CNAME s1.dkim.ionos.com
s2-ionos._domainkey CNAME s2.dkim.ionos.com
s42582890._domainkey CNAME s42582890.dkim.ionos.com

These are the shared values in the cited IONOS documentation, including the numeric third selector. They are not a fabricated account example. Check the current documentation and account instructions before applying them. In IONOS use Add Record → CNAME, enter each owner and target, and save all three. No manual private-key generation or upload is part of this documented mailbox procedure. IONOS DKIM table and reactivation

For a sending subdomain news.example.com within the example.com zone, the first relative owner becomes s1-ionos._domainkey.news; apply the same suffix to the other two owners. The targets stay unchanged. A separately delegated news.example.com zone needs names relative to that zone instead. Verify the final full names rather than adding news twice.

For IONOS Mail records published at an external DNS host, apply the following only to the controls that host actually provides; do not look for Cloudflare settings in IONOS. Where the actual authoritative DNS host offers these controls, use DNS-only aliases, not HTTP proxying or redirects, and keep a literal CNAME answer to each required target. Turn the relevant per-record Flatten option off when available, and ensure applicable zone-wide settings do not conceal the issued aliases. For Cloudflare specifically, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are Cloudflare behaviors, not assumed controls in another provider’s panel. If mandatory behavior or shared settings prevent the required CNAME answer, stop and coordinate a supported configuration without breaking dependent records. Do not blindly change the whole zone or remove an NS delegation; publish at the delegated authority when appropriate. Cloudflare CNAME verification, flattening controls.

For another mail service hosted in IONOS DNS, use that service's generated selector, record type and full public value instead. A TXT public key and a CNAME delegation are different publication instructions. Do not substitute one for the other. Return to that sending service to complete any required verification and signing activation.

Keep DMARC under the domain owner's control

DMARC passes when SPF or DKIM passes with an identity aligned to the visible From domain. Relaxed alignment compares organizational domains; strict alignment requires the domains to match exactly. A valid provider-domain DKIM signature alone is not evidence that your branded signing setup works. DMARC alignment

Inspect the existing _dmarc record and any applicable parent policy before creating a new one. Preserve established enforcement, reporting addresses and alignment settings. Do not replace p=reject or p=quarantine with a monitoring example merely because you are fixing one sender.

For a first, approved monitoring deployment with no existing applicable policy, this is an illustrative value, not a ready-to-paste configuration:

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

Replace the address with an approved, monitored destination. The full owner _dmarc.example.com maps to _dmarc in the example.com zone. For an intentional policy at news.example.com, the full owner _dmarc.news.example.com maps to _dmarc.news in the example.com zone, or to _dmarc in a separately delegated news.example.com zone. Adding a child policy can change inherited protection, so coordinate with the domain owner. IONOS uses TXT for DMARC. IONOS DMARC publication

External report destinations need the reporting service's authorization records where required. Do not copy a tutorial's tenant address or add failure-report destinations without a privacy review. Aggregate reports help review sources over time, but missing reports are not proof that all mail passes. Tighten policy only after the complete sending inventory is authenticated and reviewed. DMARC aggregate reporting

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Verify DNS and a newly delivered message

Replace the uppercase placeholders in these read-only commands. DNS_ZONE is the authoritative zone; MAIL_FROM_DOMAIN is the envelope domain, not necessarily the visible From domain.

dig +short NS DNS_ZONE
dig +short TXT MAIL_FROM_DOMAIN
dig +short CNAME s1-ionos._domainkey.SIGNING_DOMAIN
dig +short CNAME s2-ionos._domainkey.SIGNING_DOMAIN
dig +short CNAME s42582890._domainkey.SIGNING_DOMAIN
dig +short TXT s1-ionos._domainkey.SIGNING_DOMAIN
dig +short TXT _dmarc.FROM_DOMAIN
dig @AUTHORITATIVE_NS TXT MAIL_FROM_DOMAIN

Expect one appropriate SPF policy, the three intended CNAME destinations, and a resolvable public key through the selector used to sign. Compare the complete DMARC value with the approved policy. Repeat key resolution for the selector actually found in a delivered message. Inspect an applicable parent policy if no direct From-domain DMARC record exists.

IONOS's SPF guide allows up to 48 hours for propagation. Compare authoritative answers with recursive resolver answers and their TTLs rather than repeatedly rewriting a correct record while caches expire. An empty answer at the wrong owner will not fix itself through waiting.

After publication, an authorized administrator should send a new message through each real route to a controlled external mailbox, including any website application and permitted alias. Read the receiver's trusted Authentication-Results, not an arbitrary copied header. Record the visible From, smtp.mailfrom, DKIM header.d and selector, plus SPF, DKIM and DMARC results. Authentication-Results trust boundary

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

The acceptance test for this mailbox setup is a passing signature for the intended branded domain and an intended IONOS selector, plus DMARC pass under the actual alignment settings. Also require SPF pass for the intended direct route or investigate its failure explicitly. DMARC pass through SPF does not excuse missing branded DKIM; a DNS CNAME alone does not prove signing. Keep the timestamp and sanitized headers with the change record. Authentication does not guarantee inbox placement.

Troubleshoot the result, not just the record

• SPF permerror: look for duplicate policies, malformed syntax, broken include targets or excessive nested lookup terms. Correct the cause before treating this route as validated.
• SPF temperror: investigate DNS timeouts or service errors and retry after resolution; do not permanently loosen policy for a temporary failure.
• SPF fail, softfail or none: compare the evaluated domain and sending IP with the actual route and regional authorization. A message sent by a website's separate relay needs that relay's configuration.
• DKIM missing or failing: check all three owners, CNAME targets, suffix duplication and actual signing selector. If DNS is correct but fresh direct mail is unsigned, obtain IONOS support confirmation for the mailbox product and route.
• DKIM passes but DMARC fails: compare header.d with the visible From and the configured alignment mode. Test aliases and child domains independently.
• Mail rejected before delivery: Sender address is not allowed points to submission-domain restrictions, not necessarily an SPF lookup problem.

If a change damaged another sender, restore the affected record from the saved value after checking for concurrent edits. Avoid a whole-zone rollback that could undo unrelated work.