[ Sending-service guides ]

Authenticate email sent through MailerSend: configuration and verification

Authenticate the actual MailerSend domain, publish both current DKIM CNAMEs and its Return-Path record, then test the application route rather than relying on address verification.

By the EmailAuth research team · 5 min read

[ Key points ]

  • Use authenticated client domains instead of unaligned sender identities.
  • Publish both current DKIM CNAMEs and track the dated migration notice.
  • Verify the actual API/SMTP route and distinct Return-Path.
On this page
  1. Key points
  2. Takeaway
  3. By role
  4. Frequently asked questions
  5. Sources
  6. Glossary
  7. Related guides

[ Takeaway ]

Verify the actual API/SMTP route and distinct Return-Path.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Complete the two-key migration

Current MailerSend verification requires both issued DKIM CNAMEs.

Next steps

  1. Publish both current account-issued targets.
  2. Keep legacy records through the supported transition.
  3. Test Return-Path and DKIM on received mail.

CISO / SecOps

Keep client authority separate

Verifying one address does not authenticate the client domain.

Next steps

  1. Review the domain-versus-identity decision.
  2. Preserve the existing domain-wide DMARC policy.
  3. Restrict DNS and application changes to the approved scope.

Founder / Non-technical

Protect transactional workflows

A domain change can affect customer access and payment notifications.

Next steps

  1. Name the owner of each critical application.
  2. Choose authenticated domains for client-aligned sending.
  3. Require a tested recovery route before deployment.

[ FAQs ]

Frequently asked questions

Is a verified sender identity equivalent to an authenticated domain?

No. MailerSend says sender identities use the agency's authenticated domain and cannot provide SPF or DKIM alignment with the client's domain.

How to Verify and Authenticate a Sending Domain - MailerSend Domains | MailerSend Developers Agency Guide: When to Use Sender Identities vs. Domains - MailerSend RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC

How many DKIM records does current setup require?

Two account-issued CNAME records for the current 2048-bit DKIM configuration. Publish both rather than copying the old single-record setup.

How to Verify and Authenticate a Sending Domain - MailerSend Domains | MailerSend Developers Agency Guide: When to Use Sender Identities vs. Domains - MailerSend RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC

Should I delete the old DKIM record immediately?

No. The current migration instructions say it need not be removed yet. The Domains API states legacy support ends on 1 February 2027; recheck that notice at implementation time.

How to Verify and Authenticate a Sending Domain - MailerSend Domains | MailerSend Developers Agency Guide: When to Use Sender Identities vs. Domains - MailerSend RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC

Where does the Return-Path record come from?

From the domain's verification page. The default subdomain is mta, but it is configurable, so use the actual issued name and target.

How to Verify and Authenticate a Sending Domain - MailerSend Domains | MailerSend Developers Agency Guide: When to Use Sender Identities vs. Domains - MailerSend RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC

Does a custom tracking CNAME authenticate the bounce address?

No. Tracking and Return-Path are distinct configurations. Verify the Return-Path record and the received envelope identity separately.

How to Verify and Authenticate a Sending Domain - MailerSend Domains | MailerSend Developers Agency Guide: When to Use Sender Identities vs. Domains - MailerSend RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC

Can a Return-Path subdomain satisfy strict SPF alignment?

Not when it differs from the visible From domain. Strict alignment requires exact domain equality; inspect aligned DKIM as another possible passing path.

How to Verify and Authenticate a Sending Domain - MailerSend Domains | MailerSend Developers Agency Guide: When to Use Sender Identities vs. Domains - MailerSend RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC

Is an accepted SMTP or API request enough evidence?

No. Preserve a received message from the real application workflow and inspect the receiver's SPF, DKIM and DMARC identities and results.

How to Verify and Authenticate a Sending Domain - MailerSend Domains | MailerSend Developers Agency Guide: When to Use Sender Identities vs. Domains - MailerSend RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC

What remains unverified in this guide?

The account-specific records, active application route, authoritative DNS and live received-message evidence. Human SME and independent technical review remain pending.

How to Verify and Authenticate a Sending Domain - MailerSend Domains | MailerSend Developers Agency Guide: When to Use Sender Identities vs. Domains - MailerSend RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC

[ Sources ]

Sources

  1. How to Verify and Authenticate a Sending Domain - MailerSend

    Sections Add/verify sending domain; manual DNS; two DKIM CNAME581–589; Return-Path295–305; custom tracking

  2. Domains | MailerSend Developers

    Sections Get DNS Records1157–1166:2048-bit pair, mandatory both, legacy support deadline1Feb2027

  3. Agency Guide: When to Use Sender Identities vs. Domains - MailerSend

    Sections Domains107–119; identity comparison136–137

  4. RFC 7208 SPF

    Sections §3.2; 3.3; 4.6.4

  5. RFC 6376 DKIM

    Sections §3.5; 3.6.2; 6.1

  6. RFC 9989 DMARC

    Sections §4.4; 4.7; 4.10; 5

[ Glossary ]

Glossary

Sender identity
A verified individual address that can send through a different authenticated MailerSend domain.
Authenticated domain
A domain whose issued DNS records have been verified for sending through MailerSend.
Return-Path CNAME
The DNS alias configured for MailerSend bounce handling under the chosen domain.
DKIM migration
The transition from the legacy single record to both current 2048-bit DKIM CNAMEs.
Strict alignment
DMARC alignment requiring an exact match between the successful authentication domain and the visible From domain.

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base