Webcas SPF, DKIM and DMARC setup, step by step

To authenticate mail from WEBCAS email, obtain the SPF instructions for your actual sending service, generate the public DKIM record in the supported WEBCAS administration screen, publish it at the correct DNS owner, and select the corresponding author-domain signature for the intended sending task. A WEBCAS third-party signature is not the same as authenticating your own From domain. Finish by checking a controlled message sent through that exact task, not just the DNS record or task dropdown.

This guide covers an existing WEBCAS email cloud account whose controls match the current published cloud instructions. It does not cover the on-premises/package edition, WEBCAS mailcenter, formulator, DB creator, or an unrelated SMTP relay. Those products have different settings and cannot safely inherit an email-product recipe. WEBCAS publishes separate deployment notices; confirm that the instructions and controls apply to your account before changing anything.

The current cloud notices include changes dated April 23 and October 22, 2026. This is a documentary setup guide, not a claim that your account, DNS or delivered messages have been tested. See the current cloud release instructions and WEBCAS product-specific authentication guidance.

Before starting: identify the product, domain and task

Have the email service owner and DNS owner agree on the exact WEBCAS account, schema, From address, sending task and change window. Use an existing authorized account with access to the documented administration controls. If the controls are missing, ask the account administrator or WEBCAS to establish the applicable deployment and permissions; do not substitute instructions from another WEBCAS product or broaden your permissions as a troubleshooting shortcut.

Record the current task's signature selection and the existing DNS records before making a change. Identify other tasks or systems using the same domain and selector. Existing keys may still verify queued or recently sent messages, so do not replace or delete a working selector simply to make your screen resemble a tutorial.

Confirm which DNS service is authoritative for the exact record owner. A parent domain, a separately delegated sending subdomain and a delegated _domainkey namespace can have different authorities. Keep existing NS delegations, inbound MX routing, DNSSEC and unrelated records unchanged. The DNS panel where you registered the domain is not necessarily the panel that currently serves its records.

WEBCAS supports using the customer's From address, while its support explanation says SPF configuration is supplied individually. That same page explains that the optional custom-domain feature concerns personalized click-tracking URLs. Do not purchase or reconfigure tracking just to authenticate the From domain.

SPF: use the email service's actual instructions

Obtain the SPF instructions for your current WEBCAS email service and sending route. Do not copy the include:webcas.net example from a neighboring product section: in the cited cloud notices, that example is attached to formulator and DB creator, not a universal WEBCAS email policy.

SPF authenticates the SMTP envelope sender, normally the MAIL FROM domain, rather than automatically authenticating the address readers see in From. Where applicable, an empty MAIL FROM uses the HELO identity. Establish the actual envelope domain from the provider's instructions and a received message. If WEBCAS controls that domain, the provider may control its SPF; adding a record at your visible From domain does not by itself change the envelope identity or make SPF align.

When the issued instructions require a change at a DNS owner you control:

• Inspect the existing TXT records at that exact owner. There must be only one TXT policy beginning v=spf1 for the evaluated owner, not a second policy alongside the first.
• Merge only the authorized WEBCAS mechanism into the existing policy, preserving legitimate senders and the owner's intended qualifiers. Do not replace the whole record with a tutorial example.
• Check the complete policy against SPF's limit of ten evaluated DNS-dependent terms, including nested evaluation. This is not a limit of ten visible include strings. An all mechanism also means an otherwise present redirect is ignored.
• Distinguish a sender that fails authorization from temporary DNS errors and permanent policy errors. Changing a qualifier is not a reliable fix for a malformed policy or exhausted lookup budget.

These protocol rules come from RFC 7208. A visible From-domain SPF record, or a provider control-panel check, is not a substitute for the receiving system's actual SPF result and evaluated identity.

Generate the correct public DKIM record

For the documented cloud route, WEBCAS gives this navigation:

TOP → 管理機能 → スキーマ選択（複数ある場合）→ DKIM署名設定 → 新規登録

