Rule SPF, DKIM and DMARC setup, step by step

Rule’s current domain-authentication instructions use two CNAME records: one at the rm hostname and one for the keyse DKIM selector. Publish the approved records, complete Rule’s validation process, and check the actual branded signature in a delivered message. Do not replace your domain’s existing SPF or DMARC policy with a generic tutorial example.

On this page

• Which Rule workflow this covers
• Record the approved configuration
• Publish the two CNAME records
• Keep SPF and DMARC changes separate
• Complete provider validation
• Prove branded DKIM on delivered mail
• Troubleshoot without damaging other senders
• Frequently asked questions
• Sources and verification limits

Which Rule workflow this covers

This guide covers email sent through Rule using an organization-controlled sender domain. The rulemailer.se targets belong to the documented Rule setup; this is not a guide for an unrelated product with “Rule” in its name, nor for SMS or RCS authentication. Rule’s public setup page does not specify a universal subscription entitlement, regional variant or account-role name. Confirm those details with the account owner if their configuration differs. Rule domain-authentication instructions.

You need an authorized Rule operator and the administrator of the relevant authoritative DNS zone. The ability to edit a campaign does not establish permission to change shared DNS. Obtain the domain owner’s approval for the proposed scope, especially if another service already occupies either hostname.

Record the approved configuration

Before editing, record the intended visible From address, existing aliases and TXT records, applicable DMARC policy and affected campaign or automation paths. Save the old values and agree on rollback ownership. Include legitimate services that share the domain and any separately delegated _domainkey namespace.

The public instructions describe these records for a sender domain represented here by the placeholder example.com:

rm.example.com. CNAME to.rulemailer.se.
keyse._domainkey.example.com. CNAME keyse._domainkey.rulemailer.se.

Rule’s example TTL is 3600 seconds. Replace only the placeholder sender domain; compare the targets with the current account or Support instructions before publication. Do not invent a tenant identifier or generate an independent DKIM key. The published CNAME points to provider-managed key material, not a private key you must upload. Official Rule record values.

Do not treat a DNS example as permission to change inbound routing, parent nameservers, DNSSEC, credentials or unrelated records. If an existing rm name carries another service, stop for an owner-approved supported alternative rather than overwriting it.

Publish the two CNAME records

Enter the record types exactly. Some DNS interfaces append the current zone name, while others expect complete names. The destination must remain the provider hostname, not a URL with https:// or a path.

For example.com, the relative names in its own zone are rm and keyse._domainkey. For a sender domain news.example.com, the mapping changes:

• In the parent example.com zone: rm.news and keyse._domainkey.news.
• In the separately delegated news.example.com zone: rm and keyse._domainkey.
• If _domainkey.news.example.com is delegated separately, its DNS administrator handles the DKIM owner keyse within that namespace. The rm record remains outside that namespace.

Always compare the resulting fully qualified owner with the intended name. Preserve a legitimate delegation rather than deleting it to make the panel accept a local record. A signature with s=keyse and d=news.example.com looks up keyse._domainkey.news.example.com; the selector is not itself the signing domain. DKIM lookup construction.

At a CNAME owner, do not add another CNAME or conflicting TXT, A, AAAA or MX records. Investigate existing dependencies first. In particular, a DMARC TXT policy does not belong at keyse._domainkey.

Proxy and flattening checks

Mail-authentication aliases must not become HTTP-proxied addresses. Choose DNS-only where the host offers a proxy. Where Rule’s verification requires the literal alias, ensure DNS actually returns that CNAME rather than only flattened address records.

Cloudflare can flatten individual records, all CNAMEs, the zone apex, or same-zone targets under different rules. Turn the applicable per-record Flatten setting off where available, and ensure zone-wide settings do not conceal these aliases. Review dependencies before any broader change. If mandatory apex or same-zone behavior conceals the required literal alias, stop and coordinate a supported alternative design; do not invent a control, move parent nameservers or remove shared delegations. Cloudflare’s current flattening rules.

Keep SPF and DMARC changes separate

The official section titled SPF and MX describes the rm CNAME above. It is not an instruction to add an arbitrary MX record or blindly replace the apex SPF policy. Inspect the actual envelope identity used by your Rule mail before deciding which SPF owner is relevant. Rule’s current configuration.

SPF evaluates SMTP MAIL FROM, not automatically the visible From. HELO is also an SPF identity in applicable cases, including a null reverse path. If a verified account-specific route requires an SPF TXT edit, preserve existing legitimate authorizations and qualifiers in one v=spf1 policy at the evaluated owner. Do not create a second policy or put a conflicting TXT next to the rm CNAME. SPF identities.

The SPF limit covers ten evaluated DNS-dependent mechanisms and modifiers, including nested lookups. It is not a count of ten written includes. When an all mechanism is present, redirect is ignored. A fail qualifier does not independently determine whether a recipient rejects, accepts or filters a message. Lookup limits, redirect.

Use the correct DMARC owner

Rule’s record table correctly identifies _dmarc as the policy owner, but its later DMARC subsection repeats the DKIM hostname. Do not follow that misplaced hostname: use the policy domain’s _dmarc owner, not the signing-key owner. Rule source, including the conflicting instructions, DMARC policy location.

Inspect direct and applicable inherited policies first. Preserve existing enforcement, alignment settings and authorized report recipients. Only where no applicable policy exists, the domain owner approves and an appropriate monitoring plan is ready, a minimal initial record can look like this:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none;

In the example.com zone, the relative owner is _dmarc. This is a conditional monitoring example, not a required replacement. For news.example.com, the relative owner is _dmarc.news in example.com or _dmarc in a delegated child zone. Avoid duplicate policies. No reporting address is configured by this example.

