Forpsi SPF, DKIM and DMARC setup, step by step

On this page: Scope and prerequisites · SPF · DKIM · Website mail · DMARC · Verification · Troubleshooting · FAQs

To authenticate mail sent through smtp.forpsi.com, include include:_spf.forpsi.com in the appropriate SPF policy and check DKIM for the exact sending domain in FORPSI’s hosting administration. DKIM publication depends on whether the domain and hosting share a customer account and who hosts DNS. Validate the resulting message, not only the record or activation status.

This guide follows the English FORPSI.com documentation for its shared SMTP and hosted-mail service. It is not a blanket configuration for every regional FORPSI offering, VPS, standalone server or third-party sender. No customer account, DNS change or delivery test was performed.

Establish which service actually sends

A domain registered with FORPSI may send through another provider. Similarly, a website hosted at FORPSI can use PHP mail, an external SMTP server or an email API. Identify the route before granting it sending authorization.

Record the visible From domain, SMTP service, MAIL FROM or Return-Path domain, and any DKIM signing domain and selector from a representative message. Inventory aliases, subdomains, marketing systems and transactional applications separately.

You will need:

• Access to the hosting service’s customer administration.
• Access to the domain’s authoritative DNS, potentially in another account or at another company.
• A saved copy of existing DNS records and a list of active senders.
• An approved reporting destination if you are adding DMARC reports.
• An external mailbox for later received-message verification.

For application submission, FORPSI documents authenticated connections to smtp.forpsi.com, with encrypted port 587 or 465 recommended. The sender domain must match the authenticated domain or an allowed alias. Authentication failures, sender rejection and GeoIP restrictions are submission problems, not reasons to add unrelated SPF authorizations. FORPSI SMTP configuration

Add the FORPSI SPF authorization safely

FORPSI’s documented include for this SMTP service is:

include:_spf.forpsi.com

Its published example is:

v=spf1 a mx include:_spf.forpsi.com -all

The include authorizes FORPSI’s documented outbound infrastructure. The additional a and mx mechanisms authorize the addresses associated with those DNS records, so do not add them reflexively to every domain. Match the final policy to your actual senders. The provider also documents merging external services into the same SPF record. FORPSI SPF instructions and example

Choose the owner name from the envelope sender

SPF checks the SMTP MAIL FROM identity, not simply the From address displayed to the recipient. An empty reverse path uses a HELO-derived identity. If the relevant MAIL FROM domain is example.com, publish its policy there; if it is bounce.example.com, inspect that subdomain separately. An apex SPF policy is not inherited by subdomains. SPF identity rules

Do not assume that adding the include to a domain you own will authenticate a message using a provider-owned envelope domain. That message is evaluated against the provider’s policy. DMARC alignment, covered below, is a separate question.

Edit the existing record, if present

1. Read the current TXT records at the exact SPF owner.
2. If one begins v=spf1, modify that policy instead of creating a second.
3. Add the required include once, before the terminal all mechanism, retaining the other legitimate sender authorizations.
4. Preserve the existing final qualifier unless a deliberate policy decision changes it. Do not weaken a working -all policy merely to match a softfail example elsewhere.
5. Validate syntax and nested lookup usage before saving.

SPF permits at most 10 evaluated DNS-query-causing terms, including recursive includes and redirects. Duplicate policies can produce permerror; a single over-complex policy can do the same. Do not delete other services or use +all to make an error disappear. SPF record and processing requirements

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

Publish where DNS is authoritative

For FORPSI-managed DNS, the documented path is customer administration → Domains → domain → edit DNS records. Edit the existing SPF TXT record or create it only if none exists. The provider explains that an absent DNS-edit link can mean the domain uses external nameservers; in that case publish at the external host. FORPSI DNS workflow

Keep unrelated TXT records. Check whether your editor expects @, a blank field, a relative label or the full name. Verify the resulting public owner rather than assuming the interface’s text is the final DNS name. There is no need to change nameservers just to configure authentication.

Activate DKIM using the correct account and DNS branch

Open the hosting service in FORPSI customer administration and select the DKIM tab. Check each domain’s status. Main and alias domains are activated separately. New hosting with the domain in the same customer account and using FORPSI DNS receives automatic 2048-bit DKIM; verify older accounts instead of assuming they are enabled. FORPSI DKIM setup

If activation is needed, select Activate DKIM for the intended domain and follow the matching branch:

The record can be retrieved again through View public key - TXT record. FORPSI checks its publication and documents roughly half an hour for the manual DNS change. If the required TXT record is missing, the SMTP service does not sign that domain’s outgoing mail. FORPSI activation branches and validation

Prefer a supported 2048-bit RSA key

The external-DNS workflow offers 1024-bit and 2048-bit choices. Confirm that your DNS host can store the complete 2048-bit public value rather than treating an unfamiliar editor as proof it cannot. The DKIM cryptographic update recommends RSA keys of at least 2048 bits; 1024 bits is the minimum, not the preferred new deployment. DKIM key-size requirements

Publish only the generated public value. Do not generate an unrelated key pair elsewhere, copy a screenshot’s key, or put private material in DNS. The public key must correspond to the key used by FORPSI’s signer.

Keep a long TXT value as one resource record. Some editors split it into quoted strings internally; those strings are concatenated by the verifier. Do not turn each segment into a separate TXT record. Preserve all characters, and check for a duplicated domain suffix in the hostname. The lookup name comes from the actual message’s s= and d= values. DKIM key discovery and TXT handling

For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

Treat website mail as a separate sending route

For WordPress, use the application-mail route guide to establish which SMTP or API service actually handles the message.

