MailerSend SPF, DKIM & DMARC Setup: Step-by-Step Guide

For MailerSend custom-domain sending, add the domain under Email → Domains, publish the account-issued SPF TXT record, both current DKIM CNAME records and the Return-Path CNAME, then finish verification. Preserve your existing DMARC policy and validate an actual API or SMTP message.

Identify the sending route

This guide covers MailerSend's email API and SMTP relay using a domain you control. It does not configure MailerLite marketing campaigns, SMS, WhatsApp, or your employee mailbox service. Trial-domain sending is useful for application development but is not proof that your own domain is authenticated.

Also distinguish sender identities from sending domains. MailerSend's agency guidance describes identities as sending through the agency's authenticated infrastructure rather than authenticating the client's domain. Do not assume verifying one address gives a client aligned SPF or DKIM. For a client-controlled From domain, obtain the client's DNS authorization and configure that domain appropriately. MailerSend identities versus domains.

Before setup, write down the application, environment, MailerSend account or sub-account, exact From address and DNS host. Note whether the application sends by API or SMTP. Record the current SPF, DKIM, Return-Path and DMARC entries and their TTLs. Preserve the MX records that deliver ordinary incoming business email.

Confirm your account has the domain allowance and permissions needed. Optional tracking and inbound routing are separate choices, not prerequisites to copy indiscriminately. Public documentation does not establish that every plan, trial or agency configuration has identical controls. Do not infer different regional DNS values: use the values supplied for your actual domain and account.

Add and authenticate the domain

In Email → Domains, choose Add domain, enter your domain and add it. MailerSend offers automatic authentication through a DNS-provider connection. To review and publish records manually, close that prompt and use the displayed DNS instructions. After publication, select I have added DNS records and Finish verification. The documented recheck control is Re-check now. Verification commonly completes in minutes but may take up to 48 hours. MailerSend domain setup.

Treat each supplied row as a separate instruction consisting of owner, type, value and, where relevant, priority. Copy the values from your account, not from a tutorial's screenshot. The authentication set includes SPF, two DKIM CNAMEs and the Return-Path CNAME. Custom tracking or inbound forwarding introduces additional records only when you enable those features.

Translate record owners for your DNS editor. For ms1._domainkey.example.com, a zone-relative editor may want ms1._domainkey; an absolute-name editor wants the full name. Inspect the final owner to catch example.com.example.com. Use DNS-only, unproxied and unflattened CNAME resolution for authentication aliases. Cloudflare CNAME verification guidance. A target must be a hostname, not an HTTPS URL.

For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names. Where the actual authoritative DNS host offers these controls, use DNS-only aliases, not HTTP proxying or redirects, and keep a literal CNAME answer to each required target. Turn the relevant per-record Flatten option off when available, and ensure applicable zone-wide settings do not conceal the issued aliases. For Cloudflare specifically, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are Cloudflare behaviors, not assumed controls in another provider’s panel. If mandatory behavior or shared settings prevent the required CNAME answer, stop and coordinate a supported configuration without breaking dependent records. Do not blindly change the whole zone or remove an NS delegation; publish at the delegated authority when appropriate. Cloudflare CNAME verification, flattening controls.

Before saving a CNAME, check whether that owner already has another record. A CNAME cannot coexist with ordinary TXT, A or MX data at the same name. Resolve the ownership conflict with the affected application's administrator. Do not delete a live service's record just because the new wizard asks for that label.

Handle the two-key DKIM upgrade

MailerSend now publishes 2048-bit DKIM keys through two CNAME records. Its Domains API exposes them as dkim_ms1 and dkim_ms2; these are response-field names, not DNS owner labels. The official example uses ms1._domainkey and ms2._domainkey, but your account's full owner/value pairs remain authoritative. Both records must be published. MailerSend Domains API.

The same API documentation gives 1 February 2027 as the end of legacy single-record support and says the older record need not be removed during the transition. An existing green status is therefore not a reason to ignore the upgrade. Capture the new records, publish them alongside the retained legacy selector, recheck the domain and validate a fresh message.

If you automate DNS inventory, update the parser too. The legacy dkim response object can contain null fields; a script that reads only that object can overlook the two actual CNAME instructions. Retrieve the domain's DNS-record response using its real domain ID and inspect both new objects. Do not put an API credential into a DNS record, public ticket or exported worksheet.

The upgrade's acceptance evidence should include both public aliases, the domain's verification status and a received signature using the expected signing identity. Two published selectors do not mean each message must have two signatures. They support the provider's key-management workflow; inspect whichever selector a fresh message actually uses.

DKIM signs a message with a private key kept by the sending system. DNS exposes the public verification material through the CNAME destination. Publishing a public key does not itself establish that your application selected the right domain or that the message survived transit unchanged. DKIM specification.

Configure SPF and Return-Path safely

MailerSend's SPF guidance uses include:_spf.mailersend.net. Treat that as the documented authorization mechanism, not a complete replacement for a domain already used by other senders. Its setup flow can propose a merged policy. Reconcile the proposal with the current authoritative record before saving. MailerSend SPF merging.

Keep one SPF policy at each owner. Combine necessary authorizations within that policy, preserve the intended ending such as -all or ~all, and do not append a second v=spf1. The ten-DNS-querying-term limit applies during evaluation, including nested includes. Do not add unrelated mechanisms from an API example. Other TXT records, including verification tokens, may coexist with the single SPF record. SPF specification.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

