Identify every way the domain sends
Simply.com can host a mailbox, a website and DNS, but those roles do not make every application using the domain follow the same mail path. Start with a route inventory: webmail, a configured mail client, a website contact form, an order notification and any external service. Note where the application runs, which server it submits to and the visible sender the business expects.
This guide covers the routes named in Simply.com’s public mail documentation. It does not extend the provider’s signing promise to an unrelated newsletter platform, a server hosted elsewhere or a script using another transport. Existing accounts also need inspection; a documented default for new hosting plans is not evidence that an older or externally managed zone has the same records.
Review the documented records without overwriting the zone
Simply.com’s authentication guide lists the SPF authorization include:spf.simply.com and two DKIM CNAMEs: simplycom1._domainkey to dkim1.simply.com, and simplycom2._domainkey to dkim2.simply.com. Its SPF example assumes mail is sent only through Simply.com. It names webmail, websmtp.simply.com and smtp.simply.com on port 587 as signed routes.
Treat those as documented public values, not observed records for your domain. Export the current zone before making an authorized change. Identify the authoritative DNS provider and confirm the owner format its interface expects. If it appends the domain automatically, prevent a doubled suffix. Compare the published result with the required fully qualified name rather than relying on the visual appearance of a form.
For SPF, inventory other legitimate services before changing the policy. RFC 7208 describes the single-policy selection rules and DNS lookup limit. Review the combined evaluation, including nested includes, rather than counting only the terms visible at the top level. Preserve existing service permissions unless their owners have confirmed retirement.
Make website mail use the intended transport
The script-mail guide describes authenticated submission to websmtp.simply.com on port 587, with STARTTLS support, for scripts on Simply.com’s web servers. It distinguishes that route from PHP mail() and restricts the service from use as a general client or externally hosted relay. It also cautions against treating it as a large-volume bulk platform.
Check what the running application actually does. A mail plugin can be installed but disabled, overridden by another plugin or bypassed by a particular form. Record the application, effective transport and responsible maintainer. A successful password-reset notification does not necessarily validate a commerce extension that sends through a different library.
Use the organization’s approved credential-management process for any later configuration. Do not put passwords in the worksheet, DNS, screenshots or support examples. This draft does not log in, install plugins, change application settings or transmit credentials.
Review hosted DMARC policy as a separate decision
Simply.com documents a default _dmarc CNAME to dmarc.simply.com and describes reject as its standard policy. Inspect the current owner and its effective answer before deciding whether the organization should retain provider-managed policy or manage its own. An externally hosted zone may differ, and an existing custom policy may include reporting or alignment settings the business needs.
Do not add a TXT record beside an existing CNAME at the same owner. If an approved change replaces the alias, record the old answer, intended new policy, reporting destination and recovery procedure. Confirm the reporting recipient and any required authorization before transmitting reports to a new destination. This is domain-policy work, not a necessary side effect of checking two signing records.
DKIM authenticates responsibility by a signing domain, not the identity or authority of the individual human author. Provider explanations sometimes compress policy and delivery into simple promises. Use RFC 9989 for the protocol interpretation: alignment matters, and receiver handling is not a guarantee that every legitimate message reaches an inbox or that every phishing message disappears. Keep authentication acceptance and recipient placement as separate measures.
Verify both selectors and the active signature
A provider may publish more than one selector for operational reasons. Confirm that both documented CNAMEs exist as expected, without assuming which one a particular message must use. From a controlled received message, capture every DKIM signing domain and selector. RFC 6376 defines how those fields identify the verification key.
If a signature fails, separate DNS resolution, unexpected signing identity and message modification. If no expected signature appears, investigate the submission route before replacing keys. A form using an unintended transport will not become the documented signed path merely because the domain has valid CNAMEs.
Capture the envelope sender as well. The reviewed Simply.com sources do not establish a universal user-configurable custom Return-Path feature. Do not infer one from a mailbox address or a reply destination. Record the observed identity and the mechanism supplying alignment.
Keep forwarded messages in a different test group
Simply.com’s forwarding guide warns that external forwarding can be unreliable because the onward path can affect SPF or DKIM. A forwarded message therefore cannot be used as the sole test of the original outbound route.
First test direct delivery from webmail and the application paths. If forwarding is a business requirement, add it as a separate row with both the original and final receiver observations. Investigate whether the relevant signature survives and what identity the final receiver evaluates. Do not broaden the original sender’s SPF permissions simply because a later forward changes the sending server.
Use the route coverage worksheet
The Simply.com mailbox and website worksheet (create a separate review record with the fields described here) includes a row for each transport, the effective DNS policy, the current signing selectors and the final receiver results. Keep controlled message identifiers and observation times with the DNS evidence. Record a separate result for each application rather than writing “website mail passed” after one sample.
A route is ready for approval when the business owner recognizes the sender and reply behavior, the mail administrator can identify the aligned passing mechanism, and the recovery owner can explain how to reverse the specific change. Unobserved fields remain pending.
Fictional diagnostic case involving a contact form
Fictional written case only: SCOM-01 stipulates webmail From help@repair.example with passing d=repair.example. The contact form intends the same From but runs PHP mail() instead of the documented authenticated script submission route; its DKIM and SPF results are unknown. The application maintainer must inspect the effective transport, propose a supported correction and test the form separately. Order notifications remain a third untested route. No application settings, credentials, DNS or messages were accessed.
Recover and maintain route specific evidence
Before a rollout, preserve the previous DNS and application settings and agree who may restore them. If a changed form loses mail, pause that application change rather than weakening the domain policy for every sender. Avoid deleting a selector while existing messages or another configured route may still use it.
Retest after hosting moves, mail-plugin changes, SMTP changes, new external senders and DMARC-policy changes. This is an unpublished documentary draft. Account inspection, live DNS, received-message evidence, original-scope acceptance, visual review and human SME signoff remain pending.
Separate a passing message from enforcement readiness
RFC 9989 Section 7.4 requires valid DKIM for a domain publishing p=reject and cautions about indirect-mail interoperability. A single aligned SPF result does not by itself justify a reject-policy rollout. Review all legitimate routes and policy ownership separately from this provider setup.