Choose the product before editing DNS
TinkMail's personal-domain documentation describes custom domains as a Pro feature. Its business guide uses account-provided values and placeholders. Do not apply the personal sending pool to a business workspace by assumption. Confirm the product, intended From domain, DNS owner and whether moving inbound mail is part of the authorized project. This guide has not tested a TinkMail account.
Personal custom-domain procedure
Add the domain in Settings > Domains and use the resulting DNS table. The personal guide specifies promx1.tinkmail.me and promx2.tinkmail.me with priorities 10 and 20; SPF includes prospf.tinkmail.me and requires ~all. Copy the domain-generated DKIM host and public key, then run Check DNS. Activation depends on MX, SPF, DKIM and DMARC matching. The published DMARC example uses strict alignment and p=none. Reconcile those requirements with existing policy rather than adding duplicate records. The exact personal-domain source is below.
Business-domain procedure
The business page's SPF include and DKIM key are placeholders, not production values. Obtain the real include, selector and public key from the account manager, and get help merging existing SPF. Treat missing account data as a setup blocker. Do not substitute a guessed hostname, the personal pool or a fabricated key.
Original migration acceptance design
Separate inbound cutover from outbound authentication in the change ticket. A personal-domain activation checklist that includes MX can affect where new mail is delivered. Before changing MX, inventory existing mailboxes, aliases and recovery access; preserve the prior destinations. Obtain a specific inbound migration decision instead of treating MX as a harmless authentication record.
The acceptance design has two product branches and no observed data. In the personal branch, collect the dashboard's expected and live values and a newly sent custom-domain message. In the business branch, first record the account manager's actual values and product scope, then perform the same receiver checks. Use a test alias with harmless content. With strict alignment, a parent domain and its subdomain do not count as identical. Confirm the signed d= value and envelope domain rather than weakening policy merely to make a status indicator green.
Prove the identity at the receiver
Use a controlled external mailbox and send through the production workflow, with harmless content and no customer data. Save the raw message, timestamp and the receiving system's Authentication-Results. Ignore authentication assertions inserted by an untrusted sender. Record the visible From domain, Return-Path or authenticated envelope identity, and every DKIM d= and s= pair. A display name or Reply-To address is not the DMARC identity.
SPF pass authorizes the connecting server for the evaluated envelope identity. DKIM pass validates a signature for its signing domain. DMARC needs a passing method whose domain aligns with the visible From: strict alignment requires the same domain; relaxed alignment permits the applicable organizational-domain relationship. A provider-owned signature can pass without authenticating your visible From. One passing aligned DKIM signature can satisfy DMARC even when another signature fails. These protocol rules come from RFC 7208, RFC 6376 and RFC 9989, listed below.
Check authoritative DNS before diagnosing caches. Ask an authoritative server for the exact name and type, then compare a recursive resolver after its cached lifetime. For DKIM, follow any CNAME to its public-key TXT response. Never publish a private key. Keep one SPF policy at each evaluated name and check the ten DNS-lookup-causing-term limit across nested includes. Do not replace a shared SPF policy with a provider example.
Recovery and acceptance
Pause the affected workflow if tests show a new regression. Compare the changed record with the saved version and undo only that change after checking other senders. Recheck DNS and resend after recovery; reverting a value does not flush every resolver immediately. Keep old DKIM verification records available while previously signed messages may still be in transit, unless a security incident requires revocation.
Accept the change only when DNS, application state and a real received message agree. Record the flow owner, evidence timestamp and next review trigger. Inbox placement alone is not proof of authentication, and successful authentication does not guarantee inbox placement. Do not tighten a shared domain's DMARC policy on the strength of one provider's test. Inventory the other legitimate sources first.
Stop a business rollout with missing account values
Written case TM-01 assumes a business workspace intends support@example.org. The only available reference contains YOUR_PROVIDED_KEY and _spf.example.com placeholders; the current mailbox provider still receives inbound mail. No actual business selector, include or migration approval has been supplied. The workspace owner must obtain its issued records and the mailbox owner must separately decide any inbound migration. Do not substitute the personal prospf/promx pool, publish a placeholder or downgrade the existing DMARC policy. All DNS and receiver outcomes remain unknown. No account, mailbox or DNS operation occurred.
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.