RPost RMail SPF, DKIM and DMARC setup, step by step

To authenticate RPost RMail, request the record set for your actual RMail deployment, publish the supplied public DKIM material and any confirmed SPF changes, then complete RMail's confirmation process and inspect an independently delivered message. A Registered Receipt, successful encryption or an accepted SMTP submission does not prove the customer-facing message passed branded DKIM and DMARC alignment. RPost Hybrid SMTP provisioning and RMail DKIM Request Form

This guide covers RMail provider-assisted authentication, including the protected sending routes your organization provisions with RPost. It is not a universal record recipe for RSign, every RPost product, or the inbound anti-spoofing options of RMail Gateway.

No customer account, DNS publication, RMail message or receipt was tested. Account-specific selectors, keys, activation state and envelope support must be confirmed with RMail.

Map the RMail business message and receipt separately

Start with the message the external recipient actually receives. Identify the originating application or mail client, selected RMail processing mode, sender domain, service deployment and any later gateway. Map the returned acknowledgement or receipt as a separate stream.

RPost's Hybrid SMTP overview lists sender/server authentication, plan authorization, routing and message formatting, followed by separate receipt and reporting preparation. Those are distinct provisioning responsibilities. Authentication of the sender to RMail is not itself the receiving mailbox's authentication verdict on the finished message. RPost Hybrid SMTP process

For example, a legal practice might use Track & Prove for routine correspondence and encryption for confidential attachments. Test both if they take materially different processing paths. An application that adds a footer through a later relay also deserves its own test; testing a message that bypasses the relay misses the actual risk.

Keep the business protection requirement intact. If a direct Microsoft 365 message authenticates but the protected RMail route does not, the direct message is a diagnostic comparison, not a completed replacement for the RMail workflow.

Request the complete RMail authentication record set

You need a domain your organization controls, a DNS administrator authorized to change it, the relevant RMail account owner or representative, and the intended From addresses. Include subdomains explicitly: example.com and legal.example.com must not be silently treated as the same signing configuration.

RPost's published support procedure starts with its DKIM request form and a support request. The article describes completing company information, submitting the form through RMail support and receiving a completed form from a representative. The support account is separate from the RMail service account. Confirm the current support navigation with your representative if the older article's labels differ from today's portal. RPost's DKIM request procedure

Ask for a single written record set covering:

Do not request or put the DKIM private key in your public DNS worksheet. A hosted sender normally retains its signing key; you publish the public material it supplies. Do not substitute a generator's unrelated key or another customer's record.

Configure SPF for the actual envelope identity

SPF checks the SMTP MAIL FROM domain against the outbound sending IP, with a separate HELO identity check. It does not automatically evaluate the domain in the visible From address. Read the receiver's smtp.mailfrom result and corroborate it with the message's Return-Path. SPF specification

A regional RPost Nederland support page lists include:spf.rpost.net. That is useful background for a support conversation, not evidence that every RPost deployment needs that include at its root domain. Confirm the applicable authorization and exact owner with your RMail representative before changing a global policy. The same regional page describes provider configuration of the customer domain and issuance of a unique public DKIM key. RPost Nederland's RMail authentication page

Use this decision sequence:

1. RMail uses a provider-owned MAIL FROM: examine that domain's SPF result. Adding an include to your unrelated visible From domain does not repair the provider's policy or make its envelope align.
2. RMail uses your root or a customer-controlled subdomain: obtain the exact current authorization or delegation for that owner. Do not assume the root policy applies to every subdomain.
3. You require a custom return path: get explicit confirmation of availability, activation and bounce-record requirements for this deployment. The reviewed global public material does not establish one universal self-service procedure.

When changing a TXT-based SPF policy, keep exactly one policy beginning v=spf1 at that owner. Merge approved mechanisms before the terminal all, preserve other legitimate senders, and retain the existing approved qualifier unless the policy owner authorizes a change. Evaluate the ten DNS-querying-term limit, including nested includes. Do not solve an error with +all. SPF evaluation limits

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.

