Simply.com SPF, DKIM and DMARC setup, step by step

For Simply.com sending, the current SPF authorization is include:spf.simply.com. The provider documents two DKIM CNAMEs, simplycom1._domainkey and simplycom2._domainkey, for mail through webmail, websmtp.simply.com and smtp.simply.com on port 587. Preserve any existing DMARC policy before applying a DNS preset. Simply.com authentication instructions.

The important distinction is transport: a website can use the same domain as a working mailbox while sending through a different, unsigned path. This guide explains what to publish, how to handle the hosted DMARC policy, and how to prove that each route authenticates.

Identify the routes before applying a preset

List webmail, desktop or mobile mail clients, website contact forms, order notifications and external marketing tools separately. For each, record the visible From domain, actual SMTP service, envelope sender domain, current DKIM signing domain and application owner. Do not infer outbound settings from the inbound MX record.

You need access to the authoritative DNS zone, Simply.com Mail Administration where relevant, application SMTP configuration and an independent receiver mailbox for testing. Export the existing zone first. Preserve TTLs, all legitimate sender authorizations, DKIM selectors, current DMARC and delegated subdomain settings. Registration at Simply.com does not establish that its DNS editor controls the public zone.

Decide what the domain actually uses. Mail submitted directly to an external newsletter provider needs that provider’s authentication. An external VPS or cloud application should not assume that the website-only SMTP service is available to it. An old Unoeuro-era setup deserves an inventory of active selectors and messages, not a blind replacement based on an old tutorial.

Publish the current Simply.com records safely

The official baseline for an otherwise Simply.com-only sender is:

TXT at the sending domain:
v=spf1 include:spf.simply.com -all

CNAME owners relative to your domain:
simplycom1._domainkey -> dkim1.simply.com
simplycom2._domainkey -> dkim2.simply.com

Simply.com’s DNS Administration offers a “Simply.com DKIM & SPF” setup. Its documentation says new webhosting plans receive standard authentication records automatically. Review the existing zone and the preset’s proposed changes before using it. These two CNAME targets are provider-published values, unlike tenant-generated keys at some other services. For other senders, retrieve their actual account-generated records separately. Official record values and setup.

Apply only the records needed for your actual route. Do not replace incoming MX records, website addresses or unrelated verification TXT records as a side effect of fixing outbound authentication. In a DNS editor that appends the zone, enter just simplycom1._domainkey and simplycom2._domainkey; confirm the resulting full owners. Keep authentication CNAMEs DNS-only, not HTTP-proxied. A CNAME cannot coexist with a TXT record or another conflicting value at the same owner.

For child-domain sending, confirm the actual accepted sender domain and map its records to the authoritative zone. These are illustrative owners, not a claim that any child domain was configured:

Map simplycom2 in the same way. Preserve existing NS delegations and coordinate with their operators. The provider’s public CNAME targets remain unchanged; do not generate replacement private keys or copy another sender’s key.

Required CNAME answers must stay DNS-only and unflattened. In Cloudflare, switch the affected record’s Flatten control off where available and ensure applicable zone-wide settings preserve the literal alias. Flatten-all overrides per-record choices: coordinate shared changes rather than disabling features indiscriminately. Mandatory apex or same-zone flattening may have no off switch. If required answers cannot be preserved, stop and arrange a supported configuration. Do not remove delegations or change DNSSEC to work around it. Cloudflare flattening controls and verification behavior

Merge SPF at the identity the receiver evaluates

SPF authenticates the envelope MAIL FROM domain, or HELO in applicable cases such as a null reverse path. SPF identities Compare the delivered Return-Path and the receiver’s smtp.mailfrom result with the domain where you plan to edit DNS. The visible From address alone is insufficient. Root SPF does not automatically apply to a sending subdomain.

Keep one SPF TXT policy at each evaluated owner. If another legitimate service already sends there, reconcile its authorization with Simply.com’s rather than adding a second v=spf1 record. Any all mechanism makes redirect ignored, irrespective of qualifier. Preserve redirect-only control flow rather than appending all or combining complete policy strings. SPF precedence Preserve the intended final qualifier; do not weaken -all simply because another tutorial uses ~all.

The maximum is ten evaluated DNS-querying terms across nested policies: include, a, mx, ptr, exists and redirect. ip4, ip6 and all do not consume that term budget. Exceeding it produces permerror. Count the evaluation path, not just the number of includes visible in the editor. SPF specification, RFC 7208.

