Rocketseed SPF, DKIM and DMARC setup, step by step

To authenticate mail processed by Rocketseed, confirm the actual outbound route and service region, merge the applicable Rocketseed SPF authorization into the correct existing policy, and ask Rocketseed to enable branded DKIM. Rocketseed supplies a public DNS TXT value, checks it after publication, then agrees a time to activate signing. Test after branding and the final outbound gateway, not just before Rocketseed processes the message. Rocketseed SPF instructions, Rocketseed DKIM activation.

This guide covers the authentication boundary for Rocketseed cloud and Rocketmailer sending, including mail that passes through additional services. It does not assume all deployments have the same last outbound server or custom Return-Path feature.

No account settings, public customer DNS or delivered messages were tested for this article.

Why authentication must be checked after branding

A visual email signature and a cryptographic DKIM signature serve different purposes. The first adds business information or design to the message. The second authenticates a signing domain and selected message data. Adding or changing signed body content after signing can invalidate DKIM. An earlier mailbox-platform signature may therefore not survive the final route. DKIM signed-data verification.

Map the path before selecting records:

Mailbox or application → Rocketseed processing → any later relay/gateway → recipient

This is a planning diagram, not a claim that every installation uses this exact topology. For each deployed path, identify:

• The original mailbox/application platform and sending domain.
• Rocketseed cloud, Rocketmailer or another confirmed deployment.
• The assigned sending region.
• Where branding is applied and where branded DKIM is applied.
• Whether mail returns to the mailbox platform or goes through another gateway.
• The final connecting IP and SMTP MAIL FROM domain seen by the receiver.

Include shared mailboxes, aliases and automated streams that actually traverse the service. A message that bypasses Rocketseed may authenticate perfectly while proving nothing about the branded route. Likewise, a footer alone does not reveal the final sending server.

Prepare the domain and DNS change

You need the Rocketseed account/contact owner, an administrator for the authoritative DNS zone, the mailbox or gateway administrator, and permission to run controlled test messages. Export existing SPF, DKIM and DMARC records before making any approved change.

Obtain separate routing-owner approval before changing connectors, bypassing a relay, or disabling branding during recovery. Those changes alter the tested delivery path and are not implied by DNS repair permission. Local allowlisting or a bypass is not a substitute for final external authentication on the intended branded route; revalidate that route after any approved recovery change.

Record the three domains separately:

SPF authorizes the connecting server for the SMTP envelope identity. It does not inherently authenticate the visible From address. If the actual MAIL FROM belongs to Rocketseed or another provider, that provider controls its SPF; adding a mechanism to your own root domain cannot make the provider’s domain align with yours. Ask Rocketseed what envelope identity the route uses and whether an aligned custom identity is supported. No universal self-service Return-Path workflow is established by the public instructions reviewed here. SPF identities, DMARC alignment.

Select the applicable regional SPF mechanism

Rocketseed’s public SPF page identifies the following mechanisms for Rocketseed cloud and Rocketmailer. Confirm the service’s sending region, rather than using the location of the employee editing DNS. Rocketseed regional SPF table.

Do not add all regions just to be safe. If the assigned route is not covered or differs from the table, obtain current instructions from Rocketseed rather than guessing a global mechanism from an older article.

The official examples omit a terminal all mechanism and use loose PTR terminology. They are not complete replacement policies for an organization’s existing email. SPF is published as TXT, not as a reverse-DNS PTR record, and the SPF ptr mechanism is discouraged by the standard. Use the verified regional authorization within a deliberately reviewed policy. SPF publication, SPF ptr guidance.

Merge without removing other senders

Suppose an organization’s only existing sender is Microsoft 365, the evaluated owner is example.com, and Rocketseed confirms that its Americas route also needs authorization there. An illustrative change is:

Before: v=spf1 include:spf.protection.outlook.com -all
After: v=spf1 include:spf.protection.outlook.com include:spfus.rocketseed.com -all

This demonstrates preserving the original sender and -all. It is not a universal Rocketseed record and has not been DNS-tested. Retain your real baseline’s authorized services and policy, whether different mechanisms or ~all are used. Advanced redirect= policies need an evaluation-order review rather than a mechanical append.

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 only one SPF policy at the evaluated owner. Other unrelated TXT records are allowed. Check all nested DNS-querying mechanisms and modifiers against SPF’s ten-term evaluation limit. Counting just the visible include strings misses nested costs. Do not flatten provider includes into IP addresses without a supported maintenance plan, since their sending infrastructure can change. SPF record selection and lookup limits.

Request Rocketseed DKIM and coordinate activation

Rocketseed documents three stages: request signing from its contact or account manager; receive and publish a new TXT value; then let Rocketseed verify the record and arrange the start of outbound signing. Publishing DNS does not itself activate the signer. Official DKIM procedure.

For a usable change request, ask for:

1. Every sending domain and route covered by the activation.
2. The intended branded signing domain (d=) and exact selector (s=).
3. The fully qualified DNS owner, record type, complete public value and TTL guidance.
4. Confirmation that the record is valid and which time marks the start of signing.
5. Rotation, overlap and rollback instructions if replacing an existing key.

The public page does not provide a universal selector or reusable public key. Use only the material issued for the actual domain. Generating an unrelated key online does not configure Rocketseed’s signer with the matching private key. Never put private keys in DNS or support attachments. DKIM public-key model.

Publish the exact owner and complete public key

If Rocketseed hypothetically issues selector rs2026 for example.com, the owner would be rs2026._domainkey.example.com. rs2026 is invented for this naming example, not a Rocketseed default. Replace it with the issued selector.

If sales.example.com has an NS delegation, its provider is authoritative for these child-zone records. Publishing lookalike records in the parent interface may not affect the answers receivers use. An interface requiring a full name needs the FQDN instead; check the saved result for a duplicated suffix. DNS zone and name rules, master-file name conventions.

