Simplycast SPF, DKIM and DMARC setup, step by step

Use SimplyCast’s Authentication page to obtain the sending-domain instructions, publish the approved SPF and DKIM TXT records, then select the domain and run Check. Test a controlled campaign with that domain selected as its Sender Email Address. A successful record check is not proof that the delivered message retained your From identity and passed aligned DKIM. SimplyCast authentication FAQ.

On this page

• Scope and preparation
• Select the sender and obtain the instructions
• Publish DKIM without damaging an existing selector
• Add SPF at the correct owner
• Handle DMARC separately
• Check DNS and a controlled campaign
• Troubleshooting and recovery
• Frequently asked questions
• Sources and verification limits

Scope and preparation

This guide covers SimplyCast’s documented hosted Email campaign workflow. It does not configure a customer-operated SMTP server, every SimplyCast application, employee mailboxes or an unrelated product named Simply. Confirm the actual Authentication instructions for your account before changing DNS. If they differ or are unavailable, resolve the discrepancy with verified Support instead of guessing.

The public procedure does not establish a universal plan entitlement, region or exact permission role. An authorized account operator must have access to the campaign’s authentication and sender settings, while the domain owner authorizes the service and the DNS administrator publishes the records. SimplyCast says its staff cannot change your DNS records for you.

Choose an owned or controlled domain and an intended accessible sender address. Save existing SPF, DKIM, direct and inherited DMARC policies, campaign identities and a recovery plan. Identify shared selectors, delegated namespaces and other mail services before making changes. Do not change MX, parent nameservers, DNSSEC or credentials to satisfy this guide.

Select the sender and obtain the instructions

The documented account route to sender management is the client number at the upper right → Account Information → Sender Addresses. This is separate from authentication and does not prove a domain has been configured. Do not infer that the account’s separate Domains tab is the DKIM activation control. Account settings reference.

Decide which address the campaign will use, then obtain the corresponding domain information from the Authentication page and provide it to the DNS administrator. The official FAQ documents a native TXT configuration:

Published SPF authorization mechanism: ip4:64.50.144.0/20
Published DKIM selector: mail
DKIM owner for example.com: mail._domainkey.example.com
DKIM record type: TXT
DKIM value: COMPLETE-APPROVED-PUBLIC-KEY-TXT

The last value is an unmistakable placeholder, not a publishable key. Copy the complete current public value, including its tags and uninterrupted key material, from the verified account/provider instructions. The old FAQ contains a full key, but do not assume it remains appropriate for your account or recreate it from a wrapped excerpt. No private key belongs in DNS, a website upload or this setup exchange. Do not generate a replacement key with an unrelated online tool. Documented TXT workflow.

Publish DKIM without damaging an existing selector

For an intended signing domain example.com, the documented selector’s owner is mail._domainkey.example.com. In the example.com zone, the relative name is mail._domainkey. For a signing domain news.example.com, the full owner becomes mail._domainkey.news.example.com: use mail._domainkey.news in the parent zone or mail._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, its administrator publishes relative owner mail there.

Verify the complete owner rather than appending the zone twice. The generic selector name mail can already be used by another provider. Stop on a collision and coordinate a supported selector or transition with the owners; do not overwrite another service’s key, remove a delegation or assume SimplyCast allows arbitrary selector changes.

Publish the complete approved TXT value. Preserve meaningful tags and all key bytes. A DNS interface may split a long TXT into quoted character strings that concatenate into one value; separate TXT records are not a safe substitute for a single key. If the host rejects a required value, resolve its supported input format with the DNS administrator instead of truncating it. DKIM key records.

This documented branch is TXT, not a CNAME. Do not add an alias beside the key, and do not apply HTTP-proxy or CNAME-flattening changes to a TXT-only setup. If the current account issues a different record type, obtain its complete supported instructions rather than silently converting this branch.

Add SPF at the correct owner

SPF evaluates actual SMTP MAIL FROM, or HELO in applicable cases such as a null reverse path, not automatically the visible From address. The FAQ tells customers to authorize SimplyCast at their sending domain; verify the actual envelope identity in delivered messages before interpreting its SPF result or alignment. It does not establish a universal custom Return-Path feature. SPF identities.

The published mechanism is ip4:64.50.144.0/20. Where confirmed by the current account instructions, integrate the authorization into the one existing SPF policy at the required owner. Preserve legitimate senders and intentional qualifiers. The FAQ’s full example also contains a, mx and ~all; these affect authorization or results and should not replace your reviewed policy blindly. Do not publish a second v=spf1 record.

For a policy at example.com, use the DNS host’s documented apex input, often @ or blank, in that zone. For news.example.com, use news in the parent zone or the apex convention in a delegated child zone. Do not confuse a DKIM selector TXT or another verification TXT with SPF. If the intended policy owner is a CNAME, stop and coordinate a supported design rather than adding conflicting TXT.

A literal ip4 mechanism does not itself require an SPF DNS lookup, but other evaluated DNS-dependent terms, including nested evaluation, count against the total limit of ten. Do not call it a ten-include limit. Do not append mechanisms after terminal all; redirect is ignored when all is present. No SPF qualifier guarantees delivery or rejection. SPF mechanisms and lookup limits, redirect semantics.

Handle DMARC separately

Inspect direct and applicable inherited policies before creating anything. Retain existing enforcement, alignment modes and approved report destinations. A new campaign is not a reason to downgrade an existing policy.

Only when there is no applicable policy, the domain owner approves and a monitoring plan is appropriate, an initial policy can use:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none;

For example.com, the relative name in that zone is _dmarc. For a sender domain news.example.com, the owner is _dmarc.news.example.com: enter _dmarc.news in the parent zone or _dmarc in a delegated child zone. Do not duplicate the policy. This minimal example does not itself arrange report collection. DMARC policy location and discovery.

