IONOS SPF, DKIM, and DMARC Setup for Sending Domains

IONOS SPF DKIM DMARC setup is straightforward once you know which DNS record belongs where—and once you avoid IONOS’s easy-to-miss hostname behavior. This guide explains how to add the records your email provider supplies, protect existing mail flow, and verify that your sending domain is ready.

What you need before editing IONOS DNS

Do not begin by guessing record values. SPF, DKIM, and return-path records are provider-specific: the correct include domain, DKIM selector, CNAME target, and bounce-domain hostname depend on the email service that will send your messages.

Before opening IONOS, collect the DNS instructions from your sending provider. For Volanea, add and verify your sending domain first, then copy the requested records exactly from the domain-authentication screen or email API setup documentation. A single wrong character in a selector or CNAME destination can prevent verification.

You should have these details in front of you:

• The domain you want to use in the visible From address, such as example.com or mail.example.com.
• Every current sending system that legitimately sends mail for that domain: Google Workspace, Microsoft 365, IONOS Mail, a support desk, an ecommerce platform, a CRM, and any transactional email provider.
• The DNS records supplied by the sending provider, including record type, hostname, and value or target.
• Access to the account that hosts authoritative DNS—not merely the account where the domain was purchased.
• A mailbox where you can receive DMARC aggregate reports, if you plan to include a rua address.

The distinction between registrar and DNS host matters. A domain may have been bought at IONOS while its active nameservers point to Cloudflare, another hosting company, or a corporate DNS platform. In that situation, records entered into IONOS may appear in the IONOS dashboard but will not be published on the public internet. Check the domain’s active nameservers first. If they are not IONOS nameservers, make the changes at the DNS provider that those nameservers belong to.

It is also worth taking a screenshot or exporting a written list of your current MX, TXT, and CNAME records before changing anything. Email DNS is cumulative: adding the right record is helpful, but overwriting a working SPF policy or deleting a mail-related CNAME can break an unrelated system.

Where DNS management is in the IONOS dashboard

As of writing, IONOS help documentation describes the DNS path as: sign in to IONOS, open Domains & SSL, find the relevant domain, select the gear icon under Actions, and choose DNS. From the DNS view, use Add Record and choose the required type.

Depending on account layout, screen size, product bundle, and future dashboard changes, IONOS may show the same destination as a domain-details page rather than a visible gear icon. The reliable landmarks are the domain list, the domain’s Actions menu, and the DNS option. Do not confuse DNS with domain forwarding, mailboxes, SSL management, or website settings.

Use this workflow:

1. Sign in to your IONOS account.
2. Open Domains & SSL.
3. Locate the domain used in your From address, for example example.com.
4. Under Actions, select the gear icon or equivalent action menu.
5. Choose DNS.
6. Review existing records before adding anything.
7. Select Add Record.
8. Choose the record type requested by the sending provider: usually TXT or CNAME.
9. Enter the hostname and value carefully, save, then repeat for each requested record.

IONOS applies saved DNS changes in its own system quickly, but public DNS resolvers can continue returning cached data until the relevant TTL expires. IONOS notes that external visibility can take up to about an hour in normal cases. Do not repeatedly delete and recreate records while waiting; that can restart caches and make troubleshooting harder.

The IONOS hostname rule that causes the most failures

The most common IONOS-specific error is pasting a fully qualified hostname into the Host name or Hostname field when IONOS expects only the part before your domain.

If your domain is example.com and your provider says to create this record:

selector1._domainkey.example.com

enter this in IONOS’s hostname field:

selector1._domainkey

Do not enter:

selector1._domainkey.example.com

IONOS appends the domain to the hostname you enter. Supplying the complete name can produce a doubled record such as:

selector1._domainkey.example.com.example.com

That record may look plausible at a glance in the dashboard, but the sending provider will query selector1._domainkey.example.com, not the accidental doubled hostname. Domain verification and DKIM validation will fail.

This rule applies to DKIM selectors, DMARC names, custom return-path subdomains, tracking CNAMEs, and verification records. For a root-domain TXT record, use @ if IONOS presents that as the root-host notation. For a DMARC record on example.com, enter _dmarc, not _dmarc.example.com.

Hostname versus value: they behave differently

Only shorten the record name in the hostname field. Do not shorten a provider’s CNAME destination, DKIM public key, SPF include mechanism, or DMARC report address.

For example, if a provider supplies:

Host: s1._domainkey.example.com
Value: s1.domainkey.provider-example.net

the IONOS entry should generally be:

Host name: s1._domainkey
Point to / Value: s1.domainkey.provider-example.net

The destination remains a complete hostname. Follow the exact target from your provider, and do not add http://, https://, quotation marks, or an email address unless the provider explicitly requests one.

