rezora SPF, DKIM and DMARC setup, step by step

To authenticate a sending domain in rezora, review the existing SPF policy for rezora’s documented include:sendgrid.net mechanism, request domain-specific DKIM CNAME records from rezora Support, and publish the approved records. Then contact Support again: rezora must validate the records and enable DKIM. DNS publication alone does not finish the job. Finally, verify a controlled message sent through the intended rezora route. Official SPF instructions · Official DKIM instructions

This guide covers rezora’s native outbound email service, which documents SendGrid as its sending partner. It is not a guide to opening a separate SendGrid account or changing your organization’s mailbox provider. The published procedure is support-assisted; it does not establish a universal selector, CNAME target, record count, subscription entitlement or self-service signing switch.

Before you change anything

Have the domain owner approve the exact sending domain and the DNS change. Coordinate with the person who manages its authoritative DNS and the rezora account owner. Record the intended visible From address, current DNS records, effective DMARC policy, existing selectors and any delegated DNS namespaces. Preserve that baseline for recovery.

A domain can already be authenticated for another application without being authenticated for rezora. Equally, a domain’s existing SPF and DMARC policies may serve many applications. Do not replace them with a tutorial example or remove another sender’s records.

Use an approved test recipient under your control. This guide does not authorize a campaign, customer email, new account, credential change or support request on your behalf. Authentication does not replace consent, unsubscribe, list-quality and campaign-owner launch checks.

1. Review SPF without breaking existing senders

Rezora’s official SPF page names this mechanism:

include:sendgrid.net

That is a mechanism to consider within the applicable SPF policy, not a complete record to publish by itself. The official example also includes a, mx, an Outlook authorization and ~all; those are example-domain choices, not requirements for every rezora customer. Do not copy its illustrative sending IP into your policy or treat testing that IP as proof of your own sending route. Rezora SPF setup

SPF checks the SMTP envelope sender, usually shown as smtp.mailfrom in trusted authentication results. It does not directly check the visible From address. Review the domain rezora asks you to configure, then inspect the actual route’s envelope identity during acceptance testing. Adding an include at your apex cannot make a different provider-owned envelope domain align with your From address.

At each relevant owner, keep one TXT record beginning v=spf1. If that policy already authorizes SendGrid, do not duplicate the mechanism. Otherwise, have the DNS owner merge the authorized change while retaining other legitimate senders and the existing policy’s intended behavior. Mechanisms after a matching all are not evaluated. A redirect modifier is ignored when an all mechanism is present; do not casually combine or replace them.

The SPF limit is ten evaluated DNS-dependent terms, including nested lookups, not simply ten visible includes. Check the resulting policy’s evaluation path before publication. Preserve existing qualifiers unless the domain owner separately approves a policy change. SPF qualifiers are not a guarantee of inbox delivery or rejection. SPF evaluation rules

For an approved SPF TXT owner, these examples show DNS-panel naming, not a claim that rezora requires every listed domain:

Use the actual zone’s naming rules. Do not add the zone suffix twice or publish in a parent zone that is no longer authoritative for a delegated child.

2. Obtain the complete DKIM packet from rezora

Ask rezora Support for DKIM setup for the approved domain. Its instructions identify support@rezora.com as the support contact and state that rezora will generate and provide domain-specific CNAME records. Obtain the complete owner, record type and target for every issued record. Do not generate an unrelated key or substitute records from a generic SendGrid tutorial. Rezora DKIM setup

Only public DNS data belongs in DNS. Never publish a private signing key, account credential or token. The published rezora procedure does not require you to obtain a private key.

Rezora may also supply a DMARC record. Treat that separately from the DKIM packet: an existing direct or inherited DMARC policy must remain intact. Receiving a proposed record is not approval to overwrite a policy or send reports to a new recipient.

3. Publish the issued CNAMEs at the correct authority

Copy each account-issued CNAME exactly, following your DNS host’s rules for full versus relative names and trailing dots. The examples below use SELECTOR only as a placeholder. Replace it with the actual issued selector; do not create a selector named SELECTOR.

Preserve existing NS delegations, other selectors and shared dependencies. If the issued owner is already occupied, stop and reconcile the conflict with the DNS owner and rezora. A CNAME owner cannot also hold a TXT, A, AAAA, MX or a different CNAME. Do not delete a record or delegation just to make the form save. DNS alias rules

Publish authentication aliases as DNS records, not HTTP redirects. Where your DNS host offers an HTTP proxy, use DNS-only for the issued aliases. Check whether CNAME flattening would conceal the literal CNAME response required for provider validation. Where applicable, turn the record’s Flatten control off and ensure relevant whole-zone settings do not suppress the aliases. Some hosts have mandatory apex or same-zone behavior; if it cannot preserve the required literal response, stop and coordinate a supported configuration rather than inventing a switch or disabling a shared setting globally. Cloudflare’s named controls are specific to Cloudflare, not universal DNS-panel fields. Cloudflare CNAME-flattening setup

