Email Authentication for Transactional Email Services

Learn how to authenticate transactional email services with SPF, DKIM, custom Return-Path and DMARC alignment.

By CheckDomainHealth Editorial Team Reviewed by Dionis Ceban Updated Jun 28, 2026 8 min read Beginner

Introduction

Transactional email services send automated messages such as password resets, invoices, order confirmations, account alerts, login codes and application notifications. These messages often come from platforms like SendGrid, Mailgun, Postmark, Amazon SES, Brevo, SparkPost or similar providers.

A common mistake is assuming that mailbox authentication from Google Workspace or Microsoft 365 automatically covers transactional email. It does not. Transactional providers usually need their own SPF, DKIM and sometimes custom Return-Path or bounce-domain setup so their messages can pass DMARC alignment.

Quick answer

Quick answer

Transactional email services must be authenticated separately from your normal mailbox provider. Add the provider’s required SPF or include values, publish its DKIM records, configure custom Return-Path or bounce domain if supported, and verify that messages pass DMARC alignment.

Transactional email services

Transactional email services send automated, event-based emails from websites, applications and business systems.

  • Password reset emails
  • Order confirmations
  • Invoices and receipts
  • Account alerts
  • Login codes
  • Shipping notifications
  • System alerts
  • Booking confirmations

These emails may use the same domain as your normal business email, but they often come from a different sending provider.

Separate authentication

Normal mailbox email and transactional email often use different sending infrastructure.

Mailbox provider

Google Workspace or Microsoft 365

Transactional provider

SendGrid, Mailgun, Postmark, Amazon SES, Brevo or another SMTP/API service

Even if your mailbox provider is authenticated, the transactional provider still needs authorization. Otherwise, app emails may fail SPF, DKIM or DMARC alignment.

This is especially important for password resets, billing emails and other messages users expect to receive reliably.

SPF

Some transactional services provide an SPF include or sending IP range. If the provider sends mail using your domain, SPF may need to authorize that provider.

Do not create a second SPF record.

Bad example — two SPF records 
v=spf1 include:_spf.google.com ~all
v=spf1 include:transactional.example ~all
Good example — one combined SPF record 
v=spf1 include:_spf.google.com include:transactional.example ~all

Only add the transactional provider’s SPF include if that provider instructs you to do so. Some providers rely more on DKIM and custom bounce domains.

DKIM

DKIM is usually the most important authentication step for transactional providers. The provider generates one or more DNS records that prove it is allowed to sign mail for your domain.

Common DKIM setup:

  1. Provider generates DKIM records
  2. You publish TXT or CNAME records in DNS
  3. Provider verifies the records
  4. Provider signs outgoing messages
  5. Receivers verify signatures using DNS

Always use the exact DKIM records from the transactional provider dashboard. Do not invent selectors or public keys.

Return-Path

Many transactional providers use a technical bounce or Return-Path domain for delivery status and bounce handling.

Example 
Visible From:
notifications@example.com

Return-Path:
bounce.example.com

If the Return-Path domain aligns with your domain, SPF alignment may help DMARC pass. Some providers call this feature custom Return-Path, custom bounce domain, custom MAIL FROM, branded bounce domain or envelope sender domain.

If your provider supports it, configuring a custom Return-Path can improve authentication alignment and reporting clarity.

Subdomains

Many businesses use a subdomain for transactional email.

Examples:

  • mail.example.com
  • notify.example.com
  • transactional.example.com
  • alerts.example.com
  • billing.example.com

Benefits:

  • Separates transactional reputation from normal mailbox email
  • Makes DMARC reporting easier to analyze
  • Gives clearer DNS organization
  • Helps isolate application mail streams
  • Can simplify provider-specific authentication

A subdomain still needs proper SPF, DKIM and DMARC planning.

Transactional email

Password resets, invoices, account alerts, confirmations, system notifications.

Marketing email

Newsletters, promotions, campaigns, product updates.

If both streams use the same domain, reputation and authentication issues can affect important transactional messages. Some businesses separate them by subdomain.

Why this matters

Why this matters

This matters because transactional emails are often critical. If password resets, invoices or alerts fail authentication, users may not receive messages they need. Missing DKIM, misaligned Return-Path domains or duplicate SPF records can cause avoidable delivery problems.

Transactional email should be treated as production infrastructure, not only as a website plugin setting.

How to check it

Use SPF Checker, DKIM Checker and DMARC Checker to verify the DNS records used by your transactional provider.

When checking transactional email, review

These six checks help confirm authentication is complete.

Sending provider

Identify which service sends app or system emails.

SPF

Check whether the provider needs an SPF include or sending IP authorization.

DKIM

Confirm the provider’s DKIM records are published and verified.

Return-Path

Check whether a custom bounce or Return-Path domain is configured.

DMARC alignment

Send a real test message and confirm SPF or DKIM aligns with the visible From domain.

Subdomain policy

If using a subdomain, check its DMARC policy and authentication records.

Check transactional email DNS

Use SPF, DKIM and DMARC tools to verify your transactional email setup.