At an existing delegated _domainkey.sales.example.com authority, full owner rs2026._domainkey.sales.example.com maps to relative rs2026. That is still an invented naming example: use the actual issued selector and public TXT value, preserving NS delegation and other selectors. Relative names.

Inspect any existing record at the issued selector before saving. Do not overwrite an active key or replace a CNAME without coordinating its owner. CNAME and ordinary TXT data cannot coexist at the same owner. A long public key may occupy several character strings inside one TXT resource record; their concatenation must equal the issued value. Splitting it into independent TXT records is not equivalent. CNAME coexistence, TXT format.

Keep the old baseline for recovery, but coordinate any restoration with Rocketseed. If the signer has changed private keys, restoring an older public key can make verification worse.

Preserve DMARC and use reporting to watch the whole route

DMARC passes when at least one authenticated identity aligns with the visible From domain. Under relaxed alignment, shared organizational domains can qualify. Under strict alignment, the domains must match exactly. With From: person@example.com, DKIM d=example.com matches both; d=sales.example.com matches relaxed but not strict alignment. SPF’s aspf and DKIM’s adkim are separate settings. DMARC alignment rules.

Retain any established policy and reporting destination. Review a subdomain’s explicit policy and applicable inherited policy. Do not create a second DMARC record to add Rocketseed.

Only where no policy is established and an initial monitoring rollout is approved, a record may have this illustrative shape:

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

Use a working, approved mailbox or your reporting service’s exact assigned destination, not the example. An external report destination can require authorization by that destination’s operator. Review aggregate reports by sending source and identifiers, with attention to volumes and changes after activation. Reports do not contain a guaranteed receipt for every message. DMARC aggregate reports.

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. For an owner-approved first policy, full apex owner _dmarc.example.com is relative _dmarc in example.com; full child owner _dmarc.sales.example.com is _dmarc.sales in that parent or _dmarc in the delegated sales.example.com zone. Preserve applicable direct/inherited policy and the existing authority.

Do not weaken an existing enforcement policy to compensate for one incomplete signer. A stronger policy also requires a separate domain-wide review, especially for employee mail that may traverse forwarders or mailing lists. Domains publishing p=reject must not depend solely on SPF; valid DKIM is required by current interoperability guidance. DMARC interoperability considerations.

Verify public DNS before testing delivery

Use the actual envelope owner and issued selector in these read-only examples. They illustrate a route whose envelope and signing domain are both example.com:

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

Check authoritative nameservers and an independent public resolver. For a delegated child, use that child’s authoritative servers. Require one valid SPF policy with the approved merge, a complete DKIM public key matching Rocketseed’s instructions, and the intended DMARC policy. Compare the concatenated TXT value, not line wrapping.

Inspect the full DNS response if a short query is empty. Distinguish an incorrect name, NXDOMAIN/no data, a temporary failure and stale cached data. Rocketseed’s SPF guidance allows up to 48 hours for propagation. Validate the correct authoritative records first, then account for TTLs and negative caching; waiting cannot correct the wrong owner or a broken delegation. This DNS allowance is separate from the DKIM activation time agreed with Rocketseed.

Then obtain Rocketseed’s validation and activation confirmation. Record the activation time so test messages can be distinguished from mail sent before signing began.

Test after branding and after the final gateway

Once implementation is authorized and signing is active, send a harmless specimen through the ordinary branded route to a controlled external mailbox. Repeat for each distinct From domain and route. Do not use customer information, real contracts or recipient lists as test content.

Inspect the final receiver’s trusted Authentication-Results and raw signature headers. Record:

• Visible From and SMTP MAIL FROM, using the receiver’s SPF identity where available.
• Each DKIM signing domain and selector, not only the first signature.
• SPF, DKIM and DMARC outcomes.
• Final route, Message-ID and UTC time for correlation.

Only receiver results within the trusted receiving boundary are evidence of its checks. A copied or sender-inserted header is not proof. Authentication-Results trust.

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.

Acceptance criteria

The intended branded signature must report dkim=pass and align with From under the effective policy. The receiver must report dmarc=pass. A passing unrelated provider signature or an aligned SPF result must not be allowed to conceal a missing or broken Rocketseed branded signer.

For a message with multiple signatures, EmailAuth’s DKIM selector guide explains how to keep each signing domain and selector together when deriving its public-key lookup. Do not pair one signature’s selector with another signature’s domain.

SPF should authenticate the actual direct-delivery envelope route. A provider-managed envelope domain can pass SPF without aligning; document that identity and confirm branded DKIM supplies alignment. By contrast, fail, softfail, permerror and temperror are not merely “unaligned SPF.” Investigate and resolve direct-path errors, then retest even if DKIM already makes DMARC pass. For an indirect forwarded route, document the cause and supported handling separately from the direct baseline.

This acceptance standard is deliberately stricter than DMARC’s either-mechanism pass rule: it proves the requested branded signing setup works. A green DNS check, a successful internal delivery or an attractive footer cannot replace that proof.

Troubleshoot the boundary that failed

An IP change affects SPF. It does not alone invalidate DKIM, whose verification depends on the key and signed data. Conversely, adding another SPF include cannot repair a DKIM body hash changed by a downstream disclaimer. SPF results, DKIM verification.

A post-branding failure example

Suppose a fictional test message is From person@example.com. Its earlier mailbox-platform signature fails after content processing, the expected Rocketseed selector is published, and Rocketseed signing is not yet active. The setup is incomplete. Do not declare success based on DNS or assume that SPF will rescue it. Complete the coordinated activation and obtain a fresh external specimen. This is an illustrative diagnosis, not an observed customer result.