For an external platform using its own unrelated bounce domain, adding an include to your root will not by itself make SPF align. Configure that platform’s supported custom bounce identity where appropriate, or establish aligned DKIM through its own setup. Keep the route evidence separate from Simply.com’s mailbox tests.

Make website scripts use the supported submission route

Simply.com documents websmtp.simply.com on port 587 with authentication, supporting STARTTLS. Credentials are a mailbox created in its Mail Administration. This server is for scripts running on Simply.com web servers, not ordinary mail clients or applications hosted elsewhere. The provider warns against relying on PHP mail() for authenticated delivery and discourages bulk use of this website service. Outgoing mail server for scripts.

Configure your CMS’s SMTP transport or a maintained SMTP integration, using secure credential storage and an owner-approved transport change. Keep passwords out of DNS, screenshots and worksheets. Do not disable antivirus or antispam merely to follow a bulk-bounce example. Use a controlled domain address as From and the visitor’s address as Reply-To. Do not put the visitor’s unrelated email domain in From and expect your DNS records to authenticate it. Check that password resets, contact forms and checkout emails all use the intended transport; they may have separate settings.

A successful SMTP login proves access to submission, not DMARC alignment. After saving the application settings, generate fresh messages and inspect the receiver results. If the website moved to another host, revisit its SMTP route instead of repeatedly retrying the website-only endpoint. Bulk campaigns should use an appropriate sending service with its own authentication and operational controls.

Treat hosted DMARC as a separate policy decision

Simply.com documents _dmarc as a CNAME to dmarc.simply.com and describes its standard policy as p=reject. If that managed policy already exists, inspect its resolved value before making changes. Do not add a TXT policy alongside the CNAME. A custom TXT policy is an alternative, not an additional record at that owner. Simply.com DMARC configuration.

Keep existing protection and reporting intact. If you need custom reporting or different approved policy parameters, export the existing value, resolve the managed target, and plan a deliberate replacement with one TXT policy preserving the intended enforcement. Do not default an established reject policy to p=none. Review subdomain and inherited policy effects before deciding that an absent exact-owner record means no policy applies.

DMARC passes with either an aligned SPF pass or an aligned DKIM pass. For example, with visible From help@example.com, a passing intended DKIM signature with d=news.example.com aligns in relaxed mode, assuming the same Organizational Domain, but not strict mode; d=example.com aligns in either mode. These hypothetical identities are not measured Simply.com results. Relaxed alignment allows the same organizational domain; strict alignment requires the exact From domain. aspf and adkim control those identity comparisons. Authentication and policy disposition do not guarantee delivery: receivers can still reject or filter mail for other reasons. RFC 9989.

For a genuinely new policy, inventory all senders and arrange monitoring before enforcement. p=none without rua does not arrange aggregate reporting. Choose a report destination you control or have approved, and apply the reporting authorization rule below separately from the domain owner’s privacy decision. Aggregate reporting, RFC 9990. Do not use obsolete pct as a percentage rollout mechanism; current RFC 9989 removed it. Avoid enabling failure reports by default, because they may expose personal data and message content. Failure reporting, RFC 9991.

First DMARC policy when no policy already applies

Use this procedure only after confirming there is no direct or applicable inherited DMARC policy at all for the From domain, including p=none, with domain-owner approval of the monitoring plan and no managed _dmarc CNAME. An existing Simply.com managed CNAME is already a policy arrangement: retain its enforcement and do not replace it with this example or add TXT beside it. Edit an existing policy rather than creating a duplicate. A monitoring policy is a starting point for a reviewed rollout, not a replacement for established enforcement.

• For From addresses at example.com, create a TXT record at _dmarc.example.com. In the example.com zone, the relative Name is _dmarc.
• For From addresses at news.example.com, the full owner is _dmarc.news.example.com. In the parent example.com zone, use _dmarc.news; in a separately delegated news.example.com zone, use _dmarc instead.
• Confirm your editor’s resulting full owner and publish this minimal value only for that genuinely new policy:

v=DMARC1; p=none

To request aggregate reports, first provision an approved reporting mailbox or service, then append a semicolon-separated rua tag with its actual destination. For example, the suffix ; rua=mailto:dmarc-reports@example.com is illustrative, not a working destination to copy. When the report destination has a different Organizational Domain from the policy domain, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain is excepted; a different hostname alone does not trigger this requirement. Obtain the reporting service’s issued authorization rather than guessing it. RFC 9990 section 4 This protocol check is separate from owner approval to share reports: review the recipient, privacy, access and retention. Validate the single published policy and arrange a report review before any move to enforcement.

