DEV Community

Cover image for How to Set Up a Sending Domain for Email Marketing and Transactional Email
Cresca
Cresca

Posted on AI-assisted

How to Set Up a Sending Domain for Email Marketing and Transactional Email

#ai #marketing

Sending an email is easy.

Sending millions of emails reliably from your own domain is a completely different problem.

If you've ever built a SaaS product, an email marketing platform, a newsletter system, or a transactional email service, you've probably encountered terms like SPF, DKIM, DMARC, DNS, sender identity, email authentication, and domain reputation.

These aren't just configuration details.

They are part of the foundation that determines whether your emails are trusted, delivered, or filtered into spam.

In this guide, we'll break down how sending domains work, why they matter, and what you need to configure before sending emails from your own domain.

What Is a Sending Domain?

A sending domain is the domain you use as the identity for outgoing emails.

For example, imagine your company owns:

example.com
Enter fullscreen mode Exit fullscreen mode

You may want to send emails from:

hello@example.com
marketing@example.com
notifications@example.com
support@example.com
Enter fullscreen mode Exit fullscreen mode

Instead of using a generic provider address, your application sends email using your own domain.

This gives you control over your email identity and allows you to configure authentication specifically for your domain.

For an email marketing platform, a sending domain is especially important because campaigns should represent the business sending them.

Why Should You Use Your Own Sending Domain?

There are several reasons to configure a dedicated sending domain.

1. Brand consistency

Customers should recognize who sent an email before they even open it.

Compare:

newsletter@yourcompany.com
Enter fullscreen mode Exit fullscreen mode

with an unfamiliar generic sending address.

Your domain becomes part of your brand identity.

2. Email authentication

Your domain can be configured with authentication mechanisms such as:

  • SPF
  • DKIM
  • DMARC

These help receiving mail systems evaluate whether messages are authorized and whether the sender's identity is trustworthy.

3. Better control

When you're building an email infrastructure, controlling your sending domain gives you more visibility into:

  • Authentication
  • Sending identities
  • Domain configuration
  • Reputation
  • Delivery events
  • Bounce handling
  • Complaint handling

4. Separation of email traffic

You may not want every type of email to share exactly the same infrastructure.

For example:

marketing.example.com
Enter fullscreen mode Exit fullscreen mode

could be used for campaigns while:

mail.example.com
Enter fullscreen mode Exit fullscreen mode

could be used for application notifications.

The right architecture depends on your product, volume, and reputation strategy.

How Email Authentication Works

When you send an email, the receiving mail server doesn't simply trust the From address.

It can check DNS records and other authentication signals to determine whether the message is actually authorized.

Three of the most important technologies are:

SPF

DKIM

DMARC

Let's look at each one.

SPF: Sender Policy Framework

SPF allows a domain owner to publish a DNS record specifying which mail servers are authorized to send email on behalf of that domain.

A simplified example looks like:

example.com TXT
v=spf1 include:mail-provider.example ~all
Enter fullscreen mode Exit fullscreen mode

The exact record depends on the email infrastructure you're using.

When a receiving server gets an email, it can check the sending server's IP address against the domain's SPF policy.

If the server isn't authorized, the message may fail SPF evaluation.

Important SPF limitation

SPF has a DNS lookup limit.

If you keep adding providers and include statements without considering the lookup limit, your SPF configuration can eventually fail.

This is one reason email infrastructure should be designed carefully instead of continuously adding DNS records whenever a new provider is introduced.

DKIM: DomainKeys Identified Mail

DKIM adds a cryptographic signature to outgoing email.

The sending system signs the message with a private key.

The corresponding public key is published through DNS.

A simplified DKIM DNS record might look like:

selector1._domainkey.example.com
Enter fullscreen mode Exit fullscreen mode

with a value containing the public key.

When the email arrives, the receiving server can retrieve the public key and verify the signature.

This helps establish that the message was authorized by the domain associated with the DKIM signature and that important parts of the message haven't been modified after signing.

DKIM is particularly important when building a production email sending system.

DMARC: Domain-based Message Authentication

DMARC builds on SPF and DKIM.

It allows domain owners to publish a policy describing how receiving servers should handle messages that don't properly authenticate.

A basic DMARC record looks like:

_dmarc.example.com TXT
v=DMARC1; p=none
Enter fullscreen mode Exit fullscreen mode

A domain can gradually move toward stricter policies as its email authentication is understood and monitored.

For example:

p=none
Enter fullscreen mode Exit fullscreen mode

can be useful during monitoring.

More restrictive policies can then be introduced after validating legitimate sending sources.

The important part is not simply adding a DMARC record.

You need to understand which systems are legitimately sending email for your domain before enforcing a strict policy.

The DNS Setup

When adding a sending domain to an email platform, you'll typically receive DNS records to configure.

These can include:

TXT
CNAME
MX
Enter fullscreen mode Exit fullscreen mode

depending on the provider and configuration.

For example, an email platform might provide DKIM CNAME records such as:

selector1._domainkey.example.com
selector2._domainkey.example.com
Enter fullscreen mode Exit fullscreen mode

Your DNS provider could be:

  • Cloudflare
  • Route 53
  • GoDaddy
  • Namecheap
  • Vercel DNS
  • DigitalOcean
  • Another domain provider

The interface changes between providers, but the underlying DNS concepts remain the same.

A Typical Sending Domain Workflow

