Send Your First Email in 5 Minutes

Unknown — Sat, 04 Apr 2026 00:00:00 +0000
This guide takes you from zero to a delivered email. No configuration files. No infrastructure. Just an API key and a few lines of code.</p>
By the end, you'll have sent a real email through euromail's SMTP engine with DKIM signing, SPF alignment, and bounce tracking, all running from Finnish infrastructure.</p>
What you'll need</h2>
A terminal with
curl</code>, or a project using TypeScript or Rust</li>
</ul>
Step 1: Create your account</h2>
Go to dashboard.euromail.dev/register</a> and sign up with your email, a password, and your company or project name.</p>
You'll receive a verification email. Click the link to activate your account.</p>
The free plan gives you 1,000 emails per month</strong>, one domain, five templates, and two webhooks. No credit card required.</p>
Step 2: Get your API key</h2>
After verifying your email, the dashboard shows your onboarding page with a freshly generated API key. It looks like this:</p>
em_live_aBcDeFgHiJkLmNoPqRsTuVwXyZ012345</span></span></code></pre>
Copy it now. The full key is only shown once. You can always create new keys from the dashboard under API Keys.</p>
You'll pass this key in the X-EuroMail-Api-Key</code> header on every request.</p>
Step 3: Register your sending domain</h2>
Before sending email, you need to tell euromail which domain you're sending from. If your emails come from hello@yourdomain.com</code>, register yourdomain.com</code>.</p>
Via the dashboard</h3>
The onboarding wizard has a domain field. Type your domain name and click "Add domain."</p>
Via the API</h3>
curl</span> -X</span> POST https://api.euromail.dev/v1/domains</span> \</span></span>
  -H</span> "X-EuroMail-Api-Key: em_live_your_key_here"</span> \</span></span>
  -H</span> "Content-Type: application/json"</span> \</span></span>
  -d</span> '{"domain": "yourdomain.com"}'</span></span></code></pre>