Verify both selectors and the effective policy

Replace example.com, bounce.example.com and ns1.example.net with your real names. The Simply.com targets below are published service values; the example customer names are placeholders. These commands only read DNS.

dig +short NS example.com
dig @ns1.example.net example.com TXT +noall +answer
dig +short TXT bounce.example.com
dig +short CNAME simplycom1._domainkey.example.com
dig +short CNAME simplycom2._domainkey.example.com
dig +short TXT dkim1.simply.com
dig +short TXT dkim2.simply.com
dig +short CNAME _dmarc.example.com
dig +short TXT _dmarc.example.com

Expect one SPF policy at the actual envelope owner. Both DKIM CNAME owners should point to the documented target, with a usable public key reachable at each target. Multiple component strings in a DKIM TXT answer concatenate without inserted spaces into one logical record, not separate keys; preserve the complete tagged value. DKIM TXT representation Read the effective DMARC policy through the CNAME if you retain the managed setup. For a custom policy, verify one TXT record and no conflicting CNAME.

Compare authoritative answers with a public recursive resolver. A stale cached answer can remain until its TTL expires. If authoritative DNS is wrong, waiting does not repair a misspelled owner, duplicated suffix or edit made in a non-authoritative zone. Save the observed values and time rather than recording only “DNS passed.”

Accept the setup using receiver-generated evidence

Send a new webmail message, a mail-client message and each important website message to an independent mailbox you control. Inspect the original headers, not just the inbox’s sender display. Trust the final receiving system’s own Authentication-Results; a message can contain untrusted upstream copies. Establish the actual receiving processing boundary through provider documentation or the mail administrator, including how externally supplied results are removed or isolated, or obtain an authenticated receiver trace. Header position and a matching authserv-id alone are not proof. Keep acceptance pending if provenance is unclear. RFC 8601.

For each route, record the From domain, Return-Path, spf, smtp.mailfrom, dkim, header.d, dmarc, header.from and the signature’s s= selector. Require the intended Simply.com signature itself to pass and align with the intended visible From under the active policy, plus trusted receiver dmarc=pass. SPF-only DMARC success does not prove branded DKIM works. Reject a rewritten provider From as successful authentication of the intended brand. Diagnose SPF fail (authorization mismatch), temperror (temporary evaluation/DNS issue) and permerror (invalid policy or evaluation limits) separately even when DKIM makes DMARC pass; do not add unrelated root includes to mask the wrong envelope. Confirm the active selector resolves correctly, while retaining both documented selectors for the provider’s signing setup.

Do not call the entire domain complete because webmail works. Test application mail independently and keep forwarded messages in a separate group. Forwarding may change SPF’s evaluated path; signed content changes may break DKIM. Simply.com warns that external forwarding can be unreliable. Do not enable forwarding or change recipients merely to test authentication; use the owner-approved route. A successful direct message therefore does not certify every forwarding chain. Repeat the evidence collection after changing transport, DNS provider or sending service.

Troubleshooting Simply.com mail

• Webmail passes but a contact form fails: inspect the form’s transport. A correct DNS preset cannot move PHP mail onto the supported SMTP path.
• Website SMTP fails after migration: confirm whether the application still runs on Simply.com web servers. The website endpoint is not a general external relay.
• A tutorial shows unoeuro._domainkey: compare it with current official instructions and the selector in a recent signature. Add the current supported records after review; do not delete an old selector until you know no active traffic depends on it.
• DMARC TXT will not save: check whether _dmarc already has the managed CNAME. Decide between managed and custom policy rather than forcing both into DNS.
• DKIM passes but DMARC fails: the signature may belong to an unrelated domain. Compare header.d and From under the active alignment mode.
• SPF shows permerror: check duplicate SPF records and the nested term budget before adding another include.

Related authentication guide

Read EmailAuth’s raw DKIM results versus aligned DKIM policy results when a signature passes but the domain policy does not. External services still require their own account-specific configuration.

Before adopting or retaining reject enforcement, assess all legitimate routes and indirect-mail behavior. RFC 9989 section 7.4 requires valid DKIM signatures for domains publishing p=reject; one SPF-aligned sample is not domain-wide readiness evidence. Interoperability requirements

If a changed application loses mail, pause that change and restore only its approved known-good configuration after comparing the saved baseline. Preserve keys and aliases needed by other routes or queued messages. Retest direct message authentication and reply handling after restoration. No live account, DNS or received-message acceptance has been performed here.