How Sendamatic sends email from your domain

If you're using an email service provider like Sendamatic to send emails from your own domain, you've probably been asked to add some DNS records - things like CNAME, TXT, and MX. These records are the key to letting services send authenticated email on your behalf, without needing access or changes to your existing email infrastructure.

This setup is often called delegated email authentication, though you might also hear terms like white-label email, DKIM delegation, or subdomain routing. Whatever the name, the goal is the same: make sure your emails look like they’re coming from you, and pass all the necessary checks to prove it.

Why email authentication matters

When you send an email from [email protected], the receiving server wants to know: "Is this message really from example.com?" To answer that, your email needs to pass authentication checks:

• SPF: Confirms the sending server is allowed to send mail for your domain.
• DKIM: Adds a cryptographic signature to prove the message hasn’t been tampered with.
• DMARC: Tells receiving servers what to do if SPF or DKIM fail - and checks whether those results align with your visible "From" address.

Fail these, and your message might end up in spam, or get rejected entirely.

In 2024, Gmail and Yahoo (and more recently Microsoft) introduced new requirements for bulk email senders to improve inbox safety and reduce spam. If you're sending any sort of volume to their users, it's essential to get your authentication correct.

The two "From" addresses in every email

Every email has two different "from" addresses.

• Envelope sender: Used for handling bounces and delivery failures. Think of it as the return address on the envelope.
• Header from: The address your recipient sees - the one they reply to. This is like the name and address on the letter inside.

SPF checks the envelope sender. DKIM signs the header. DMARC makes sure everything lines up.

DMARC alignment: making it all match

DMARC doesn’t just care whether SPF and DKIM passed - it wants to know if they’re aligned with the domain in your visible "From" address. There are two modes:

• Relaxed: The default mode. As long as the domains share the same root (e.g. example.com and myapp.example.com), they’re considered aligned.
• Strict: Everything must match exactly - no subdomains allowed.

Sendamatic leverages relaxed alignment, which gives you flexibility while still passing DMARC.

How Sendamatic authenticates on your behalf

Let’s say you’ve created a mail identity for example.com, and you’re using myapp.example.com as your sending domain. Here’s how Sendamatic makes sure your messages pass authentication:

DKIM signing

You’ll add a CNAME record like:

foo._domainkey.example.com → foo.dkim.sendamatic.net

This delegates DKIM signing to Sendamatic. We manage the keys, sign your messages, and recipient servers verify the signature using the public key we publish on your behalf.

SPF authorization

You’ll add a TXT record like:

myapp.example.com → "v=spf1 include:spf.smtp.sendamatic.net ~all"

The envelope sender we use will be something like <id>@myapp.example.com. When a recipient mail server receives your email, it checks the SPF record for myapp.example.com to see which servers are authorized to send on its behalf, so by including spf.smtp.sendamatic.net in that record, you're explicitly allowing Sendamatic to send mail from that subdomain, without affecting example.com's existing SPF setup.

Bounce handling with MX records

To track delivery failures, you’ll add an MX record like:

myapp.example.com → return.smtp.sendamatic.net

This lets Sendamatic receive bounce messages and provide you with actionable feedback, without interfering with your normal email replies.

Putting it all together - a typical customer DNS configuration

If you’re using Google Workspace for example.com, your DNS might already look like this:

After setting up Sendamatic, your final DNS configuration might look like this:

Want to learn more? Head over to the docs.