Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Choose the Loops sending identity deliberately
Loops requires a domain whose DNS records you can configure. Its current setup guide recommends a sending subdomain and explains that no preliminary A or CNAME is needed just to create that subdomain: Loops supplies the required records. Identify the exact account and intended sending domain before changing DNS. A free hostname under a hosting platform is not an interchangeable substitute when you cannot publish the required records. Loops domain setup.
Assign the application owner to identify production mail paths, the email owner to approve sender addresses and the DNS administrator to preserve existing services. Inventory campaign, workflow and transactional messages that the organization intends to send. A successful editor preview cannot establish that an application-triggered transactional message uses the same identities. Keep those paths separate in the acceptance plan even if they currently share one configured domain.
Publish the generated records without replacing inbox DNS
From Settings, then Domain, open View records. Copy the displayed owner, value and DNS type for each item; use the type, such as TXT, CNAME or MX, rather than the human label SPF or DKIM when entering it at the DNS provider. Loops places its SPF record at an envelope subdomain and provides a Verify Records action. Its Cloudflare instructions require the CNAME records to be DNS Only. Account domain records.
Do a record-by-record review before saving. Record the full expected hostname and how the DNS interface appends the zone name, so a relative name does not become a doubled domain. Check whether each owner is already in use and preserve the existing value in the change log. If importing a zone file, review its contents and intended changes rather than treating an import as permission to replace unrelated records. The necessary records must correspond to the selected account, not another team's setup screenshot.
The provider's DNS explanation distinguishes the Loops envelope MX, used for delivery feedback, from the MX records that receive ordinary inbox mail. It also notes that Loops uses randomized DKIM selectors, so probing a short list of common selector names cannot establish that the account's DKIM is absent. Use the exact names on the domain records page. Loops DNS checker explanation.
This separation is an important recovery boundary. Do not replace corporate root MX records while configuring an envelope subdomain. If a DNS provider's mail preset must be changed, first capture and preserve the working inbox configuration with its owner. Stop for clarification if the interface cannot express the required record at the intended subdomain. A provider-specific workaround needs validation, not an improvised root-domain substitution.
Keep From and replies distinct
Loops' sending settings describe a From field combined with the configured sending domain, plus an optional Reply address. If Reply is blank, replies go to From. Review those settings on the messages being tested and make sure a monitored mailbox receives responses where the business flow requires one. New messages inherit the most recently used From address, so review it rather than assuming a neutral default. A working Reply address does not authenticate the From domain. Loops sending settings.
Treat any sender change as a user-facing change as well as a DNS change. Confirm the address the recipient sees, the destination used when replying and the application workflow that selected the template. For a transactional test, use a harmless controlled event rather than a real customer's reset link or financial document. For a marketing test, restrict the audience to approved test recipients and confirm that restriction before sending.
Read the protocol results rather than inferring success
SPF evaluates the SMTP envelope domain. Loops' separate envelope record does not require a second SPF policy at an unrelated root owner; however, an already-used envelope owner still needs conflict review. Maintain one applicable policy per owner and apply RFC 7208 §4.6.4’s ten evaluated DNS-causing-term limit, including nested evaluations. Record the receiver's actual SPF identity and result instead of assuming it from the account's sending-domain label. SPF specification.
For DKIM, compare the received d= signing domain and s= selector with the published records. DMARC needs an aligned passing DKIM signature or an aligned passing SPF result. An envelope subdomain's relationship to From must be assessed under the actual alignment mode, especially when strict SPF alignment is configured. Preserve an established DMARC policy and reporting arrangement; do not overwrite it with a default setup example without a domain-wide review. DKIM and DMARC.
Verify each production path and retain a rollback
Run Verify Records, then inspect a received message from every materially different workflow or From domain. The original acceptance matrix proposed here should contain account, workflow or template identifier, send time, From, Reply-To, Return-Path, SPF identity/result, all DKIM d=/s= pairs and results, DMARC result, relevant DNS answers and restricted evidence location. Record DNS verification and message verification as separate columns. Green DNS checks do not demonstrate inbox placement or correct application triggering.
If a row fails, compare the exact queried hostname, DNS type and target before republishing. Check application/template selection and signature identities next. Pause the affected mail path or retain its previously approved provider while investigating; restore only the changed records if rollback is required. No account, live DNS or received-message test was performed here. Exact-route confirmation, original identity-table evidence and human SME approval remain required before production or publication acceptance.