Do not copy the third-party rua or ruf addresses from a source page. Aggregate-report recipients and the data-sharing purpose require the domain owner’s approval; provision the approved recipient and monitor successful report receipt. Failure reporting needs a separate privacy assessment. Compare the report URI’s destination-host Organizational Domain with that of the domain where the policy was found, which can differ from the visible From domain. A destination in a different Organizational Domain requires the report-generating receiver’s DNS authorization check, while the same Organizational Domain is excepted. Different hostnames alone do not determine this. DNS authorization does not replace owner approval. External aggregate-report destinations.

Before stronger enforcement, inventory legitimate senders and examine reports and indirect routes. RFC 9989 section 7.4 warns about forwarding and mailing-list interoperability; a p=reject domain must apply valid DKIM rather than rely solely on SPF. General-user domains with mailing-list users need that specific risk assessment. Do not use obsolete pct rollout guidance or weaken an existing policy simply to troubleshoot Rule. DMARC interoperability.

Complete provider validation

Compare authoritative answers with a public resolver after publication. These commands use the placeholder domain and do not represent test results:

dig +short CNAME rm.example.com
dig +short CNAME keyse._domainkey.example.com
dig +short TXT _dmarc.example.com
dig @AUTHORITATIVE-NS CNAME keyse._domainkey.example.com
dig @PUBLIC-RESOLVER-IP CNAME keyse._domainkey.example.com
dig @PUBLIC-RESOLVER-IP TXT keyse._domainkey.rulemailer.se

Replace AUTHORITATIVE-NS with the actual authoritative server for that owner and PUBLIC-RESOLVER-IP with the chosen recursive resolver. The first two answers should match the approved targets. Follow the DKIM alias to its target and confirm it resolves to a usable DKIM public-key TXT record, not merely an existing alias. Preserve the complete tagged public value; never obtain or publish a private key. If they do not, inspect suffix duplication, delegation, proxying, flattening, caching and record conflicts. A TTL is a caching parameter, not a promise that every resolver updates at an identical time.

Rule directs customers to its DNS checker and then Support for validation, identifying each configured domain. Complete that provider step for all intended domains, not just the first. Share only approved configuration information with verified Support. Do not include private keys, account passwords or customer message content. This article does not send a support request for you. Rule validation procedure.

Prove branded DKIM on delivered mail

Provider validation is one checkpoint, not the final acceptance test. Have the authorized campaign operator send harmless content to controlled valid recipients through each intended Rule production path. No customer sends were performed in preparing this guide. Check the original received message, retaining both a failed sample and a known-good comparison where possible.

Use authentication results generated inside the actual receiving service’s known processing boundary, with its documented handling of externally supplied Authentication-Results. Header position or a matching authserv-id string can be forged and is not enough. Ignore untrusted externally inserted results and involve the receiver’s administrator if their provenance is unclear. Authentication-Results security.

Accept the new branded DKIM configuration only when all of these hold:

1. The delivered visible From remains the approved sender address. A provider-owned rewrite is not success for that brand identity.
2. The intended Rule signature is present and the receiver reports dkim=pass for its signing domain and selector.
3. That same passing signature aligns with the approved From under the applicable DMARC alignment policy.
4. The trusted receiver reports dmarc=pass for that From domain.
5. SPF for the actual smtp.mailfrom identity is recorded and any error is diagnosed independently.

Relaxed alignment permits the applicable same-Organizational-Domain relationship; strict alignment requires an exact domain match. A child envelope domain does not establish strict SPF alignment with a parent From address. Conversely, SPF-based DMARC pass does not prove branded DKIM is working. Track each signature separately when multiple signatures appear. Raw DKIM versus aligned DKIM results.

Troubleshoot without damaging other senders

CNAME exists, DKIM is absent: confirm provider validation and the selected sender domain for the actual campaign. Do not add another selector at random. A key lookup is not proof that Rule signed the message.

DKIM exists but fails: use d= and s= from the failing signature to identify the exact DNS lookup. Check key availability and possible message modification after signing. A different provider signature’s pass does not repair the intended signature.

SPF fails: inspect authorization for the actual envelope identity rather than adding Rule to every domain. A temperror warrants investigation of transient DNS or evaluation failures and a retest. A permerror requires correcting structural problems such as multiple policies or excessive evaluated lookups. These remain issues even when aligned DKIM makes DMARC pass. SPF result definitions.

DMARC fails despite authentication: compare the passing signature or SPF identity against From and the actual strict/relaxed modes. Do not change the visible From or downgrade policy as an unapproved shortcut.

Another service stopped working: check whether its existing hostname, policy or delegated key namespace was overwritten. With the affected campaign owner’s approval, pause only the failing flow and restore the previously approved, known-good configuration. Preserve active selectors and shared dependencies while queued mail or other legitimate services still need them. Retest the failed route and a known-good route after recovery; preserve existing DMARC protection throughout.

Before launch, also check audience permission, unsubscribe operation and campaign reputation practices. SPF, DKIM and DMARC neither guarantee inbox placement nor prevent a compromised authorized account from sending unwanted mail.

Sources and verification limits

The current page contains no decisive setup screenshots needed to interpret these text-issued records. The domain checker was inspected without submitting a customer domain.

No account, DNS, support-message, live-send, mailbox-delivery, browser-render or website-publication test was performed. Resolve account-specific deviations with Rule before changing production. This guide is not a guarantee of availability on every plan or a claim that your domain is already authenticated.