In English, this is Top → Administration → select the schema if more than one exists → DKIM signature settings → New registration. Use the intended schema and domain. The cloud instructions identify this as the place to issue the public key for the author-domain signature.

Obtain the complete account-generated public record, including its selector, full DNS owner, record type and full TXT value. The author-domain signature is intended to sign with the same domain as the sender. Do not generate a random selector, copy a truncated screenshot key, or publish a private signing key. If the issued record or domain does not match the approved task, stop and resolve it before publication.

The October 22, 2026 release added creation of 2048-bit public keys for the documented deployment. It also says that moving from an existing 1024-bit key requires regenerating the public key and registering it again in DNS. That is a key change, not a harmless display preference. For an existing working signer, plan a supported transition with the service owner rather than regenerating it during diagnosis. For a new configuration, use the supported 2048-bit option and confirm that the DNS service stores the complete value correctly.

Publish and check the exact DKIM owner

For a TXT-based DKIM record, the public key normally lives below the selector and _domainkey labels of the signing domain. Use the actual owner issued by WEBCAS, not the illustrative names below.

If the issued full owner is selector-from-account._domainkey.mail.example.com, a DNS panel managing example.com may expect selector-from-account._domainkey.mail. A panel managing the separately delegated zone mail.example.com may expect selector-from-account._domainkey. Some panels accept the full name; others append their zone automatically. Check the resulting full owner so that the domain is not duplicated or accidentally placed at the apex.

Store the complete public TXT value, preserving its tags and key characters. A DNS provider may represent a long TXT value as multiple quoted character strings within one TXT record; this is different from creating multiple competing keys at the same owner. Confirm the returned record reconstructs the full issued value.

If that owner already has a CNAME, do not add TXT beside it or delete the alias without reviewing its dependencies. This documented route does not call for a proxy, CNAME flattening change, new MX records or nameserver migration. If your account instead issues a materially different record type, stop and obtain the instructions for that configuration instead of silently converting it into TXT.

The following read-only queries use placeholders. Replace the owner and authoritative server with the values established for your domain:

dig TXT selector-from-account._domainkey.mail.example.com
dig @authoritative-dns.example.net TXT selector-from-account._domainkey.mail.example.com

Compare the returned owner and complete public value with the current WEBCAS record. No answer, a stale key, an unexpected alias, or conflicting records requires investigation. A TXT answer alone does not prove that WEBCAS is using the corresponding signer. DKIM's key and signature model is specified in RFC 6376.

Select the author signature on the actual task

WEBCAS made selection of a DKIM signature mandatory in the task settings in July 2024. The notices permit choosing WEBCAS第三者署名, the WEBCAS third-party signature, when customer DKIM is absent or unavailable. Do not mistake that fallback for completed customer-domain authentication.

For the approved task, inspect its From domain and DKIM signature setting together. Choose the intended author-domain signature whose public record you have verified. Do not send a production campaign merely to find out which signature is selected.

The current deployment added automatic selection in April 2026 when a DKIM signature matching the sender-address domain exists. Earlier behavior selected the first available signature, and copied tasks retained the source task's signature setting. These changes explain why inspecting the actual task is essential: automatic selection is not evidence that every old or copied task already uses the right signer.

In the October 2026 deployment, a sent task's 参照 → 設定確認, or Reference → Settings confirmation, exposes its DKIM and List-Unsubscribe settings. Use that view to corroborate the task configuration. It does not replace a received-message check. Keep unsubscribe behavior intact; disabling List-Unsubscribe is not an authentication repair.

The published instructions establish record issuance and task-level signature selection. They do not establish a universal standalone “Verify” or “Enable DKIM” button for every deployment. If your account requires additional approval or presents different controls, have WEBCAS confirm the route before proceeding.

Preserve DMARC policy and reporting choices

