This article covers email problems in both directions: emails sent to your support address that do not create tickets, and emails sent from Atera that do not reach the recipient.
When incoming emails fail to create tickets, the issue generally falls into two categories: Atera never received the email, or Atera received the email but was not allowed to create the ticket. Work through the sections below in order.
If emails sent from Atera are not reaching a recipient, see Emails From Atera Are Not Reaching a Recipient at the end of this article.
Email Forwarding Verification
Atera can only create tickets if it actually receives the email.
Your support emails should be sent to your primary support address configured in Atera. This address should automatically forward all incoming messages to the autogenerated Atera email address, which is what ultimately creates the tickets in the console. As an alternative, you can send emails directly to the autogenerated address, but using the primary address is the recommended setup.
For instructions on setting up the forwarding correctly, see Set up email forwarding in Atera.
You can also verify the forwarding setup with a quick test. Simply send one email to your primary support address and another to the autogenerated Atera address:
- If both messages create tickets, the forwarding is correctly configured and you can continue with the next checks.
- If only the email sent to the autogenerated address creates a ticket, the forwarding rule for the primary address isn’t working and should be reviewed.
- If neither email creates a ticket, the overall configuration might be incorrect and must be resolved before Atera can receive messages.
Note: Even if forwarding is correct, ticket creation can still fail due to contact or customer settings, or an SPF authentication failure on the sender's domain. Continue with the steps below.
Exclude Atera's Own Emails From Your Forwarding Rule
Atera sends its automated emails, such as Support Request Received and Customer Portal Credentials, from your primary support address. Those messages arrive back in your support mailbox. If your forwarding rule forwards everything in that mailbox, it forwards them on to the autogenerated Atera address as well, and each one creates another ticket, which sends another automated email.
This creates a loop that can generate dozens of tickets within seconds of each other.
In your mail provider, add a condition to the forwarding rule that excludes messages sent from your own support address. Then send one test email to the primary support address and confirm that only one ticket is created.
Contact Email Settings
In Admin > Support and ticketing > Email settings, scroll to the Contact Email Settings section.
If this is disabled, Atera will not create tickets from email addresses that are not already added as contacts.
Enable this option if you want new email senders to automatically become contacts and create tickets.
Contact-Level Settings
If the sender exists as a contact, open their Contact Page and check the options under the "Permissions" tab:
Set as Main Contact
This setting affects ticket creation if the customer is configured to allow only main contacts to submit tickets (see below).
Ignore Emails From Contact
If enabled, Atera will ignore all emails from that address.
Make sure it is unchecked unless intentionally blocking that sender.
The “Unassigned” Customer
Do not delete the Unassigned customer.
It is recommended to keep it because Atera uses it to store contacts from domains that do not match the domains of existing customers (especially useful if each customer has its own domain).
Deleting it can disrupt how new contacts are handled and how tickets are assigned.
Verify Forwarding From Your Email Side
If all Atera settings look correct, check an email trace on your side to confirm the forwarding rule actually sent the message to the correct Atera email address.
If all the steps above have been checked and everything appears correctly configured, please reach out to our support team. Make sure to include both an .eml file of the affected email and an email trace from your mail provider, this will help us diagnose and resolve the issue much faster.
SPF Authentication Failures
If a customer's domain sends outbound mail through a security gateway or spam filter in addition to their primary mail provider (for example, Microsoft 365 plus a service like MailInBlack), that gateway must also be authorized in the domain's own SPF record. If it isn't, mail routed through the gateway will fail SPF validation when it reaches Atera, and no ticket will be created - even though the sender's own mail trace shows the message as successfully sent.
Note: This is about the customer's own domain's SPF record, not any record Atera generates. It affects every message sent from that domain, regardless of which Atera address it's sent to.
The telltale sign: the sender's mail trace (for example, a Microsoft 365 message trace) shows the email as delivered successfully, because the sending side has no visibility into Atera's SPF check on arrival. The failure only shows up on Atera's side, as an SPF authentication failure at the point the domain routes through the gateway rather than directly through the authorized mail provider.
To resolve this, the administrator who manages the domain's DNS or mail security needs to:
- Get the SPF
include:value or IP range that the gateway provider publishes for its customers (available from the gateway's own support documentation or portal). - Add it to the domain's SPF TXT record alongside the existing mail provider's include, for example:
v=spf1 include:spf.protection.outlook.com include:<gateway's SPF include> -all - Once the SPF record is updated, DNS propagation is usually within about an hour. Resend the email once propagation completes.
Check the Email's Character Encoding
In rare cases, an email reaches Atera but cannot be processed into a ticket because it uses an obsolete character encoding, such as UTF-7. Modern mail systems expect UTF-8, and messages encoded in legacy formats may fail during processing even though they were successfully received.
To check the encoding, open the affected email's .eml file in a text editor (e.g., Notepad++) and look for the "Content-Type: charset=" value in the message headers. If it shows a legacy encoding such as UTF-7, update the sending mail client or server to use UTF-8, then resend the email.
Note: The encoding issue may not always be visible in the original .eml file. If the headers look normal but emails from a specific sender still fail to create tickets, contact our support team and include the .eml file and an email trace.
Emails From Atera Are Not Reaching a Recipient
When an email sent from Atera does not arrive, there are two different situations and the fix is not the same. Either an individual message was rejected by the receiving mail server, or the recipient's address has been blocked in Atera and no further emails are being sent to it.
An Individual Message Bounced
A bounce means the receiving mail server rejected that specific message. Nothing is blocked in Atera, and once the cause is resolved the next email will be delivered normally.
The rejection reason is returned as an SMTP error code by the recipient’s own mail server, for example 5.4.1, 5.1.1, 5.1.10, 5.5.0, 5.3.0 or 5.7.230. The code and the message alongside it come from the receiving server rather than from Atera, and describe why that server refused the message.
Ask the recipient to confirm that the mailbox exists, is not full, and accepts external email, and ask them to check whether their spam filtering is rejecting messages from Atera. Then send the email again.
The Address Has Been Blocked
After repeated or permanent delivery failures to the same address, Atera stops sending email to that address. This protects email deliverability for all accounts.
When this happens, Atera sends an email and adds a message to the Notification Center reading Email address ... blocked. This is sent to Admin users only, so a technician who is not an Admin will not see it. Clicking the notification does not remove it.
Note: There is no list of blocked addresses in Atera, so there is nowhere in the console to check whether a particular address has been blocked. The notification and email are the only indication.
An address cannot be unblocked from within your account. Contact Atera support with the affected email address and we will remove it. Resolve the underlying delivery problem first, or the address will be blocked again.
Confirming That an Email Was Sent
Atera does not provide mail delivery logs, and there is no way to view or export a record of individual emails sent from your account. If you need to confirm whether a specific email left Atera and was accepted by the recipient's mail server, contact Atera support with the ticket number and the recipient's address.
