Gladly SPF, DKIM and DMARC setup, step by step

To authenticate native Gladly Team email, an Administrator adds the sending domain in Settings > Channels > Email, publishes the account's SPF and DKIM TXT records, and waits for the domain to become Verified. Then add the actual email address as an Entry Point, confirm its Inbox, and activate only the approved forwarding route. DNS verification is not the final test: a delivered native message must carry a passing Gladly DKIM signature aligned with your visible From domain.

This guide covers Gladly Team, formerly Gladly Hero, using an existing, working mailbox on a domain your organization controls. It does not provision email hosting for a new bare domain, configure an external SMTP service, or cover the separate Gladly AI product. Gladly's domain setup and email-address prerequisites establish these distinct authentication and mailbox steps.

On this page

• Before adding the domain
• Add the exact domain in Gladly
• Publish SPF without replacing other senders
• Publish the issued DKIM TXT record
• Verify the domain
• Add the address and approve inbound routing
• Preserve or establish DMARC
• Test the actual Gladly sending path
• Troubleshooting
• Acceptance and rollback
• Frequently asked questions

Before adding the domain

Have an Administrator in Gladly Team and the administrator of the authoritative DNS zone coordinate the change. The instructions establish the role, not a universal subscription or regional entitlement. Confirm that your account exposes the native Email channel before proceeding.

Confirm that the intended support mailbox can already send and receive at its existing mail provider. Agree on its exact lowercase address, visible sender name, Gladly Inbox, responsible agents and approved forwarding destination. Keep a record of the existing SPF, DKIM, DMARC and mailbox-routing configuration for rollback. Gladly's address instructions explicitly require a functioning email address before adding it.

Make DNS changes where the authoritative zone actually lives, which may differ from the registrar or website host. For a delegated child domain or _domainkey namespace, identify the responsible child zone instead of creating ineffective records in its parent. Preserve existing NS delegations, MX, DNSSEC and unrelated records.

Do not invent receiving MX records. Gladly's configuration requirements mention additional MX considerations for some domains, but do not issue a universal receiving-mail target. A website or CNAME is not what makes a mailbox operational. If the proposed domain has no working mailbox, resolve its actual supported mail-hosting and routing requirements first; this guide's existing-mailbox workflow does not supply them.

Add the exact domain in Gladly

1. Open the menu, choose Settings, then Channels > Email.
2. Use the first-domain prompt or Add Domain for an additional domain.
3. Enter the intended domain using lowercase letters. Check the spelling and whether you mean the apex or a specific child domain before saving.
4. Choose Save and Continue to obtain its SPF and DKIM records.

A saved domain cannot be renamed or deleted through ordinary self-service controls. Gladly says uppercase corrections require Support and change the SPF/DKIM values. Do not add a second speculative domain or continue using an old packet after a correction. These constraints and the wizard sequence are documented in Add Email Domain.

Retain each issued type, full owner and complete value together. You can retrieve them later from Email > Domains, hover over the domain, open its menu, and select View SPF and DKIM values. Gladly specifies TXT for both records in Find SPF and DKIM TXT Values.

Publish SPF without replacing other senders

Gladly's documented native authorization uses this SPF mechanism:

include:mailgun.org

It is a mechanism to merge into the one SPF policy at the account-specified owner, not a second standalone SPF record. If that owner already authorizes your mailbox service or other senders, preserve those authorizations and the owner's approved ending qualifier. Gladly's requirements and domain instructions show different example endings, so neither example justifies blindly changing your current policy to -all or ~all.

If no SPF policy exists at the issued owner and the domain owner has approved a policy authorizing only this documented route, the requirements page's baseline is:

v=spf1 include:mailgun.org ~all

Do not use that baseline to erase other senders. If a policy exists, insert the authorization in the evaluated portion before its terminating all, after checking the complete policy. A redirect= design needs particular care: adding an all mechanism makes the redirect ineffective. Qualifiers affect an SPF result; they do not guarantee how every receiver delivers or rejects mail. RFC 7208 also limits evaluated DNS-dependent mechanisms and modifiers to ten, including nested lookups, not merely ten visible include entries.

Map the owner to the DNS editor rather than automatically choosing @. For an issued SPF owner example.com, @ is normally the relative name in the example.com zone. For support.example.com in that parent zone, the relative name is support; in a separately delegated support.example.com zone it is @. A full-name editor may instead require the entire owner. Check the resulting public name to avoid appending the zone twice.

