Re:amaze SPF, DKIM and DMARC setup, step by step

Re:amaze’s default delivery and its Gmail custom SMTP connection are different sending routes. For branded replies through an existing Google Workspace mailbox, authenticate the domain in Google Workspace, connect that same mailbox to the Re:amaze email channel, then verify a real reply delivered through the connection. There is no universal Re:amaze DKIM key to paste for this route. Re:amaze Gmail custom SMTP instructions.

This guide covers an existing, approved Re:amaze channel with working inbound forwarding and a matching Google Workspace custom-domain mailbox. It does not configure consumer Gmail branding, Microsoft 365, arbitrary SMTP servers, aliases, groups, new forwarding destinations or mailbox migrations. Google’s authentication must already be configured or completed separately by the authorized Workspace administrator before switching customer replies.

Choose the sending route before changing DNS

Re:amaze’s SPF and deliverability article says its default messages are signed by Re:amaze and that a default setup does not require your own SPF change. Its Gmail sender-requirements article nevertheless recommends an optional Re:amaze SPF authorization. Neither statement supplies a customer-domain DKIM issuance and activation procedure.

The same documentation says Re:amaze SPF authorization is unnecessary when using custom SMTP. Do not add an include for Re:amaze merely because staff compose replies inside its interface. Identify which server actually transmits those replies and which envelope domain it uses.

Forwarding and display names are separate again. Re:amaze’s forwarding article describes customers seeing a connected address, whereas its authentication guidance describes provider-domain defaults. Do not resolve this by assuming every account uses identical raw From headers. Inspect the delivered message. A familiar display name or Reply-To address is not proof that your domain signed it.

Prepare the existing channel and Google sender

Before connecting, record the approved brand, Re:amaze channel, external mailbox, intended visible From address and responsible administrators. The mailbox chosen in Google must match the channel’s connected email address. Re:amaze’s actual connection screenshot explicitly requires this match; selecting whichever Google account is already signed in is not sufficient.

Confirm these prerequisites:

• The existing channel receives mail through its approved forwarding arrangement. The Re:amaze forwarding instructions are a separate inbound setup, not DKIM activation.
• The Workspace mailbox belongs to the custom domain you intend customers to see. Do not substitute a personal Gmail account, unverified alias or unrelated administrator mailbox.
• The authorized Workspace administrator has checked domain authentication for this sender and any existing outbound gateway.
• The owner has approved Re:amaze’s access to this particular Google account and the permissions presented during connection. A previous forwarding approval does not automatically authorize a new sending integration.
• You have a controlled external recipient, a non-sensitive test conversation and permission to test this channel without contacting a customer.

Keep the current routing and authentication settings in the change record. Do not change MX, nameservers, DNSSEC, forwarding filters or security controls to follow this article. If the existing forwarding or mailbox is not approved and working, stop here and have its owner complete that separate task.

Confirm upstream SPF and DKIM in Google Workspace

Use the existing Google Workspace SPF and DKIM guide for the domain-administration workflow, alongside Google’s current primary instructions. Connecting Re:amaze does not generate a new Google DKIM key or automatically turn on domain signing.

SPF belongs to the actual envelope domain

Google’s SPF setup documentation gives this example for a domain whose only sender is Google Workspace:

v=spf1 include:_spf.google.com ~all

This is a conditional Google-only example, not a replacement instruction for a mixed-service domain. An administrator must inventory all legitimate senders and inspect the actual SMTP MAIL FROM domain before deciding which policy applies. SPF is not automatically evaluated at the visible From domain, and a child envelope domain does not simply inherit an apex SPF record.

Publish at most one v=spf1 policy at each evaluated owner. Preserve other authorized senders, existing qualifiers and unrelated TXT records. A second SPF policy can cause permerror. Count the ten evaluated DNS-dependent mechanisms/modifiers, including nested processing, rather than ten visible includes. An all mechanism makes redirect ineffective regardless of where redirect appears. Do not append a new include after a terminating all or casually replace an existing redirect design. SPF softfail is not a universal command forcing spam placement. SPF specification.

DKIM requires publication and signing activation

Google’s current DKIM instructions separate generating a domain’s public record, publishing it and selecting Start authentication. The authorized administrator should first check whether the existing domain already signs successfully; do not rotate a working key just to connect Re:amaze.

For an incomplete Google setup, follow that primary workflow rather than inventing a Re:amaze selector: select the correct domain in Apps > Google Workspace > Gmail > Authenticate email, obtain its generated TXT hostname and complete public value, publish them at the authoritative DNS service, then activate signing in Google. Google recommends 2048-bit keys where supported. Its documented active status is Authenticating email with DKIM. Key generation and activation require the appropriate administrative privileges; do not broaden an operator’s privileges as a troubleshooting shortcut.