SPF, DKIM, DMARC, and return-path record shapes

The table below shows the normal IONOS TYPE/HOST/VALUE shape for email authentication. The placeholder values are examples of structure only. Replace them with the exact values shown in your sending provider’s domain setup instructions.

A provider may request more than one DKIM CNAME. That is normal. Providers commonly use multiple selectors for key rotation or service separation. Create every requested record rather than assuming one successful-looking DKIM record is enough.

Likewise, a return-path setup can involve more than one record type. Some providers use a CNAME for a custom bounce domain; others use an MX record plus a TXT SPF policy; some configure it automatically. Never convert a requested CNAME into a TXT record simply because DKIM and DMARC commonly use TXT. DNS record type is part of the instruction.

Add SPF without creating a second SPF record

SPF is a TXT record that declares which servers may send mail using an envelope sender domain. It is often described as a record for your From domain, but SPF evaluation actually looks at the SMTP envelope sender, commonly visible to recipients as the Return-Path.

The operational rule is simple: publish one SPF record per hostname. Do not create one SPF TXT record for IONOS Mail, another for Google Workspace, and a third for a transactional email provider at the same root hostname. Multiple SPF records can produce an SPF PermError, causing receivers to treat the result as invalid.

Check whether SPF already exists

In IONOS DNS, find TXT records at the root hostname. Look for a value beginning with:

v=spf1

If one already exists, edit and merge it rather than adding another SPF TXT record. For example, imagine an existing policy for IONOS Mail:

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

If your sending provider instructs you to authorize its infrastructure using include:spf.provider-example.net, a merged example would be:

v=spf1 include:_spf-us.ionos.com include:spf.provider-example.net ~all

The final mechanism, such as ~all or -all, belongs at the end. Do not place it before later includes because SPF stops evaluating when it reaches an all mechanism.

Do not copy example SPF values blindly

The IONOS SPF include above is relevant only if IONOS mail servers actually send mail for your domain. If all mail sends through another provider, do not add IONOS merely because the domain was registered there. Conversely, removing an existing IONOS include can break mailbox-originated mail, password-reset replies, or staff messages sent through IONOS SMTP.

Inventory senders first. A useful checklist includes:

• Employee mailboxes and shared mailboxes.
• Application notifications, receipts, login links, and password resets.
• Sales and marketing platforms.
• Support systems and ticketing tools.
• Ecommerce platforms and order systems.
• Finance, HR, survey, calendar, and form tools.

SPF also has a practical DNS-lookup limit. Each include, a, mx, redirect, and exists mechanism can add DNS lookups; an overly complicated policy can exceed the SPF limit of 10 DNS-querying mechanisms. This is another reason to remove inactive platforms instead of continually appending new includes.

A custom return-path can reduce pressure on the root-domain SPF record. When an email provider sends with an envelope sender under a delegated subdomain such as bounce.example.com, SPF can be evaluated against that subdomain’s policy while the visible From address remains billing@example.com. That arrangement can also help SPF align with DMARC when the subdomain is organizationally aligned with the From domain.

Add DKIM records exactly as issued

DKIM adds a cryptographic signature to outgoing mail. A receiving server retrieves the public key or delegated key location from DNS and checks whether the message signature is valid. Unlike SPF, DKIM survives forwarding more reliably because it authenticates the signed message content and selected headers rather than the sender’s connecting IP address.

The two common DNS patterns are CNAME-based DKIM and TXT-based DKIM.

CNAME-based DKIM in IONOS

With CNAME DKIM, the email provider hosts the actual DKIM key and gives you a selector hostname plus a CNAME destination. An example shape is:

Type: CNAME
Host name: v1._domainkey
Point to: v1.domainkey.provider-example.net

IONOS then publishes the record at:

v1._domainkey.example.com

CNAME DKIM is convenient because a provider can rotate key material behind the target record. Still, your provider may issue two or three selectors. Add each one and preserve the spelling, underscores, hyphens, and dots exactly.

TXT-based DKIM in IONOS

With TXT DKIM, the provider gives you a full public key. The entry normally resembles:

Type: TXT
Host name: selector1._domainkey
Value: v=DKIM1; k=rsa; p=PUBLIC_KEY_MATERIAL

The public-key value can be long. Paste it as one uninterrupted value unless IONOS’s form itself handles line wrapping. Do not insert spaces into the p= value and do not add quote characters just because zone-file examples sometimes display quoted strings.

DKIM conflicts to avoid

A CNAME cannot coexist with other ordinary DNS record types at the same hostname. If selector1._domainkey.example.com already has a TXT record, do not simply add a CNAME with the same hostname. Review whether the older DKIM record belongs to a live provider, whether the new provider uses a different selector, and whether it is safe to retire the old configuration.