The response includes DNS records you'll need to configure:</p>
{</span></span>
  "data"</span>: {</span></span>
    "id"</span>:</span> "d4e5f6..."</span>,</span></span>
    "domain"</span>:</span> "yourdomain.com"</span>,</span></span>
    "dns_records"</span>: {</span></span>
      "dkim"</span>: {</span></span>
        "type"</span>:</span> "TXT"</span>,</span></span>
        "host"</span>:</span> "euromail._domainkey.em.yourdomain.com"</span>,</span></span>
        "value"</span>:</span> "v=DKIM1; k=rsa; p=MIIBIjANBg..."</span></span>
      },</span></span>
      "spf"</span>: {</span></span>
        "type"</span>:</span> "TXT"</span>,</span></span>
        "host"</span>:</span> "em.yourdomain.com"</span>,</span></span>
        "value"</span>:</span> "v=spf1 include:spf.euromail.dev ~all"</span></span>
      },</span></span>
      "return_path"</span>: {</span></span>
        "type"</span>:</span> "MX"</span>,</span></span>
        "host"</span>:</span> "em.yourdomain.com"</span>,</span></span>
        "value"</span>:</span> "bounce.euromail.dev"</span>,</span></span>
        "priority"</span>:</span> 10</span></span>
      }</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>
Notice that all records live under the em.</code> subdomain. This isolates your transactional email reputation from your root domain, so a delivery issue with marketing email won't affect your password reset deliverability (or vice versa).</p>
Step 4: Send your first email (sandbox mode)</h2>
Here's the trick: you don't have to wait for DNS verification to test the API. Euromail has sandbox mode</strong>. When your domain isn't verified yet, you can send emails to your own account email address. The email goes through the full pipeline (queue, DKIM signing, SMTP delivery) but is restricted to your address only.</p>
Using cURL</h3>
curl</span> -X</span> POST https://api.euromail.dev/v1/emails</span> \</span></span>
  -H</span> "X-EuroMail-Api-Key: em_live_your_key_here"</span> \</span></span>
  -H</span> "Content-Type: application/json"</span> \</span></span>
  -d</span> '{</span></span>
    "from": "hello@yourdomain.com",</span></span>
    "to": "your-account@email.com",</span></span>
    "subject": "My first euromail",</span></span>
    "html_body": "<h1>It works!</h1><p>Sent from Finland.</p>"</span></span>
  }'</span></span></code></pre>
If everything is correct, you'll get a 202 Accepted</code> response:</p>
{</span></span>
  "data"</span>: {</span></span>
    "id"</span>:</span> "a1b2c3d4-..."</span>,</span></span>
    "message_id"</span>:</span> "<a1b2c3d4@euromail.dev>"</span>,</span></span>
    "status"</span>:</span> "queued"</span>,</span></span>
    "to"</span>:</span> "your-account@email.com"</span>,</span></span>
    "sandbox"</span>:</span> true</span>,</span></span>
    "created_at"</span>:</span> "2026-04-04T12:00:00Z"</span></span>
  }</span></span>
}</span></span></code></pre>
The "sandbox": true</code> flag tells you the domain isn't verified yet. The email still delivers to your address. Check your inbox.</p>
Using TypeScript</h3>
Install the SDK:</p>
npm</span> install @euromail/sdk</span></span></code></pre>
Send an email:</p>
import</span> { EuroMail }</span> from</span> "@euromail/sdk"</span>;</span></span>
</span>
const</span> euromail</span> = new</span> EuroMail</span>({</span></span>
  apiKey:</span> "em_live_your_key_here"</span>,</span></span>
});</span></span>
</span>
const</span> result</span> = await</span> euromail.</span>sendEmail</span>({</span></span>
  from:</span> "hello@yourdomain.com"</span>,</span></span>
  to:</span> "your-account@email.com"</span>,</span></span>
  subject:</span> "My first euromail"</span>,</span></span>
  html_body:</span> "<h1>It works!</h1><p>Sent from Finland.</p>"</span>,</span></span>
});</span></span>
</span>
console.</span>log</span>(</span>`Email queued: ${</span>result</span>.</span>id</span>}`</span>);</span></span>
console.</span>log</span>(</span>`Sandbox: ${</span>result</span>.</span>sandbox</span>}`</span>);</span></span></code></pre>Using Rust</h3>
Add the dependency:</p>
cargo</span> add euromail</span></span></code></pre>
Send an email:</p>
use</span> euromail</span>::</span>{</span>EuroMail</span>,</span> SendEmailParams</span>};</span></span>
</span>
#[tokio</span>::</span>main]</span></span>
async fn</span> main</span>()</span> -></span> Result</span><(),</span> Box</span><</span>dyn</span> std</span>::</span>error</span>::</span>Error</span>>> {</span></span>
    let</span> client</span> =</span> EuroMail</span>::</span>new</span>(</span>"em_live_your_key_here"</span>);</span></span>
</span>
    let</span> response</span> =</span> client</span>.</span>send_email</span>(</span>&</span>SendEmailParams</span> {</span></span>
        from</span>:</span> "hello@yourdomain.com"</span>.</span>into</span>(),</span></span>
        to</span>:</span> "your-account@email.com"</span>.</span>into</span>(),</span></span>
        subject</span>:</span> Some</span>(</span>"My first euromail"</span>.</span>into</span>()),</span></span>
        html_body</span>:</span> Some</span>(</span>"<h1>It works!</h1><p>Sent from Finland.</p>"</span>.</span>into</span>()),</span></span>
        ..</span>Default</span>::</span>default</span>()</span></span>
    })</span>.await?</span>;</span></span>
</span>
    println!</span>(</span>"Email queued: {}"</span>, response</span>.</span>id);</span></span>
    Ok</span>(())</span></span>
}</span></span></code></pre>Step 5: Verify your domain</h2>
Sandbox mode is useful for testing, but to send to real recipients you need to configure DNS. Add the three records from Step 3 to your DNS provider:</p>
Record</th> Type</th> Host</th> Value</th></tr></thead>

DKIM</td> TXT</td> euromail._domainkey.em.yourdomain.com</code></td> v=DKIM1; k=rsa; p=...</code> (from dashboard)</td></tr>
SPF</td> TXT</td> em.yourdomain.com</code></td> v=spf1 include:spf.euromail.dev ~all</code></td></tr>
Return path</td> MX</td> em.yourdomain.com</code></td> bounce.euromail.dev</code> (priority 10)</td></tr>
</tbody></table>
After adding the records, verify them:</p>
curl</span> -X</span> POST https://api.euromail.dev/v1/domains/YOUR_DOMAIN_ID/verify</span> \</span></span>
  -H</span> "X-EuroMail-Api-Key: em_live_your_key_here"</span></span></code></pre>
DNS propagation typically takes 5 to 30 minutes. If verification fails, wait a few minutes and try again. The dashboard shows real-time status for each record.</p>
Once verified, the sandbox</code> flag disappears and you can send to any recipient.</p>
What happens when you send</h2>
When your email hits POST /v1/emails</code>, here's the pipeline it goes through:</p>

Validation</strong> ... the API checks the sender domain, recipient addresses, body size, and your plan quota</li>
Queue</strong> ... the email is added to a Redis stream and returns 202 Accepted</code> immediately</li>
DKIM signing</strong> ... the worker signs the message with your domain's RSA-2048 key</li>
SMTP delivery</strong> ... direct connection to the recipient's MX server, with STARTTLS and optional DANE verification</li>
Bounce handling</strong> ... if the recipient's server rejects the email, the bounce is parsed and classified (hard/soft)</li>
Webhook notification</strong> ... if you've configured webhooks, you'll get a callback for each delivery event</li>
</ol>
The entire pipeline runs in Finland. No data leaves the EU.</p>
Next steps</h2>
Add a webhook</h3>
Get notified when emails are delivered, bounced, or marked as spam:</p>
curl</span> -X</span> POST https://api.euromail.dev/v1/webhooks</span> \</span></span>
  -H</span> "X-EuroMail-Api-Key: em_live_your_key_here"</span> \</span></span>
  -H</span> "Content-Type: application/json"</span> \</span></span>
  -d</span> '{</span></span>
    "url": "https://yourdomain.com/webhooks/euromail",</span></span>
    "events": ["delivered", "bounced", "complained"]</span></span>
  }'</span></span></code></pre>
The response includes a secret</code> for HMAC-SHA256 signature verification. Store it securely.</p>
Use templates</h3>
Instead of sending raw HTML every time, create a reusable template:</p>
curl</span> -X</span> POST https://api.euromail.dev/v1/templates</span> \</span></span>
  -H</span> "X-EuroMail-Api-Key: em_live_your_key_here"</span> \</span></span>
  -H</span> "Content-Type: application/json"</span> \</span></span>
  -d</span> '{</span></span>
    "alias": "welcome",</span></span>
    "name": "Welcome Email",</span></span>
    "subject": "Welcome, {{ name }}!",</span></span>
    "html_body": "<h1>Hello {{ name }}</h1><p>Your account is ready.</p>"</span></span>
  }'</span></span></code></pre>