Use the generated selector, not a screenshot’s key. Preserve all tags in the public TXT value and never publish a private key. Account for DNS-host suffix rules: the full owner must be the issued selector beneath _domainkey of the selected domain, without duplicating the zone suffix. Preserve existing selectors and delegated namespaces. If that owner is already a CNAME or belongs to another signer, stop rather than overwriting it. DKIM record specification.

Public DNS publication and Google’s active status are prerequisites, not final proof that a Re:amaze reply uses this signature. A direct Gmail test helps establish the upstream baseline; the connected application path still needs its own test.

Connect the approved Gmail mailbox in Re:amaze

Follow the documented Gmail connection procedure. Despite its historical setting-up-your-dkim URL, the current article is a Gmail custom SMTP connection guide, not a native Re:amaze DNS-key generator.

1. Open Settings > Email Channels and locate the correct channel under the intended brand.
2. Open Custom SMTP Off for that channel. If it already has another active connection, stop and review the planned route change instead of replacing it silently.
3. In the SMTP Settings dropdown, choose Gmail. The separate Custom SMTP option is not this walkthrough.
4. Select Connect Gmail Connection.
5. On Google’s account chooser, select the exact approved Workspace mailbox matching the connected channel address.
6. Review the requesting application, account and actual permissions. The documented consent example grants sending on the account’s behalf. Continue with Allow only when the account owner or administrator has approved that access; unexpected or broader permissions require review first. Do not bypass Workspace restrictions or share credentials with support.
7. After returning to the channel settings, confirm the banner reports successful Gmail SMTP setup. If connection fails or returns to the wrong channel, resolve that state before sending replies.

The documentation does not require typing a universal SMTP host, port, app password or DKIM private key in this Gmail connection. Do not substitute a password-based tutorial for this account-connection flow. The success banner confirms the connection step, not your domain’s delivered-message alignment or inbox placement.

Verify a real Re:amaze reply, not just the connection banner

Use a controlled conversation and an external mailbox you own or have permission to use. Google specifically cautions that sending to yourself is not a valid DKIM verification test. A different controlled Gmail or Workspace recipient can be used; the operator must be able to inspect its received original message.

Have that test recipient contact the existing channel, then reply through Re:amaze using the intended brand and connected mailbox. Avoid real customer threads, live orders, confidential content and bulk sends. Check for automations or additional recipients before initiating the test. This is a suggested controlled acceptance test, not a claim that this project performed one.

At the receiving service, inspect its original message and the authentication assessment produced inside its known receiving infrastructure. Establish which systems generate those results and how they remove or distinguish externally supplied Authentication-Results. A header’s position or familiar authserv-id text alone does not establish trust; ignore results inserted by the sender or other untrusted sources. Authentication-Results trust boundaries.

Save the approved visible From, envelope domain, intended Google DKIM signing domain d=, selector s=, SPF result and DMARC result. Require all of the following before accepting branded DKIM:

• The visible From is the intended approved Workspace address, not a rewritten provider address.
• The intended Workspace domain’s signature passes. An unrelated Google or Re:amaze signature is not enough.
• That passing signature aligns with the From domain under the effective DMARC adkim mode.
• The trusted receiver reports dmarc=pass for that intended From domain.

Relaxed DKIM alignment uses the same Organizational Domain; strict alignment requires identical domains. DMARC can pass through either aligned SPF or aligned DKIM, but SPF-only success does not validate this DKIM configuration. See raw DKIM results versus aligned policy results and the current DMARC specification.

Record SPF separately even when DKIM makes DMARC pass. A forwarding hop may change SPF observations, and a gateway may alter signed content. Do not disable filtering or protective controls merely to obtain a green test; have the security owner approve any necessary equivalent-control design.

Preserve the domain’s DMARC policy

This connection is not permission to weaken existing protection. Inspect the direct policy at _dmarc of the intended From domain and any applicable inherited policy, including child-domain treatment and alignment modes. Preserve authorized report destinations. Do not create a duplicate record, copy a p=none example over enforcement, or add a child override that weakens an inherited policy.

This procedure assumes the domain already has an approved authentication and DMARC plan. If no applicable policy exists, have the domain owner complete that separate deployment before treating this route as accepted. No new report recipient, percentage rollout or enforcement change is required merely to connect Gmail.

If the owner separately changes aggregate reporting, the receiving reporter must check DNS authorization for a destination in a different Organizational Domain from the domain where the DMARC policy was found, including an inherited policy. Destinations within that policy domain’s Organizational Domain are excepted. Protocol authorization does not replace permission to share reporting data. DMARC aggregate-report authorization.

Troubleshooting by observation