For related investigation, use EmailAuth's SPF permerror guide. A returned permerror needs diagnosis; it is not interchangeable with a harmless lack of SPF alignment.

Publish the issued DKIM records safely

Export or copy the existing affected DNS records first. For the TXT workflow described in RPost's form, publish the exact selector owner and public key returned for your company. If the representative issues a different record type, reconcile it with the current deployment before changing anything. Do not convert TXT to CNAME because another provider uses CNAMEs.

These owner examples are fictional and demonstrate placement only:

If legal.example.com is separately delegated and you edit that child zone, the full DKIM owner rm2026._domainkey.legal.example.com uses the relative name rm2026._domainkey, not rm2026._domainkey.legal. Publish in the zone that actually serves that owner.

At an existing separately delegated _domainkey.legal.example.com authority, full owner rm2026._domainkey.legal.example.com maps to relative rm2026. Substitute the actual provider-issued selector and preserve that NS delegation and other selectors. Relative names.

rm2026 is not a documented RMail default. Replace it with the issued selector. An email signature's d= and s= determine the key lookup name. DKIM selector lookup

Check whether the DNS editor appends the zone automatically. Compare the final full owner to the provider's instructions. Preserve the complete public-key value without smart quotes, extra spaces inside the key or lost characters. A DNS tool may display one long TXT record as multiple quoted strings; do not turn those chunks into separate competing key records.

The RPost form notes that DNS syntaxes can differ around semicolons. Follow your DNS host's input format and validate the returned logical value rather than blindly inserting backslashes. If a CNAME is specifically issued, publish it as DNS only where proxy controls exist and check for conflicting data at that owner. Never overwrite an active selector merely to clear an error. RPost DKIM form

Only if a representative actually issues an authentication CNAME for this deployment: Where the actual authoritative DNS host offers these controls, use DNS-only aliases, not HTTP proxying or redirects, and keep a literal CNAME answer to each required target. Turn the relevant per-record Flatten option off when available, and ensure applicable zone-wide settings do not conceal the issued aliases. For Cloudflare specifically, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are Cloudflare behaviors, not assumed controls in another provider’s panel. If mandatory behavior or shared settings prevent the required CNAME answer, stop and coordinate a supported configuration without breaking dependent records. Do not blindly change the whole zone or remove an NS delegation; publish at the delegated authority when appropriate. Cloudflare CNAME verification, flattening controls.

Ask the representative to confirm the activation state and intended signing domain after DNS validation. Publication and provider activation are separate acceptance steps.

Retain DMARC policy and reporting

A message passes DMARC if at least one passing SPF or DKIM identity aligns with the visible From domain. Relaxed alignment allows the same organizational domain; strict alignment requires an exact domain match. A valid RPost-owned signature can therefore be genuine DKIM authentication without being your branded aligned signature. DMARC specification

Read the existing applicable DMARC policy, including any inherited subdomain policy. Preserve its enforcement level, report destinations and alignment modes. Do not publish a second policy or weaken protection to work around an unresolved RMail configuration.

Only if no established policy applies, including an inherited policy, use a separately approved first-policy monitoring rollout. Create a TXT record in the authoritative DNS zone. Map the full owner to the selected zone:

The domain owner must explicitly approve this first monitoring policy and its monitoring/review plan before publication. This approval does not permit replacing an applicable direct or inherited policy or using an unapproved reporting recipient.

Choose the applicable row and zone, not both zones for the same owner. Confirm the editor's resulting full owner, enter the approved policy as the TXT value, and save. The illustrative value below is not a replacement for an existing or inherited policy. Replace its placeholder mailbox with an authorized working report destination before deployment:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Review aggregate reports for the actual RMail source, SPF identity, DKIM domain and aligned result. External report destinations may require authorization under the external-destination verification rules. Reports also need an owner who will investigate failures. Monitoring is not enforcement, and reports are not a substitute for inspecting a new message. DMARC aggregate reporting

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.