A production email platform can make this process much simpler for users.

The workflow can look like this:

Add Domain
    ↓
Generate DNS Records
    ↓
User Adds DNS Records
    ↓
Verify DNS
    ↓
Validate Authentication
    ↓
Domain Ready
    ↓
Send Email
Enter fullscreen mode Exit fullscreen mode

This is the workflow we recently introduced in Cresca with our new Sending Domains feature.

Sending Domains in Cresca

We built Sending Domains because email infrastructure shouldn't require users to manually manage everything across multiple systems.

Inside Cresca, users can add their domain and get the DNS configuration required for the sending setup.

The general flow is:

Cresca Dashboard
      ↓
Sending Domains
      ↓
Add Your Domain
      ↓
Configure DNS
      ↓
Verify Domain
      ↓
Start Sending
Enter fullscreen mode Exit fullscreen mode

Once the domain is verified, it can be used as part of the email sending setup.

This is especially useful for teams using Cresca for:

  • Email marketing
  • SaaS notifications
  • Transactional emails
  • Product updates
  • Customer communication
  • Automated campaigns

Marketing Email vs Transactional Email

It's also important to understand that not all emails are the same.

Marketing emails

Examples include:

Product announcements
Newsletters
Promotional campaigns
Product updates
Offers
Enter fullscreen mode Exit fullscreen mode

These are generally sent to audiences for marketing purposes.

Transactional emails

These are triggered by user or application actions.

Examples:

Welcome emails
Password reset emails
Order confirmations
Payment receipts
Account notifications
Security alerts
Enter fullscreen mode Exit fullscreen mode

The infrastructure may overlap, but the sending strategy and reputation considerations can be different.

For SaaS products, keeping your email architecture organized becomes increasingly important as sending volume grows.

Don't Ignore Bounce and Complaint Handling

Domain authentication is only one part of email deliverability.

You also need to pay attention to what happens after an email is sent.

For example:

Email Sent
   ↓
Delivered
   ↓
Opened
   ↓
Clicked
Enter fullscreen mode Exit fullscreen mode

But another path can be:

Email Sent
   ↓
Hard Bounce
   ↓
Suppress Address
Enter fullscreen mode Exit fullscreen mode

Or:

Email Sent
   ↓
Spam Complaint
   ↓
Suppress Address
Enter fullscreen mode Exit fullscreen mode

Continuing to send repeatedly to addresses that have permanently bounced is a bad strategy.

A production email system should process delivery events and maintain suppression information.

Why Sending Reputation Matters

Email providers don't evaluate your messages in isolation.

Your sending behavior contributes to the reputation associated with your infrastructure and domains.

Poor recipient quality can lead to:

  • High bounce rates
  • Spam complaints
  • Reduced deliverability
  • Provider throttling
  • Reputation problems

This means email marketing isn't simply:

Write email → Click Send
Enter fullscreen mode Exit fullscreen mode

A more realistic system looks like:

Audience
   ↓
Validation
   ↓
Authentication
   ↓
Sending
   ↓
Delivery Events
   ↓
Bounce / Complaint Processing
   ↓
Suppression
   ↓
Reputation Monitoring
Enter fullscreen mode Exit fullscreen mode

That entire feedback loop matters.

A Simple Production Checklist

Before sending production email from a domain, check the following.

Domain

  • [ ] Domain is owned and controlled by your organization
  • [ ] DNS access is available
  • [ ] Sending identity is configured

Authentication

  • [ ] SPF configured correctly
  • [ ] DKIM configured and verified
  • [ ] DMARC configured
  • [ ] Legitimate sending sources are documented

Sending infrastructure

  • [ ] Sending provider configured
  • [ ] Bounce events processed
  • [ ] Complaint events processed
  • [ ] Suppression system enabled
  • [ ] Sending limits understood

Application

  • [ ] From address is controlled
  • [ ] Users cannot arbitrarily spoof sender identities
  • [ ] Domain verification happens before sending
  • [ ] Campaign recipients are managed responsibly

Monitoring

  • [ ] Delivery rate monitored
  • [ ] Bounce rate monitored
  • [ ] Complaint rate monitored
  • [ ] Domain reputation monitored

What We Learned Building This

One of the biggest lessons from building email infrastructure is that sending an email is the easy part.

The difficult part is building the systems around sending.

You need to think about:

Identity
Authentication
Infrastructure
Recipient quality
Deliverability
Events
Suppression
Reputation
Monitoring
Enter fullscreen mode Exit fullscreen mode

A good email platform should hide much of this complexity from the user while still giving them enough visibility and control when they need it.

That's the direction we're taking with Cresca.

Sending Domains Are Now Live in Cresca

We've now added Sending Domains to Cresca so teams can connect their own domains and build their email sending setup around their own brand.

Instead of treating domain configuration as a separate technical task, it's becoming part of the email workflow itself.

If you're building a SaaS product, running email campaigns, or sending transactional email, having control over your sending domain is an important foundation.

Your domain. Your brand. Your emails.

You can explore Cresca here:

https://www.cresca.xyz/

Final Thoughts

Email deliverability isn't solved by one DNS record.

It's a combination of:

Authentication + recipient quality + sending behavior + monitoring + reputation.

Getting the sending domain right is one of the first steps.

And as your email volume grows, having that infrastructure built into your email platform can save a significant amount of engineering and operational work.

That's exactly what we're building with Cresca.

Top comments (0)