GoodTime SPF, DKIM and DMARC setup, step by step

GoodTime's documented company-domain email setup uses three CNAME records, followed by verification with your GoodTime Customer Success Manager (CSM). Publish the two DKIM aliases and the gtmail alias for your approved sending domain, then have the CSM verify the GoodTime back-end configuration. Do not add a guessed GoodTime or SendGrid SPF include to your main domain.

This guide covers native candidate email from an existing GoodTime HIRE account. It does not configure the individual-mailbox Candidate Inbox/Chrome extension, standalone GoodTime MEET, new calendars, or SMS/WhatsApp. DNS resolution and CSM verification are necessary checkpoints, but the final authentication check is an actual intended message with aligned, passing DKIM and a trusted receiver's DMARC pass.

The operative procedure is GoodTime's CNAME setup guide, together with its separate IT setup and back-end verification instructions.

Confirm the route and approvals first

Start with the recruiting owner, the domain's DNS administrator and the CSM. Confirm the exact company domain that should appear in the sender address, the existing GoodTime account, and the native candidate-email route. If several domains or subsidiaries are involved, treat each approved sending domain separately. Do not assume that authenticating a parent domain automatically configures every child domain or alias.

The distinction between routes matters:

GoodTime's Candidate Inbox documentation expressly distinguishes individual email-account access through the Chrome extension from the company-level HIRE connection. Its permission guide identifies MEET as a standalone tool that does not connect to the ATS.

Use people who already have the required authority. The public authentication pages do not establish a universal subscription-tier requirement or a self-service activation permission. If the route or account eligibility is unclear, have the CSM resolve it before publishing. Do not upgrade a plan, grant a role or switch the sending route simply to follow a tutorial.

Before changes, save a copy of the existing DNS records, current sending-domain decision and CSM instructions. Check whether another system already uses any of the three proposed names. Creating an alias authorizes a provider-controlled destination for that name, so the domain owner must approve it even when the destination is in official documentation.

The three records GoodTime currently publishes

GoodTime publishes the following requirements for this native route. The destination values below are fixed constants in that first-party procedure, not tenant keys reconstructed from a screenshot. Replace COMPANYDOMAIN with your exact approved domain. Do not paste the placeholder itself.

Source: GoodTime's current DNS table.

Copy the complete destination as a hostname, without https://, a URL path, spaces or quotation marks. Follow your DNS editor's convention for a final dot. Do not change gt to s1, replace the numeric destination with another SendGrid account, generate your own key, or paste a public key into these CNAME fields.

If the CSM supplies a different account-specific packet, stop and reconcile it with the CSM. Preserve the exact approved packet and its scope rather than mixing two configurations. A different account, product or changed provider instruction is not permission to derive new targets yourself.

Where SPF fits

The published GoodTime procedure does not instruct you to add a separate apex SPF TXT record. Keep the required gtmail CNAME, but do not infer the message's actual envelope identity merely from that name. Ask the CSM to confirm the native configuration and inspect smtp.mailfrom in an authorized delivered message.

SPF checks the SMTP envelope MAIL FROM identity, or HELO in relevant cases, not automatically the address shown in From. The evaluated owner must have at most one selected v=spf1 policy. Preserve existing legitimate authorizations and qualifiers; never replace the main domain's SPF or add a second policy because a generic SendGrid example suggests one. A CNAME owner must not also receive an SPF TXT record.

If a separately approved change to an existing SPF policy becomes necessary, validate the whole evaluation chain. The limit is ten evaluated DNS-dependent terms, including nested include, a, mx, exists, ptr and redirect processing, not simply ten visible includes. An all mechanism makes redirect ineffective. Preserve the deliberate meaning of -all, ~all or ?all; none is a delivery guarantee. These are protocol safeguards, not additional GoodTime setup steps. See RFC 7208.

Publish at the correct authoritative DNS location

Make the change at the DNS service that actually hosts the relevant authoritative zone. A registrar's record editor is not necessarily authoritative. Check existing nameservers and any child-zone or _domainkey delegation before deciding where to enter a record. Do not move nameservers, remove a delegation or alter DNSSEC.

The table below uses documentation-only example.com and recruit.example.com. The CNAME destinations remain the published GoodTime constants above; these examples explain owner names, not a new recommendation to change your sending domain.