Then send with the template and variables:</p>
curl</span> -X</span> POST https://api.euromail.dev/v1/emails</span> \</span></span>
  -H</span> "X-EuroMail-Api-Key: em_live_your_key_here"</span> \</span></span>
  -H</span> "Content-Type: application/json"</span> \</span></span>
  -d</span> '{</span></span>
    "from": "hello@yourdomain.com",</span></span>
    "to": "user@example.com",</span></span>
    "template_alias": "welcome",</span></span>
    "template_data": {"name": "Alice"}</span></span>
  }'</span></span></code></pre>
Templates use MiniJinja</a> syntax: {{ variable }}</code> for interpolation, {% if condition %}</code> for conditionals, {% for item in list %}</code> for loops.</p>
Check delivery status</h3>
Poll the status of a sent email:</p>
curl</span> https://api.euromail.dev/v1/emails/YOUR_EMAIL_ID</span> \</span></span>
  -H</span> "X-EuroMail-Api-Key: em_live_your_key_here"</span></span></code></pre>
The status</code> field progresses through: queued</code> -> processing</code> -> sent</code> -> delivered</code> (or bounced</code> / failed</code>).</p>
Explore the API</h3>
The full API reference with an interactive Swagger UI is at api.euromail.dev/docs</a>. Every endpoint is documented with request/response examples.</p>
Common issues</h2>
"Domain not verified" error when sending to other people</strong></p>
Your DNS records aren't fully propagated yet. Both DKIM and return path must be verified. Check status in the dashboard or call POST /v1/domains/{id}/verify</code>.</p>
"Authentication required" (401)</strong></p>
Make sure you're passing the API key in the X-EuroMail-Api-Key</code> header (not Authorization</code> without the right prefix). The key must start with em_live_</code>.</p>
"Monthly quota exceeded" (429)</strong></p>
The free plan allows 1,000 emails per month. Upgrade to Starter ($25/mo) for 25,000 emails at dashboard.euromail.dev</a>.</p>
Email lands in spam</strong></p>
This usually means DNS isn't fully configured. Verify that SPF, DKIM, and return path all show "Verified" in the dashboard. Also check your sending domain's reputation with Google Postmaster Tools</a>.</p>


Why We Chose Rust for Transactional Email
Unknown — Fri, 03 Apr 2026 00:00:00 +0000
Most transactional email platforms are built on Node.js, Python, or Go. We built euromail on Rust. Not because it's trendy, but because the specific problems in email infrastructure map almost perfectly to Rust's strengths: long-lived concurrent connections, cryptographic signing on every message, and zero tolerance for resource leaks under sustained load.</p>
This post walks through the real engineering reasons behind the choice, with concrete examples from our codebase.</p>
The Problem with Email at Scale</h2>
Transactional email sounds simple: accept an API call, build a MIME message, connect to an MX server, deliver it. But at scale, the system is doing dozens of things simultaneously:</p>

