Paubox Encrypted Email SPF, DKIM and DMARC setup, step by step

For Paubox Email Suite outbound email, preserve your existing SPF policy and add the documented authorization include:_spf.paubox.com at the appropriate sending-domain owner. In the Paubox dashboard, open Account Settings > DKIM Settings, generate the key for the correct domain, publish the unique DNS values, and only then enable DKIM Email Signing. Verify a real message after it has passed through Paubox: you want a passing branded DKIM signature aligned with the visible From domain.

This guide covers authentication for the Paubox Email Suite encrypted outbound route connected to a business email platform. Paubox Email API, Marketing and Webmail are distinct products, not interchangeable setup paths. Authentication alone neither proves encryption nor establishes HIPAA compliance.

Identify the Paubox product and final sending route

Paubox's email-platform configuration documentation separates Google Workspace, Microsoft 365 and Exchange outbound setup from inbound security and DNS configuration. Determine which users, groups and domains actually route through Paubox before changing authentication.

This article does not reproduce connector, firewall or inbound MX changes. Use the exact platform guide for those operations. SPF publication cannot make a bypassing application route through Paubox, and an inbound security MX change does not itself enable outbound signing.

Do not confuse a valid signature with one aligned to the intended brand. EmailAuth's raw DKIM versus aligned DKIM guide explains why those are separate results. Map application and device routes independently from ordinary Paubox-routed mailbox traffic.

Prepare administrator access and a change record

Arrange access to the correct Paubox account and domain, the authoritative DNS host, and the email-platform administrator who owns routing. A DNS administrator can publish public record values without receiving a private signing key or your Paubox login credentials.

Save existing SPF, DKIM and applicable DMARC records. Inventory ordinary mail, applications, devices and other authorized senders, including routes that do not pass through Paubox. Preserve their authorizations until their retirement is confirmed. Note the exact domain or subdomain: SPF is not inherited automatically from a parent domain.

Retain a redacted baseline original message and record expected identities separately from observations. Name the pilot, recovery and mail-security review owners. Include shared mailboxes, aliases, applications and bypass routes rather than assuming one employee test covers all traffic.

Use non-sensitive test content and controlled recipients. Do not send patient information to a public header-analysis website or outside test mailbox to check authentication. Record sanitized headers and delivery metadata rather than message bodies wherever possible.

Step 1: Update SPF without replacing other senders

Paubox's current SPF guide, documents include:_spf.paubox.com. Find the existing TXT policy beginning v=spf1 at the relevant domain and add that mechanism before its final all mechanism. Keep existing legitimate authorizations and the ending already approved by your mail administrator.

The guide provides Google Workspace and Microsoft 365 examples, but those are not exhaustive sender inventories. Do not paste an example over a policy that also authorizes other systems. One sentence in the official page abbreviates the prefix incorrectly as vspf1; the valid SPF version marker is v=spf1.

Under RFC 7208, SPF authenticates the connecting IP against the envelope MAIL FROM identity, normally reflected in Return-Path. It does not authenticate the visible From address by itself. Confirm the actual smtp.mailfrom domain in received results instead of assuming it from the mailbox address.

For a null reverse path and relevant HELO checks, evaluate the applicable HELO identity rather than assuming MAIL FROM or visible From. SPF identity rules Any all mechanism makes redirect ignored regardless of the qualifier. Preserve the existing design; qualifiers specify SPF results rather than guaranteeing rejection or inbox placement. SPF all processing

SPF has a maximum of 10 evaluated DNS-lookup-causing terms, including nested include and redirect processing. Count the evaluation path, not only the visible includes. ip4, ip6 and all do not consume these terms. Do not solve a lookup overflow by copying a provider's current IP addresses into an unmanaged flattened policy; provider infrastructure changes can make that authorization stale.

Step 2: Generate the domain-specific DKIM record

The current Paubox DKIM guide, gives this sequence:

1. Sign in to the Paubox dashboard.
2. Open your profile/name in the lower-left navigation and select Account Settings.
3. Open DKIM Settings.
4. Select the intended domain and choose Generate DKIM Key.
5. Publish the exact DNS values shown for that domain.
6. After publication, set DKIM Email Signing to Enabled.

Paubox describes DKIM as recommended rather than mandatory. The branded-signing acceptance standard in this guide nevertheless requires the intended aligned DKIM path to work. Do not regenerate an already working key without a rotation plan.

