ReachMail SPF, DKIM and DMARC setup, step by step

To authenticate a ReachMail campaign domain, first verify permission to use it under Account > Campaign Settings > Sending Domains. Then add the domain under Domain Authentication, publish the SPF and DKIM values generated for your account, and check DNS again in ReachMail. Preserve any existing DMARC protection. Finally, inspect a delivered campaign for a passing, aligned signature using your own domain. A verified sender or a green DNS indicator alone does not prove that final result.

This guide covers ReachMail marketing campaigns using a domain you control. Easy-SMTP relay profiles and dedicated routing need their own account-specific instructions. No customer account, DNS zone or live message delivery was tested.

Choose the sending identity before changing DNS

ReachMail distinguishes domain permission from authentication. The sending-domain guide describes an email confirmation link; the authentication guide describes DNS records. Complete both for branded campaigns. Record the selected mailing’s actual From and Reply-To, not just a saved account default; existing or scheduled campaigns may retain an older identity. Domain permission for one brand is not approval for another.

Official pages describe both restrictions on free-webmail sending and a shared-domain rewriting option. Treat rewriting as an account-specific fallback to confirm with support, not a guarantee that any free address will be accepted. The authentication page identifies send.reach-mail.com as a shared identity with its own policy. Do not change DNS for a domain owned by ReachMail.

Prepare access and preserve the working configuration

You need ReachMail account access, access to the mailbox used for domain verification, DNS editing permission at the authoritative DNS host, and an approved recipient for a test campaign. The registrar and DNS host may be different companies.

Save the existing TXT records, any DKIM selectors, the applicable DMARC policy and the current campaign identity. Inventory other senders such as Microsoft 365, Google Workspace, support tools and transactional systems. Record the exact domain or subdomain being authenticated; SPF at the parent does not automatically authorize a subdomain.

For an IT handoff, provide the generated record type, complete owner name, full value, intended From domain and current SPF record. Do not send account passwords or private signing keys. A DNS administrator does not need either to publish public authentication records.

If your campaign From address uses a Google Workspace alias or secondary domain, verify that identity separately in Workspace; it does not replace ReachMail campaign authentication. When interpreting the campaign itself, EmailAuth’s raw DKIM versus aligned DKIM guide explains why a passing provider signature can still miss your brand.

Step 1: Verify permission to use the campaign domain

Open Account > Campaign Settings > Sending Domains, choose Verify a New Domain, and complete the confirmation email for the domain. If the message is missing, check filtering and use the resend control rather than repeatedly adding the domain. ReachMail also documents revocation and deletion controls; neither is needed just to repair a DNS record.

The native screenshot includes an old Gmail example, but the current written instructions exclude free-webmail sending domains. Do not treat that sample row as current permission. The padlock in this area indicates whether a DMARC policy was detected. It does not establish that the campaign's SPF or DKIM identity aligns, or that every legitimate sender works under that policy. See ReachMail's sending-domain instructions.

Step 2: Retrieve the current SPF and DKIM records

Under Account > Campaign Settings > Domain Authentication, enter the domain and any applicable subdomain, then add it. ReachMail's SPF instructions describe the existing SPF display and the required addition. Its DKIM instructions provide the record name and public TXT key.

Copy the complete issued tagged TXT value, including its k= and p= data and any other supplied tags, not just the public-key characters. The native screenshot shows a particular selector and include; neither is a substitute for your own account packet. Copy those values rather than choosing an include domain, selector or public key from an unrelated tutorial. The documentation's references to the root domain concern where the DNS zone is managed; DKIM still belongs at the supplied selector owner, not indiscriminately at @.

If DNS has changed since the panel last refreshed, compare the live record before merging. A periodically refreshed panel is not a substitute for the current authoritative answer.

Step 3: Publish safely, manually or through Entri

For SPF, edit the existing TXT policy beginning v=spf1; do not add a second SPF policy at the same name. Insert the authorized ReachMail mechanism before the terminating all mechanism, keeping other legitimate mechanisms and the existing ending. Do not replace the whole record with a provider-only example.

SPF, RFC 7208 evaluates the connecting server against the envelope MAIL FROM domain, normally reflected in Return-Path, or HELO in applicable cases such as a null reverse-path, not simply the visible From address. There is a maximum of 10 evaluated DNS-lookup-causing terms, including nested include and redirect evaluation. This is not a count of all TXT records or only top-level includes. ip4, ip6 and all do not consume those terms. Check the full evaluation path before adding another sender. If an all mechanism is present, redirect is ignored; do not append a redirect after all expecting a second policy to apply. Preserve the approved policy design. SPF all/redirect precedence

Publish DKIM at the account-supplied owner. A DNS panel may append your zone automatically; avoid creating a name ending in the domain twice. Preserve unrelated selectors. If the account supplies a CNAME rather than the documented TXT route, confirm that instruction with ReachMail, remove no conflicting record without investigating it, and keep the alias DNS-only and unflattened. A CNAME cannot coexist with other ordinary data at its owner.

For example, the illustrative full DKIM owner issued-selector._domainkey.news.example.com maps to issued-selector._domainkey.news in the parent example.com zone, or issued-selector._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com is itself delegated, its administrator publishes issued-selector in that zone. These are owner-mapping examples, not prescribed ReachMail selectors. Preserve NS delegations and other selectors; do not delete a delegation to force publication in the parent. DNS delegation and aliases

