All documentation

Email Delivery

Client update email delivery starts after the project record is created. Posting an update queues an email copy for the client email saved on that project. The project page is the lasting record, while email tells the client about the new update and gives them the client link.

How client update email delivery works

When you select Post update, the service validates the update and any attachment. A valid update appears in the project history immediately. Its email is then waiting for the configured mail delivery process.

The owner view shows one of these states beneath each posted update:

1. Queued for name@example.com means the email has been recorded and is waiting for a delivery attempt.
2. Sent to name@example.com at 14:25 UTC means the configured mail server accepted the message at the shown time. Times in this status use UTC.
3. Delivery failed, retrying means an attempt failed and another attempt is scheduled.
4. Recorded locally for name@example.com appears when live SMTP email delivery is not enabled. The update is in the project history, but no external message has been sent.

The service retries ordinary failed messages with increasing waits, up to a one hour wait between attempts. You do not need to post the same update again while its status says that delivery is retrying. A duplicate post would add a second update and queue a second email.

The current configured sender may appear as mara-updates@agentmail.to. The sender is a service setting and can change, so use the sender shown in the received message when checking mail rules. Each message also includes the configured support contact.

What Sent does and does not prove

Sent means the outbound mail server accepted the message. It does not guarantee that the recipient's provider placed it in the inbox, that the provider did not filter it, or that the client read it. The service does not show opens, clicks, bounces, or inbox placement.

If the status is Sent but the client cannot find the message:

1. Confirm the recipient shown in the status is the intended address.
2. Ask the client to check spam, junk, quarantine, and mail rules.
3. Copy the client link from the project page and send it through an agreed channel.
4. Ask the client to allow messages from the sender shown on a received message.
5. Use the support link in the site footer if delivery continues to fail.

Do not post a replacement solely to produce another email unless the update itself needs correction. The original project page remains available even when email is delayed or filtered.

Reply-To behavior

Update emails go to the project's client email. Their Reply-To address is the account owner's email. If the client uses the email program's Reply command, their response goes to the owner as an ordinary email.

An email reply does not add a comment to the project page. To keep a response with the update, the client must open the client link and submit the reply form under that update. The update email says to reply on the page for that reason.

When a client submits a reply on the project page, the service records the comment first and queues a notification to the owner. The notification's Reply-To address is the client email saved on the project. Replying to that notification therefore sends an ordinary email to the project client address, but it still does not add another project comment.

Use page replies when the response should remain in the shared project history. Use ordinary email when a private or separate conversation is intentional. Copy any resulting decision into a later project update if the client needs a common record.

Attachments and email

Update and reply attachments are stored with the project record and downloaded from the project page. They are not attached to the outbound email. A recipient needs the current client link to reach an update attachment. A client reply notification points the owner back to the signed in project view.

If you create a New link, routes that contain the old client token stop working. Old update emails can therefore contain a link that no longer opens. Send the new client link to intended readers after changing it. Read Attachments for supported formats, size limits, and download safety.

Handle common failures

If the update form reports an error, the update was not accepted. Correct the error and submit again. A file error requires you to select the file again. Do not assume an email is queued until the update appears in the posted history.

If the update appears but stays Queued, wait for the normal delivery process before reposting. If it changes to Delivery failed, retrying, the service will make another attempt. Share the client link separately when the information is time sensitive.

If the displayed recipient is wrong, the product has no project edit screen and no control to change a client email. It also has no control to edit, delete, archive, or mark a project done. Create a new project with the correct client email for future updates. Use the support link in the footer if an incorrect queued message creates a privacy concern, but do not assume support can perform an unsupported change.

Treat client update email delivery as a notice, and use the project page to review what was posted. Keep both limits in mind when setting client expectations. The client update template helps you write the message, and Weekly Nudges explains reminder emails sent to owners.