SPF evaluates the actual SMTP MAIL FROM, usually reflected in Return-Path, or HELO in relevant cases. Publishing authorization at the configured domain does not establish the envelope identity of every delivered Gladly message. The cited Gladly instructions do not promise a universal MAIL FROM or strict SPF alignment.

Publish the issued DKIM TXT record

Use the actual account's complete public DKIM record. Do not copy an example key or derive a selector from a screenshot. Some Gladly illustrations display a domain.key label and escaped punctuation; those illustrations are not a substitute for the account-issued, standards-valid owner and value. If the current packet itself is malformed, obtain a corrected packet from Gladly rather than guessing a repair.

The lookup structure is SELECTOR._domainkey.SIGNING-DOMAIN. For example, if the issued full owner is SELECTOR._domainkey.support.example.com, its relative input is SELECTOR._domainkey.support in the example.com zone, or SELECTOR._domainkey in the delegated support.example.com zone. If _domainkey.support.example.com itself is delegated, publish in that authoritative namespace using its own relative name. SELECTOR here is a placeholder, not a value to publish.

Paste the full tagged TXT value, including the entire public p= key, without adding literal backslashes or dropping characters. A DNS editor may display one long TXT value as several quoted chunks; these must remain one logical record, not separate competing DKIM records. Private signing keys do not belong in DNS. See RFC 6376 for the lookup and public-key format, and EmailAuth's guide to finding a DKIM selector when checking the delivered signature later.

Check for an existing record or delegation at the issued owner before writing. Do not overwrite another sender's selector. A CNAME cannot coexist with this TXT at the same owner; resolve an ownership conflict with the DNS administrator and Gladly, not by deleting an existing dependency. The native workflow here uses TXT, so it does not require adding authentication CNAMEs or changing proxy/flattening settings. RFC 1034 explains the CNAME owner constraint.

Verify the domain

After publishing the records, continue with Next, then Done in the domain wizard. Gladly initially displays Unverified and documents that verification can take up to 72 hours. That is a verification allowance, not a promise of inbox placement.

To recheck, open Email > Domains, hover over the domain, open its menu and choose Check Verification Status. Continue when the domain shows Verified. If it does not, compare the current account packet with authoritative DNS and publicly cached answers before changing anything. Gladly's domain guide documents these labels and timing.

Although Gladly permits preparing an address before DNS verification, use the verified-domain sequence here to avoid an unfinished route. The platform's Verified label confirms its DNS check; it does not prove that your particular outgoing message was signed correctly.

Add the address and approve inbound routing

In Settings > Channels > Email, use Add Email Address or the initial address prompt. Enter the lowercase local part, choose the verified sending domain, and set the friendly sender name. Select Next, retain the unique forwarding address, then finish with Save and Close as shown in the dedicated Add Email Address instructions. An uppercase-address correction requires Support and changes that Entry Point's forwarding address.

Confirm the resulting Entry Point's destination Inbox under Settings > Orchestration > Entry Points. New entries use the Email channel's default Inbox unless configured otherwise. The Email section of Connect New Channels explains the routing and readiness sequence.

Forwarding is a separate customer-data-sharing and inbound-routing decision, not an automatic side effect of SPF/DKIM setup. Compare the exact generated destination, source mailbox, intended messages and Inbox with the organization's authorized routing plan. Only the mailbox administrator should activate the approved server-side route, and only after setup and agents are ready. A manually forwarded message is not equivalent to that route. Do not copy example destinations, broaden forwarding to unrelated mailboxes, bypass security gateways or disable spam controls merely to make a test succeed.

If a different Reply-To address is required, Gladly documents contacting Support to configure it, followed by the corresponding authorized forwarding setup. A Reply-To address affects where replies go, not the DMARC alignment identity. Do not silently replace the actual sender domain to conceal an authentication failure. See Add Email Domain.

Preserve or establish DMARC

Inspect the visible From domain's direct DMARC record and any applicable inherited policy before making changes. Preserve an existing protective policy and its authorized reporting destinations. Do not add duplicate DMARC records or weaken an inherited policy just because Gladly is a new sender. Current policy discovery and alignment rules are in RFC 9989.

Only if no direct or applicable inherited policy exists, the domain owner approves it, and someone will review the authentication evidence should a first monitoring policy be introduced:

v=DMARC1; p=none

Publish it as one TXT at _dmarc.FROM-DOMAIN. For From domain example.com, the full owner is _dmarc.example.com, normally entered as _dmarc in that zone. For support.example.com, the full owner is _dmarc.support.example.com: enter _dmarc.support in the parent zone, or _dmarc in a separately delegated child zone. Do not paste the placeholder FROM-DOMAIN. This baseline requests monitoring, not enforcement or automatic delivery.

Add rua only for an actual owner-approved report destination with an appropriate privacy and monitoring plan. A destination in a different Organizational Domain requires the report-generating receiver to check DNS authorization; a destination in the same Organizational Domain is excepted. This is not a rule that every different hostname is external. The rule is specified in RFC 9990, section 4. Protocol authorization does not replace permission to share reporting data.

Test the actual Gladly sending path

After authorized implementation, use controlled valid recipients and the actual native Team route. Check a real agent reply and any automated outgoing path you intend to use. Do not test by exposing customer correspondence or by sending through the ordinary mailbox provider instead of Gladly.

Inspect raw headers and the results produced inside the receiving service's known processing boundary, using its documented handling or removal of externally supplied Authentication-Results. A familiar authserv-id or a header near the top is not sufficient proof. Ignore attacker-supplied or otherwise untrusted result fields. RFC 8601, section 7.1 explains this boundary.

Require all of the following:

• The visible From is the intended organizational address, not a rewritten provider-owned substitute.
• The intended Gladly signature has dkim=pass. Its d= domain aligns with the visible From under the policy's adkim mode; its s= selector resolves to the intended current public key.
• The trusted receiver reports dmarc=pass. A pass through SPF alone does not prove that the newly configured branded DKIM route works.
• SPF is evaluated separately using the actual MAIL FROM. Record its result and alignment, including any fail, temperror or permerror, even when aligned DKIM makes DMARC pass.
• Approved inbound mail and replies reach the intended Gladly Inbox without a forwarding loop or unauthorized recipient.

Relaxed alignment permits the same Organizational Domain; strict alignment requires exact domain equality. A child envelope domain might align under relaxed SPF but not strict SPF. Do not promise strict alignment without inspecting actual identities. DKIM verification, DMARC acceptance, Inbox routing and delivery reputation are different checks. RFC 9989 governs the alignment comparison.

Troubleshooting

The domain remains Unverified

Retrieve the current values rather than relying on an old screenshot. Check the authoritative zone, full owner, TXT type, complete key, duplicate SPF records, a conflicting CNAME and cached answers. Use Check Verification Status after the corrected answer is visible. If public DNS matches and the documented window has elapsed, provide Gladly Support with the domain and relevant record details, not credentials or private keys.

DNS is verified but email does not appear in Gladly

Check the separate Entry Point, Inbox association, approved server-side forwarding and current destination. If an uppercase correction changed the forwarding address, reconcile the approved route. Do not treat this as a reason to add an invented SPF include or replace MX.

DKIM passes but DMARC does not

Compare the passing d= with the actual visible From and the alignment mode. A passing signature belonging to an unrelated provider domain is not sufficient. Confirm the message used the intended Gladly Entry Point rather than another route.

SPF fails while DMARC passes

Aligned DKIM can satisfy DMARC independently. Still diagnose SPF at the actual evaluated owner: fail indicates an unauthorized sending path for that policy; permerror can indicate invalid syntax, duplicate policies or a lookup-budget problem; temperror indicates a temporary evaluation problem. Do not “fix” a different envelope domain by repeatedly editing the visible From domain's SPF.

Acceptance and rollback

Accept the deployment only when the intended domain is Verified, the correct Entry Point and approved Inbox/forwarding route are ready, and controlled native messages satisfy the aligned-DKIM and trusted-DMARC tests above. Keep a dated record of the account packet, DNS changes and real delivered evidence. None of those live checks is claimed by this article.

If the route fails, pause the affected rollout and keep the previously approved support channel available. Restore only changes made for this rollout after checking shared dependencies. Removing a Gladly SPF mechanism must leave every other legitimate sender intact; removing a DKIM key prematurely can break verification of in-flight messages. Reverse forwarding only with the mailbox owner and preserve mail continuity. Because saved domains are not self-service removable, use Gladly Support for domain correction rather than inventing a delete/reset procedure.