IONOS SPF setup

Choose the implementation approach

Choose the approach based on the sender inventory and the DNS record already published for the domain.

• If no SPF record exists, obtain the exact record instruction from every approved sending service before publishing a new record.
• If an SPF record already exists, treat the work as a controlled merge. Confirm how each approved sender's instruction fits into the existing value before editing.
• If a service sends through a different domain, subdomain, or return-path domain, do not assume the IONOS zone for the visible From domain is the place to edit.
• If ownership of the domain's DNS is unclear, identify the authoritative DNS provider before opening any IONOS setting.

The implementation decision is simple: publish the exact approved record only after you know whether it is a new record or an edit to the one existing SPF record. If that distinction is not clear, pause the change.

How to configure an SPF record in IONOS

1. Confirm the sending domain and current DNS authority

Start with a recent message sent through the exact application you need to authorize. Record the return-path or envelope-sender domain from the message evidence, then establish which organization controls the authoritative DNS zone for that domain.

Do not rely on an old implementation note. A domain can use IONOS for email, hosting, or registration while DNS is managed elsewhere.

2. Obtain the sender-specific SPF instruction

Open the official setup documentation for the service that sends the mail. Obtain its current SPF instruction, the domain it applies to, and any instruction about coexistence with other sending services.

The sender's documentation is the required source for the record value. Do not publish a universal IONOS SPF value because no such value applies to every sender configuration.

Do not replace a current TXT record until the DNS owner has captured it and the sending-service owner has approved the proposed merged state. A DNS record that looks unrelated may support another production mail stream.

3. Inspect the existing TXT records in the IONOS-managed zone

Use the current IONOS DNS documentation or authenticated control panel to locate the TXT records for the confirmed domain. The exact navigation path, form labels, and save behavior can change, so follow the current IONOS instructions rather than a copied screen path.

Look for records at the domain name and any relevant subdomain. Record what exists before creating or editing anything. If an SPF record is present, compare its full value with the sender inventory. Do not create another SPF record merely because a sender has supplied an additional mechanism.

The following is an illustrative change description, not a production DNS value:

Owner: yourdomain.com
Type: TXT
Value: <approved SPF value generated from the confirmed sending inventory>

Replace the placeholder only with a value approved from the current documentation for the services that send your mail. Do not publish a selector, hostname, token, or include value copied from another tenant.

4. Apply the approved DNS change

Make the smallest DNS change that implements the approved sender inventory. Keep a copy of the prior record and the exact new value entered. Record the time of the save and any TTL shown by the DNS interface.

If the IONOS interface shows a warning, conflict, or record-normalization message, do not infer what it means. Compare it with current official IONOS guidance or escalate it to the DNS owner before saving.

5. Keep the change scoped

Do not combine SPF work with DKIM, DMARC policy, MX, or mail-routing changes in the same unreviewed update. Separate changes make it possible to identify which action caused an unexpected result.

When a sender also needs DKIM, use its official instructions for that configuration. For example, Customer.io SPF and DKIM setup and HubSpot SPF and DKIM setup are separate sender-specific tasks.

How to validate the setup

Treat DNS publication, sender status, delivered-message authentication, and DMARC reporting as independent checks.

• DNS: Query the authoritative DNS source for the exact domain and compare the returned TXT record with the approved change. Then check at least one public resolver. Record the observed values and timestamps.
• Sender: Use the sending service's own status or verification method when it provides one. A green status does not prove that a new production message used the expected path.
• Message: Send a new message through the exact application, account, and route you configured. Inspect the recipient-side message headers and preserve the authentication result with sensitive data redacted.
• DMARC: Once aggregate-report data accumulates, inspect the production source's SPF result and alignment outcome over time. This is the layer that shows whether the observed sender appears in reporting, rather than only in one test message.

domain: yourdomain.com
sender: <application or mail system>
dns_result: <authoritative and public resolver observations>
sender_status: <service verification result, if available>
message_result: <redacted delivered-message authentication result>
dmarc_result: <aggregate-report observation after data accumulates>
checked_at: <UTC timestamp>

A passing DNS lookup means the public record can be retrieved. It does not prove that the application uses the expected return path, that all mail streams are covered, or that a receiving mailbox will make a particular delivery decision.

Troubleshooting

I cannot find the DNS record controls in IONOS

Confirm first that IONOS is authoritative for the domain's DNS. Then use current official IONOS Help Center guidance or ask the domain administrator for the documented DNS-management path. Do not use a third-party walkthrough as evidence for the current control-panel labels.

An SPF-related TXT record already exists

Do not add a second record before determining its purpose. Capture the complete record and compare it with the current sender inventory. Ask the sender owner for its official merge instructions when a new sending service must be added.

The public result does not match the record I entered

Compare the full domain name, record type, and value with the change log. Then query the authoritative DNS source and a public resolver. If the answers differ, preserve both observations and avoid further edits until the DNS owner confirms the intended state.

DNS looks correct but a new message still has an authentication problem

Check a newly delivered message from the exact production path. Confirm the application, account, return-path domain, and recipient are the ones you intended to test. A public DNS result does not establish that a sender used that record.

The sender's documentation conflicts with the existing record

Pause the change. The existing record may support a different approved source. Obtain an approved record plan from the owners of every sending system before changing DNS.

Check the SPF record before relying on the change

After the DNS owner has published the approved value, inspect the domain with Palisade's SPF checker. Compare the public result with the exact record captured in the change log, then compare both with a new message from the production sender.

For an ongoing domain portfolio, Palisade is AI-first, agent-first DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose a next DMARC policy step when the evidence supports it, while a human reviews the evidence and applies the change. That workflow does not replace IONOS DNS ownership, change DNS automatically, or guarantee receiver delivery decisions.

Start with Palisade

The SPF checker inspects public DNS. It cannot prove the production sending path, continuously monitor later DNS changes, repair a sender configuration, or guarantee inbox placement.