These are read-only query templates. Replace every uppercase placeholder; repeat for every issued CNAME:

dig @AUTHORITATIVE-NS CNAME ISSUED-DKIM-OWNER
dig @RECURSIVE-RESOLVER CNAME ISSUED-DKIM-OWNER
dig @RECURSIVE-RESOLVER TXT RESOLVED-DKIM-TARGET
dig @AUTHORITATIVE-NS TXT APPLICABLE-SPF-OWNER
dig @RECURSIVE-RESOLVER TXT APPLICABLE-SPF-OWNER

Compare the exact CNAME owner and target with the issued packet at authoritative and recursive DNS. Then confirm that the target chain resolves to the public DKIM key rather than a loop, missing record or unrelated key. A visible alias alone is not proof of usable key resolution. Allow for actual cache lifetimes, not an assumed universal propagation deadline.

4. Ask rezora to validate and enable DKIM

After publication, inform rezora Support that the records are in place. The official procedure explicitly requires rezora to validate them and enable DKIM for the domain. Wait for that confirmation. A successful DNS lookup does not prove the sending service has begun using the key. Rezora activation step

Keep the approved sending identity and route unchanged during this check. If Support reports a mismatch, compare its expected domain, owner, type and target against the authoritative answers before editing anything else. Do not switch mailbox routing or weaken DMARC to work around incomplete activation.

5. Prove authentication on the intended rezora route

After provider confirmation, send a controlled message through the actual approved rezora workflow, using the unchanged intended From address and a valid test recipient. Do not substitute a message sent directly from your ordinary mailbox.

Establish the receiving service’s known processing boundary and its documented treatment of externally supplied Authentication-Results: removal, ignoring or clear separation from its own results. Use only results generated inside that trusted boundary. Header position or a familiar authserv-id string alone is not proof; an attacker can insert convincing-looking fields. If provenance is unclear, use an administrator-verified message trace instead. Authentication-Results trust model

Acceptance requires all of the following:

• The intended rezora-issued signature matches the active configured d= signing domain and s= selector, and the trusted receiver reports dkim=pass for that signature.
• That signing domain aligns with the unchanged approved visible From domain under the effective adkim mode. A different aligned signer, a provider-rewritten From or SPF-only DMARC success does not complete rezora branded DKIM setup.
• The trusted receiving system reports dmarc=pass for that intended From domain.
• SPF is checked separately against the actual smtp.mailfrom identity. Diagnose authorization fail or softfail, transient DNS temperror, and policy/duplicate-record/lookup-budget permerror separately even when aligned DKIM supplies DMARC’s pass.

Relaxed alignment permits matching Organizational Domains; strict alignment requires exact domain equality. Under aspf=s, a child envelope domain such as bounce.example.com does not align with From domain example.com, even if SPF passes. Under adkim=s, a child signing domain likewise does not align with its parent From domain. These sources do not establish a rezora custom MAIL FROM configuration procedure, so do not promise one. DMARC identifier alignment · Why a custom MAIL FROM affects SPF alignment

Preserve DMARC and approve reporting separately

Check both direct and applicable inherited policy before creating anything. Do not downgrade an existing policy, duplicate it, remove approved report destinations or automatically follow a generic progression to enforcement. A single passing rezora sample does not inventory your other legitimate senders.

Only when no direct or applicable inherited policy exists, and the domain owner explicitly approves an initial monitoring policy with an appropriate review plan, this minimal TXT value can be considered:

v=DMARC1; p=none

For example.com, the full owner is _dmarc.example.com, relative _dmarc in the example.com zone. For news.example.com, the full owner is _dmarc.news.example.com, relative _dmarc.news in the parent zone or _dmarc in a separately delegated news.example.com zone. An explicit child policy can override inherited behavior, so do not add it casually. No reporting address is included in this example; an approved monitoring plan must still establish who reviews the relevant authentication evidence.

If reports are desired, use only an actually provisioned, owner-approved and monitored destination. When the report URI host’s Organizational Domain differs from the Organizational Domain of the domain where the DMARC policy was found, the report-generating receiver checks DNS authorization. A destination within that same Organizational Domain is excepted; a different hostname alone is not enough to require external authorization. This protocol check does not replace permission to share potentially sensitive report data with the recipient. RFC 9990, section 4

Troubleshooting and safe recovery

For recovery, coordinate with the domain and campaign owners. Pause only affected sends if approved, preserve evidence, and restore only the previously approved configuration that is understood to be safe. Coordinate key changes with rezora so queued messages and shared selectors are not stranded. Retest the failed route and a known-good control after correction; never intentionally fail live DNS or use a customer campaign as the test.

Documentation review and testing boundary

The two core rezora setup pages did not display an article update date in the captured bodies. This is a documentary guide, not a report of changes to your account: no Support contact, customer DNS edit, message send, live implementation test or publication was performed.