Run SPF Check →

Common problems

Provider not authenticated

High

The transactional service sends mail for your domain, but its DNS records are missing.

Next step: Publish the SPF, DKIM and domain verification records from the provider dashboard.

Duplicate SPF records

High

A separate SPF record was added for the transactional provider.

Next step: Merge all authorized senders into one SPF TXT record.

DKIM not verified

High

The provider cannot verify the DKIM records or is not signing mail.

Next step: Copy the exact DKIM records from the provider and verify DNS visibility.

Return-Path not aligned

Medium

SPF may pass for the provider’s bounce domain, but DMARC alignment may fail.

Next step: Configure custom Return-Path or rely on aligned DKIM.

Website forms send directly from hosting

Medium

Forms bypass the transactional provider and send from the hosting server instead.

Next step: Configure the website to send through authenticated SMTP or API.

Old transactional provider still authorized

Medium

An unused provider remains in SPF or DNS records.

Next step: Remove old provider records after confirming it no longer sends mail.

Subdomain DMARC not reviewed

Low

Transactional email uses a subdomain without its own DMARC plan.

Next step: Check parent and subdomain DMARC policy.

Test emails pass but production emails fail

Medium

Different templates, From addresses or mail streams may use different authentication settings.

Next step: Test each real mail stream, not only one sample message.

How to authenticate it

  1. Step 1: Identify all transactional senders

    List apps, websites, billing systems, CRMs, helpdesks and notification tools that send automated mail.

  2. Step 2: Choose the sending domain

    Decide whether the provider should send from the root domain or a subdomain.

  3. Step 3: Publish provider DNS records

    Add SPF, DKIM, verification and bounce-domain records exactly as provided.

  4. Step 4: Avoid duplicate SPF

    Merge transactional sender authorization into the existing SPF record if SPF is required.

  5. Step 5: Enable DKIM signing

    Verify DKIM records in the provider dashboard and enable signing.

  6. Step 6: Configure custom Return-Path if supported

    Use a branded bounce domain to improve alignment and reporting.

  7. Step 7: Send real test messages

    Test password reset, invoice, alert and notification emails, not only one generic test.

  8. Step 8: Review DMARC results

    Confirm messages pass DMARC through aligned SPF or aligned DKIM.

Examples

Combined SPF example 
v=spf1 include:_spf.google.com include:transactional.example ~all
Transactional DKIM example hostname 
s1._domainkey.example.com
Transactional DKIM value 
v=DKIM1; k=rsa; p=PUBLIC_KEY_FROM_PROVIDER
Custom bounce domain example 
bounce.example.com CNAME provider-bounce.example
DMARC starter example 
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Check commands 
dig example.com TXT
dig s1._domainkey.example.com TXT
dig bounce.example.com CNAME
dig _dmarc.example.com TXT

These examples are illustrative. Use the exact DNS records from your transactional email provider.

Checklist

For each provider, confirm

Use this checklist before and after transactional email setup.

Sending domain

Sending domain is known.

SPF requirement

SPF requirement is understood.

DKIM published

DKIM records are published.

DKIM signing

DKIM is verified and signing.

Return-Path

Return-Path or bounce domain is configured if supported.

DMARC alignment

DMARC alignment passes.

Old records removed

Old provider records are removed.

Real flow tests

Test emails work from real application flows.

Monitor reports

Reports are monitored after changes.

Frequently asked questions

Does Google Workspace or Microsoft 365 authentication cover transactional email?

No. Transactional providers need their own authentication setup if they send mail for your domain.

Should I add a separate SPF record for my transactional provider?

No. If SPF is required, merge the provider into the existing single SPF record.

Is DKIM required for transactional email?

It is strongly recommended. DKIM is often the most reliable way for transactional providers to pass DMARC alignment.

What is a custom Return-Path?

It is a branded bounce or envelope-sender domain used by the provider for delivery status and SPF alignment.

Should I use a subdomain for transactional email?

Often yes, especially for applications, alerts or high-volume transactional sending.

Why do password reset emails go to spam?

Possible reasons include missing DKIM, SPF errors, DMARC alignment failure, poor reputation, content issues or app sending through the wrong server.

Do I need to test every type of transactional email?

Yes. Different app flows may use different From addresses, templates or sending settings.

Use these free tools to verify your configuration after applying changes.

SPF Checker DKIM Checker DMARC Checker MX Lookup Domain Health Checker Reverse DNS Checker
SPF When Using Multiple Email Providers 7 min read DKIM Signatures: How They Work and Why They Matter 8 min read Understanding DMARC Alignment 8 min read Google Workspace Email Authentication: SPF, DKIM and DMARC 8 min read Microsoft 365 Email DNS Setup: SPF, DKIM and DMARC 8 min read
Browse all Email Authentication guides →

Need help applying this fix?

Send us your domain, report link or issue details. CheckDomainHealth will review the request and route it to the right technical team if hands-on support is needed.

Get Help Run Domain Health Check

Was this guide helpful?

Your feedback helps us improve our guides for everyone.