Connecting a Strato domain to an external website - how it works

I'll show you step by step how to connect your Strato domain to an external website - including DNS, SSL and typical pitfalls, so that all runs smoothly. The guide uses the focus keyword strato domain externally connect, explains the necessary entries and helps you to keep email at Strato while your site is at Squarespace, Webflow, Shopify or another service. runs.

Key points

Before I go into the implementation, I will summarize the most important aspects so that you can classify the individual steps more easily and not prioritize them. lose. I'll briefly explain the task of DNS records and why you need A and CNAME records to properly map a domain to an external provider. direct. I'll show you how to continue using email at Strato without hosting your website there so that mailboxes and aliases remain uninterrupted. I go into forwarding vs. DNS changes and explain when which method makes sense and what effects it has on SEO. I also provide you with a compact checklist that you can use to successfully complete the connection and quickly avoid any subsequent errors. find.

• DNS basicsUnderstand A, CNAME, MX, TXT records
• Keep e-mailLeave MX records unchanged
• SEO advantagesDNS connection instead of 301/302 forwarding
• SSL/HTTPSCheck certificate after linking
• TroubleshootingTTL, propagation and cache at a glance

What does "Connect Strato domain externally" mean?

You keep your domain with Strato, but redirect it to another platform via DNS - the website is therefore external, while Strato continues to use your domain. Manage. This way you separate ownership of the address from hosting and can use construction kits such as Squarespace, Webflow or Shopify without having to transfer. To do this, you adjust A and CNAME records, and sometimes also TXT records for confirmations and security features. Email can continue to run via Strato if you do not change MX records and adapt SPF/DKIM to the overall system. This decoupling creates maximum freedom for tools, performance and future moves without you losing control of your Address lose.

DNS basics briefly explained

I make a clear distinction between A-Record and CNAME, because both have different objectives. have. The A record points to an IPv4 address of the target platform, while a CNAME record points a name to another name, usually for "www" or verifications. For a quick refresh, I check the TTL value because it influences how quickly changes are visible worldwide. become. MX records direct e-mail, so I only touch them when I'm really moving e-mails. For more in-depth basics, I like to use compact explanations such as A-Record vs. CNAMEto avoid confusion. Avoid.

Preparation: Collect and check data

I have my Strato login ready, select the specific domain and decide whether I want to connect only "www" or root domain and "www" together on the target page. guide wants. Then I open the instructions for the target platform, copy IPs, host names and any TXT values for verification and leave the window open. I check whether emails should remain with Strato, because then I don't touch MX records and plan any necessary SPF/DKIM additions. If I manage DNS with an external service, I consider whether dedicated External DNS hosting offers advantages in terms of performance and administration. The better the preparation, the quicker I can set up the entries without having to wait until later. Corrections.

Step 1: Set up the target platform (Squarespace, Webflow, Shopify)

In Squarespace, I open "Use external domain", enter the domain and select "Connect domain", whereupon CNAME and A records appear with specific values [1][2], such as IPs like 198.185.159.144 for the A record etc.. After "Add a custom domain", Webflow shows me the necessary A, CNAME and possibly TXT entries for verification, which I later enter in Strato [3]. In Shopify, I go to Settings, Domains, "Connect existing domain" and receive the DNS target data, which is transferred exactly to Strato [7]. I leave these tabs open so that I don't type anything incorrectly and copy all names exactly. This way I minimize typing errors and shorten the subsequent Adjustment.

Step 2: Log in to Strato and select domain

I log in to the Strato customer area, go to "Manage domains" and select the appropriate Address. I then open the DNS tab or the domain administration, depending on how the menu is displayed. I check whether existing A or CNAME records are stored and decide whether to overwrite them or add new subdomain entries. If in doubt, I make a note of the previous status so that I can go back at any time. An overview and diligence save me a lot later on Time.

Step 3: Set DNS entries - A, CNAME, TXT

Enter A-Record

I open the A-Record, set the IP from the target platform and save the Amendment. With Squarespace I use the IPs provided [1][2], with Webflow the addresses displayed [3], with Shopify the specified target values [7]. If the root domain should be accessible without "www", I set the A-Record exactly for the main domain. Some providers also require a second A-record, which I also copy exactly. Exact copying prevents later Problems.

Store CNAME records

For "www", I usually set a CNAME to the hostname of the platform, such as ext-cust.squarespace.com for Squarespace [1][2] or the corresponding default for Webflow or Shopify [3][7]. Some platforms generate a random CNAME for verification, which I enter exactly with host and target and also use save. If "www" should point to the root domain, I either use a CNAME to the root (if allowed) or the variant recommended by the provider. I do not remove any MX records if e-mail remains with Strato. This keeps the delivery reliable and without Failure.

TXT records for verification and e-mail

Webflow often requires a TXT record with a one-time verification value [3], which I adopt and save in the same way. For a clean sender reputation, I add or update SPF and later DKIM if I plan to use external email services. I type or copy TXT values exactly so that no unnecessary errors occur. arise. After each change, I check whether the entry fits syntactically and whether duplicate records cause unnecessary conflicts. Cleanly maintained TXT records save me a lot of time. Support.

