How to Add SPF, DKIM, DMARC, and Return-Path Records in Strato

If you need to add SPF DKIM DMARC records in Strato, the DNS work is straightforward once you know which hostname belongs in each field. The real risk is not the number of records—it is publishing a correct record at the wrong name, creating duplicate SPF policies, or letting Strato append your domain twice.

Email authentication records prove that your sending platform is authorized to send mail for your domain. They also tell recipient servers how to validate signed messages, where to send bounce feedback, and what to do with mail that fails authentication. Getting them right is foundational for transactional email delivery, domain verification, and protecting your domain from impersonation.

This guide explains how to reach Strato DNS management, how to translate the records displayed by your email provider into Strato’s fields, how SPF, DKIM, DMARC, and the Return-Path work together, and how to avoid the Strato-specific hostname mistake that causes many failed verifications.

What you need before changing Strato DNS

Prepare the records before opening the Strato dashboard. Your email provider should generate the exact DNS values after you add the sending domain or sending subdomain to its dashboard. Do not substitute a value from an old setup guide, another provider, or a different domain.

For a typical outbound-email setup, collect the following information from your provider’s domain-records screen:

• The sending domain you are verifying, such as updates.example.com or example.com.
• The record type for every generated record: TXT, MX, or CNAME.
• The record hostname, sometimes labelled Name, Host, or Record name.
• The full destination or content value.
• The MX priority, if an MX record is required for the Return-Path.
• Whether your provider generated one or more DKIM selectors.
• Whether the provider now uses CNAME records for sending verification instead of the older SPF TXT plus Return-Path MX pattern.

Copy the records exactly from the provider dashboard. Authentication values are machine-readable. A missing underscore in _dmarc, an altered DKIM key, or a hostname entered as a fully qualified domain where Strato expects only a label can prevent verification.

It is usually best to send application mail from a dedicated subdomain—for example, notify.example.com, updates.example.com, or mail.example.com—rather than from the root domain. Separating transactional or marketing streams helps isolate reputation and makes the purpose of the mail easier to understand. It also keeps Return-Path or inbound-routing changes away from the root domain that may already receive employee email.

If you are setting up a new sending domain in Volanea, use the generated records in the email API setup documentation as the source of truth. The examples in this article explain the shape of records, but they are not replacement values for the records shown for your domain.

The Strato navigation path for DNS management

As of writing, Strato’s documented route starts in the STRATO Kunden-Login and follows this path:

1. Sign in to your Strato customer account.
2. Open Domains.
3. Select Domainverwaltung.
4. Find the domain you want to configure in the domain overview.
5. Select the gear icon next to that domain.
6. Open Einstellungen (Domain).
7. Select the DNS tab.

From the DNS tab, Strato separates different DNS functions. For TXT and CNAME entries, select TXT- und CNAME-Records → verwalten. For a Return-Path MX record, use the relevant MX-Record management area. Strato documents DNS management for both domains and subdomains, so make sure you are editing the same DNS zone and hostname your email provider displayed. (strato.de)

The language and exact presentation can vary by account locale or future dashboard updates. If a button label is slightly different, use the documented hierarchy rather than guessing: domain overview, gear icon, domain settings, DNS, then the record category.

Choose the correct domain or subdomain first

This is more important than it sounds. If your provider asks you to verify updates.example.com, do not automatically enter the records in a separate zone that you think represents updates.example.com. In many registrar interfaces, the base domain’s DNS page is where you add the updates hostname.

Conversely, if you explicitly created send.example.com as a Strato subdomain and Strato presents a dedicated settings page for it, its DNS controls may be where you manage its MX settings. Follow the record name and the Strato page context carefully.

Before saving any change, ask one simple question: Will this record resolve publicly at the exact hostname shown by my email provider? If the answer is unclear, stop and review the final hostname Strato will construct.

DNS record map: TYPE, HOST, and VALUE in Strato

The table below shows the usual record shapes. The example domain is example.com, the email-sending subdomain is updates.example.com, and the Return-Path subdomain is send.example.com.

