Agillic SPF, DKIM and DMARC setup, step by step

Agillic's standard email-domain setup uses a new, unused subdomain, the DNS records supplied in Settings → System Settings → Domains, and an SSL certificate configured with Agillic. Publish the sending-domain CNAME, DKIM CNAME and ownership TXT shown for your instance, then complete SSL before expecting Verified status. Agillic documents SPF and DKIM as handled by this standard setup; it does not provide a universal root SPF include in that procedure. Check DMARC and a delivered message separately. Agillic verified-domain instructions.

Scope: the standard managed email-domain workflow

This guide covers Agillic's native marketing email using a dedicated subdomain of your organization's existing domain, such as news.example.com. It also explains the additional domain requirements for Agillic's transactional-email channel.

It does not cover moving an active website or employee-email domain to Agillic, a custom apex-domain arrangement, or configuring a separate SMTP relay. Agillic says nonstandard domain arrangements need a different setup through its support team. SMS-domain registration and domain-based unsubscribe migrations are separate tasks. Domain-selection requirements.

Older domain-and-brand material describes verification as recommended and uses older menus. For the standard route here, follow the current dedicated procedure, which requires a verified domain, rather than relying on the older optional-verification wording. Older domain-and-brand context.

Before you start: choose a subdomain with no existing workload

Choose an unused subdomain under a domain your organization controls. Agillic explains that its standard configuration points web and email traffic for that hostname to Agillic. Reusing an active hostname can disrupt an existing website or mail service.

Before selecting news.example.com, inventory its DNS and ownership:

• Does it already host a website, tracking service or mailbox domain?
• Does it contain A, AAAA, MX, TXT or CNAME records for another service?
• Is the subdomain delegated to separate nameservers?
• Is any current campaign, integration or unsubscribe flow dependent on it?
• Which people can change its DNS and the intended Agillic environment?

A missing web page alone does not prove a hostname is unused. Save the existing zone data and resolve ownership with the relevant administrator. If the hostname is active or ambiguous, choose a different unused subdomain or obtain an Agillic-supported custom design. Do not delete records simply because a verification dialog suggests an old record is in the way.

Confirm access to the intended Staging or Production instance and to the authoritative DNS provider. Public documentation does not establish your particular contract entitlement or access role. Arrange a monitored reply address and a sender-domain migration plan before enabling validation across existing emails.

1. Add the domain in the intended Agillic environment

1. Log into Staging or Production, as appropriate for the configuration being prepared.
2. Open Settings.
3. Under System Settings, open Domains.
4. Enter the chosen subdomain in both From: domain name and Link domain name.
5. Select the plus icon to add it. Repeat for additional approved subdomains.
6. Open the i icon beside the domain to display its DNS configuration.

A new domain initially showing Failed is expected: DNS and certificate setup are still incomplete. Confirm the environment and exact domain before copying the records. Do not assume that a change in Staging has also completed Production. Agillic domain creation.

2. Publish the instance-issued DNS records

The official DNS dialog illustration shows this pattern. The actual values must come from your domain entry.

The illustration includes an agillic selector and an _agauth ownership label. It also shows regional target examples. These are not universal values to reconstruct from memory or a screenshot. Copy all records from your current i dialog. Official DNS-record illustration.

Avoid owner-name and CNAME conflicts

For a signing domain of news.example.com, these are DNS-name mappings, not permission to use that domain or to create a new delegation. Replace ISSUED_SELECTOR with the exact account selector and preserve the issued type and complete target/key.

Keep existing NS and DNSSEC delegations. A parent-zone record below a delegation is not a substitute for publication at the real authority. DKIM owner construction, relative DNS names.

The sending-domain CNAME at news.example.com belongs under relative news in the parent zone. A separately delegated zone at that exact hostname has required apex NS/SOA records and cannot simply host an ordinary CNAME there. Obtain an Agillic-supported design rather than removing delegation or substituting an address alias. The DKIM mappings above describe lookup authority, not proof that a particular alternative topology is supported.

Publish CNAME targets as DNS hostnames, without https:// or a URL path. Keep required CNAMEs visible in DNS: an HTTP proxy or CNAME-flattening feature can prevent the expected alias response. Use the provider-supported DNS-only configuration rather than adding an unverified CDN layer.

A CNAME cannot coexist with ordinary A, AAAA, MX or TXT data at the same owner. Records at different descendants, such as _dmarc.news.example.com, are a separate matter. If a requested CNAME collides with existing data, identify the dependency rather than deleting it. CNAME restrictions.

Agillic notes that existing records may prevent its dialog from showing the required settings or stop CNAME validation. Treat that as a reason to investigate the selected hostname. A new unused subdomain is safer than dismantling an active service to satisfy the standard setup.