Record the supplied type, complete hostname, selector and public value. Do not invent a selector or reuse another customer's public key. An independently generated key pair will not work unless the sending service is configured to use its private half.

If the intended domain is absent, do not enable a different domain as a workaround. Check your account and product scope and ask Paubox support to confirm the supported domain setup. The dashboard-generated record is authoritative for that account; screenshots and older menu labels are secondary.

Step 3: Publish the key before enabling signing

Create the exact public record supplied by Paubox at the authoritative DNS host. A relative owner such as issued-selector._domainkey may be sufficient if the host appends your domain; verify that the final name has the domain only once.

For an illustrative full owner issued-selector._domainkey.news.example.com, use relative issued-selector._domainkey.news in the parent example.com zone, issued-selector._domainkey in a separately delegated news.example.com zone, or issued-selector in a delegated _domainkey.news.example.com namespace. Preserve shared NS delegations and publish at the actual authority instead of deleting a delegation.

Paubox notes that some DNS hosts need long 2048-bit TXT keys split into quoted strings. Those strings must form one logical TXT record and concatenate without inserted spaces, preserving the full tagged public-key value. DKIM TXT concatenation Do not turn one key into multiple unrelated records or include a private key. Keep other providers' DKIM selectors intact.

If the actual supported account configuration explicitly supplies a CNAME, keep the issued target/type and resolve any owner collision before proceeding. No TXT, A, AAAA, MX or second CNAME may coexist at that CNAME owner. Preserve active records and involve their owners rather than deleting a conflict blindly. This is conditional DNS safety, not a claim that Paubox's documented TXT setup has become a universal CNAME workflow. DNS alias rules

For a required literal CNAME on Cloudflare, use DNS only, turn an applicable per-record Flatten control off and ensure applicable whole-zone flatten-all does not suppress the issued alias. Assess shared dependencies and coordinate the owner's approval before changing a global setting. If mandatory apex or same-zone flattening prevents the required literal answer, stop and agree a supported design; do not invent an override or remove shared delegation. Do not convert a TXT workflow into CNAME or vice versa. Cloudflare proxy status · CNAME flattening controls

Confirm public DNS before enabling signing. Enabling the toggle does not publish DNS, and publishing a key without enabling the Paubox signer does not prove that outbound mail uses it. After a correction or key rotation, allow for DNS caches and in-flight messages before retiring an old key.

Step 4: Verify DNS and the actual outbound message

These are read-only example queries. Replace the example domain and selector with your real account values. Query the actual envelope domain separately if it differs from the visible From domain.

dig +short NS example.com
dig +short TXT example.com
dig +short TXT issued-selector._domainkey.example.com
dig +short TXT _dmarc.example.com

Expect one valid SPF policy, the complete issued DKIM public record and your intended DMARC policy. For CNAME-issued records, query CNAME and inspect the target's TXT response. Compare authoritative and recursive answers if stale caches are suspected; waiting does not repair a wrong selector or truncated key.

Send an authorized, non-sensitive message from a mailbox actually routed through Paubox to a controlled external recipient. Use results generated inside the actual receiving service's known processing boundary. Confirm from its documentation or administrator how it removes or distinguishes externally supplied Authentication-Results. Header position or a matching authserv-id alone cannot establish trust; ignore attacker-supplied fields. If the boundary cannot be established, use a controlled receiver with a documented boundary or its trusted trace. Receiver-result provenance Record:

• The final visible From domain.
• The envelope smtp.mailfrom domain and SPF result.
• Each DKIM signing domain (header.d) and selector (header.s).
• The DMARC result for the final From domain.
• Which mailbox, group or application route produced the message.

The branded signing acceptance criterion is dkim=pass with a domain aligned to your visible From domain. A provider-domain signature alone is insufficient to prove branded DKIM. A passing Microsoft or Google signature may help DMARC, but does not prove the Paubox signing setting has taken effect. Identify the expected Paubox-issued selector and validate that signature on the final message. Require the intended Paubox signature to pass and align under current policy, plus trusted dmarc=pass for the intended visible From. SPF-only DMARC pass does not establish Paubox DKIM. A rewritten provider-owned From is not successful authentication of the original brand. Diagnose SPF fail, softfail, temperror and permerror independently even if aligned DKIM yields DMARC pass.