FORPSI’s signing applies to the shared SMTP route, including its webmail, not automatically to PHP mail() or another SMTP service. Its delivery guidance also states that the From and envelope-sender domains must be the same for its DKIM signing. This is a provider signing prerequisite, separate from DMARC’s general relaxed-alignment rules. FORPSI delivery and signing prerequisites

For a contact form, compare the configured SMTP host and envelope sender with those of a working mailbox message. Use a legitimate sender on your own domain rather than placing a visitor’s unrelated email domain in From; where appropriate, use Reply-To for the visitor’s address. If you choose authenticated SMTP submission, configure it deliberately in the application and test that route again. Merely publishing the FORPSI key does not change how the application sends.

Keep credentials in the application’s supported secure configuration. DNS instructions never require publishing a mailbox password, and an authentication guide is not a reason to disable transport encryption or server protections.

Review DMARC without discarding an existing policy

FORPSI documents automatic SPF -all and DMARC p=quarantine for new hosting using its DNS. Inspect what your domain actually publishes before adding anything. Its SPF/DMARC guide recommends rejection, but moving to enforcement should follow validation of all legitimate routes, not only one mailbox. FORPSI hosting defaults

DMARC needs one aligned pass: SPF with an aligned MAIL FROM domain, or DKIM with an aligned signing domain. Under relaxed alignment the organizational domains match; under strict alignment the full domain names must match. An authentication pass for an unrelated service domain does not protect your visible From domain. RFC 9989 DMARC

Read _dmarc at the From domain and any applicable parent policy. Do not create competing DMARC records or replace an existing quarantine/reject policy with a generic monitoring record. If no policy applies and you are starting a monitored rollout, the following is an illustrative template:

Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example mailbox with an approved, working destination and ensure the owner resolves beneath the correct domain. Use monitoring to identify and fix legitimate failures, then make an intentional enforcement decision. The current DMARC standard supersedes RFC 7489 and removes pct; old percentage-rollout examples are not current guidance.

Publish this first monitoring policy only with the domain owner’s approval and only when neither a direct nor applicable inherited policy exists; otherwise preserve the existing policy and authorized reporting destinations.

Put DMARC at the intended DNS owner

For a policy directly on example.com, the full owner is _dmarc.example.com; a relative-name editor for the example.com zone normally needs _dmarc. For a deliberate policy directly on billing.example.com, the full owner is _dmarc.billing.example.com: enter _dmarc.billing in the parent example.com zone, or _dmarc in a separately delegated billing.example.com zone. These are naming examples, not a recommendation to override an existing parent policy. Check the published full name and applicable policy before changing it.

Aggregate reports can help distinguish expected FORPSI traffic from other systems and unauthorized sources. A report destination outside your domain may require authorization at the destination. External-destination authorization Failure reports may include sensitive message details and need a separate privacy decision. Aggregate-report authorization, failure-report considerations

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Verify DNS and actual authentication separately

Check the public records

Replace example.com and selector1 with the actual envelope domain, signing domain and selector. These commands are examples, not observed results:

dig +short NS example.com
dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com

Expect one SPF policy at the evaluated envelope domain, the exact generated DKIM public record at its owner, and the intended DMARC policy. Query a different signing or MAIL FROM subdomain separately when the message uses one.

If the panel and public lookup disagree, inspect the authoritative answer before waiting indefinitely:

dig @ns1.dns-provider.example TXT selector1._domainkey.example.com
dig @1.1.1.1 TXT selector1._domainkey.example.com

Replace the illustrative nameserver with the real authoritative server. A correct authoritative answer and a stale cached answer call for cache expiry; a wrong authoritative answer calls for fixing the zone or owner. FORPSI’s half-hour estimate does not guarantee every cache has refreshed, especially after a delegation change.

Check each real sending route

After the change, send through FORPSI webmail, the configured email client, and each relevant application to an external mailbox you control. Test aliases separately. Inspect the receiving system’s trusted authentication results and retain the raw source. Authentication-Results

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

For each message record:

• The visible From domain and smtp.mailfrom domain.
• Whether SPF passed for that envelope identity.
• Whether DKIM passed, together with header.d and the signature’s s= selector.
• Whether DMARC passed through at least one aligned method.
• The timestamp, recipient provider, message ID and any rejection text.

To verify FORPSI DKIM itself, require dkim=pass for the expected provider-issued selector and confirm that its d= domain aligns with the final visible From domain. An unrelated service-domain signature passing is not enough. If SPF shows fail, softfail or temperror, investigate the evaluated envelope domain, authorized route and DNS response even when DKIM supplies a DMARC pass.

Accept this branded-DKIM setup only when the intended provider signature has trusted dkim=pass, its actual d= aligns with the intended visible From under the effective adkim mode, and the trusted receiver reports dmarc=pass for that From. SPF-only DMARC success does not complete the DKIM deployment. Independently diagnose SPF fail or softfail (authorization mismatch), temperror (transient evaluation failure, often DNS) and permerror (uninterpretable policy, duplicates or lookup limits) at the observed smtp.mailfrom, even when aligned DKIM supplies DMARC. A passing but unaligned provider envelope is a different outcome from an SPF error. DMARC alignment, SPF results.

A valid DNS record is necessary configuration evidence, not proof that this route signs or aligns. Authentication passing also does not guarantee inbox placement.

Common FORPSI problems and next checks

Preserve the domain, service, DNS host, route, timestamps and redacted message evidence for support. Do not assume silence proves delivery: inspect available mail logs and recipient evidence rather than treating the absence of a bounce as a guarantee.