send-test.emailHow It Works
From a recipient address to a receiving server’s response.
1. A real message from an external sender
Enter a mailbox you are allowed to test and complete the automated-abuse check. The service creates a report and queues one plain-text email from noreply@send-test.email. The subject and content are fixed; the tool cannot send arbitrary messages.
2. DNS, MX and SMTP
For delivery, the sending infrastructure resolves the domain’s mail servers through DNS and MX records and communicates with the receiving system over SMTP. The server checks the recipient and its own policies, then accepts the message, temporarily defers it or rejects it. Where STARTTLS is supported, the connection can use transport encryption.
3. Where Cloudflare fits
Cloudflare Workers handles requests, Turnstile helps prevent abuse, Queues separates email processing from the HTTP request, and Email Sending sends the message. D1 stores reports and delivery events. An event subscription returns available Email Sending outcomes to a queue; the service matches them to the message and updates the report.
4. What the report proves
Accepted for sending means the sending service accepted the request. Delivered confirms acceptance by the receiving server, not inbox placement or a human reading the email. Reports show the SMTP codes and diagnostics supplied by the provider; Email Sending does not expose a full SMTP conversation.
5. Authentication
The receiving server can check the sender’s SPF, DKIM and DMARC. Read Authentication-Results in the received message to see those checks: an inbound delivery test does not validate your domain’s outgoing mail configuration.
An open explanation of the architecture, technologies and diagnostic limits lets you assess the service’s claims instead of treating it as a black box. That transparency is the best foundation for trust.