Maintaining SMTP connections to hundreds of recipient domains</li>
DKIM-signing every message with per-customer RSA keys</li>
Enforcing per-domain rate limits and IP warmup schedules</li>
Processing bounces, complaints, and DMARC reports in real time</li>
Running circuit breakers for domains that are temporarily rejecting mail</li>
</ul>
Each of these operations involves shared mutable state, concurrent access, and resources that must be cleaned up correctly. A leaked connection or a missed semaphore release under load doesn't just slow things down. It cascades.</p>
Ownership Makes Resource Leaks Impossible</h2>
The single biggest win from Rust is deterministic resource cleanup. In our SMTP connection pool, each domain gets a semaphore controlling how many concurrent connections we open:</p>
pub struct</span> ConnectionGuard</span> {</span></span>
    domain</span>:</span> String</span>,</span></span>
    semaphores</span>:</span> Arc</span><</span>DashMap</span><</span>String</span>,</span> Arc</span><</span>Semaphore</span>>>>,</span></span>
}</span></span>
</span>
impl</span> Drop</span> for</span> ConnectionGuard</span> {</span></span>
    fn</span> drop</span>(</span>&mut</span> self</span>) {</span></span>
        if let</span> Some</span>(sem)</span> =</span> self</span>.</span>semaphores</span>.</span>get</span>(</span>&</span>self</span>.</span>domain) {</span></span>
            sem</span>.</span>add_permits</span>(</span>1</span>);</span></span>
        }</span></span>
    }</span></span>
}</span></span></code></pre>
When a ConnectionGuard</code> goes out of scope, whether the delivery succeeds, fails, panics, or the task gets cancelled, the semaphore permit is released. There is no try-finally</code> to forget. No defer</code> to put in the wrong place. The compiler enforces it.</p>
In Node.js, a forgotten finally</code> block under a rare error path means a domain's connection slot leaks permanently. We've seen this pattern cause cascading delivery failures in other systems. In Rust, it cannot happen.</p>
Async Without the Garbage Collector Tax</h2>
Our worker process runs 18+ concurrent tasks on the Tokio async runtime: email consumers, bounce processors, webhook dispatchers, retry schedulers, reputation analyzers, and more. Each task is a lightweight future, not a thread.</p>
let</span> email_consumer</span> =</span> {</span></span>
    let</span> w</span> =</span> Arc</span>::</span>clone</span>(</span>&</span>worker);</span></span>
    tokio</span>::</span>spawn</span>(</span>async move</span> { w</span>.</span>run_email_consumer</span>()</span>.await</span> })</span></span>
};</span></span></code></pre>
The critical difference from Go or Node.js: there is no garbage collector. Rust allocates and frees memory deterministically. Under sustained load of thousands of emails per second, our memory usage stays flat. There are no GC pauses causing delivery latency spikes.</p>
Benchmarks back this up. In comparable server workloads, Rust uses roughly 15-16 MB of memory where Node.js uses 64 MB. More importantly, Rust's latency profile has no tail spikes from garbage collection, a real problem when you're holding open SMTP connections that have timeout windows.</p>
Type-Safe State Machines Prevent Logic Bugs</h2>
Email delivery has complex state: queued, processing, sent, delivered, bounced, failed. SMTP domains cycle through circuit breaker states: closed, open, half-open. Bounce types are hard, soft, or undetermined. Getting any of these wrong means lost mail or duplicate deliveries.</p>
Rust's enum system makes invalid states unrepresentable:</p>
pub enum</span> CircuitState</span> {</span></span>
    Closed</span>,</span></span>
    Open</span>,</span></span>
    HalfOpen</span>,</span></span>
}</span></span></code></pre>
Pattern matching on these enums is exhaustive. If we add a new state, the compiler flags every function that doesn't handle it. In Python or JavaScript, a new status string silently falls through to a default case, and you find out in production.</p>
Our email status, bounce type, plan tier, and operation status types are all enums. The compiler catches category errors that unit tests would miss.</p>
Cryptographic Safety by Default</h2>
Every outgoing email gets DKIM-signed with the customer's RSA key, and optionally ARC-sealed. That's RSA-2048 cryptographic operations on every single message. The signing pipeline:</p>
pub fn</span> sign_message</span>(</span></span>
    message</span>: &</span>[</span>u8</span>],</span></span>
    domain</span>: &</span>str</span>,</span></span>
    selector</span>: &</span>str</span>,</span></span>
    private_key_pem</span>: &</span>str</span>,</span></span>
)</span> -></span> Result</span><</span>Vec</span><</span>u8</span>>,</span> SmtpError</span>></span></span></code></pre>
The key never leaves its scope. There's no way to accidentally log it, serialize it, or pass it to the wrong function, because the borrow checker prevents moving the reference outside its intended lifetime.</p>
We use rustls</code> for TLS instead of OpenSSL. That means our TLS implementation is 100% Rust with no C FFI boundary. No buffer overflows. No memory corruption from a mismanaged SSL context. The entire TLS handshake for SMTP STARTTLS is memory-safe by construction.</p>
Lock-Free Concurrency for Rate Limiting</h2>
Email providers enforce per-domain rate limits, per-IP warmup schedules, and per-account quotas. These all require concurrent counters that thousands of tasks read and write simultaneously.</p>
We use DashMap</code> (a lock-free concurrent hashmap) and atomic operations instead of traditional mutexes:</p>
pub struct</span> DomainThrottle</span> {</span></span>
    limiters</span>:</span> Arc</span><</span>DashMap</span><</span>String</span>,</span> Arc</span><</span>Limiter</span>>>>,</span></span>
    rate_per_second</span>:</span> NonZeroU32</span>,</span></span>
}</span></span></code></pre>
For IP warmup, hourly send counters use AtomicU64</code> with compare-and-swap:</p>
match</span> counter</span>.</span>value</span>()</span>.</span>compare_exchange</span>(</span></span>
    current,</span></span>
    current</span> +</span> 1</span>,</span></span>
    Ordering</span>::</span>AcqRel</span>,</span></span>
    Ordering</span>::</span>Relaxed</span>,</span></span>
) {</span> ...</span> }</span></span></code></pre>
No locks. No contention. No poisoned mutex if a thread panics. These patterns are common in Rust's ecosystem and almost impossible to get right in languages without an ownership model.</p>
SSRF Protection at the DNS Layer</h2>
Webhook delivery is a common feature in email platforms: notify the customer's server when an email bounces or gets complained about. But webhooks are also a vector for SSRF attacks, where an attacker configures a webhook URL that resolves to an internal IP.</p>
Most implementations validate the IP, then connect. That leaves a TOCTOU (time-of-check to time-of-use) gap where DNS can rebind between validation and connection.</p>
We solve this by implementing Rust's Resolve</code> trait for reqwest</code>, making validation and resolution atomic:</p>
impl</span> Resolve</span> for</span> SsrfSafeResolver</span> {</span></span>
    fn</span> resolve</span>(</span>&</span>self</span>, name</span>:</span> Name</span>)</span> -></span> Resolving</span> {</span></span>
        Box</span>::</span>pin</span>(</span>async move</span> {</span></span>
            let</span> addrs</span> =</span> tokio</span>::</span>net</span>::</span>lookup_host</span>(</span>&</span>addr_str)</span>.await?</span>;</span></span>
            // Block private/reserved IPs before returning</span></span>
            let</span> blocked</span>:</span> Vec</span><_></span> =</span> addrs</span></span>
                .</span>iter</span>()</span></span>
                .</span>filter</span>(</span>|</span>a</span>|</span> is_private_or_reserved</span>(a</span>.</span>ip</span>()))</span></span>
                .</span>collect</span>();</span></span>
            if !</span>blocked</span>.</span>is_empty</span>() {</span></span>
                return</span> Err</span>(</span>/* SSRF blocked */</span>);</span></span>
            }</span></span>
            Ok</span>(addrs)</span></span>
        })</span></span>
    }</span></span>
}</span></span></code></pre>
DNS rebinding attacks cannot work because resolution and validation happen in the same step. The HTTP client never sees the private IP.</p>
Structured Error Handling Across the Stack</h2>
Our error types form a layered hierarchy using thiserror</code>:</p>
#[derive(</span>Debug</span>, thiserror</span>::</span>Error</span>)]</span></span>
pub enum</span> SmtpError</span> {</span></span>
    #[error(</span>"DNS resolution failed for {domain}: {source}"</span>)]</span></span>
    DnsError</span> { domain</span>:</span> String</span>, source</span>:</span> Box</span><</span>dyn</span> Error</span> +</span> Send</span> +</span> Sync</span>> },</span></span>
</span>
    #[error(</span>"Circuit open for domain {domain}"</span>)]</span></span>
    CircuitOpen</span> { domain</span>:</span> String</span> },</span></span>
</span>
    #[error(</span>"Warm-up limit reached for IP {ip} (limit: {limit})"</span>)]</span></span>
    WarmupLimitReached</span> { ip</span>:</span> String</span>, limit</span>:</span> u64</span> },</span></span>
}</span></span></code></pre>
Each error variant carries structured context. When a delivery fails, we know exactly why: DNS failure, circuit breaker tripped, warmup limit hit, permanent SMTP rejection. Metrics can tag by error type. Retry logic can branch on the variant. Alert thresholds differ per category.</p>
In Node.js or Python, this is typically a string message or a generic error code. In Rust, the type system guarantees you handle every case.</p>
The Workspace: Six Crates, One Build</h2>
Our codebase is a Cargo workspace with six crates:</p>
Crate</th> Responsibility</th></tr></thead>