For the second DKIM selector, substitute gt2 in the corresponding DKIM examples. If _domainkey.recruit.example.com is itself delegated, its relative selector inputs are gt and gt2. The separate gtmail record belongs in its own authoritative zone, not inside _domainkey.

An editor that expects full names needs the full owner instead. Inspect the saved record to prevent a doubled suffix such as gt._domainkey.example.com.example.com.

At each exact CNAME owner, stop if a TXT, A, AAAA, MX, existing CNAME or delegation conflicts. Do not delete a live record to make room. Have the affected service owners and CSM agree a supported arrangement. These instructions do not replace the domain's inbound MX records and do not authorize root-mail migration.

Keep the required CNAME answers visible

These aliases are not website proxy records. In Cloudflare, use DNS only, not Proxied, for the GoodTime aliases. Where a per-record Flatten setting is available, turn it off for these records, and ensure applicable whole-zone settings do not flatten them. The required result is that DNS can return the intended CNAME aliases, rather than only substituted IP addresses.

Cloudflare documents default apex flattening, optional all-CNAME flattening, and same-zone behavior that can ignore the usual setting. The GoodTime owners above are not apex names and their published targets are external, but existing DNS arrangements still need inspection. Coordinate any shared-setting change with the DNS owner. If mandatory behavior or a delegation cannot preserve the required answer, stop for a supported configuration rather than inventing a switch or changing the whole zone blindly. See Cloudflare's proxy status and CNAME flattening setup guidance.

Check publication, then request CSM verification

After saving all three records, compare their full owners, types and targets with the approved configuration. If you use command-line DNS tools, these are read-only examples. Replace the example domain before querying; they do not configure GoodTime or send email.

dig +short CNAME gtmail.example.com
dig +short CNAME gt._domainkey.example.com
dig +short CNAME gt2._domainkey.example.com

For the documented setup, the respective CNAME answers should name the three corresponding targets in the DNS table. No real results are asserted here. If answers are missing or different, inspect authoritative DNS, suffix handling, conflicting records, proxying and flattening. Compare authoritative answers with recursive caches before assuming that more waiting is the solution.

GoodTime does not publish a guaranteed completion time in this procedure. Allow for the actual TTL and caching behavior, then give the recruiting contact the exact domain and publication outcome. The contact coordinates verification with the CSM. GoodTime's IT setup instructions separately say the CSM verifies the configuration on the GoodTime back end.

Obtain that confirmation before calling the native integration ready. There is no established self-service Activate button or universal green-status label in the operative procedure, so do not substitute a different product's controls. A successful DNS lookup is not confirmation that GoodTime is using the intended identity to sign messages.

Confirm the actual native sender

Authentication must cover the domain the recipient will actually see. Review the intended recruiter/coordinator sender with the account owner and CSM, including any existing directory alias.

GoodTime's Team tab guide describes Send Emails From as the place to choose a preferred email when a user has multiple directory aliases. Its role table permits Team management for Admin and Super Admin, while company-wide integration settings have a narrower Super Admin boundary. Use an already authorized administrator to review the existing profile; do not grant new permissions or create a mailbox/alias as an authentication shortcut.

Keep changes limited to the approved sender decision. The same profile contains externally visible nicknames, activity status, availability, reminders and other settings. They are not part of DNS authentication. If the chosen alias uses another domain, confirm that domain's native authentication separately before using it.

A delivered message that still uses a provider no-reply From may demonstrate a functioning fallback, but it does not prove your intended company-domain route is authenticated. Likewise, changing a display name or Reply-To does not establish DKIM alignment.

Preserve DMARC policy and alignment

Find the policy applicable to the intended visible From domain, including inherited policy. Retain its protection, alignment modes and authorized report destinations. Do not add a child p=none record that weakens an inherited policy, change adkim=s or aspf=s merely to make a test pass, or copy a reporting address from an example.

For the newly configured branded DKIM route, require a passing intended GoodTime signature whose d= domain aligns with the intended From domain. Under strict DKIM alignment the domains must match exactly. Relaxed alignment uses the applicable Organizational Domain relationship. The selector name is not the aligned identity. The same strict-versus-relaxed distinction applies to the authenticated MAIL FROM domain for SPF. A child envelope domain does not automatically satisfy strict SPF alignment.

DMARC can pass through aligned SPF even when DKIM fails. That is not sufficient acceptance for this DKIM setup. See RFC 9989 and EmailAuth's raw DKIM versus aligned DKIM results for the separate signature and policy checks.

