Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Choose an authenticated domain for the application
MailerSend distinguishes an authenticated sending domain from a verified sender identity. An agency can verify a client's email address while sending through the agency's domain, but MailerSend explicitly says that arrangement does not provide SPF or DKIM alignment with the client's domain. Use the authenticated-domain route when the requirement is mail aligned to that client's visible From address. MailerSend domains versus sender identities.
Record the account or sub-account, domain, application, intended From address and whether the application submits through SMTP or the Email API. Inventory every affected workflow, such as receipts, password resets and account notifications. A domain shown as verified in a dashboard does not prove which domain an application actually selects. Assign an application owner, DNS owner and operator able to pause or roll back the deployment. Preserve the current DNS answers and application configuration before changing either.
Avoid treating sender-identity verification as a workaround for an established DMARC enforcement policy. If the client cannot authorize DNS changes, document that constraint and choose a supported route with the domain owner. Do not lower policy across all of the client's mail simply to accommodate one application.
Publish the current account-issued record set
In MailerSend, go to Email > Domains, add the intended domain and collect its verification instructions. The manual path supplies SPF, DKIM and a CNAME for the Return-Path. Automatic authentication involves granting access to the domain registrar, so review that authorization before using it. Copy the records from the actual domain's verification page rather than from a generic example. MailerSend domain setup.
Prepare a record worksheet containing each complete owner name, type, value, prior answer and change owner. Publish into the authoritative DNS zone. If SPF already exists at the required name, merge the necessary authorization into that single policy while preserving other legitimate senders. Inspect nested lookup costs, not just the number of visible includes. The SPF limit and single-record rule apply to each evaluated name; a domain and a separate subdomain can legitimately have different policies. SPF specification.
Current MailerSend documentation describes 2048-bit signing with two DKIM CNAME records. The Domains API identifies them as dkim_ms1 and dkim_ms2 and says both must be published, including when migrating a previously verified domain. Its current migration notice says support for the legacy record ends on 1 February 2027 and that the old record need not be removed in the meantime. Recheck that dated notice before a later implementation. MailerSend Domains API, Get DNS Records.
Treat this as a controlled migration: record both new answers, confirm their status and test mail before retiring old trust. Do not infer a customer's CNAME targets from the selector labels. Keep the returned targets exactly as issued and check whether the DNS editor automatically appends the zone name.
Verify the Return-Path and separate optional branding
MailerSend's setup guide supplies a distinct Return-Path CNAME, with a configurable subdomain that defaults to mta. Use the issued record for the chosen value. Custom tracking is another optional CNAME configuration; it is not a substitute for the Return-Path or either DKIM record. After publication, complete the verification step and use Re-check now when appropriate. Return-Path and tracking configuration.
Determine what DMARC mode the domain already uses. SPF authenticates the envelope identity, while DKIM authenticates its signing domain. DMARC requires at least one successful authentication path to align with the visible From domain. A Return-Path subdomain can satisfy relaxed alignment without satisfying strict alignment, which requires an exact domain match. Check DKIM separately instead of assuming the branded bounce address resolves every case. DKIM and DMARC.
Test each live application route
Original acceptance worksheet, not an executed test: send harmless content to controlled external recipients using each changed production-equivalent application workflow. Record the submission route, account, domain, message identifier and timestamp. Save the original received message and the trusted receiver's results. Build an identity table containing the visible From domain, Return-Path, SPF identity and result, every DKIM d= and s= pair, and the receiver's DMARC result.
Explain which passing identity supplies alignment under the actual policy. An API success response or SMTP acceptance only proves submission reached that stage. It does not prove the message reached a receiver with the intended signature. If both submission routes are used, test both; if several applications share one domain, test their actual From-address selection rather than extrapolating from a dashboard test.
For failures, compare the selected application domain with the DNS worksheet, verify both DKIM CNAMEs and inspect the complete Return-Path. Pause the affected deployment if necessary and restore the known-working application route under the approved recovery plan. Keep old records needed by in-flight mail until their retirement is safe. Review bounces and application outcomes separately from authentication because a passing message can still encounter reputation or recipient-policy problems.
No MailerSend tenant, authoritative DNS record or received message was tested here. Current account-issued records, exact SMTP/API and application-route evidence, and a received-message identity table remain mandatory gates. Independent technical review and human SME approval are still required before publication or production acceptance.