euromail-api</code></td> HTTP API server (Axum)</td></tr>
euromail-worker</code></td> Background job consumer, retry logic</td></tr>
euromail-smtp</code></td> SMTP delivery, DKIM, ARC, circuit breakers</td></tr>
euromail-common</code></td> Shared types, auth, database, queue</td></tr>
euromail-dashboard</code></td> Admin dashboard (server-rendered HTML)</td></tr>
euromail-tests</code></td> Integration test suite</td></tr>
</tbody></table>
All crates share workspace-level dependency versions, preventing version drift. A single cargo build --release</code> compiles all three production binaries (API, worker, dashboard) with shared dependency compilation. Changes to the common crate propagate type-checking across the entire system instantly.</p>
The release profile uses thin LTO and symbol stripping:</p>
[</span>profile</span>.</span>release</span>]</span></span>
lto =</span> "thin"</span></span>
strip =</span> true</span></span></code></pre>
The API binary compiles to roughly 30 MB stripped. The worker with the full SMTP engine is about 40 MB. These run on debian:bookworm-slim</code> Docker images, keeping the total image size small enough for fast container scheduling on Kubernetes.</p>
Graceful Shutdown Without Lost Messages</h2>
Email systems cannot afford to lose messages during deploys. Our shutdown sequence uses tokio_util::CancellationToken</code> to coordinate all 18+ worker tasks:</p>
let</span> messages</span> =</span> tokio</span>::</span>select!</span> {</span></span>
    result</span> =</span> queue</span>::</span>read_messages</span>(</span>&</span>self</span>.</span>redis, stream, group,</span> &</span>self</span>.</span>consumer_name,</span> 10</span>) </span></span>
        =></span> result,</span></span>
    _</span> =</span> self</span>.</span>shutdown</span>.</span>cancelled</span>()</span> => break</span>,</span></span>
};</span></span></code></pre>
When SIGTERM arrives, the token cancels. Every consumer loop breaks at its next select!</code> point. In-flight message processing runs to completion. Then telemetry flushes and the process exits cleanly.</p>
Compare this to Node.js, where process.on('SIGTERM')</code> gives you a callback but no structured way to drain async work. Or Python, where signal handling in async contexts is notoriously fragile. Rust's select!</code> macro makes the shutdown path as explicit and testable as the happy path.</p>
What We'd Choose Differently</h2>
Rust isn't without trade-offs.</p>
Compile times are real.</strong> A clean release build takes about 5 minutes with sccache. Incremental builds are fast (under 30 seconds), but CI cold builds require caching strategies to stay reasonable.</p>
The learning curve is steep.</strong> Lifetimes, trait bounds, and async pinning take time to internalize. We wouldn't recommend Rust for a prototype or a CRUD API. We'd reach for it again for anything that holds open thousands of concurrent connections and signs cryptographic material on every request.</p>
The ecosystem is younger.</strong> Some email-specific crates are less mature than their Go or Python equivalents. We've contributed patches upstream and occasionally vendor-forked.</p>
The Bottom Line</h2>
We chose Rust because email infrastructure is fundamentally about managing concurrent I/O, shared state, and resource lifetimes correctly under sustained load. These are exactly the problems Rust's ownership model, async runtime, and type system were designed to solve.</p>
After two years of development, the choice has paid off in ways we expected (no memory leaks, no GC pauses) and ways we didn't (the type system catches logic bugs that would be integration test failures in other languages). Our worker process handles thousands of concurrent SMTP connections with flat memory usage and predictable latency, deployed as a 40 MB container image.</p>
If you're building infrastructure that's long-lived, concurrent, and security-critical, Rust is worth the investment.</p>


Google Postmaster Tools: Monitor Your Email Reputation
Unknown — Mon, 23 Mar 2026 00:00:00 +0000
You spend time crafting your transactional emails, setting up SPF, DKIM, and DMARC, warming up your IP — then an important password reset lands in someone's spam folder. What happened?</p>
Without visibility into how Gmail evaluates your sending domain, you're flying blind. Google Postmaster Tools is the only way to see your reputation from Gmail's perspective — not what your ESP reports, but what Google actually sees.</p>
What Google Postmaster Tools Is</h2>
Google Postmaster Tools</a> is a free dashboard provided by Google that shows metrics about email you send to Gmail addresses. It covers spam rates, domain and IP reputation, authentication results, encryption, and delivery errors.</p>
Gmail accounts for over 30% of email users worldwide. If you send transactional email — password resets, invoices, shipping notifications — a significant portion of your recipients are on Gmail. Postmaster Tools is your window into whether those emails reach the inbox or disappear into spam.</p>
The tool updated to a V2 interface in late 2025, shifting focus from vague reputation grades to binary compliance checks and spam rate tracking. This aligns with Google's stricter sender requirements that took effect in 2024.</p>
Setting Up Postmaster Tools</h2>
Setup takes about 10 minutes, though data needs 24–48 hours to populate.</p>
Step 1: Verify Your Domain</h3>