Step 4: Checking, SSL and redirects

After saving, I wait for the DNS propagation, which can take from a few minutes to several hours, and then start the Examination. I look at the connection status in the target platform, often a green tick or a confirmation appears. I activate or renew the SSL certificate so that HTTPS runs without a warning message and test http on https, as well as "www" on the root or vice versa. I check whether canonical URLs are correct and whether redirects work properly so that there is no duplicate content. A quick test with several devices and networks reveals cache effects and local Resolver on.

Forwarding vs. DNS change

I set up a domain forwarding if I only want to redirect, for example from an additional domain to a main address, without changing DNS records in detail [4][6]. To do this, I go to Strato's domain management and use "Set up redirect", enter the target URL and select 301 for permanent or 302 for temporary [6]. For clean SEO, however, I use the DNS connection via A and CNAME record for main projects so that the page structure and URLs remain unchanged. stay. If you want to know exactly how to do this, this guide to the Forwarding with Strato. The following table shows the difference in short form and makes your Decision.

Method	Advantages	Disadvantages
DNS (A/CNAME change)	Full control, good SEO, no URL changes	Technically a little more complex
Forwarding (301/302)	Quickly set up	Less professional, own URL structure is lost

Typical errors and quick solutions

If nothing is live after 24 hours, I compare all values again and look for typing errors in host names, points or Hyphens. I check whether I have unintentionally left old records that could overlay new entries, such as several A records for the same hostname combination. I clear the browser and DNS cache or test via hotspot to rule out local effects. I check TTL, because a high value significantly delays visibility worldwide. In stubborn cases, I remove contradictory entries and reset the target values so that only the correct records are used. grab.

Keep e-mail with Strato: MX, SPF, DKIM

I leave MX records unchanged if mailboxes are to continue running at Strato, and only change web records such as A and CNAME. I add SPF so that Strato remains allowed as the sending server, possibly plus external services that send mails later. I set up DKIM where my mail is actually signed so that recipients can check the signature. I test delivery, anti-spam rates and bounces to quickly identify misconfigurations. This keeps website and email cleanly separated and working reliably more.

Understanding DNS propagation: Choosing the right TTL

TTL describes how long resolvers cache an entry, so I plan changes in such a way that I set a lower TTL in advance and only then set the target values change. After the changeover, I increase the TTL again in order to generate fewer requests and stabilize response times. For urgent launches, I reduce TTL in good time so that updates are visible more quickly. I communicate internally that there may be delays and plan buffers for DNS propagation. In this way, I avoid false assumptions and keep expectations realistic at Team.

Checklist without a hook: this is how I proceed

I start with the target platform, capture all DNS values and open the window with A, CNAME and TXT records for the later Takeover. I then log in to Strato, select the domain and open the DNS tab. I set A-Record(s) for the root domain, enter the CNAME for "www" and accept the verification TXT values. I save and wait for the update, monitor the target platform and confirm the connection as soon as the status is green. I activate SSL, test http to https, "www" to root and check that all pages are accessible and canonicals are correct so that SEO is clean. remains.

Special technical features at Strato: host names, root and CNAME limits

When entering the DNS records, I pay attention to the input masks. For the root domain, I either use the host field "@" or leave it empty, depending on the interface. I do not set a protocol part (no http/https) for the target of a CNAME, but only the FQDN - ideally with a final dot in thoughts, even if the UI does not show it. Important: A CNAME at the root is not permitted in the DNS standard. If I want to point the root domain to a platform, I use A-Record(s) (and optionally AAAA for IPv6). Some DNS providers offer ALIAS/ANAME for the root; at Strato I plan conservatively with A/AAAA and use "www" as CNAME on the platform host. This way the zone remains standard-compliant and stable.

I deliberately keep the number of entries per host low. Multiple A-Records with different destinations may be desirable (load balancing), but if mixed incorrectly they generate Inconsistencies. CNAME and A/MX/TXT must never share the same host. I therefore check for duplicate hosts and remove contradictory combinations before adding new values. save.

IPv6 (AAAA), CAA and DNSSEC at a glance

Many platforms now support IPv6. If the target platform offers me AAAA addresses, I add them next to the A record so that the page can also be accessed via IPv6. reachable is. This increases reach and can improve latencies. I can also define CAA records to determine which certification authorities (CAs) are allowed to issue certificates for my domain. This is a voluntary Protection against false positives. If DNSSEC is activated at Strato, I only change nameservers or critical DNS entries with a view to correct signatures. If a name server change is planned, I make sure that the key rollover and DS entry are properly coordinated so that no Failure comes.

www or non-www: Canonical strategy and HSTS