Your actual selector, mail server destination, public key, CNAME targets, and reporting mailbox will differ. Copy those values from your provider rather than using these placeholders in production.

For a sending subdomain such as updates.example.com, Strato normally expects the relative hostname in the Name field. That means _dmarc.updates, selector._domainkey.updates, or send.updates, depending on the exact record you are creating. Do not type the base domain again unless Strato explicitly shows that it expects a fully qualified hostname.

The most common Strato mistake: entering the full hostname

The most common Strato-specific failure is entering a complete hostname in a field where Strato automatically appends the root domain.

Suppose your provider displays this DKIM hostname:

selector1._domainkey.example.com

If you are editing the example.com DNS zone in Strato, the Name field should generally be:

selector1._domainkey

—not:

selector1._domainkey.example.com

If Strato appends the root domain, the second entry can become:

selector1._domainkey.example.com.example.com

That record exists, but it is not at the hostname your provider checks. Domain verification will fail even though the record appears to have been saved successfully.

Strato’s own provider guidance makes this explicit for DKIM: when the supplied record name is resend._domainkey.example.com, enter only resend._domainkey in Strato; omit the root domain. The same hostname logic applies to DMARC, SPF subdomains, CNAME verification records, and Return-Path MX records. (resend.com)

How to spot this problem after saving

Look at the hostname Strato displays once the record is saved. It should end in your domain exactly once.

For example, these are correct final names for the example.com zone:

send.example.com
selector1._domainkey.example.com
_dmarc.example.com

These indicate that the root domain was appended twice:

send.example.com.example.com
selector1._domainkey.example.com.example.com
_dmarc.example.com.example.com

If you see a doubled suffix, remove the incorrectly named record and recreate it with only the relative host portion.

Add the SPF record without creating a duplicate policy

SPF is a TXT record that identifies the servers permitted to send mail for a particular envelope-sender domain. It is evaluated against the SMTP envelope sender, also known as the Mail From or Return-Path domain—not simply the address shown to the recipient in the visible From header.

For an email platform that uses send.example.com as its Return-Path domain, you may receive a record that looks structurally like this:

Type: TXT
Host: send
Value: v=spf1 include:provider.example ~all

In Strato:

1. Open Domains → Domainverwaltung.
2. Use the gear icon for example.com.
3. Open Einstellungen (Domain) → DNS.
4. Select TXT- und CNAME-Records → verwalten.
5. Create another record and choose TXT.
6. Enter send as the name when the final hostname should be send.example.com.
7. Paste the full SPF value from your email provider.
8. Save the record.

One hostname can have only one SPF policy

A common DNS error is publishing two separate SPF TXT records at the same hostname:

v=spf1 include:provider-a.example ~all
v=spf1 include:provider-b.example ~all

That is not a valid way to authorize two services. Multiple SPF records at one hostname can cause SPF evaluation errors. Instead, combine the necessary authorization mechanisms into one SPF record when you control that policy:

v=spf1 include:provider-a.example include:provider-b.example ~all

Only combine values if both services genuinely send mail using that same envelope-sender hostname. If one platform uses a dedicated Return-Path such as send.example.com and another uses the root domain, their SPF records can remain separate because they are published at different hostnames.

Avoid changing an existing root-domain SPF record casually

If staff email is handled by Google Workspace, Microsoft 365, Strato Mail, or another mailbox provider, your root domain may already have an SPF record. Replacing it with an application-email provider’s record can break authentication for employee mail.

A dedicated sending and Return-Path subdomain avoids that risk. Your employees can continue sending as person@example.com, while your application can send visible mail from notifications@example.com and use send.example.com for bounces.

Add the Return-Path MX record safely

The Return-Path is the address used for delivery failures, bounce processing, and certain complaint feedback flows. It is part of the SMTP envelope and is usually different from the address recipients see in the From header.

For older or MX-based sending setups, an email provider may require both of these records on a subdomain such as send.example.com:

send.example.com  MX   10  feedback-smtp.provider-region.example
send.example.com  TXT      v=spf1 include:provider.example ~all

The MX record tells other mail systems where mail for the Return-Path subdomain should be handled. It does not redirect ordinary mail for your root domain and does not normally interfere with inboxes at person@example.com.

Why Strato users should use a dedicated Return-Path subdomain

Strato domains commonly have a default mail path associated with the mail subdomain. A dedicated send or bounce subdomain avoids colliding with that default behavior and makes the purpose of the MX record clear.

In Strato’s provider-specific DNS guidance, the recommended process is to create a subdomain such as send, then configure its MX record using own mail server and the provider’s server value, with the provider-specified priority. The same guidance uses a matching SPF TXT record at send. (resend.com)

Return-Path MX record checklist

Before saving the MX record, verify all four items:

1. Hostname: It is the dedicated Return-Path subdomain, such as send, not the root domain unless your provider explicitly requires the root.
2. Mail server: It exactly matches the destination supplied in your provider dashboard.
3. Priority: It matches the specified preference value. Lower numbers represent higher MX priority.
4. Existing records: You are not replacing the root-domain MX records that deliver mail to your normal inbox provider.

A Return-Path MX record on send.example.com is distinct from the MX records on example.com. MX routing applies to the hostname where the record is published, so configuring send.example.com should not reroute normal mail addressed to @example.com. (resend.com)

Add DKIM records exactly as generated

DKIM adds a cryptographic signature to each outgoing message. Receiving servers retrieve the corresponding public key from DNS and use it to verify that the message was signed by an authorized sender and was not altered after signing.

A typical DKIM TXT record has this shape:

Type: TXT
Host: selector1._domainkey
Value: p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

The selector1 portion varies. Your provider may use a branded selector, a generated selector, or more than one selector. The _domainkey label is required in the hostname for DKIM.

Add DKIM in Strato

1. Return to DNS → TXT- und CNAME-Records → verwalten for the appropriate domain.
2. Create another TXT record.
3. In the Name field, enter the relative DKIM host—for example, selector1._domainkey.
4. Paste the public-key value into the TXT value or content field.
5. Save the record.

Do not change capitalization, remove semicolons, add line breaks, or manually wrap long key values. Some interfaces display long TXT strings with quotation marks or visual line wrapping. That does not necessarily mean you should add quotation marks yourself. Use the exact value provided by your sending platform.

DKIM alignment matters for DMARC

DKIM can technically pass while DMARC still fails if the domain in the DKIM d= signature is not aligned with the domain in the visible From header. For example, if the message shows From: alerts@example.com, DKIM should normally sign with example.com or an aligned subdomain such as updates.example.com.

This is one reason to verify your own sending domain rather than relying solely on a provider-owned shared domain. It gives your mail a domain identity that can align with the From address recipients see.

Some providers now publish DKIM or sending-verification records as CNAMEs rather than TXT public keys. If the domain screen shows a CNAME, create a CNAME—not a TXT record—and use the exact target it provides. A CNAME cannot coexist with other DNS records at the same hostname, so do not reuse a hostname that already has TXT, MX, or other records. (resend.com)

Add a DMARC record in monitoring mode first

DMARC builds on SPF and DKIM. It tells recipient servers how to handle messages that fail authentication and are not aligned with the From domain. It can also request aggregate reports that show how mail claiming to be from your domain is being authenticated around the internet.

The basic DMARC record is always a TXT record at _dmarc:

Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

To add it in Strato, go to DNS → TXT- und CNAME-Records → verwalten, create a TXT record, enter _dmarc as the name, and paste the DMARC policy as the value.

Start with p=none

DMARC policies have three primary enforcement levels:

• p=none asks receivers to monitor failures without instructing them to quarantine or reject mail.
• p=quarantine asks receivers to treat failing mail suspiciously, often by placing it in spam.
• p=reject asks receivers to reject failing mail.