For Cloudflare, set required aliases to DNS only. Where available, leave each record’s Flatten option off and check that CNAME flattening for all CNAME records is off; the zone-wide setting overrides per-record choices. Coordinate shared-setting changes with the DNS owner first, then query actual CNAME answers. Cloudflare flattens apex CNAMEs by default and flattens same-zone targets regardless of the flattening setting. Its zone-wide flatten-all option cannot be overridden per record. Where the sender requires a literal CNAME answer, leave the applicable record-level Flatten control off and ensure zone settings do not conceal it. If mandatory apex/same-zone behavior or shared settings prevent that answer, stop and coordinate a supported design; do not delete a delegation or disable shared controls blindly. Cloudflare exact flattening behavior. Cloudflare proxy behavior, Cloudflare flattening controls.

Preserve legitimate NS delegation for child zones, including _domainkey, and their DNSSEC records. Publish each selector in the zone actually authoritative for it, coordinating with that zone’s operator. Do not remove delegation merely to add a record in the parent. If a delegation conflicts with the requested CNAME owner, obtain a supported alternative. DNS-host delegation guidance.

Keep the three records distinct

The ownership TXT is not SPF and is not a DKIM public key. The DKIM CNAME points receivers toward a provider-managed key. Do not generate an unrelated key, publish a second competing value at the selector, or convert the requested CNAME into a TXT record. DKIM verification needs the public key corresponding to the private key Agillic actually uses. DKIM DNS lookup.

3. Complete SSL before expecting Verified status

Green DNS checks do not complete Agillic domain verification. The current instructions say the domain can still show Failed until its SSL certificate is configured.

Agillic offers a support-managed Let's Encrypt option, described as free. Arrange that with Agillic Support for the chosen subdomain and wait for confirmation that certificate setup is complete. This avoids treating a private-key exchange as an ordinary DNS task. Agillic SSL requirement and managed option.

The documentation also describes supplying a certificate and private key in PEM format. If your organization needs that route, have its authorized security or certificate administrator agree on the transfer process with Agillic. Never publish a TLS private key in DNS, put it into an ownership TXT value or include it in routine diagnostic screenshots.

Confirm that the domain itself now shows Verified. HTTPS availability and DKIM signing are different checks: the certificate enables the domain's web/link use, while a delivered email supplies evidence of actual mail authentication.

4. Update current From addresses before enabling validation

Agillic explicitly warns that enabling Enable domain name validation without verified domains causes emails to fail during send-out. It also rejects From domains that do not match a verified domain.

Before enabling that control:

1. Inventory current emails and flows that can send from the environment, including scheduled and automated messages.
2. Update their From addresses to the intended verified domain.
3. Check saved templates and operational processes that create new emails.
4. Confirm a valid verified domain exists for every affected sending workflow.
5. Then enable Enable domain name validation as the documented procedure directs.

For example, verifying news.example.com does not make sender@example.com the same configured From domain. Use an address such as sender@news.example.com when that is the domain selected for the email.

In the email editor, expand Email settings, choose the verified domain from the Sender email dropdown, and enter the local part of the address in the corresponding field. Confirm the resulting full address before scheduling. Validation sequencing and sender selection.

5. Understand what SPF and DMARC still need to prove

Agillic's current guide states that SPF and DKIM are handled with the standard domain setup. The documented DNS pattern does not establish a universal include: mechanism to add at your root domain. Do not invent one or add TXT data alongside the sending-domain CNAME.

SPF checks the sending IP against the SMTP MAIL FROM domain (or the HELO identity in applicable cases, such as a null reverse-path), not simply the visible From address or link domain. The reviewed Agillic bodies do not specify the exact delivered envelope identity for every account. Read smtp.mailfrom from a representative recipient's results before deciding which SPF owner to investigate. SPF records do not inherit from the parent domain. SPF identities and record processing.

If a separately agreed configuration calls for an SPF TXT edit, keep one SPF policy at the required owner and preserve other legitimate senders. Evaluate the complete policy against SPF's maximum of ten DNS-querying terms, including nested includes and redirects, not merely the number of includes visible in the first record. If the evaluated owner is provider-managed, coordinate the correction with Agillic rather than changing an unrelated apex policy. SPF DNS limits.

Any all mechanism makes redirect= ignored, regardless of order; mechanisms after all are never evaluated. Preserve a legitimate redirect-based policy instead of adding an all that silently disables it. SPF all and redirect processing.

Preserve direct and inherited DMARC protection

For From addresses at news.example.com, inspect _dmarc.news.example.com first. If there is no valid direct policy, DMARC discovery may find the organizational-domain policy through a DNS tree walk. Review its applicable subdomain handling, including sp where present. Do not assume that a missing direct TXT means no policy applies. Current DMARC discovery.

Agillic's starter p=none advice is not a reason to replace established enforcement. A new subdomain-specific monitoring record can override protection previously inherited from the parent. Retain the intended policy and reporting destinations, and publish no second competing DMARC policy at the same owner.

