Confirm the Greatmail service in scope
Begin with the order and account owner, not an SPF string found in an old tutorial. Establish whether this change moves hosted mailboxes to Greatmail or only authorizes an outbound service. Record the affected domain, existing mailbox provider, applications sending on its behalf and who can approve changes to receiving mail. This guide's provider-specific installation facts cover Greatmail email hosting; do not silently apply an inbox migration to an SMTP-only account.
Greatmail's hosting support page says its onboarding email supplies the required DNS settings: MX routing plus TXT records for SPF and DKIM. Obtain that instruction set from the account owner or Greatmail support before publishing anything. This guide deliberately does not provide a universal server name, selector or public key. Greatmail hosting DNS requirements
Separate receiving and sending changes
Create two parts in the change record. The receiving part identifies the planned mailbox location and MX cutover. The sending part identifies authorized envelope domains and DKIM signing domains. An organization moving all mailboxes may need both; a limited outbound project must not change receiving mail without separate approval. Save existing public records and service settings before starting.
Compare each supplied DNS owner with its fully qualified result. A DNS editor's shorthand for the zone apex and its treatment of appended domain names vary. Confirm the actual published answer. For a DKIM TXT record, retain the complete public-key value and use the DNS host's documented handling for long TXT strings. Do not truncate a key merely to fit an interface. The public key belongs in DNS; private signing material does not.
SPF requires one applicable policy at an owner. If that policy already authorizes other legitimate services, merge the approved Greatmail authorization into it instead of adding a competing policy. Check the complete lookup cost, including nested includes. Keep a record of which sender justifies each term so future cleanup does not accidentally remove a payroll, billing or support application.
Test both directions when migrating mailboxes
Original acceptance plan: for a mailbox migration, deliver a harmless message from an unrelated controlled account to the hosted mailbox, then reply through the normal user client. Also test each application included in the sending change. A successful webmail login is not evidence that public MX routing or an application relay has changed correctly.
For outbound messages, record the trusted recipient system's authentication results, visible From domain, SMTP envelope domain and each DKIM signing domain and selector. Evaluate DMARC alignment against the visible From domain and its applicable alignment mode. Passing SPF for a different organizational domain does not establish an aligned SPF result. A passing aligned DKIM signature can still satisfy DMARC when the SPF path does not align.
Illustrative case: staff mail succeeds after a mailbox move, but an older application still sends through its previous relay. Removing that relay's SPF authorization immediately may break the application. Identify and migrate or explicitly retain the dependency before cleaning up the policy. Do not interpret one successful mailbox test as a complete sending inventory.
Preserve a usable recovery path
If receiving fails, investigate MX scope and mailbox readiness. If outbound authentication fails, investigate the actual sending route and signing key. Restore the last approved change at the failing layer instead of replacing all DNS records together. Coordinate any MX rollback with the mailbox owners to avoid splitting incoming messages across unattended systems.
Documentation was reviewed on 8 November 2026. No Greatmail account, supplied onboarding values, live DNS record or delivered message was inspected. Account-specific configuration remains required before execution; the test design and example are illustrative operational guidance.
Keep a concrete relay dependency ledger
Written case GM-01 assumes the hosted mailbox user@example.com receives a controlled message and replies with trusted DKIM pass, d=example.com and s=host1. A separate legacy application still uses its old relay with From alerts@example.com, envelope bounce@example.com, and no observed receiver results or signatures. The first route supplies exact DKIM alignment only for that message; it establishes nothing about the application. Retain the old authorization while the application owner confirms its approved replacement and obtains a controlled test. The mailbox administrator owns receiving rollback, and the application owner owns relay migration. These are stipulated teaching facts, not inspected mailboxes, onboarding settings or tests.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.