Newsletter with a .at domain: plan senders, replies and sending

Start with the name your readers recognise

A small Austrian initiative has been sending event updates from a private address. It now wants its newsletter to match its own website. Before copying any DNS values, the team records its chosen domain, the displayed sender and the person who will answer questions. For a new .at domain, search two or three clearly distinguishable names. Say them aloud and compare them with the name used on your website. A separate registration solely for newsletter sending is not automatically necessary. Aim for a consistent identity that you can retain when you eventually change sending services, rather than choosing a name tied to one temporary tool.

Distinguish the sender from the reply destination

The displayed name, sender address and reply destination do different jobs. The From field identifies the message author; a Reply-To field can specify a different reply address. Ask the sending service to show you both settings. Choose an address whose incoming messages someone actually handles. A polished sender name does not create a mailbox. For approval, record the complete addresses as well as the visible name. This helps you notice when an old template still uses another project’s address, or when replies would go to a person who has since left. Review the settings again when the person responsible changes.

Treat newsletter sending and a mailbox as separate services

A newsletter service and the service handling ordinary incoming email can be different. Before buying, ask whether the offer covers sending only or also includes a usable mailbox. Establish who will set up the reply mailbox and who needs access. Successfully verifying a domain with the sending service does not automatically create that mailbox. Keep existing incoming mail working during setup. If your normal messages already arrive, do not replace every MX record as a precaution. Ask which specific change the new sending setup needs and which existing records must remain. Keep the answers with your project notes for the next person managing it.

Make a deliberate choice about a sending subdomain

Some sending services require or recommend a dedicated subdomain for particular sending functions. Ask for the complete name and its purpose: is it for the visible sender, technical feedback or links inside the newsletter? These do not have to be the same address. A subdomain under a domain you already own does not require another domain registration. It also does not automatically separate every risk or responsibility. Before setup, ask what must change or be removed if you switch services later. Do not invent target values or treat an illustrative example name as a working configuration for your account.

Edit the DNS zone that is actually active

Before making changes, compare the active nameservers with the service where you intend to edit DNS. With our default nameservers, you can manage supported records in your domain account. After switching to external nameservers, active records must be edited at that external DNS service. An old zone retained with us then has no control over those public answers. When requesting support, specify the configuration you need help with and establish who has the required access. Do not switch nameservers merely because a newsletter needs a TXT or CNAME record. First save the existing values relevant to the change.

Ask the service to explain the complete sender check

Your sending service should show which checks are missing for your project and which records it expects. For DMARC, SPF or DKIM must provide the appropriate alignment with the visible From domain; an unrelated successful check is insufficient. Avoid copying a generic policy from somebody else’s setup. Record the type, host, value and purpose of every requested change. Ask the responsible service how existing ordinary email sending is accommodated. If verification fails, save the specific message rather than experimenting by deleting established mail records. Follow the technical guide for the detailed authentication configuration and review uncertainty before changing a working setup.

Approve the first issue with a practical checklist

Before regular sending begins, arrange a controlled preview through your sending service to your own designated recipient addresses. Check its appearance on a phone and a computer. Reply to that preview and confirm that the reply reaches the agreed mailbox. Open important links and check the intended public destination. Also check whether any link subdomain you use supports HTTPS. A sending service accepting a message does not prove that it reached the recipient. Passing authentication does not guarantee inbox placement either. Record the actual outcome, time and unresolved points before approval, instead of treating a green setup indicator as the whole result.

• The sender name and complete address match the project.
• Replies reach a mailbox that someone monitors.
• Links open the correct public destination.
• Responsibility and outstanding questions are clear before launch.

Budget for ongoing services and a later move

A standard new .at domain at atdomain.at currently costs €12.99 total for the first year. Renewal costs €15.99 total per additional year, checked on 2 November 2026. At unchanged prices, the first year and one later annual renewal total €28.98. Newsletter sending, hosting and email mailboxes are not included; we do not currently sell those services. Check separate charges and terms with your chosen sending service. Record who will renew the domain and who will review DNS values after a service change. Remove old records only after their purpose is understood and the transition has been confirmed, rather than clearing the zone all at once.