Email delivery and troubleshooting

Begin with addresses you control. On Free, the test correspondent must be your verified signup email address; upgrade for other correspondents. Verify the Robotomail account, choose the intended mailbox and send a short plain-text message with a unique subject. Save the returned message ID and check the message status and delivery events.

Inspect the receiving mailbox, including spam and quarantine folders. Reply to the message, confirm that Robotomail receives it, and check that your webhook, event-stream listener or polling job handles it once. Test thread continuity in the actual email client, not only in your application's database.

Repeat with an HTML alternative, an attachment within current limits and a controlled failure scenario. Use a test environment for failures that could affect reputation. Record the time, sender, recipient domain, message ID and event outcome without logging full private message bodies or API keys.

A successful HTTP request means the service accepted that API operation. It is not the same as confirmed receipt by the destination mailbox.

• SENT: the outbound message has entered the sending flow. Check its later events or status.
• DELIVERED: the recipient's mail server accepted the message. This does not establish inbox placement or a human read.
• BOUNCED: delivery failed; inspect the event details and recipient condition before deciding what to do.
• COMPLAINT: a recipient or downstream system reported a complaint. Stop unwanted sending and honor suppressions.

Use the messages reference and webhooks reference for the exact response and event fields. Correlate records by ID and avoid treating an HTTP 200 as proof that the user saw the message.

A queued message is waiting for a processing or delivery step; it is not proof that the recipient server accepted it. Applications, workers and receiving providers can each introduce waiting time.

Check the API response and current message status first. Distinguish a request that failed before acceptance from one whose outcome is uncertain after a timeout. Blindly submitting a second send can create duplicates. Keep a record of the intended business event and any returned message ID, and reconcile before retrying an uncertain send.

Check account verification, plan limits and service status if sending is blocked. For an ongoing issue, provide support with message IDs and timestamps, excluding credentials and unnecessary private content.

A temporary failure, often called a soft bounce, can involve a full mailbox, a temporary server issue or throttling. A permanent failure, often called a hard bounce, can involve a nonexistent recipient or a rejected address. Providers classify and report failures differently, so inspect the actual diagnostic rather than relying only on the label.

Do not repeatedly resend to a permanently failed recipient. Respect Robotomail suppressions, honor complaints and give users a way to correct an address. For temporary failures, understand the provider's retry behavior before adding application retries.

An undelivered-message notice can also be forged. Do not execute instructions or open attachments solely because a message claims to be a delivery report. Use trusted API events and message IDs to reconcile the outcome.

Check SPF, DKIM and DMARC alignment for the domain actually used. Confirm that your From identity, links and message content match the recipient's expectation. Send only wanted messages, remove invalid recipients and avoid sudden unexplained volume spikes.

Authentication is necessary for a credible sending setup, but it does not guarantee inbox placement. Recipient filters, domain reputation, content, user feedback and sending patterns all affect the result. Test across representative recipient systems and inspect the complete headers when investigating an issue.

A delivered event means the server accepted the email even if it later places it in spam. Changing the wording repeatedly or rotating domains to evade filtering is not a substitute for resolving the underlying cause. See domain authentication and the acceptable-use policy.

Track sends, deliveries, bounces, complaints, inbound volume and the time from arrival to a useful application action. Distinguish mail transport failures from agent or business-logic failures.

Use structured logs with message IDs, mailbox IDs, event type, timestamps and processing outcome. Restrict access and avoid recording API keys or full email bodies by default. Record whether a retry was already handled so repeated webhook notifications do not trigger repeated replies.

Add alerts for sustained failures, authentication errors, exhausted quotas and workers that stop processing. Reconcile missing events using the messages API and your application's action ledger. Monitor both the provider status and your own webhook endpoint or persistent event connection.

The documented Robotomail message events cover transport and delivery outcomes, including received, sent, delivered, bounced and complaint events. Do not assume that native open or click tracking is available simply because delivery webhooks are supported.

An open-tracking pixel, if your application or another service adds one, measures a remote-resource request. Mail privacy features, image blocking, caching and automated scanners make that an imperfect signal. A clicked URL can also be visited by security software. Neither event reliably proves a person read or acted on the message.

Use outcomes closer to the job: a reply, completed activation or resolved support request. If you implement tracking, disclose and configure it appropriately for the audience and data involved. A custom tracking domain is separate from the mailbox's MX and authentication records; this guide does not imply Robotomail offers a hosted link-tracking product.

Check the address syntax your application accepts and reject obviously malformed input. Confirm ownership through a verification message when the workflow requires it. A plausible address does not prove that the mailbox exists or that its owner wants your messages.

A domain publishing MX records has advertised mail routing, not the existence of every recipient address. A Null MX record explicitly advertises that a domain accepts no email. Transient DNS failures are an unknown result, not proof that an address is invalid. Some domains can receive through protocol-defined fallback behavior even without a conventional MX record, so do not treat a simplistic DNS check as a complete validator.

Robotomail is not documented here as a standalone email-validation API. Handle bounces and suppressions after sending, and avoid probing recipient servers as a substitute for consent and verified ownership.

Allowlisting is a recipient-side policy that may permit particular senders or domains through some filters. If a customer controls an organization mail system, its administrator may investigate or adjust that policy. An individual sender cannot guarantee placement by declaring itself trusted.

A recognized From address is not sufficient authorization for an agent to disclose data or perform an account action. Verify the request using your application's identity and permission model. Keep sender authentication, content safety and business authorization as separate checks.

Robotomail outbound suppressions prevent inappropriate future sending to affected recipients; they should not be described as an inbound quarantine or content allowlist.