How Sendamatic sends email from your domain

When you configure a mail identity in Sendamatic, you’ll need to add a few DNS records - things like CNAME, TXT, and MX. These records tell the world, “Sendamatic is authorized to send mail for us.”

This type of setup goes by many names: white-label email authentication, subdomain routing, DKIM delegation… the list goes on.

We’ll keep it simple and call it delegated email authentication.

What is email authentication?

This isn’t about usernames and passwords - it’s about proving an email really comes from the domain it claims to.

When you send a message from [email protected], receiving servers want to know if the message is authentic - i.e. “Is this actually from example.com?”

To prove that it is, most recipient mail servers require your email to pass authentication checks - specifically:

SPF: Checks the envelope sender (the return path) to confirm the sending server is authorized for your domain. This helps prevent spoofing.
DKIM: Adds a digital signature to the email so the recipient can verify it hasn’t been altered and really came from your domain.
DMARC: Builds on SPF and DKIM by telling receiving servers what to do if those checks fail - for example, reject, quarantine, or allow the message.

If these authentication checks fail, your emails might be rejected or land in spam folders.

Understanding the two "From" addresses

It's important to understand that every email has two different "from" addresses:

Envelope: Also called the bounce address, return-path, P1, 5321.MailFrom, or MAIL FROM address. This is used for handling delivery failures.
Header: What the recipient sees, also called the P2 or 5322.From address. This is used to display who the message is from, usually contains a display name (e.g. Alice <[email protected]>), and is the address recipients would reply to.

Think of it like a physical letter: the envelope has a return address (for undeliverable mail), while the letter inside shows who it's from and who to reply to. The two addresses are often different, as they have different purposes.

DMARC alignment

The last thing we need to understand is DMARC, and DMARC alignment.

DMARC doesn’t just check if SPF or DKIM passed - it also checks if the tests are aligned with the domain in your email’s "From" address. In other words, it asks: "Do these authentication results actually match the address the recipient sees?"

There are two modes:

Relaxed alignment: This is the default mode. As long as the domains share the same organizational root, they're considered aligned. So if your 5322.From address is example.com, SPF and DKIM can use mail.example.com or myapp.example.com.
Strict alignment: Everything has to match exactly. If your email says it’s from example.com, then the domains used for SPF and DKIM must also be example.com - no subdomains allowed.

You'll need to use the default relaxed alignment mode in your DMARC record when using Sendamatic.

Putting it all together - how we can send authenticated mail on your behalf

In the following examples, let's say you've created a mail identity for example.com, and have chosen to use myapp.example.com for the mail from domain.

Here’s how it works:

DKIM signing

We create and manage seperate DKIM public/private keypairs for each mail identity. This means we don't have to have access to any existing DKIM keys you may have.

You’ll be asked to add a CNAME DNS record like: foo._domainkey.example.com → foo._domainkey.sendamatic.net

We sign messages with the private key. When a recipient mail server receives an email, it can look up the public key from your foo._domainkey.example.com DNS record, which will refer them to the public key we manage for your domain. The recipient server can then verify the signature against this public key and say, "Yes, this email came from example.com and is unaltered."

SPF

You’ll also add a TXT DNS record like:

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

The envelope address we use will be from <id>@myapp.example.com. The recipient mail server will look up the TXT record for myapp.example.com, looking for a list of allowed sending servers, and get our list from spf.smtp.sendamatic.net.

MX record for bounce handling

You'd add an MX record like: myapp.example.com → return.smtp.sendamatic.net

Any delivery failures or bounces would be sent to the envelope <id>@myapp.example.com address, which would point to our return MX, so we can provide you clean, actionable feedback.

Typical DNS setup

Finally, let's look at a typical DNS example. Say you're a Google Workspace customer, on example.com. Your existing DNS configuration for inbound email might look like:

Type	Name	Value
MX	@	smtp.google.com
TXT	@	v=spf1 include:_spf.google.com

You create a Sendamatic mail identity for example.com, and use myapp.example.com for the mail from domain. After creating the necessary records, your DNS would look something like this:

Type	Name	Value
MX	@	smtp.google.com
TXT	@	v=spf1 include:_spf.google.com
MX	myapp	return.smtp.sendamatic.net
TXT	myapp	v=spf1 include:spf.smtp.sendamatic.net ~all
CNAME	foo._domainkey	foo.dkim.sendamatic.net
CNAME	bar._domainkey	bar.dkim.sendamatic.net

So hopefully that gives you a good grounding on how everything works. If you've got any questions, feel free to reach out to reach out to support, we're always happy to help.