Only when there is no applicable policy

If no direct or applicable inherited policy exists, and the domain owner approves a first monitoring policy and monitoring plan, a starting TXT value is:

v=DMARC1; p=none

This is not a replacement for an existing policy, and by itself it does not request reports. Publish only one DMARC policy at the applicable owner.

Add rua only with a real, authorized reporting destination and an approved privacy/data-sharing decision. If the reporting destination's Organizational Domain differs from the Organizational Domain of the domain where the DMARC policy was discovered, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain is excepted; a different hostname alone is not enough to make it external. RFC 9990 section 4 defines this check. The authorization record uses the domain where the policy was retrieved, which need not be the report recipient's domain or every message's exact From domain. DNS authorization does not replace the owner's approval to share reporting data.

Verify an actual message without changing a candidate workflow

Prefer an owner-authorized, recently delivered native HIRE message to a controlled mailbox, sent after the CSM confirmed the configuration and using the exact intended From domain. Keep any personnel data private. An old message from before activation, a mailbox-webmail send, a Chrome-extension message or a MEET invitation is not a substitute.

If no suitable message exists, coordinate a separately approved synthetic native test with the CSM and account owner. Confirm the route, sender, recipient and all side effects before it is sent. Every recipient, CC/BCC address and calendar attendee must be controlled and approved. Do not schedule a real interview, change a real candidate's stage, trigger reminders, send an NDA, or contact an applicant merely to test DNS. The public procedure does not establish a generic Send Test button; if a safe native test path cannot be arranged, leave message acceptance pending.

For the selected message:

1. Obtain its original headers inside the receiving mailbox, not a forwarded copy or pasted header fragment from the sender.
2. Have the receiving administrator identify the authentication results generated by that receiving service's actual processing infrastructure. Confirm how it removes or disregards untrusted incoming Authentication-Results, using that service's documentation or message trace. A familiar authserv-id string or header position alone is not proof; ignore attacker-supplied results. This boundary is described in RFC 8601.
3. Record the visible From domain, actual smtp.mailfrom/Return-Path, and each relevant DKIM d=/s= pair with its verification result. Identify the intended GoodTime signature rather than choosing whichever unrelated signature happens to pass.
4. Require that intended signature to pass and align under the effective policy, plus trusted receiver dmarc=pass. Investigate SPF separately even if DKIM supplies the passing DMARC path.
5. Keep a minimal private acceptance record: route, domain, CSM confirmation, message time, intended signature and receiver results. Do not upload raw candidate correspondence or full headers containing personal data to a public checker without separate authorization.

GoodTime's delivery troubleshooting page describes EMAIL COMMUNICATION in an existing event's side panel. Sent, delivered and opened events can help locate the message, but they are not DKIM or DMARC results. Not opened does not prove spam placement. Authentication also cannot guarantee an inbox tab or recipient engagement.

Troubleshoot the failed checkpoint

Roll back deliberately and keep the evidence current

If acceptance fails, pause the affected native sending through the existing operational process and coordinate recovery with the recruiting owner and CSM. Do not disconnect all GoodTime integrations, revoke mailbox access, delete calendars or change company-wide scheduling settings as a DNS rollback.

Restore only changes you can identify from the saved before-state, after checking dependencies. The three aliases may support other approved users on the same domain. Removing them while mail is active can break authentication. Keep existing SPF authorizations, DMARC protection, inbound MX and delegations intact. Do not enable an unapproved no-reply or individual-mailbox route merely to get a message out.

Recheck the account and exact records when the CSM changes the service configuration, a sender domain changes, or DNS is moved. Review the native message evidence again after a meaningful change; the previous successful sample does not certify all future messages or every GoodTime product.

Sources and documentary review

GoodTime's current help pages expose relative update labels that differ between retrieved views; no absolute vendor update date is inferred from them. The procedure is based on the complete current textual requirements, not an inaccessible historical illustration or an untested account.

• GoodTime: CNAME entries for native company-domain email
• GoodTime: IT setup and CSM back-end verification
• GoodTime: Team profile and sender alias
• GoodTime: user permission boundaries
• GoodTime: candidate email delivery diagnostics
• GoodTime: separate Candidate Inbox mailbox route

This is documentary setup guidance. No customer account, DNS change, message send or delivery result was tested for this guide.