I consciously decide whether my main address should run with or without "www". Both variants are technically correct, but I need a clear Canonical and a clean 301 redirect from the secondary variant. I check the redirect chain: There should only be one hop from http to https and possibly from www to root (or vice versa). Longer chains increase latencies and weaken SEO. If I use HSTS, I only activate it when HTTPS is clean on both variants, as incorrectly set HSTS leads to hard blockages with mixed content or faulty certificates. I actively warn against mixed content by setting all assets to https switch.

Alternative: Change name server instead of maintaining DNS at Strato

Sometimes it makes more sense to place the name servers completely with an external provider (external DNS administration), for example for Anycast-performance, Geo DNS or extensive automation. I only change the name server entries at Strato and move all zone records (A, AAAA, CNAME, MX, TXT, CAA) to the new DNS provider. Advantages: fast changes, APIs and possibly integrated CDN/WAF services. Disadvantages: additional dependency and extra work during initial setup. Transfer of the zone. For the core goal "connect strato domain externally", however, the administration in Strato is usually sufficient - I only choose to switch if I really need the extras. use wants.

Mixed operation: subdomains for blog, store and app

I plan the namespace at an early stage. The main page often runs under the root or "www", while a store is under "store." and a blog under "blog." . I specifically set subdomain records for this: CNAME for "www" and, if applicable, "blog." to the platform hosts, A/AAAA for services that require IPs, or a separate MX/separate TXT entries if subdomains send mails independently. I stay away from wildcard records ("*.domain.tld") unless I really need them - they can make troubleshooting more difficult and identify suspicious subdomains. conceal.

Extended e-mail security: cleanly coordinating SPF, DKIM, DMARC

To ensure that e-mail remains reliable with Strato, I carefully adjust the sender authentication in addition to unchanged MX records. SPF should include all legitimate senders, but not exceed the 10 DNS lookup limit. I avoid duplicate SPF records and maintain a single, consolidated Policy. DKIM where mails are actually signed (e.g. newsletter tool). I rotate keys on a regular basis and leave old selectors in place during the transition phase. I also add DMARC with "p=none" to start, monitor reports and later increase to "quarantine" or "reject". This is how I increase deliverability without risking legitimate Sender.

Diagnostics and tests: tools and commands

For reliable testing, I don't just rely on browser tests. I use commands like dig or nslookupto query A, AAAA, CNAME, MX and TXT records (e.g. dig A your-domain.tld +short, dig CNAME www.deine-domain.tld +short). With curl -I https://deine-domain.tld I see HTTP status codes and check whether redirects are working as expected. openssl s_client -connect your-domain.tld:443 -servername your-domain.tld helps with the SSL handshake. In case of problems I clear DNS caches: under Windows ipconfig /flushdns, on macOS sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderunder Linux depending on the resolver. Tests via mobile hotspot hide local network caches from.

Zero-downtime planning and rollback

If I absolutely want to avoid downtime, I lower the TTL to e.g. 300 seconds 24-48 hours before the switch. I set up the target platform completely, activate SSL preparations and test under a temporary subdomain (e.g. "staging."). On the switchover date, I change the relevant DNS records, monitor accessibility and leave the old environment in parallel for a short time. If an error occurs, I can use the low TTL to quickly revert to the previous configuration. jump back. After successful stabilization, I increase the TTL back to a balanced value (e.g. 3600 seconds) for fewer queries and stable responses.

Subtleties in platform specifications

Many providers display several A-IPs. I adopt all of them, if recommended, so that the platform load balancing and failover use can. For CNAME verifications, I use the exact host specified by the platform (including any prefixes such as "_verification" or random tokens). I wait for the internal status check before deleting old verification records. Some platforms need time to issue certificates - so I don't plan to run immediate live tests seconds after the Changeover.

Frequently asked questions (FAQ) about "connect strato domain externally"

• How long does the changeover take? Between minutes and 24-48 hours, depending on TTL, caches and global Propagation.
• Will e-mail be lost? No, if MX remains unchanged and SPF/DKIM/DMARC are correctly maintained. Web changes affect e-mail not.
• Do I have to set IPv6? No, but it is recommended. If the platform delivers AAAA, the accessibility and often the Latency.
• Can I only connect Root via CNAME? Standard DNS does not allow a root CNAME. I use A/AAAA or the ones recommended by the provider Alternatives.
• Why do I see old content? Local or provider caches, high TTL or CDNs can temporarily delete old entries. show. Patience and cache flush help.
• What about subdomains? I can connect individual subdomains separately (blog, store, app) and thus mixed operation without conflicts realize.
• How do I protect myself? With CAA records for certificates, DNSSEC (if used), a clear redirect strategy and consistent e-mail authentication (SPF/DKIM/DMARC).

Briefly summarized

I connect my Strato domain externally by setting A, CNAME and necessary TXT records exactly and MX records for e-mail at Strato leave. After the changeover, I test SSL, redirects and the status in the target platform until everything is green. For SEO and clear URLs, I prefer to use the DNS link instead of pure redirects. In the event of errors, I meticulously check spellings, TTL and caches before making any further changes. With this process, the connection is reliable without affecting your email or project structure. jeopardize.