Before adding or changing DMARC, check both a direct policy and any applicable inherited policy for the visible From domain. Keep existing protection and authorized reporting destinations. Do not replace an existing policy with p=none just because a new sending task is being configured, and do not create a second DMARC record at the same owner.

Only if no direct or applicable inherited policy exists, the domain owner approves initial monitoring, and someone will review the results, a first-policy example for mail.example.com is one TXT record at _dmarc.mail.example.com containing v=DMARC1; p=none. In an example.com zone that owner may be entered as _dmarc.mail; in a delegated mail.example.com zone it may be _dmarc. Confirm the DNS panel's name handling. This conditional example is not a policy downgrade or a claim that reporting is configured.

Add aggregate-report destinations only after the owner approves the recipient and data sharing. When the report destination's Organizational Domain differs from the Organizational Domain of the domain where the policy was found, the receiver generating the report must check DNS authorization. A destination within that same Organizational Domain is excepted. RFC 9990, section 4 defines that distinction; DNS authorization does not replace the owner's privacy decision.

Apply the current policy and alignment rules in RFC 9989. Do not infer successful authentication, guaranteed delivery or permission to enforce a stronger policy from the existence of a DNS record alone.

Verify a controlled message through the intended WEBCAS route

After DNS and task configuration are ready, arrange an approved test through the same native WEBCAS email task and sending path you intend to use. Use a controlled recipient and harmless content. Do not import a customer list, release a scheduled campaign or change recipients' consent state for this test. If a preview or test mode has a different sending identity from a real task, establish a supported representative test with the service owner rather than accepting the preview as proof.

Inspect the full headers at the receiving system. Use Authentication-Results generated inside that system's known processing boundary, with its documented handling of externally supplied results. A familiar authserv-id string or a header's position is not enough to establish trust. Ignore attacker-supplied or otherwise untrusted result fields; see RFC 8601.

The acceptance record should identify:

• The actual visible From domain, confirming that it was not rewritten into an unrelated provider identity.
• The intended WEBCAS author signature, its d= signing domain and s= selector, with a trusted dkim=pass result.
• Alignment of that passing intended signature with the visible From under the applicable policy. Relaxed DKIM alignment compares Organizational Domains; strict alignment requires the exact domain match.
• A trusted dmarc=pass result. A DMARC pass obtained only through SPF does not establish that the new DKIM setup works.
• The actual MAIL FROM domain and SPF result. Relaxed SPF alignment also compares Organizational Domains; strict SPF alignment requires an exact match. A child envelope domain is not automatically strictly aligned with a parent From domain.

Investigate SPF fail, temperror and permerror separately even if aligned DKIM already produces DMARC pass. Likewise, a passing third-party WEBCAS signature is not the intended customer-domain result. EmailAuth's guide to raw DKIM results versus aligned DKIM policy results explains why those are different conclusions.

Troubleshooting the common failure points

The public key is in DNS, but the message still has the third-party signature. Check the actual task's DKIM selection, From domain and copied-task history. DNS publication does not change every task's selected signature. Confirm the deployment's supported application process with WEBCAS if the documented setting is absent.

The correct selector is queried, but DKIM fails. Compare the full current key with the issued record and look for wrong-zone publication, stale caches, TXT truncation or conflicting records. Also investigate whether an intermediary changed signed content. Do not regenerate keys or disable message security controls as an automatic first response.

A task selected DKIM automatically, but DMARC fails. Verify which signature actually passed and which domain it authenticated. Check the applicable policy's alignment mode. Task selection and raw authentication success do not establish alignment with the final visible From.

The SPF instructions look different from an online example. Confirm the actual WEBCAS product, route and evaluated envelope identity. Use the current individually supplied email-service instructions, not formulator or DB creator examples. Escalate contradictory account instructions before changing a working SPF record.

Authentication passes, but the message is delayed or lands in spam. Check the receiver's actual diagnostic and delivery information. Authentication is necessary evidence for this setup, not a guarantee of inbox placement. Content, consent, reputation and receiving policy remain separate concerns.