Start with p=none while you identify every legitimate mail source: application email, help desk tools, CRM platforms, newsletter systems, billing software, employee inbox providers, and any third-party service that sends mail using your domain.

After reports show that legitimate traffic passes SPF or DKIM with alignment, gradually move to p=quarantine and then p=reject. A reject policy is powerful protection against domain spoofing, but publishing it before your legitimate senders are aligned can block genuine mail.

Root-domain versus subdomain DMARC

A DMARC record at _dmarc.example.com establishes a policy for the organizational domain and can apply to subdomains when they do not publish their own DMARC record. If your transactional messages use From: updates@example.com, you can either rely on the root policy or publish a dedicated policy at _dmarc.updates.example.com.

A dedicated subdomain DMARC policy can be useful when the subdomain has different sending behavior or a different enforcement rollout. Do not publish conflicting policies at the same _dmarc hostname. There should be one DMARC TXT record for each exact policy hostname.

Understand the difference between SPF, DKIM, DMARC, and Return-Path

These records are related, but they solve different problems. Treating them as interchangeable leads to misconfiguration.

SPF authorizes envelope senders

SPF checks whether the server that sent the message is authorized for the envelope-sender domain. It is often associated with the Return-Path or Mail From domain.

An SPF pass alone does not guarantee the visible From address aligns with the authenticated domain. That is why SPF by itself is not enough for strong anti-spoofing protection.

DKIM proves a domain signed the message

DKIM applies a cryptographic signature. The recipient retrieves the public key from DNS at a selector hostname, such as selector1._domainkey.example.com.

Because DKIM signs the message, it can survive some forwarding situations better than SPF. It is also especially useful for DMARC because the signing domain can align with the visible From domain.

DMARC enforces alignment and publishes a policy

DMARC checks whether either SPF or DKIM passes with domain alignment to the From header. It then applies the policy you publish for failures.

A message does not need both SPF and DKIM to pass DMARC. One aligned mechanism can be sufficient. In practice, configure both: that gives your email more resilience across forwarding, routing changes, and receiving systems. (resend.com)

Return-Path provides operational feedback routing

The Return-Path is where bounces and feedback are directed. It commonly uses a dedicated subdomain and may require an MX record plus SPF TXT record, depending on your provider’s current verification design.

It is not the same as the From address. Recipients might see billing@example.com, while the envelope sender and Return-Path use an operational address under send.example.com.

Verify the records and allow for DNS propagation

After saving DNS records in Strato, return to your email provider’s domain-verification page and request verification if the interface requires it. Many providers automatically check on a schedule; others offer a verify or refresh action.

Strato says DNS changes can take up to 24 hours to become fully active. Email platforms may often detect correctly published records sooner, but global DNS propagation and cached answers can take longer. Some providers allow up to 72 hours before treating a record as failed to verify. (strato.de)

A practical verification sequence

Use this order when troubleshooting:

1. Confirm the record type matches the provider’s record type.
2. Confirm the hostname does not contain your root domain twice.
3. Confirm the record value was copied without edits.
4. Confirm an MX record has the requested priority.
5. Check that there is only one SPF TXT record at the same hostname.
6. Check that there is only one DMARC TXT record at the same _dmarc hostname.
7. Wait for DNS publication, then refresh domain verification in your email provider.
8. Send a test email and inspect its authentication results for SPF, DKIM, and DMARC.

Authentication headers in a received test message are valuable evidence. Look for results such as spf=pass, dkim=pass, and dmarc=pass. A domain can be verified by a sending platform but still fail DMARC on a live message if the visible From domain is not aligned with the SPF or DKIM domain.

Common Strato DNS problems and how to fix them

The DNS record saved, but domain verification still fails

First, inspect the final hostname. The most likely cause is entering record.example.com into Strato’s relative name field and ending up with record.example.com.example.com.

Fix the record name by entering only the relative portion, such as record, selector._domainkey, or _dmarc.

You changed the wrong MX record