DMARC needs at least one aligned pass: either the passing DKIM d= domain or the passing MAIL FROM domain must align with the visible From domain. Relaxed alignment uses the organizational domain determined by DMARC discovery; strict adkim=s or aspf=s requires exact domain equality. Confirm which mechanism supplies the pass instead of equating DNS verification with alignment. DMARC alignment rules.

Only when no direct or applicable inherited policy exists, the owner approves it and someone will review the reports, a first monitoring TXT value may be:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the mailbox address after mailto: with the approved monitored address, not a second mailto: URI. From example.com uses full owner _dmarc.example.com, relative _dmarc in example.com. From news.example.com uses full owner _dmarc.news.example.com, relative _dmarc.news in its authoritative parent zone or _dmarc in a separately delegated news.example.com zone. Do not create a child monitoring override of inherited protection. Current DMARC publication and discovery.

For illustrative From sender@news.example.com, a passing intended signature with d=example.com aligns under relaxed adkim when both share Organizational Domain example.com, but fails strict alignment. A passing d=news.example.com signature aligns under either mode. Do not infer the emitted signing domain from the link-domain setting; observe the actual signature.

Use only approved report recipients and review their access and retention arrangements. Aggregate reports expose sending IP addresses, domains, message counts and authentication outcomes. The external-authorization test in RFC 9990 compares the organizational domain of the domain from which the policy was retrieved with the organizational domain of the reporting URI’s host. Different hostnames under the same organizational domain do not alone trigger that test; when those organizational domains differ, the report-generating mail receiver must check DNS authorization published by the report-destination operator. For a policy retrieved for example.com using rua=mailto:reports@reports.example.net, authorization is normally a TXT containing v=DMARC1 at example.com._report._dmarc.reports.example.net, published by the report receiver. Use the actual policy domain, not automatically the From subdomain. External report authorization.

Transactional email needs a fresh verified domain

Agillic treats transactional email as a separate channel. Use a fresh domain that has not previously sent email, satisfying the current dedicated guide's restriction. Do not repurpose a marketing sending hostname. Current dedicated-domain requirement.

Complete the same verified-domain prerequisites first. The transactional instructions then describe selecting Use for Transactional Emails and reviewing its terms and conditions. The authorized account owner should accept those terms only after confirming that the intended use and account permissions fit. Domain-name validation must be enabled for this channel. Domain-validation requirement, Agillic transactional-email setup.

Keep its sender configuration and delivered-message checks separate from marketing. A transactional label does not remove consent or content obligations applicable to a particular message, and this guide does not determine its legal classification.

Verify DNS, platform activation and delivered results

Public DNS checks

Replace these example names with the exact owners shown by Agillic. The selector and ownership label below illustrate the documentation, not fixed values for every instance.

dig +short NS example.com
dig +short CNAME news.example.com
dig +short CNAME agillic._domainkey.news.example.com
dig +short TXT agillic._domainkey.news.example.com
dig +short TXT _agauth.news.example.com
dig +short TXT _dmarc.news.example.com
dig +short TXT _dmarc.example.com

Confirm that the two aliases reach the expected targets, the DKIM lookup resolves to a public key, and the ownership TXT matches the instance-issued token. Compare authoritative and recursive answers when caching is suspected. For a delegated subdomain, use its own authoritative zone. DNS success still leaves the SSL and Verified status checks to complete in Agillic.

Real-message checks

Once the account is ready and your team authorizes testing, send a representative email through the actual Agillic workflow to a mailbox you control. Open its raw source. Use receiver-controlled authentication diagnostics, or have the receiving mail administrator establish that its trust boundary strips or clearly distinguishes externally supplied Authentication-Results before relying on the result. A familiar authserv-id or header position alone does not establish provenance. Authentication-Results trust boundary.

Capture the visible From domain, actual smtp.mailfrom, SPF result, DKIM d= and s=, and the receiver's DMARC result for header.from. Completion requires trusted receiver dmarc=pass for the intended header.from and a pass from the intended branded DKIM signing domain that aligns under the applicable adkim mode. A DMARC pass supplied only by SPF does not prove the branded DKIM setup is complete; neither does a DKIM pass from an unrelated signer. Look up the selector from the real signature if it differs from the example. Check SPF independently, even when DKIM provides the aligned pass. An intended-branded-DKIM test also fails if the provider rewrites From to an unrelated domain merely to obtain DMARC pass.

Repeat for Production, transactional email and materially different sender domains as applicable. A preview or isolated test route may not represent an active flow. Record the configuration and result date without retaining unnecessary recipient or message content.

For a message with several signatures, the EmailAuth raw-versus-aligned DKIM guide explains why an unrelated signer’s pass is not the branded path you are trying to validate.

Troubleshooting Agillic domains