Cloudflare Email Service / interpretation guide
Follow the evidence past “success”.
Keep one send attempt together: the selected interface, declared configuration, send result and observed inbox behavior. This tool explains those facts locally. It does not send email or connect to an account.
Read a response into the timeline.
Choose REST, SMTP or Workers. Paste one redacted response and run the parser. REST recipient arrays are counted without retaining addresses in the result. SMTP needs command/reply context and the terminating DATA dot. Workers accepts messageId or code; request_meta is this tool’s optional count format, not an official response field. Record inbox and callback observations independently in the timeline.
Workers: inspect the binding result.
The structured API returns a message ID on success and uses string error codes on failure. Check recipient counts, attachment counts and the whole encoded message size before investigating delivery. A message ID helps correlate logs; it is not inbox evidence. Workers API reference.
REST: read each recipient category.
The response separates delivered, queued and permanent_bounces. A pending recipient has a different next step from a permanent failure. Record counts here without sharing recipient addresses, and inspect your provider’s detailed result privately. REST API reference.
SMTP: identify the command first.
Cloudflare submission uses implicit TLS on port 465. A 250 response to a recipient command does not mean the complete message was submitted. Even after DATA, a 250 without a Message-ID can occur when all recipients are suppressed and dropping them is enabled. Review logs and configuration before concluding that this is the cause. SMTP reference.
Keep receiving mail intact.
Email Routing and Email Sending have different setup requirements. Existing receiving MX records do not prove outbound readiness. Compare your actual sending records with the documented configuration; a failed lookup of a guessed DKIM selector is incomplete evidence. Domain configuration reference.
Finish the application test.
Reproduce your public form and its callback in a fresh WebTraceCheck session. Use CleanTempMail to observe a message sent to a non-sensitive test identity on your own app. Record arrival and completion separately. Both optional products share this site’s operator.
ONE RESPONSE / THREE RECIPIENTS
Read a mixed result without resending the whole batch.
This invented REST response describes three separate recipients. The names use a reserved example domain; the file is a parser fixture, not a message to send. It is deliberately mixed so “success: true” cannot be mistaken for one shared delivery outcome.
{"success":true,"result":{
"delivered":["one@example.test"],
"queued":["two@example.test"],
"permanent_bounces":["three@example.test"]
}}Download the exact response fixture and paste it into the REST tab. The inspector should report one recipient in each group. A red delivery-stage warning summarises the presence of a bounce; it does not erase the other two recipient outcomes.
Original response reading exercise| Recipient | What is recorded | Next useful evidence | What this does not prove |
|---|
| one | API reports delivery | Observe this test inbox, then the intended app action | Inbox placement, opening or completed signup |
|---|
| two | Queued for later | Correlate a later delivery event with this attempt | A permanent failure or a reason to send again immediately |
|---|
| three | Permanent bounce reported | Inspect the actual failure detail privately | The same cause for every recipient or a general provider outage |
|---|
The response groups follow Cloudflare’s REST reference. The follow-up decisions are our worked example. Keep recipient-level detail in your own protected log; an aggregate exported diagnosis cannot tell you which individual address needs attention.
DISPATCH MEMO 01
Retry is a decision, not a default button.
Suppose a dashboard times out after your application submits a request. You do not yet know whether the provider accepted it. Record the attempt identifier and inspect the available send logs before creating a second attempt. A second accepted send can produce a duplicate even if the first UI never displayed success.
For the mixed fixture, resending all three recipients would ignore that one delivery is already reported and another is still pending. Establish the unresolved state first, then use the provider’s documented recovery behaviour. This guide does not claim the API offers an idempotency guarantee.
DISPATCH MEMO 02
Match the SMTP reply to its command.
In an invented transcript, RCPT TO receives 250, but the connection closes before the message body and terminating dot. You have a recipient-command acknowledgement, not a completed DATA submission. Move the evidence marker back to submission; do not describe this as “delivered but missing”.
Save the command names, reply codes and whether DATA completed. Remove addresses, credentials and message content before sharing. A single bare 250 without its preceding command cannot locate the failure.
DISPATCH MEMO 03
Measure the encoded message.
A 3,000,000-byte attachment becomes 4,000,000 base64 characters before MIME line breaks and headers. The arithmetic is four times the ceiling of bytes divided by three. Add the body, boundaries and other attachments when checking the complete message against the current service limit; the original file size alone is insufficient.
This is an encoding example, not an upload test. Use the actual encoded payload size and the current limits reference before changing a production application.
A four-line receipt for the next operator
Attempt: owned test / UTC time / interface
Submission: response or uncertainty, not a guess
Recipients: reported delivered 1 / queued 1 / bounced 1
Observed later: inbox ___ / application action ___
Keep the same attempt identity on every line. Record later evidence with its own time instead of rewriting the earlier observation as if it had been known all along. If only the callback fails, investigate that application step rather than restarting delivery.
Inspect an attempt →