Do not reuse generic selectors such as default, mail, or selector1 without checking what exists. A provider-generated selector is designed to reduce collisions. If a selector conflict exists, ask the sending provider for a different selector or use the selector it generated in its current domain setup.

Publish DMARC safely before enforcing it

DMARC connects the visible From domain to SPF and DKIM. It tells receivers what to do when neither SPF nor DKIM passes with acceptable alignment, and it can request aggregate reports that show who is attempting to send as your domain.

For a root domain example.com, the DMARC record always lives at _dmarc.example.com. In IONOS, create a TXT record with:

Host name: _dmarc

A sensible monitoring-first policy is:

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

Use a real, monitored address for rua. Ideally, use a dedicated mailbox or reporting service rather than an individual employee inbox. Aggregate reports are XML files and can arrive from many receiving systems, so they are not pleasant as ordinary mail.

Choose a staged policy

DMARC policy should usually mature in stages:

1. Monitor: p=none collects reports but asks receivers not to impose a policy based on DMARC failure.
2. Quarantine: p=quarantine asks receivers to treat unauthenticated mail as suspicious, often routing it to spam.
3. Reject: p=reject asks receivers to refuse messages that fail DMARC.

The correct progression depends on report data, not a calendar deadline. Keep p=none until you have identified every legitimate sender and corrected failures. Then apply quarantine gradually, optionally with a pct tag, before moving to reject.

For example, an incremental policy may look like:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com

Do not add strict alignment tags such as adkim=s or aspf=s until you understand your mail streams. Relaxed alignment is the usual default and permits aligned subdomains. Strict alignment can be appropriate for tightly controlled domains, but it can break legitimate sending setups that use a subdomain for DKIM or a custom return-path.

DMARC passes when one aligned method passes

A common misconception is that every message must pass both SPF and DKIM for DMARC to pass. DMARC can pass when either SPF passes and aligns with the From domain, or DKIM passes and aligns with the From domain.

That is why DKIM should be treated as essential, not optional. Forwarded mail may fail SPF because forwarding changes the connecting server, while a valid aligned DKIM signature can still make DMARC pass. A custom return-path supports aligned SPF as an additional authentication path, rather than replacing DKIM.

Configure a custom return-path without touching inbound MX

The return-path, also called the envelope sender or MAIL FROM domain, handles bounces and is the domain against which SPF is checked. It is not necessarily the same as the visible From address.

For example, an email might display:

From: receipts@example.com
Return-Path: bounces@bounce.example.com

If bounce.example.com is configured by the sending provider and is organizationally aligned with example.com, SPF authentication for the envelope sender can support DMARC alignment. It also gives the provider a controlled location for delivery failures and bounce processing.

Follow the provider’s requested record type

A provider might ask for one of these arrangements:

• A CNAME from bounce.example.com to a provider-managed hostname.
• An MX record at a dedicated bounce subdomain, pointing to provider mail exchangers.
• A TXT SPF record at that same bounce subdomain.
• A combination of CNAME, MX, and TXT records.

Each has a different purpose. The MX record for bounce.example.com is normally for bounce handling at that subdomain. It does not replace the MX records for example.com, which control incoming mail to addresses such as hello@example.com.

Never delete or overwrite the root-domain MX records while adding a return-path configuration. If the provider requests an MX record, create it at the exact custom return-path hostname it supplies. In IONOS, that typically means entering only the left-hand portion, such as bounce, in the hostname field for a bounce.example.com record.

Also check for a CNAME conflict. If bounce.example.com is a CNAME, it cannot simultaneously host MX or TXT records. Providers generally design their setup instructions to avoid this, but conflicts can occur if an older email tool already used the same subdomain.

Verify records after saving them

Saving a record in IONOS is not the same as proving that the intended public record exists. Verification should happen in two stages: inspect public DNS, then complete verification in the sending provider.

First, check the published names and record types. A command-line workflow can look like this:

dig TXT example.com +short
dig TXT _dmarc.example.com +short
dig CNAME selector1._domainkey.example.com +short
dig CNAME bounce.example.com +short

For a return-path setup that uses MX, query the MX record too:

dig MX bounce.example.com +short

The exact query name should match the provider’s requested hostname. If the provider gave v1._domainkey.example.com, query that full public name. If the result instead appears at v1._domainkey.example.com.example.com, you have hit the doubled-hostname issue.

Second, return to the sending provider’s domain-verification screen and run its verification check. DNS can be publicly correct while an account is awaiting a manual verification refresh. Conversely, do not assume a green DNS check means all real messages are aligned; send a test email and inspect the delivered message headers.