If you add aggregate reporting, obtain approval for the destination and purpose, provision the approved recipient and monitor report receipt. Compare the report URI’s destination-host Organizational Domain with that of the domain where the policy was found, not automatically the visible From domain. When those Organizational Domains differ, the report-generating receiver must check DNS authorization. The same-Organizational-Domain case is excepted, even where the individual hostnames differ. This protocol check does not replace the owner’s data-sharing and privacy decision. Never copy someone else’s report address. RFC 9990 section 4.

Plan enforcement across all legitimate senders, not only SimplyCast. Review reports and forwarding or mailing-list paths before tightening policy. RFC 9989 section 7.4 warns of indirect-flow disruption and requires valid DKIM rather than sole reliance on SPF for p=reject domains. General-user domains whose users participate in mailing lists need that specific risk assessment. Do not use obsolete pct rollout instructions. DMARC interoperability considerations.

Check DNS and a controlled campaign

Compare authoritative and public-recursive DNS answers with the approved instructions. These commands are illustrative, not successful results:

dig @AUTHORITATIVE-NS TXT mail._domainkey.example.com
dig @PUBLIC-RESOLVER-IP TXT mail._domainkey.example.com
dig @PUBLIC-RESOLVER-IP TXT example.com
dig @PUBLIC-RESOLVER-IP TXT _dmarc.example.com

Replace the server, resolver address and full owners with your actual values. The DKIM answer must contain the complete usable public key, not just any TXT. At the SPF owner, confirm one valid policy and distinguish unrelated verification TXT. The FAQ says updates may take up to 24 hours; a wrong owner or collision will not be fixed by waiting.

Select the intended sender domain in the Authentication page’s dropdown and run Check. Resolve individual SPF/DKIM failures. Do not invent an undocumented activation toggle or upload code to a website: the current served FAQ specifies DNS TXT publication and checking. If your account requires an additional supported activation step, obtain and follow its verified instructions before testing. Account check procedure.

For a controlled campaign, the authorized operator opens Email → Dashboard, finds the project and chooses Schedule. Set the approved Sender Email Address, review the intended send time and select only a controlled test list with valid recipients and harmless content. Next opens the Review Checklist; inspect its Authentication item and resolve red errors. A yellow warning being technically bypassable is not a reason to ignore an authentication problem. Complete Project completes scheduling and can send immediately depending on the selected mode. Do not enable unrequested social auto-posting, recurring sends or analytics during a test. Official campaign procedure.

Use the original received headers, not a forwarded body. Repeat for each intended domain and production path; one Email campaign does not validate unrelated applications or API routes. No live campaign was sent for this guide.

Identify results produced inside the receiving service’s known processing boundary and its documented treatment of externally supplied Authentication-Results. Neither header position nor a familiar authserv-id string alone proves authenticity. Ignore attacker-supplied result fields; consult the receiving administrator when provenance is uncertain. Authentication-Results trust boundary.

Require all of the following before approving branded DKIM:

1. The delivered visible From remains the approved intended address, not a provider-owned rewrite.
2. The intended SimplyCast signature is present, with its d= and s= recorded together and trusted receiver dkim=pass for that signature.
3. Its passing signing domain aligns with the intended From under the applicable adkim policy.
4. The receiver records dmarc=pass for that intended From domain.
5. The actual SPF identity and result are recorded, with failures and errors investigated even if DKIM supplied DMARC pass.

Strict alignment requires exact domain equality; relaxed alignment permits the applicable same-Organizational-Domain relationship. A child envelope domain is not strict SPF alignment with its parent. A generic DMARC pass via SPF does not prove branded DKIM. Keep multiple signatures and their outcomes separate. Raw versus aligned DKIM results.

Troubleshooting and recovery

Check cannot find DKIM: compare the complete owner, selector, active authoritative zone and key with the actual account instructions. Resolve selector collisions and wrapped/truncated keys rather than replacing unrelated records.

DNS passes but the intended signature is missing: verify the campaign’s selected Sender Email Address and account/domain configuration. Keep the failed sample and ask verified Support to establish signing activation. Do not accept a provider-owned From rewrite or a different signature as successful branded DKIM.

SPF fails or errors: inspect the actual MAIL FROM and its authorization. A fail differs from transient temperror and persistent permerror, such as malformed syntax, duplicate SPF or too many evaluated DNS terms. Investigate these even when DKIM supplies DMARC pass. SPF results.

A change breaks campaigns or another sender: with affected owners’ approval, pause only the affected send and restore the last known-good approved configuration. Retain keys needed by queued mail and shared authorization. Retest both the failed path and a known-good path, keeping the evidence. Do not weaken DMARC or remove other senders to force a green status.

A recurring campaign still uses old content or settings: the official scheduling guide says recurring campaigns use the content present when scheduled. Review the actual scheduled campaign instead of assuming an edited project changes an existing recurrence. Obtain campaign-owner approval for any scheduling or sender change.

Before launch, confirm audience permission, unsubscribe handling and appropriate sending practices. Authentication is not an inbox-placement guarantee.

Sources and verification limits

The full currently served authentication FAQ, account-settings FAQ and campaign-scheduling instructions were read. Their publication labels are June 26, June 27 and June 1, 2018 respectively. Current retrieval does not make those historical instructions evidence of every present account entitlement, region, key or UI variant.

No account login, sender registration, DNS mutation, actual campaign send, live mailbox test, CMS visual rendering or publication was performed. Complete current account values and any account-specific signing activation remain implementation checks. No decisive account setup screenshots were supplied by the read FAQ bodies; no video demonstration was claimed inspected.