Distinguish Coremail cloud mail from a self-built system
Coremail's official article “如何设置企业邮箱的SPF” distinguishes cloud mail from self-built systems. For cloud mail it describes adding a DNS TXT record and supplies an example using include:spf.icoremail.net. It directs self-built deployments to different guidance rather than presenting the cloud include as a universal authorization. This article covers that documented cloud-mail SPF route and the related public administrator-help discussion of DMARC. It does not establish DKIM provisioning, a current tenant's generated values or a universal configuration for all Coremail editions. Coremail SPF instructions
Confirm the actual subscribed service before proposing a change. A company can use Coremail software while operating its own outbound infrastructure, or it can use the provider's cloud service. Those arrangements create different evidence requirements for the servers authorized to send. Record the service name, responsible operator, intended envelope domain and current supported instructions. The retained pages do not establish a publication date for every instruction, so current applicability must be checked rather than inferred from a site copyright year.
This is a documentary configuration plan. No mailbox, domain or server has been inspected, and no DNS query, tenant change or test message has been performed. The original catalogue requirement for actual implementation and verification remains open. The narrower source-backed scope is deliberately visible so that a reader does not mistake an SPF publication guide for completed SPF, DKIM and DMARC acceptance.
Use the cloud SPF example as scoped input
The cloud-mail article directs the operator to the domain's DNS administration interface and to create a TXT record. Its illustrative settings use the root-domain host notation, a default resolution line and a ten-minute TTL. These are example presentation choices, not proof that every DNS editor accepts the same input or that a particular customer's record should overwrite existing data. Confirm the fully qualified owner and the actual DNS provider's field semantics. Coremail SPF instructions
Before applying any provider authorization, retrieve the existing approved policy through an authorized process and inventory other legitimate sending services. If staff mail, website notifications and an application share the applicable identity, they must be reviewed together. A short cloud-service example is not a safe replacement for an existing multi-sender policy. Preserve unrelated TXT records at the owner while ensuring there is only one applicable SPF policy. RFC 7208, sections 3.1–3.3
The include mechanism evaluates another domain's SPF policy within the protocol's rules; it is not a general statement that any message mentioning Coremail is legitimate. Review the dependency path and evaluated DNS-querying term limit. Caching does not turn the ten-term evaluation limit into a larger allowance, and counting only the visible top-level includes can miss nested work. Keep unresolved dependencies as explicit review items rather than flattening them into guessed addresses. RFC 7208, sections 4.6.4 and 5.2
Verify the identity that SPF actually evaluates
SPF applies to the relevant SMTP MAIL FROM identity, or HELO in the appropriate cases. The domain in the visible From address may be different. This distinction matters when a cloud route uses a provider-managed envelope identity or when an application changes its sender presentation without changing its actual submission path. Record those identities separately instead of treating an editor's From field as an SPF result. RFC 7208, sections 2.3–2.4
The policy's final all mechanism produces an SPF evaluation result; it does not guarantee that every receiver rejects, quarantines or delivers the message in a particular way. Receiver handling and other controls remain relevant. A failure may help diagnose an unauthorized route, but it is not a complete incident conclusion. A passing result establishes only the applicable authorization assessment, not the truth of message content or the safety of a payment request. RFC 7208, section 8 RFC 9989, section 2.4
Separate the provider's DMARC prerequisite from protocol semantics
The public Coremail administrator help recommends configuring its specified cloud SPF record before setting the proposed DMARC record. Preserve that as the provider's stated setup prerequisite for the documented route. It is not the same as a protocol rule that DMARC must always pass both SPF and DKIM. DMARC can use a qualifying aligned passing result from either mechanism. Coremail administrator help, “How to set the DMARC record?” RFC 9989, section 4.4
The help page includes a monitoring-policy example with reporting destinations operated by Coremail. Do not copy those recipients as an automatic authorization to share the organization's report data. The domain owner must decide who receives reports, what service arrangement applies and whether the chosen destination is appropriate. Equally, a monitoring example does not authorize weakening an existing quarantine or reject policy. Keep the organization's policy decision separate from a provider's illustrative string.
The help text makes broad statements about phishing prevention and report delivery. This guide does not adopt those as guarantees. Authentication is bounded by domain identity and alignment; reporting availability and receiver behavior are not proved by publishing a record. The recommended acceptance method records actual evidence when it becomes available and does not interpret silence as proof that no mail was sent or that no abuse occurred. RFC 9989, sections 2.4 and 5.3
Keep DKIM implementation unresolved until supported
The retained cloud SPF instructions and administrator discussion do not provide a complete DKIM enablement workflow, selector allocation rule or account-specific public key. Do not generate an arbitrary key pair or publish a guessed selector to make the broader authentication checklist appear complete. The sending system must actually sign with the corresponding private material, and the receiver must locate the appropriate public verification record using the signature's selector and domain. RFC 6376, sections 3.5 and 3.6.2.2
Assign the open DKIM task to the responsible service administrator and obtain applicable official instructions before planning implementation. Record whether the requirement concerns cloud mail, a self-built deployment or another product route. An incoming DKIM verification setting is not evidence that outbound signing is enabled. Until the actual route and supported controls are established, the article's DKIM implementation gate remains open rather than being silently satisfied by protocol explanation.
Fictional diagnosis: a cloud example applied to the wrong route
Consider a fictional organization, Lantern Manufacturing, with a self-operated mail platform and a separately contracted cloud service. An administrator finds the cloud SPF example and proposes replacing the organization's current policy with it. Another colleague assumes that a published DMARC record will also create DKIM signing. Neither assumption is an observed event or a test result; this is a fictional review exercise.
The proposed review first classifies the sending routes. It retains the self-operated route's approved authorizations and confirms whether the cloud include is relevant to any in-scope messages. It then separates SPF publication, DMARC policy and DKIM enablement into different work items. No record is declared complete merely because it resembles the example. The owner requires appropriate evidence for each route and leaves the unknown DKIM setup unresolved.
Blank cloud-mail acceptance worksheet
- Actual product, deployment model and current provider confirmation: ____.
- Business owner, mail administrator and authoritative DNS operator: ____.
- In-scope sending route, MAIL FROM domain and visible From domain: ____.
- Existing SPF policy, retained legitimate senders and proposed cloud authorization: ____.
- Intended complete DNS owner and editor-specific input convention: ____.
- Evaluated SPF dependency review and unresolved errors: ____.
- Provider DMARC prerequisite and organizational policy decision: ____.
- Approved report recipients and applicable service arrangement: ____.
- DKIM implementation information still required: ____.
- Authorized DNS observations, received-message results and release approver: ____.
All fields are blank. Original evidence, human/SME review, source applicability, production routes, visual/accessibility review and owner release remain open. This draft does not claim a live configuration, a successful message result or guaranteed delivery.