The Return-Path CNAME is a different record. It supplies the bounce identity, whereas SPF evaluates the actual envelope MAIL FROM domain used on delivery. A correctly merged SPF policy at the visible From domain cannot by itself prove that envelope identity aligns. Publish the account-issued Return-Path alias and inspect the delivered smtp.mailfrom value.

Do not confuse Return-Path with Reply-To. A customer reply goes to the reply address; delivery failures use the envelope return path. Changing your Reply-To mailbox is not an authentication fix. Likewise, a branded tracking CNAME affects links, not DKIM verification. See MailerSend tracking options when deliberately configuring that separate feature.

Set DMARC without weakening protection

Before adding DMARC, inspect the visible From domain's policy and relevant inherited parent policy. Preserve established enforcement, subdomain policy, strictness and report destinations. A missing local record is not permission to override a parent's p=reject with a new p=none.

Only when there is no existing or inherited policy, and a monitored initial rollout is appropriate, create a TXT record:

Full owner: _dmarc.example.com for mail From example.com.
Relative host: _dmarc in the example.com DNS zone.
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com.
TTL: the DNS host's normal default.

Replace the example domain and report address with a real authorized destination that can receive aggregate reports. For From notify.example.com, the local owner would be _dmarc.notify.example.com, often entered as _dmarc.notify in the parent zone. Do not create duplicate DMARC policies. If reports go outside your domain, confirm any required external-destination authorization.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4. In a separately delegated notify.example.com zone, the full owner _dmarc.notify.example.com has relative name _dmarc. Preserve the delegation and existing applicable policy.

DMARC requires an aligned SPF pass or an aligned DKIM pass. Relaxed mode accepts an organizational-domain match; strict mode requires the identical domain. A bounce subdomain therefore does not automatically satisfy aspf=s. Do not loosen policy simply to hide a misconfigured sender. p=none observes without requesting DMARC-based blocking. Current RFC 9989 supersedes RFC 7489 and removes pct; plan enforcement around observed sender readiness, not that removed percentage mechanism.

Verify DNS and application messages

Run these read-only checks after substituting the actual names. The two selector labels below reflect the current documented scheme; confirm the full owners in your account.

dig +short NS example.com
dig +short TXT example.com
dig +short CNAME ms1._domainkey.example.com
dig +short CNAME ms2._domainkey.example.com
dig +short TXT DKIM-TARGET-FROM-ACCOUNT
dig +short CNAME RETURN-PATH-HOST.example.com
dig +short TXT RETURN-PATH-HOST.example.com
dig +short TXT _dmarc.example.com

Expect both DKIM aliases to match the supplied destinations and the final DKIM TXT data to contain a usable public key. Follow the return-path resolution to inspect SPF. Check the authoritative nameserver directly if recursive resolvers disagree. A blank response is not enough to distinguish an incorrect name from the wrong query type or caching; inspect the full response and status if needed.

Then send an authorized sample through the actual application and transport. If you run both API and SMTP integrations, test both rather than extrapolating from one. MailerSend's SMTP guide distinguishes generated SMTP credentials from account login credentials. SMTP users are not domain-exclusive: they work account-wide for any verified domain. A successful SMTP login is not a delivered-message authentication result.

In the trusted receiving system's Authentication-Results, confirm spf=pass for the expected smtp.mailfrom, dkim=pass for the intended header.d, and dmarc=pass for header.from. Compare domains under the actual DMARC modes. Also record s= from DKIM-Signature so you know which selector was exercised. Ignore untrusted sender-inserted authentication claims.

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

Retain a dated, redacted evidence record per application environment. Successful DNS publication, provider verification and receiver authentication are three different checkpoints. None guarantees inbox placement or that every future application message chooses the same From identity.

For setup acceptance, require a passing DKIM signature for the expected branded domain that aligns with From, plus DMARC pass. Independently investigate actual SPF fail, permerror or temperror results even when DKIM carries DMARC; an unaligned SPF pass is a different diagnosis.

Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.

Troubleshooting and FAQs

Why does an older domain say verified but need new DKIM records?

It may have been verified under the legacy single-key flow. Check the current two-CNAME instructions and the documented February 2027 deadline. Preserve the old record during the supported transition rather than removing it first.

Why does SPF pass but DMARC fail?

Compare the SPF envelope domain and DKIM signing domain with the visible From. A passing identity that belongs to the provider or another client is not necessarily aligned. Check sender-identity use, application From configuration and the Return-Path before changing policy.

What if verification remains pending?

Compare authoritative DNS with every issued row, including both DKIM CNAMEs. Check suffix duplication, CNAME conflicts, proxying and a stale merged SPF proposal. Recheck after the documented propagation interval. Escalate with redacted record evidence, not API or SMTP secrets.

Do I need to change my business mailbox MX?

Not for ordinary outbound authentication. Optional inbound routing is a separate service. Do not publish its MX at a production mailbox domain without an intentional receiving-mail migration.

Use EmailAuth's SPF overview and DKIM overview for protocol background, and EmailAuth for broader domain-policy planning.

For the trust boundary of authentication headers, see RFC 8601.

This guide involved no customer-account configuration, DNS change or delivered-message test.

MailerSend SPF, DKIM and DMARC setup, step by step

On this page