The local default is where this bites first. `wrangler dev` binds a simulator rather than the service, so a call to `env.EMAIL.send()` resolves, the message lands in your console, and nothing crosses the network [11][10]. Setting `remote: true` on the binding is what makes a local run send real mail [11]. In an unmodified project, then, the first genuine send happens after deploy, which is also the first exercise of SPF and DKIM alignment on the onboarded domain [11][7]. A suite that asserts "email sent" against a log line stays green no matter what DNS says.
The plan gate is stated two ways in the same walkthrough. Up front, the native option currently requires the Workers Paid plan, not just a Cloudflare account [2]. Lower down, it is sending to arbitrary recipients that requires Workers Paid, with the pre-onboarding binding limited to destination addresses you have explicitly verified [5]. Those are different specifications. Under the broad reading a free-tier project cannot use the binding at all; under the narrow one, a Worker that mails three verified addresses on your own team may work unpaid. The walkthrough does not resolve which applies, and it is worth confirming against your own account before you add the `send_email` entry to Wrangler [9].
Onboarding does the DNS work for you. Cloudflare adds the SPF, DKIM and DMARC records it needs plus MX records on a `cf-bounce` subdomain [7], four record types you would otherwise place by hand [17]. The stated window is minutes in the usual case and up to 24 hours [8]. That window, not the code, carries the schedule risk, because the code is one config block and one `send()` call [9][10].
The argument for the fetch path is narrower than portability. Workers run on a V8 isolate rather than Node.js, so a library that assumes Node-specific built-ins can break in ways that are tedious to debug [13]. An HTTP API you call with `fetch()` has no package to be incompatible in the first place, and the walkthrough's example, Notify, ships no SDK at all [14]. That reasoning transfers to any keyed HTTP mail API. It would have to, for the comparison to be neutral: the same piece links Notify's docs and shows its webhook registration for Bounce and Delivery events, and the claim that the native binding offers no equivalent without building your own event handling is the author's [18][15]. Notify's domain verification is standard SPF, DKIM and DMARC records placed directly with Notify [16], so the DNS work does not disappear on that side either.
Whichever path you take, `allowedSenderAddresses` and `allowedDestinationAddresses` restrict what the binding is permitted to use, and the walkthrough recommends setting them regardless [12]. The decision rule is simpler than the feature comparison. If the first user-facing message goes to an address nobody can enumerate in advance, such as a password reset for a stranger, the binding is not an option until onboarding completes [5][8].