Do not replace MX records for example.com when the provider asked for send.example.com. Root MX records usually deliver normal employee and support inbox mail. A Return-Path MX record belongs at the dedicated bounce subdomain unless the provider explicitly tells you otherwise.

You created two SPF records

Merge legitimate mechanisms into one SPF policy for the same hostname, or move application mail to a dedicated Return-Path subdomain. Do not leave multiple v=spf1 TXT values on one exact hostname.

You pasted a DKIM hostname with the domain suffix

Remove the suffix in Strato’s name field. For a generated hostname such as selector._domainkey.example.com, enter selector._domainkey while managing the example.com zone.

You published a strict DMARC policy too early

If genuine messages are landing in spam or being rejected after enabling p=quarantine or p=reject, revert temporarily to p=none, investigate all sending sources, then roll enforcement forward again only after alignment is confirmed.

You used a CNAME where another record already exists

A CNAME cannot share its exact hostname with TXT, MX, A, or other records. Use a different Return-Path hostname if needed, or follow the provider’s generated record layout exactly.

A safer production rollout

For a business domain that already sends mail through several systems, avoid making all changes at once. Use a staged rollout:

1. Verify the sending domain or subdomain with its required DKIM and Return-Path records.
2. Send a small volume of test mail and inspect authentication headers.
3. Publish DMARC with p=none and a mailbox prepared to receive aggregate reports.
4. Review legitimate senders and resolve alignment failures.
5. Move to p=quarantine once the environment is stable.
6. Move to p=reject when you are confident legitimate senders consistently pass aligned SPF or DKIM.

This approach reduces the chance that a DNS change disrupts password resets, receipts, account alerts, support responses, or staff email. It also gives you a clean operational boundary between normal mailbox traffic and application-generated mail.

Final checklist for Strato email authentication

Before considering the setup complete, confirm the following:

• Your Strato path was Domains → Domainverwaltung → gear icon → Einstellungen (Domain) → DNS.
• TXT and CNAME records were created in TXT- und CNAME-Records → verwalten.
• Every name field uses the relative hostname when Strato appends your root domain.
• The SPF policy is not duplicated at the same hostname.
• DKIM includes the exact selector and unmodified public-key value or CNAME target.
• The Return-Path MX record is on a dedicated subdomain and does not replace root MX records.
• DMARC is published at _dmarc and begins with a monitoring policy unless you have already validated every sender.
• Your sending provider reports the domain as verified.
• A real test message passes SPF, DKIM, and DMARC.

Correct DNS authentication is more than a one-time verification task. It is a durable part of your email infrastructure. Keep a record of each service authorized to send on your behalf, review DMARC reports as you move toward enforcement, and revisit the DNS zone whenever you add or remove an email platform.

FAQ

Where do I find DNS settings in Strato?

In the Strato Kunden-Login, go to Domains → Domainverwaltung, select the gear icon beside the domain, open Einstellungen (Domain), and choose the DNS tab. TXT and CNAME entries are managed through TXT- und CNAME-Records → verwalten. (strato.de)

Should I enter the full domain name in Strato’s Host or Name field?

Usually no. When editing the example.com zone, enter the relative host only, such as _dmarc, send, or selector._domainkey. Strato can append example.com automatically, so entering the full hostname can create an invalid doubled name.

Can I have more than one SPF record?

You can have SPF records at different hostnames, such as one at example.com and another at send.example.com. However, you should not publish more than one SPF TXT policy at the same exact hostname. Combine legitimate senders into a single SPF value where necessary.

Will a Return-Path MX record break my normal email inboxes?

Not when it is placed on a dedicated subdomain such as send.example.com. It applies only to that subdomain. Do not replace the root-domain MX records used by your regular inbox provider unless you intentionally want to change where @example.com mail is delivered.

How long does Strato DNS verification take?

Strato advises that DNS changes may take up to 24 hours to become fully active. Many email platforms detect records sooner, but provider verification and wider DNS propagation can sometimes take up to 72 hours. (strato.de)