Go to gmail.com/postmaster</a> and sign in with a Google account</li>
Click the +</strong> button in the bottom right corner</li>
Enter the domain you send email from (e.g., notifications.yourdomain.com</code>)</li>
Google generates a TXT record — copy it</li>
</ol>
Step 2: Add the DNS Record</h3>
Add the TXT record to your domain's DNS. The exact steps depend on your DNS provider, but the record looks like this:</p>
@  TXT  "google-site-verification=abc123..."</span></span></code></pre>
If you're using EuroMail, you already have DNS records for SPF, DKIM, and DMARC. This verification record sits alongside those — it doesn't interfere with authentication.</p>
Step 3: Verify and Wait</h3>
Click Verify</strong> in Postmaster Tools. DNS propagation typically takes a few minutes, but can take up to 48 hours.</p>
Once verified, data starts appearing after Google processes enough messages from your domain. You need a minimum volume of roughly 100–200 daily emails to Gmail for dashboards to populate — Google suppresses metrics below this threshold to protect recipient privacy.</p>
Adding Team Members</h3>
You can grant access to other people on your team. In Postmaster Tools, select your verified domain, click the settings icon, and add their Google account email. They'll get read access to all dashboards.</p>
The Dashboards</h2>
Postmaster Tools provides seven dashboards. Here's what each one tells you and what to watch for.</p>
Compliance Status</h3>
This is the first dashboard you should check. It shows whether you meet Google's sender requirements:</p>
Requirement</th> What it checks</th></tr></thead>

SPF</strong></td> Valid SPF record exists and emails pass SPF checks</td></tr>
DKIM</strong></td> Emails are signed with a valid DKIM signature</td></tr>
From header alignment</strong></td> Your From domain matches your SPF/DKIM domain</td></tr>
DMARC</strong></td> A DMARC policy is published (at minimum p=none</code>)</td></tr>
TLS encryption</strong></td> Emails are sent over an encrypted connection</td></tr>
Spam rate</strong></td> Below 0.3% for bulk senders (5,000+ daily emails)</td></tr>
</tbody></table>
Bulk senders also need to support one-click unsubscribe via a List-Unsubscribe</code> header.</p>
For transactional email, most of these should pass automatically if your provider handles authentication correctly. If you see failures here, fix them before looking at any other dashboard.</p>
Spam Rate</h3>
This is the single most important metric. It shows the percentage of your emails that Gmail users mark as spam, relative to the total delivered to the inbox.</p>
Thresholds:</strong></p>

Below 0.10%</strong> — Good. You're in a healthy range.</li>
0.10% – 0.30%</strong> — Warning. Investigate which emails are generating complaints.</li>
Above 0.30%</strong> — Critical. Gmail may start throttling or rejecting your messages.</li>
</ul>
The dashboard also accounts for messages users rescue from spam (mark as "not spam"), which can offset your reported rate.</p>
For transactional email, a high spam rate usually means one of two things: your emails look like marketing to the recipient, or your From address is shared with promotional campaigns. Keep transactional and marketing email on separate domains or subdomains.</p>
Domain Reputation</h3>
Gmail assigns your sending domain a reputation rating based on how recipients interact with your mail:</p>

High</strong> — Emails are consistently delivered to the inbox</li>
Medium</strong> — Mostly delivered, but some may be filtered</li>
Low</strong> — Significant portion goes to spam</li>
Bad</strong> — Most emails are rejected or sent to spam</li>
</ul>
Domain reputation is built over time. Sudden volume spikes, high spam rates, or authentication failures can drop it quickly. Recovery is gradual — consistent, authenticated, low-complaint sending is the only way back.</p>
IP Reputation</h3>
Similar to domain reputation, but evaluated per IP address. This matters if you're on dedicated IPs or if your provider uses shared IP pools.</p>
The dashboard shows a stacked bar chart of traffic distribution across reputation levels. You want to see mostly green (High) and some yellow (Medium). Red (Low/Bad) bars indicate problems with specific IPs.</p>
If you're on shared infrastructure, IP reputation is partly outside your control — your provider's sending practices across all customers affect it. This is why choosing a provider with strict anti-abuse policies matters.</p>
Authentication</h3>
This dashboard shows pass rates for SPF, DKIM, and DMARC across all messages sent to Gmail:</p>

SPF pass rate</strong> — Percentage of messages where the sending IP matches your SPF record</li>
DKIM pass rate</strong> — Percentage of messages with a valid DKIM signature</li>
DMARC pass rate</strong> — Percentage of messages that pass DMARC alignment (SPF or DKIM aligned with the From domain)</li>
</ul>
All three should be at or near 100%. If they're not:</p>

Low SPF</strong> — Check that all sending IPs are included in your SPF record. Watch for include</code> chains that exceed the 10-lookup limit.</li>
Low DKIM</strong> — Verify your DKIM key is published correctly and your provider is signing every message.</li>
Low DMARC</strong> — Usually caused by SPF/DKIM misalignment. Ensure the domain in your From header matches the domain authenticated by SPF or DKIM.</li>
</ul>
Encryption</h3>
Shows the percentage of your emails sent using TLS encryption. In 2026, this should be 100% — any modern email provider sends over TLS by default.</p>
If you see anything below 100%, something is misconfigured in your sending infrastructure.</p>
Delivery Errors</h3>
Lists specific error codes and rejection reasons when Gmail refuses your messages. Common errors include:</p>

