Website works, email does not? Check your .at domain

1. Describe more than just “email does not work”

If your website opens while messages are missing, the entire domain is not necessarily broken. Website and mail are separate services. First note the complete affected address and when the problem started. Does it affect every mailbox or only one? Does the sender receive a bounce, or is the message missing without an obvious error? Also check the spelling after the @: a website using www does not mean that the email address should contain www too. These simple observations help you avoid changing working website records just to see whether that helps.

2. Check the mailbox before changing DNS

Sign in through the known webmail address of your mail service. Use a saved address or open it yourself rather than following a suspicious link in a supposed error notice. Is the mailbox created, active and within its storage allowance? Check rules, forwarding, deleted messages and spam. If webmail works but one app does not, compare that app with the service instructions. Changing DNS will not repair an incorrect app password. Avoid immediately creating a new mailbox with the same name: important messages may remain at the previous service. Preserve existing access before preparing a move.

3. After a website change, which zone is active?

If you recently connected a website or changed nameservers, first compare the current delegation with your inventory. With custom nameservers, edit the zone there; with our default nameservers, use DNS management in your atdomain.at account. A correctly saved record in an inactive zone will not fix the public receiving route. Compare previous MX and related mail records with the instructions from the mail service you still use. Do not clear the zone or combine random values from different instructions. Record exactly what changed so that each step can be traced and, where appropriate, reversed.

• Match the active nameservers to the zone you are editing.
• Note the previous values and the time of the change.
• Keep working website records intact.

4. Compare the MX name, target and priority individually

Incoming mail first looks for MX records at the recipient domain; lower preference numbers take priority. Copy the name, target and priority from your mail service. The target is a hostname, not a website URL, and must not be a CNAME alias. Missing MX alone does not prove reception is impossible: SMTP provides a fallback to the domain address. That is not a dependable substitute for your intended mail configuration. A single null MX with preference 0 and a dot as its target explicitly declares that the domain accepts no mail. Change it only according to your actual setup instructions.

5. For sending problems, look beyond MX

If you receive messages but cannot send successfully, first establish whether the mail service permits sending for your mailbox and device. Then compare the supplied SPF and DKIM records and the DMARC configuration. SPF checks authorised sending sources, DKIM verifies a signature against published information, and DMARC checks the appropriate sender alignment. Multiple competing SPF policies at the same name are not a solution. Do not simply disable protection to make a test pass. Include every sending service you actually use according to its instructions. A website contact form may send through a different route from your regular mailbox; investigate those separately.

6. Keep the error details rather than whole messages

Record the time, affected recipient domain and exact technical error. SMTP replies beginning with 4 indicate temporary rejection; those beginning with 5 indicate permanent rejection of that request. The accompanying text helps interpretation but does not by itself establish the cause in your case. Avoid repeatedly sending the same message or changing more DNS records after each attempt. Remove private contents, credentials and unnecessary addresses belonging to other people from a support extract. Keep enough technical detail for the responsible mail service to locate the event in its logs.

7. Check each correction with a small test

After a justified change, read back both the saved value and the public DNS answer. Previous answers may remain cached; record the time and previous TTL rather than promising a fixed number of minutes. Then test from an independent mailbox to your domain and in the opposite direction. Separate a webmail test from an app test. Also check whether messages are still arriving at the old mail service. One successful message does not confirm every forwarding address or website form. Work through the routes you actually use individually and document the results before changing anything else.

8. Separate domain management, mail costs and support

atdomain.at provides domain registration and management. A standard new .at address costs €12.99 total price for the first year; renewal currently costs €15.99 total price per additional year. DNS management with the default nameservers and custom nameservers are supported. We do not currently sell email mailboxes or hosting; use a separate service with its own charges. For a DNS question, send the domain, time, affected direction and redacted error through your account. Ask your mail service about mailbox access, storage and app settings. Never share passwords or secret verification links.