A record or CNAME? Connect your .at domain correctly
Does your website service ask for an A record or CNAME? Read the DNS instructions, separate the main domain from www and check your .at website connection.
Read guide ↗The essentials
A DNS record connects a hostname to technical destinations. A web redirect instead answers a website request and sends the browser to another URL. A complete destination address containing https and a page path therefore does not belong in an A or CNAME record. First decide whether the other address should appear in the browser or your own domain should remain the website address.
Start with the result you want in the browser
Before arranging anything, write down what someone should see after opening your .at address. Should the browser’s address bar then show a different address? You want a web redirect. Should your own domain remain in the address bar, with the website directly available under that name? Connect it as a custom domain with the website service, using that service’s DNS instructions. For an Austrian project, this decision often matters more than the individual record type. Registering another address does not connect any content by itself. Before buying an additional domain, establish which outcome the existing website service actually supports.
Explore .at domains and included managementUnderstand A records and CNAMEs when connecting a websiteA CNAME does not redirect to a particular page
A CNAME points to another hostname in DNS, but it does not instruct the browser to open a particular page path. The illustrative destination https://target.example/offer contains several parts: scheme, hostname and path. The /offer path is not part of the hostname. This example explains the distinction; it is not a setting to copy into your domain. For a DNS connection, use only the instructions supplied by the responsible website service. If someone gives you a complete website URL, establish whether it is intended as a redirect destination or simply the public address of an existing project. Do not guess the corresponding DNS value.
Three commonly confused tasks
The table separates typical requests. A technical alias, a web redirect and an embedded display can initially show similar content, but they behave differently. For a form, booking page or sign-in screen, test the complete interaction rather than only the first page. Displaying a page inside a frame is not the same as a normal HTTP redirect. A home page looking correct does not prove that the whole arrangement works. Ask which method will be used, which address remains in the browser and whether the destination system supports the intended display. Choose the approach around your project rather than applying a universal DNS recipe.
| Your goal | Suitable approach | Clarify first |
|---|---|---|
| Open another address in the browser | Web redirect | Complete destination URL and behaviour |
| Keep your own domain as the website address | Connect a custom domain with the website service | DNS instructions and domain assignment |
| Show another page inside a frame | Embedded display, not a normal redirect | Permission and functionality of the destination system |
HTTPS must work at the starting address too
When someone opens an https address, the secure connection to that starting address is established before the browser can read a redirect response. A valid certificate at the destination alone is insufficient. Plan secure access for the redirecting domain and, where relevant, its www address. Do not bypass a certificate warning; have the affected connection checked. A working http request does not demonstrate that https is configured correctly too. Give the responsible support team the exact address opened and the warning shown. Buying the same domain again or entering an unrelated IP address will not resolve that check. Treat the starting connection and the final website as separate test points.
Check the domain connection and certificate separatelyAgree what happens to www, page paths and parameters
Record whether the redirect applies to the main domain, www or both. Also decide what happens when a visitor adds a page path: should every request land on one destination page, or are there matching destinations for existing paths? An old bookmark ending in /contact should not be left untested. URL parameters can also matter for a booking or campaign. Some contain private information, so avoid access tokens or confidential links in tests. Ask for an explicit decision about preserving these components when the redirect is arranged. Then check typical visitor journeys with harmless test values rather than assuming that the home-page result covers every address.
Include old addresses when changing a websitePermanent or temporary – and no redirect loops
HTTP distinguishes permanent and temporary redirects, among other response types. A permanent destination should actually be a long-term decision; a short campaign may have different needs. Agree the appropriate status with whoever is configuring it and test before publishing the address. Avoid a loop in which the first address points to a second and the second returns to the first. Unnecessary intermediate steps also complicate diagnosis. Inspect the final destination, not just the first visible move. Selecting a redirect status is no promise of improved search positions. A useful destination and a working journey for visitors are what the arrangement needs to deliver.
A website redirect is not an email redirect
A web redirect does not decide where messages to addresses at your domain are delivered. Keep existing MX records and required email verifications if the mailboxes should continue unchanged. Document the configuration before editing it. A nameserver change is not automatically necessary for a redirect request and affects more than the website. In your atdomain.at account, check the existing records and nameserver configuration. To request a redirect, open a support ticket with the starting address, complete destination, intended duration and desired treatment of www, page paths and parameters. We will review the appropriate setup with you. Do not include passwords or transfer authorisation codes.
Request a redirect with specific detailsDocument existing website and email recordsPlan the cost and control of an additional .at address
A new standard .at domain currently costs €12.99 total for the first year; renewal is €15.99 total per additional year. New .at domains also have three years of prepaid coverage for one €39.00 total payment: registration and two annual renewals without further payment. This saves €5.97 compared with €44.97 in annual payments at today’s prices. The paid-through date and annually updated technical expiry are different account details. Arrange further renewal in good time afterwards at the offered price; there is no automatic card charge. The package does not apply to transfers or existing-domain renewals. Website hosting and mailboxes are not included. Check any required additional services before ordering.
Compare total prices and prepaid coveragePlan several domains for one project economicallyFurther sourcesRFC 1034: aliases and canonical names in DNS ↗RFC 3986: components of a URL ↗RFC 9110: HTTP redirects and HTTPS verification in section 4.3.4 ↗