Only for a CNAME instruction confirmed for your account, Cloudflare must return the required literal alias. Use DNS only, turn a relevant per-record Flatten control off where available, and ensure an applicable whole-zone flatten-all setting does not suppress that alias. Coordinate affected services before changing shared zone behavior. Apex flattening and same-zone target behavior can be mandatory regardless of that per-record setting; if these prevent the required answer, stop and obtain a supported configuration from the DNS owner and ReachMail. Do not change unrelated global settings or substitute an invented target. Cloudflare flattening controls · Domain-verification caveats

For the automated route, ReachMail's Entri guide describes Publish with Entri, selecting your DNS host, reviewing proposed records and approving them. Have the authorized DNS owner complete any provider sign-in and review the connection’s permissions as well as the proposed records. Keep credentials out of DNS, shared notes and support tickets. Review the actual diff: automation does not justify duplicate SPF, lost senders or downgraded DMARC. Use the manual IT-managed route if the proposed change is unsafe.

Step 4: Confirm DNS and ReachMail status

The manual guides advise waiting at least ten minutes and selecting Check Current DNS. The Entri guide says verification often takes minutes but can take up to 24 hours. These are guidance, not proof that a wrong owner will eventually work.

The following are read-only examples. Replace all example.com names with your real domain, SPF identity and issued selector. Use the record type that ReachMail actually supplied.

dig +short NS example.com
dig +short TXT example.com
dig +short TXT selector-from-reachmail._domainkey.example.com
dig +short TXT _dmarc.example.com

Expect one applicable SPF policy, the complete issued public key and the intended DMARC policy. For a long DKIM TXT value, component strings must form one logical TXT record and concatenate without inserted spaces; do not create separate records for pieces of the key or truncate the value. Preserve the full supplied tagged value. Two separate SPF policies are likewise not acceptable. DKIM TXT string handling Compare authoritative answers and a recursive resolver if the panel disagrees. Green ReachMail status is the DNS gate; delivered-message verification is the next gate.

Step 5: Prove branded authentication on a real campaign

Send an authorized, non-sensitive campaign to controlled recipients through the same campaign route and From address used in production. Use results generated inside the receiving service’s known processing boundary, with its documented handling of externally supplied Authentication-Results, such as stripping or isolating those fields. Ignore untrusted sender-supplied results. A familiar authserv-id or header position alone proves nothing. If that handling cannot be established, use receiver-controlled trace or logs instead. Authentication-Results trust boundary

Capture the visible From domain, smtp.mailfrom, DKIM header.d, selector header.s, and dmarc result. The branded-DKIM acceptance target is dkim=pass with a signing domain aligned to the visible From domain. Completion also requires trusted dmarc=pass for the intended visible From. A DMARC pass through SPF alone is not proof of the intended DKIM setup. A passing shared ReachMail signature alone does not establish that target; a rewritten shared From authenticates that shared identity, not your original brand. Also verify SPF for the actual envelope domain and independently diagnose fail, temperror and permerror even when aligned DKIM already provides a DMARC pass.

DMARC, RFC 9989 passes when either SPF or DKIM passes with alignment. Relaxed alignment generally allows domains sharing the same Organizational Domain; strict alignment requires an exact domain match. Do not weaken adkim=s or aspf=s merely to accommodate the setup. For example, with visible From newsletter@example.com, a passing intended signature using d=mail.example.com aligns in relaxed mode when both share the same Organizational Domain, but not in strict mode. A passing d=example.com aligns in both modes. These are fictional identity examples, not a promise of ReachMail’s envelope domain. DKIM alignment modes

If authentication passes but a campaign goes to spam, investigate consent, complaints, content and sending reputation separately. Authentication cannot guarantee inbox placement.

RFC 9989 requires domains publishing p=reject to apply valid DKIM signatures to their messages. Indirect routes, including mailing lists and forwarding, can still create interoperability problems; test those actual routes rather than assuming a direct campaign pass covers them. RFC 9989 DKIM and interoperability

Retain DMARC protection and arrange useful reporting

Check for an existing applicable policy, including inherited policy for a subdomain, before adding anything. A missing TXT record at one subdomain does not prove that it is unprotected. Keep established quarantine or reject protection while repairing the ReachMail route.

Only when there is no applicable policy, and your domain owner approves an initial monitoring phase, publish one TXT policy at _dmarc for the chosen From domain beginning v=DMARC1; p=none. Add ; rua=mailto: followed by an approved aggregate-report mailbox. The mailbox must exist or be provisioned by your chosen service; for a report destination in a different Organizational Domain from the policy domain, the report-generating receiver must check DNS authorization before sending aggregate reports. A destination within the same Organizational Domain is excepted, so a different hostname alone is not sufficient to call it external. Separately obtain the domain owner’s approval for the aggregate recipient and data sharing; DNS authorization is not privacy approval. See RFC 9990, Section 4. Never copy a report address from an example.

For clarity, an apex From domain of example.com uses the full owner _dmarc.example.com, usually entered as _dmarc in that zone. A From subdomain of news.example.com uses _dmarc.news.example.com: enter _dmarc.news when editing the parent example.com zone, or _dmarc when editing a separately delegated news.example.com zone. These are owner-name examples, not instructions to override an existing applicable policy. Confirm whether your DNS host appends the zone name before saving.

Review legitimate senders before advancing enforcement. RFC 9989 replaced the older DMARC specification and removed pct; do not plan a percentage rollout around that obsolete tag. RFC 9990 covers aggregate reporting; failure reports can expose message data. Do not add ruf without a privacy-approved need and recipient.

Troubleshooting ReachMail authentication

Keep a sanitized receiver header, campaign reference, time, DNS answers and the exact failing indicator for support. Do not remove all domain authentication or revoke a working sender merely to clear one error.