Rate limit exceeded</strong> — You're sending too fast. Implement gradual sending and backoff.</li>
Suspected spam</strong> — Content or reputation triggers. Check your spam rate and domain reputation.</li>
Bad reputation</strong> — IP or domain reputation too low. Focus on authentication and reducing complaints.</li>
DMARC policy</strong> — Your own DMARC policy caused the rejection (e.g., p=reject</code> with failing authentication).</li>
</ul>
This dashboard is your diagnostic tool when you notice delivery drops — it tells you exactly why Gmail rejected specific messages.</p>
A Practical Monitoring Routine</h2>
You don't need to check Postmaster Tools every hour. Here's a reasonable cadence:</p>
Weekly:</strong></p>

Check spam rate trend — is it stable, rising, or falling?</li>
Verify authentication pass rates are still at 100%</li>
Glance at domain reputation for any changes</li>
</ul>
After changes:</strong></p>

New sending domain or subdomain? Monitor compliance status daily for the first week</li>
Changed DNS records? Verify authentication pass rates within 48 hours</li>
Increased sending volume? Watch IP reputation and delivery errors</li>
</ul>
When something breaks:</strong></p>

Delivery rate drops → Check delivery errors dashboard first</li>
Complaints increase → Check spam rate, then review recent email content</li>
Authentication failures → Check authentication dashboard, then verify DNS records</li>
</ul>
Postmaster Tools and EuroMail</h2>
If you're using EuroMail, your email authentication is handled automatically — SPF, DKIM, and DMARC are configured during domain setup. Your compliance status dashboard should show all green checks from day one.</p>
Postmaster Tools complements this by giving you ongoing visibility. EuroMail handles the sending infrastructure; Postmaster Tools shows you how Gmail evaluates the result. Together, they give you full control over your transactional email deliverability.</p>
Setting up Postmaster Tools for your EuroMail sending domain takes the same 10 minutes described above. Add the verification TXT record alongside your existing SPF and DKIM records, and you'll have direct insight into how your email performs at Gmail's front door.</p>


Why Your SaaS Needs an EU-Based Email Provider
Unknown — Tue, 03 Mar 2026 00:00:00 +0000
Every time your SaaS sends a password reset, order confirmation, or invoice, that email carries personal data: names, email addresses, sometimes purchase details or account information. If you're using a US-based email provider, that data crosses the Atlantic — and with it, your GDPR compliance gets complicated.</p>
For European developers building for European users, there's a simpler path: send email from infrastructure that never leaves the EU.</p>
The Problem with Transatlantic Email Data</h2>
The GDPR doesn't ban sending data outside the EU, but it requires adequate safeguards</strong> when you do. After the Schrems II ruling invalidated the EU-US Privacy Shield, companies relying on US-based email providers have been in a legal gray area.</p>
The current EU-US Data Privacy Framework attempts to fill that gap, but its future is uncertain. Legal challenges are already underway, and European Data Protection Authorities continue to scrutinize transatlantic data flows.</p>
Here's what this means in practice for email:</p>

Standard Contractual Clauses (SCCs)</strong> are required for transfers to the US, adding legal overhead and ongoing compliance work</li>
Transfer Impact Assessments (TIAs)</strong> must evaluate whether the recipient country provides adequate protection</li>
Your Data Processing Agreement (DPA)</strong> must explicitly address international transfers and sub-processors</li>
Data subject requests</strong> (access, deletion, portability) become harder when data lives in another jurisdiction</li>
</ul>
For most SaaS teams, email infrastructure is a background concern — until an audit or a customer due diligence questionnaire surfaces these gaps.</p>
What EU Data Residency Actually Means</h2>
EU data residency for email means that every component of the email pipeline processes and stores data within the European Union:</p>
Component</th> What it handles</th> Why residency matters</th></tr></thead>

API server</strong></td> Receives your send request with recipient data</td> First point of data ingestion</td></tr>
Queue / worker</strong></td> Processes email jobs, renders templates</td> Personal data in transit</td></tr>
SMTP engine</strong></td> Delivers to recipient MX servers</td> Outbound connection metadata</td></tr>
Bounce processor</strong></td> Handles delivery failures and complaints</td> Contains recipient addresses</td></tr>
Logs & analytics</strong></td> Tracks delivery events</td> Retention-relevant personal data</td></tr>
Database</strong></td> Stores email records, templates, settings</td> Long-term personal data storage</td></tr>
</tbody></table>
If any of these components runs outside the EU — even a logging sidecar or an analytics pipeline — the entire chain breaks. True data residency requires control over every layer.</p>
Email Authentication: Not Just Compliance, Deliverability</h2>
GDPR compliance is table stakes. What actually determines whether your email reaches the inbox is email authentication</strong> — and getting it right is non-negotiable in 2026.</p>
SPF (Sender Policy Framework)</h3>
SPF tells receiving mail servers which IP addresses are authorized to send email for your domain. Without it, your emails are more likely to land in spam.</p>
v=spf1 include:spf.euromail.dev -all</span></span></code></pre>
The -all</code> directive means "reject anything not in this list" — a strict policy that builds sender reputation.</p>
DKIM (DomainKeys Identified Mail)</h3>
DKIM adds a cryptographic signature to every outgoing email. The receiving server verifies this signature against a public key published in your DNS. This proves the email wasn't tampered with in transit.</p>
euromail._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjAN..."</span></span></code></pre>
Your email provider should sign every email automatically — no manual key management on your side.</p>
DMARC (Domain-based Message Authentication)</h3>
DMARC ties SPF and DKIM together and tells receivers what to do when authentication fails. It also enables aggregate reporting so you can monitor your email authentication health.</p>
_dmarc.yourdomain.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com"</span></span></code></pre>
A p=reject</code> policy is the gold standard: it tells receiving servers to drop any email that fails authentication.</p>
Why This Matters for Deliverability</h3>
Google and Yahoo now require</strong> SPF, DKIM, and DMARC for bulk senders. Even for transactional email, proper authentication directly impacts inbox placement. An EU-based provider with a clean IP reputation and proper authentication gives you the best foundation.</p>
Sending Email with the EuroMail API</h2>
Here's what sending a transactional email looks like with an EU-based provider that handles authentication automatically:</p>
curl</span> -X</span> POST https://api.euromail.dev/v1/emails</span> \</span></span>
  -H</span> "X-EuroMail-Api-Key: em_live_..."</span> \</span></span>
  -H</span> "Content-Type: application/json"</span> \</span></span>
  -d</span> '{</span></span>
    "from": "notifications@yourdomain.com",</span></span>
    "to": "customer@example.com",</span></span>
    "subject": "Your invoice #1042",</span></span>
    "html_body": "<h1>Invoice Ready</h1><p>Your invoice for March 2026 is attached.</p>",</span></span>
    "tags": ["invoice", "billing"]</span></span>
  }'</span></span></code></pre>
