Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.
Separate mail hosting from the sending route
FORPSI's DKIM workflow covers messages submitted through smtp.forpsi.com. Start by listing mailbox clients, webmail, website notifications and any external applications. Record the actual outgoing server for each. A domain hosted at FORPSI does not mean every application sends through its authenticated SMTP service. A website using a local mail function is a separate route until evidence establishes otherwise.
Assign the hosting-account owner and authoritative DNS owner. They may belong to different teams or customer accounts. Record the main domain and every alias domain used in From addresses. A successful message for the main domain is not proof that an alias is configured. This inventory determines the activation path and acceptance tests.
Activate DKIM for the correct ownership arrangement
References: RFC 6376 §3.6.2, RFC 7208 §3.3.
In hosting management, open the DKIM tab and activate the intended domain. Main and alias domains are separate. When hosting and domain share an account and use FORPSI DNS, the required TXT record is created automatically. With separate accounts, publish the displayed TXT record yourself. With external DNS, choose a supported key option and publish its supplied owner/value at that DNS host. View public key - TXT record displays it again; check status after publication. Source: FORPSI, DKIM.
Prefer a supported modern key size rather than choosing a smaller key merely because a DNS editor has an awkward field. Ask the DNS provider how it represents long TXT data. Preserve the generated key as one logical record; do not invent a key or split it into independent records. Do not expose private signing material. The public-key record belongs at the exact selector owner, not at the root simply because other TXT records are there.
FORPSI says signing does not occur without the required TXT record and limits this activation to smtp.forpsi.com. Its delivery guidance also calls for the visible From and envelope-sender domains to match for its valid signing route. Test those identities in the actual application, especially when a web script chooses its own envelope sender. Sources: FORPSI, DKIM; Sent emails are not delivered or are delivered into the SPAM folder.
Add SPF without replacing other senders
References: RFC 7208 §3.2, RFC 7208 §4.6.4.
The provider documents include:_spf.forpsi.com for mail sent through smtp.forpsi.com. At FORPSI DNS, the documented editor is under Domains > chosen domain > edit DNS records. If that editor is absent, publish at the domain's actual authoritative DNS service. SPF is a TXT policy; retain one policy containing all necessary authorizations. Source: FORPSI, Setting of SPF and DMARC records.
Do not copy the provider's full sample policy without checking its a and mx mechanisms against your infrastructure. Preserve legitimate external senders and count DNS-lookup-dependent mechanisms across nested includes. A second SPF policy is not an additive permission. Likewise, do not move straight to a stronger DMARC policy merely because one mailbox works; every legitimate route must be considered first.
Verify webmail, aliases and website mail independently
References: RFC 9989 §4.4, RFC 9989 §5.3.5.
Query authoritative DNS for the intended TXT owner, then compare the result with the generated public key. Confirm that the editor has not duplicated the domain suffix or altered the key. Check a recursive resolver separately to identify caching rather than assuming every failure is propagation. Avoid a universal promise that all resolvers update after a particular number of minutes.
Send controlled messages from each route and preserve originals. Record From, envelope domain, DKIM d=/s= and trusted receiver Authentication-Results. SPF verifies the envelope domain; DKIM verifies its signing domain; DMARC needs at least one passing path aligned to visible From under the applicable mode. A provider's activation badge alone does not demonstrate those conditions at a receiver.
Synthetic example: webmail sends From accounts@example.com with envelope example.com and a verified signature d=example.com. That establishes a passing aligned path for that sample. A website sends the same visible From via an unrelated server and has no valid aligned signature. The webmail result does not rescue the website message. Investigate its submission route and envelope identity rather than repeatedly reactivating mailbox DKIM.
Use failures to locate the responsible layer
An absent signature suggests that the route, domain activation or required DNS publication differs from the working case. A present but invalid signature requires inspecting its selector, key and any changes after signing. A passing aligned result with spam placement calls for delivery-error and reputation investigation, not arbitrary DNS additions. Absence of a bounce alone does not prove that a person saw the email.
Retain prior DNS and application settings, and test any approved alternate SMTP route before relying on it for recovery. Keep other senders' permissions until their dependency is understood. Acceptance requires recorded DNS, activation and real-message evidence for the main domain, relevant aliases and website routes. This guide contains source review and synthetic reasoning only. It does not claim account changes, live DNS measurements, received-message tests, human approval or publication.