Before increasing enforcement, cover other legitimate mail streams and indirect paths too. Current DMARC interoperability guidance cautions about forwarding and mailing-list disruption, and requires valid DKIM for domains using p=reject. One RMail test is not domain-wide enforcement readiness. DMARC interoperability considerations

Verify DNS before provider confirmation

Replace the example domain, authoritative server, envelope owner and selector below with the confirmed deployment values. These queries do not change DNS:

dig +short NS example.com
dig @ns1.example.net rm2026._domainkey.example.com TXT +noall +answer
dig @1.1.1.1 rm2026._domainkey.example.com TXT +noall +answer
dig @8.8.8.8 rm2026._domainkey.example.com TXT +noall +answer
dig bounce.example.com TXT +noall +answer
dig _dmarc.example.com TXT +noall +answer

Expect the public DKIM value issued for that selector, not merely any TXT answer. Query the actual envelope domain for SPF; bounce.example.com is not an assertion that RMail uses that name. For provider-issued CNAMEs, query CNAME at the issued owner and TXT at the returned target. Check delegated subdomains against their own authoritative servers.

Compare authoritative and recursive answers. Stale cached data may explain different results; a wrong authoritative owner or truncated key requires correction rather than more waiting. Validate SPF syntax and lookup cost separately because dig only retrieves records, not a complete message-level SPF verdict.

RPost's form asks for a Track & Prove or encrypted test message to dkim@rpost.com, copying the RMail representative, after checking the selector record. Arrange that through the organization's approved support process, confirm the current instructions, and use harmless content. The form describes advisor confirmation as typically within 48 hours, not a guaranteed DNS propagation time. RPost's confirmation workflow

Test branded signing on delivered RMail messages

Complete an independent receiver test as well as provider confirmation. Use the same production mode, application, From domain and downstream processing. Save the original message headers from an external mailbox you control, not just the receipt returned to the sender.

Record Message-ID, UTC time, From, Return-Path, each DKIM d= and s=, and the receiving system's trusted Authentication-Results. If there are several signatures, identify the result for the intended customer-domain signature. Do not treat an unrelated dkim=pass as a pass for your key.

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. Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.

Acceptance requires:

• The protected business message followed the intended RMail route.
• The expected branded DKIM signature is present, passes, and aligns with From under the applicable policy.
• The actual SPF result is recorded and checked for fail, softfail, none, neutral, temperror or permerror. Investigate unexpected results even when DKIM supplies DMARC pass.
• SPF alignment is stated separately from SPF pass. Unsupported custom envelope alignment remains a documented limitation.
• DMARC passes for the intended From domain, with the aligned mechanism identified.
• Required encryption and receipt behavior remain intact as separate business checks.

DMARC can technically pass through SPF alone, but that is not enough to accept this DKIM implementation. Likewise, a DNS status indicator and a successful receipt are not substitutes for the intended brand signature passing.

Fictional example: a receipt arrives, but the separate recipient message shows From adviser@example.com and only a passing signature from provider.example.net. That signature does not align with the brand. Determine whether there is another passing aligned signature or SPF identity before judging DMARC, and resolve the missing branded DKIM before accepting setup. No receipt or message from a real tenant was examined here.

Troubleshoot without bypassing protection

Pause the affected workflow or restore an approved configuration if needed. Do not quietly remove encryption, route around required proof-of-delivery processing, or weaken DMARC just to obtain a passing sample. Escalate with redacted headers, the public DNS answers, timestamps and the precise failing route, not confidential message contents.

Keep a route-specific acceptance record

Keep the provider request and completed public record set together with DNS observations, activation confirmation and receiver-test evidence. Record separate results for materially different Track & Prove, encryption and application routes.

Assign an owner to revisit the configuration when the From domain, integration, gateway or signing key changes. Preserve the previous working settings and RMail's recovery guidance. EmailAuth's selector investigation guide helps connect a later failure to the key actually referenced by a message.