Look for results resembling:

spf=pass
dkim=pass
dmarc=pass

The header names and layout vary by mailbox provider. For DMARC, also confirm that the aligned domain matches or is a permitted subdomain of the visible From domain.

Troubleshooting IONOS DNS and email verification failures

Most failures are mechanical rather than mysterious. Work from the public record backward instead of repeatedly changing records at random.

The provider cannot find the record

Check these items in order:

• Confirm the authoritative nameservers are IONOS nameservers. If not, edit DNS at the active provider.
• Confirm you edited the correct domain. example.com and example.co are different zones; mail.example.com is not automatically a separate DNS zone.
• Remove the root domain from the IONOS hostname field. Enter _dmarc, not _dmarc.example.com.
• Compare the record type. A TXT record will not satisfy a CNAME request.
• Compare the CNAME target or TXT value character for character.
• Wait for DNS propagation and avoid switching the record back and forth.

SPF returns PermError or fails unexpectedly

Search the root TXT records for more than one value beginning v=spf1. Merge all authorized senders into one policy. Then check that every active sender is authorized and that the policy remains under SPF’s DNS lookup limit.

Be cautious about changing ~all to -all. A hard fail is not automatically better; use it only after you know that every legitimate sender is represented. A strict policy with an incomplete sender inventory can cause valid business mail to fail SPF.

DKIM is pending or fails

Verify that the selector name is correct and that the selector is part of the hostname, not the value. For a CNAME, make sure the target is a complete provider hostname and not a hostname accidentally modified to include your own domain.

If a TXT DKIM key is long, confirm that no characters were removed or replaced. Do not substitute a TXT record for a CNAME record, and do not add a CNAME where a TXT DKIM record already exists at the same selector.

DMARC reports failures after publishing p=none

This is expected at first. DMARC reporting often reveals software or vendors that were already sending mail without proper authentication. Use reports to classify each source as legitimate, unauthorized, or uncertain.

For legitimate senders, configure their SPF, DKIM, and From-domain settings properly. For unauthorized sources, do not add them to SPF merely to make reports quieter. The purpose of DMARC is to distinguish approved mail from impersonation.

A practical rollout plan for a domain already in use

A domain with active business mail deserves a careful rollout rather than a one-time DNS change. The safest sequence minimizes the chance of disrupting employee mail, support systems, receipts, or automated messages.

1. Document current DNS records and current mail senders.
2. Add the provider-issued DKIM records first. DKIM generally does not require editing a shared root SPF policy.
3. Add the custom return-path records exactly as requested, using a dedicated subdomain that does not conflict with existing DNS.
4. Merge the provider’s SPF authorization into the existing single SPF record only if the provider requires root-domain SPF authorization.
5. Publish DMARC with p=none and a working aggregate-report address.
6. Verify public DNS and verify the domain in the sending provider.
7. Send test messages to multiple mailbox providers and inspect authentication headers.
8. Review DMARC reports before moving toward quarantine or reject.

This order creates multiple opportunities to catch an error before policy enforcement affects recipients. It also reflects the fact that email authentication is a system: successful DNS verification is important, but real inbox authentication and DMARC alignment are the operational outcome.

Conclusion

The key to a successful IONOS SPF DKIM DMARC setup is accuracy, not complexity. Start in Domains & SSL, open the domain’s Actions menu, select DNS, and add each provider-issued record using the requested type.

Keep one SPF record per hostname, add all DKIM selectors, publish DMARC at _dmarc, and treat custom return-path records as their own subdomain configuration. Above all, enter only the host portion in IONOS’s hostname field—never the full hostname including your root domain—then verify the public DNS record before declaring the sending domain ready.

FAQ

Where do I find DNS settings in IONOS?

Sign in to IONOS, open Domains & SSL, find the relevant domain, choose the gear icon or Actions menu, and select DNS. IONOS dashboard labels can change, but the domain Actions menu and DNS destination are the standard route.

Should I create a separate SPF record for each email provider?

No. A hostname should have one SPF TXT record beginning with v=spf1. Merge authorizations for all legitimate senders into that single record.

What do I enter for a DKIM hostname in IONOS?

Enter only the portion before your root domain. For selector1._domainkey.example.com, enter selector1._domainkey when managing example.com in IONOS.

Is DMARC a TXT or CNAME record?

DMARC is a TXT record. For a root domain, create it at the hostname _dmarc with a value beginning v=DMARC1.

Will a custom return-path break my normal incoming email?

Not when configured at the provider-requested subdomain and without changing your root MX records. A bounce domain such as bounce.example.com is separate from the MX records that receive mail for example.com.