What happens behind the scenes:</p>

The API server in Finland receives your request</li>
DKIM signature is applied using your domain's private key</li>
The SMTP engine delivers directly to the recipient's mail server — no third-party relay</li>
Delivery status, bounces, and complaints are tracked and available via webhooks</li>
All data stays within Finland throughout the entire process</li>
</ol>
For TypeScript projects:</p>
import</span> { EuroMail }</span> from</span> "@euromail/sdk"</span>;</span></span>
</span>
const</span> euromail</span> = new</span> EuroMail</span>({ apiKey:</span> "em_live_..."</span> });</span></span>
</span>
await</span> euromail.</span>sendEmail</span>({</span></span>
  from:</span> "notifications@yourdomain.com"</span>,</span></span>
  to:</span> "customer@example.com"</span>,</span></span>
  subject:</span> "Your invoice #1042"</span>,</span></span>
  html_body:</span> "<h1>Invoice Ready</h1><p>Your invoice is attached.</p>"</span>,</span></span>
  tags: [</span>"invoice"</span>,</span> "billing"</span>],</span></span>
});</span></span></code></pre>Choosing an Email Provider: What to Evaluate</h2>
When selecting a transactional email provider for a GDPR-conscious SaaS, consider these criteria:</p>
Data residency</strong></p>

Where are API servers, databases, and SMTP infrastructure located?</li>
Are sub-processors also within the EU?</li>
Is a Data Processing Agreement (DPA) included?</li>
</ul>
Email authentication</strong></p>

Does the provider handle DKIM signing automatically?</li>
Are SPF records provided and documented?</li>
Is DMARC guidance part of the onboarding flow?</li>
</ul>
Delivery infrastructure</strong></p>

Does the provider use its own SMTP engine or relay through a third party?</li>
What IP warm-up options are available?</li>
How are bounces and complaints handled?</li>
</ul>
GDPR tooling</strong></p>

Can you export all data for a specific email address (data subject access requests)?</li>
Is there a right-to-erasure endpoint?</li>
Are audit logs available for compliance reviews?</li>
Can you configure data retention periods?</li>
</ul>
Transparency</strong></p>

Where does the provider publish its infrastructure details?</li>
Is the DPA publicly available before sign-up?</li>
What sub-processors are listed?</li>
</ul>
Beyond Compliance: Building Trust</h2>
GDPR compliance isn't just about avoiding fines — though those can reach 4% of annual global revenue. It's about building trust with your users. When you can tell your customers that their data never leaves the EU, that every email is cryptographically signed, and that you can fulfill any data subject request within hours, you're not just compliant — you're competitive.</p>
European B2B customers increasingly require their vendors to demonstrate data residency. Having your email infrastructure in the EU simplifies vendor assessments, shortens sales cycles, and eliminates compliance blockers.</p>
EuroMail Blog

Send Your First Email in 5 Minutes

Next steps</h2>

Why We Chose Rust for Transactional Email

Google Postmaster Tools: Monitor Your Email Reputation

The Dashboards</h2> Postmaster Tools provides seven dashboards. Here's what each one tells you and what to watch for.</p>

Encryption</h3> Shows the percentage of your emails sent using TLS encryption. In 2026, this should be 100% — any modern email provider sends over TLS by default.</p> If you see anything below 100%, something is misconfigured in your sending infrastructure.</p>

Why Your SaaS Needs an EU-Based Email Provider

Email Authentication: Not Just Compliance, Deliverability</h2> GDPR compliance is table stakes. What actually determines whether your email reaches the inbox is email authentication</strong> — and getting it right is non-negotiable in 2026.</p>

The Dashboards</h2>
Postmaster Tools provides seven dashboards. Here's what each one tells you and what to watch for.</p>

Encryption</h3>
Shows the percentage of your emails sent using TLS encryption. In 2026, this should be 100% — any modern email provider sends over TLS by default.</p>
If you see anything below 100%, something is misconfigured in your sending infrastructure.</p>

Email Authentication: Not Just Compliance, Deliverability</h2>
GDPR compliance is table stakes. What actually determines whether your email reaches the inbox is email authentication</strong> — and getting it right is non-negotiable in 2026.</p>