Repeat for each materially different routed domain or group. Also check legitimate bypass traffic so an SPF edit does not accidentally break it. Verify encryption through the separate approved Paubox workflow; neither spf=pass nor dkim=pass says whether content was encrypted in transit or delivered through the secure message center.

Paubox's encryption user guide, describes ordinary encrypted delivery and a secure-message-center notification for recipients whose services cannot accept TLS-encrypted email. Where applicable, test those recipient experiences separately using synthetic content under the approved encryption plan. Do not infer either experience from DNS or DMARC alone.

Retain DMARC policy and verify alignment

DMARC, RFC 9989, passes when either SPF or DKIM passes with alignment to the visible From domain. Relaxed alignment generally allows the same Organizational Domain; strict alignment requires exact domain equality. Do not silently change adkim=s or aspf=s to make a new route pass.

For a hypothetical visible From care@example.com, a passing intended Paubox signature with d=news.example.com aligns in relaxed mode but not strict mode. A passing intended d=example.com matches in both. Likewise, a passing envelope at news.example.com does not satisfy aspf=s for From example.com. These are illustrative identities, not measured Paubox outputs. Identifier alignment

Check the existing applicable DMARC policy, including inheritance for subdomains. Preserve established quarantine or reject protection while fixing the route. A missing TXT response at _dmarc for one subdomain is not proof that no policy applies.

Only where no applicable policy exists, and the domain owner approves a monitoring phase, create one TXT policy at _dmarc for the chosen domain beginning v=DMARC1; p=none. Append ; rua=mailto: followed by an approved aggregate-report destination. Confirm that the mailbox or service is provisioned. If its destination is in a different Organizational Domain from the policy domain, the report-generating receiver must check DNS authorization supplied by the report-destination operator. A destination within the same Organizational Domain is excepted; a different hostname alone is not external. RFC 9990, Section 4. DNS authorization does not replace the domain owner's privacy approval of aggregate metadata sharing, recipients, access and retention. Do not send reports to a copied tutorial address.

For clarity, an apex From domain of example.com uses the full owner _dmarc.example.com, usually entered as _dmarc in that zone. A From subdomain of news.example.com uses _dmarc.news.example.com: enter _dmarc.news when editing the parent example.com zone, or _dmarc when editing a separately delegated news.example.com zone. These are owner-name examples, not instructions to override an existing applicable policy. Confirm whether your DNS host appends the zone name before saving.

Review all legitimate senders before advancing enforcement. The current standard removed pct, so do not rely on that obsolete tag for percentage-based rollout. RFC 9990 specifies aggregate reports. RFC 9991 covers failure reporting, which can disclose personal or message data. In healthcare environments especially, do not add ruf or upload headers containing sensitive information without approved privacy handling.

Separate Email API and Marketing instructions

The Email API REST setup guide, uses Settings > Domains for domain registration and SPF-based verification, followed by product-scoped API credentials and DKIM setup. It explicitly directs customers to support for DKIM on additional domains or subdomains. This support-managed branch is not a reason to guess a key or reuse a different domain's configuration. A domain showing Verified in the API settings is not the same as proof of a passing DKIM signature. The API guide requires a subscription or trial and notes an initial 24-hour security hold for new Freemium accounts. Treat its proposed SPF Required Value as a reviewed merge, not permission to delete other senders. API and Marketing credential scopes cannot share one key; credential provisioning belongs to the authorized developer, not DNS troubleshooting.

The Marketing DKIM guide, also generates unique domain values and requires DNS publication before enabling its DKIM control. In the Marketing account, use the profile menu → Account settings → DKIM settings, select the domain and Generate DKIM Key, publish its unique DNS values, then set DKIM Enabled to Yes. Follow that product's current control labels and test a Marketing message. Do not assume a successful Suite mailbox test covers API-generated mail, Marketing or Webmail.

Troubleshooting Paubox authentication

Keep one acceptance row per route with the tenant/platform and owner, selected domain and issued record references, DNS check and signing times, harmless test identifiers, expected/observed SPF and DKIM identities/results, trusted DMARC, separate encryption evidence, reviewer and unresolved exceptions. Mark untested fields pending.

For support, collect the affected product, route, domain, timestamp, sanitized receiver results and issued selector. Do not include patient message content, API secrets or private keys. Preserve a working route while making a targeted correction; do not remove all SPF authorizations or reduce DMARC protection as a broad rollback.