Separate permission to send from authentication
ReachMail has two distinct domain checks. Sending-domain validation confirms permission to use an address domain in campaigns. Domain authentication connects the outbound mail to DNS-based evidence. Completing an emailed verification link does not prove that a subsequent campaign will carry an aligned SPF or DKIM identity.
Choose the owned domain and intended From address before changing settings. ReachMail's validation guide excludes free webmail domains such as Gmail, Yahoo and AOL for this use. Record the business owner, reply mailbox and account responsible for each brand. Keep different client or brand domains separate rather than assuming one approval extends to the rest.
The getting-started checklist says default DKIM, SPF and tracking use ReachMail-managed shared domains. This explains why basic authentication may already exist without proving alignment to the organization's visible From. The acceptance goal is a controlled message using the intended customer identity, not simply a statement that the platform signs its mail.
Validate the campaign domain
The documented validation path is Account, Campaign Settings, Sending Domains. A verification email is sent to an address at the selected domain, and its confirmation link completes that step. Use a mailbox the organization controls and record the approval outcome. If the message is missing, investigate delivery to that mailbox rather than repeatedly adding new domains.
ReachMail's validation instructions also describe a padlock indicating whether a DMARC policy is detected. Treat that as a policy-presence indicator. It is not a received-message result, an assessment of every authorized sender or proof that the campaign's authenticated domains align.
Check the actual From and reply address on the mailing to be tested. A saved default and the identity selected on an existing campaign can differ, so verify the final object before sending. Obtain approval before revoking a domain used by active campaigns. Cleanup should not unexpectedly remove the sending identity needed by a scheduled business message.
Generate the authentication instructions for the right domain
The DKIM installation guide directs administrators to the Account tab, Campaign Setting and Domain Authentication, then to add the domain and applicable subdomain. Its setup page presents SPF, DKIM and DMARC instructions. Capture the exact values issued for the selected account and domain.
Create a DNS change sheet listing each complete owner, record type, value and purpose. Confirm whether the DNS editor expects a short label or full domain name. Preserve existing records at those owners and resolve conflicts before replacement. The public guide explains the workflow; it does not provide a universal key to copy into every customer's zone.
The DKIM instructions identify the record and TXT-key data to publish, followed by Check Current DNS. ReachMail advises waiting at least ten minutes before rechecking. Treat that as the provider's minimum guidance, not a promise that all caches or application checks will update by a fixed deadline. Compare the authoritative answer, relevant TTL and expected value before repeating a change.
Merge SPF carefully and retain DMARC ownership
ReachMail's SPF instructions display an existing record and the required addition, and warn against removing existing authorizations. Interpret this as updating the one SPF policy at the intended owner, not creating another separate SPF policy. Preserve the legitimate services that still need to send.
RFC 7208 defines SPF record selection and the ten-term limit for DNS-querying mechanisms and modifiers during evaluation. Review nested includes and redirects, not just the number of visible include terms. If the proposed combined policy exceeds the limit or has unclear dependencies, resolve that design before rollout.
SPF is evaluated against the SMTP identity, normally the MAIL FROM domain, not merely the visible From address. A root-domain addition alone does not prove that ReachMail uses an aligned customer envelope. The reviewed setup pages do not establish your account's custom-envelope behavior; keep that claim pending until current provider instructions and a real header confirm it.
Inspect the existing DMARC record before applying a suggested value. Preserve its approved policy, alignment modes and reporting destinations. A campaign setup wizard should not silently replace a security decision shared by all senders on the domain. Any change to enforcement needs the domain owner's review and evidence from other legitimate routes as well.
Test the campaign that will actually be sent
Record the Domain Authentication status and public DNS answers after publishing. Then send a harmless campaign to a small controlled list. Verify that the campaign uses the intended From rather than an old default. Include an internal recipient as a separate case if employee announcements are part of the route.
Save Message-ID, UTC time, From, Return-Path, all DKIM signing domains and selectors, and trusted receiving-system results. RFC 6376 defines the DKIM d= and s= identifiers. Inspect every signature: a passing shared-domain signature may coexist with a customer-domain signature, and the latter needs its own result.
DMARC's current specification requires an aligned passing SPF or DKIM identity. Record which observed mechanism supplies the pass and which alignment mode applies. A customer-domain DKIM pass may establish DMARC even when the envelope remains provider-owned, but provider setup requirements still need to be met.
Record authentication and placement separately. Delivery to junk can occur despite an aligned pass, and a message accepted because of a local exception may conceal an unverified route. If no copy arrives, correlate campaign activity and bounce information before altering DNS. Repeating the full audience send is not an appropriate diagnostic test.
ReachMail acceptance worksheet
Complete one row per campaign domain and relevant sending route:
- Account, brand, business owner and intended From: ____.
- Sending-domain verification mailbox and completion time: ____.
- Campaign identity and reply address checked: ____.
- Account-issued SPF, DKIM and DMARC instructions: ____.
- Complete DNS owners, value references and existing conflicts: ____.
- Combined SPF policy review and retained DMARC policy: ____.
- Public DNS answers and Check Current DNS outcome: ____.
- Message-ID, UTC time, Return-Path and all DKIM identifiers: ____.
- Trusted authentication results and actual aligned mechanism: ____.
- Recovery action, release reviewer and future recheck trigger: ____.
A verified domain or closed padlock cannot fill the message-evidence fields. Leave the route pending until the intended campaign has been received and checked.
Fictional diagnosis of a misleading green indicator
Fictional example only: Maple Studio verifies its sending domain and sees a closed padlock. The team assumes custom authentication is complete. A controlled campaign shows only a shared signing domain and an unaligned envelope, so DMARC fails for the studio's visible From.
The administrator opens Domain Authentication, retrieves the account-issued customer DKIM instructions and completes the approved DNS change. A fresh campaign is checked for its actual signing domain and aligned result before broader sending resumes. The existing DMARC policy remains in place. No Maple account, domain or message was inspected; this is an illustrative distinction between approval, policy presence and message authentication.
Maintain the approved domain inventory
Recheck after sender-domain changes, DNS moves, account migration or key replacement. Review scheduled campaigns before retiring a verified identity or delegated record. Live tenant inspection, account-specific values, DNS and received-message evidence, custom-envelope confirmation, visual review, human SME approval and publication remain pending. This guide addresses ReachMail marketing campaigns; separate relay products require their own current instructions and tests.
Record which green indicator was checked
Use separate worksheet fields for emailed domain approval, detected DMARC policy, DNS authentication status and received campaign alignment. Record the campaign identifier beside the last item. The fictional example stipulates no aligned passing mechanism; it does not prove that an unaligned envelope alone always causes DMARC failure, because aligned DKIM could still supply a pass.
Separate message acceptance from policy rollout
A passing aligned SPF result can satisfy a message evaluation, but does not alone justify moving an entire domain to reject. RFC 9989 Section 7.4 requires valid DKIM for domains publishing p=reject and warns about indirect-mail interoperability. Inventory all legitimate senders and indirect routes before the policy owner approves enforcement. No DNS change, tenant operation or received-message test was executed for this article.