Adestra SPF, DKIM and DMARC setup, step by step

Choose your Adestra domain model before changing DNS. An authenticated domain stays under your DNS management and uses Adestra's documented SPF authorization plus support-assisted custom DKIM. A delegated subdomain uses Adestra's CNAME or NS model, with the service supplying its underlying records. In either case, complete domain setup and signing activation, then verify a real campaign carries a passing, aligned signature for your intended brand. Authenticated domains, delegated domains

Adestra's publicly available current-path pages retain modification dates of April 16, 2019 and April 6, 2020 respectively. Confirm that your account still follows the described MessageFocus interface before making changes. This is a documentation-based guide; no customer account, DNS change, support request or campaign test was performed.

Select the correct domain model

An authenticated From domain and a delegated campaign domain solve different problems. Do not combine their records into one catch-all recipe.

Adestra recommends a subdomain for delegation and does not officially support delegating the root domain. Its delegated model covers campaign resources such as tracking and images as well as relevant mail records. Inventory everything already using the proposed name, including websites, replies, tracking, verification tokens and other senders. Adestra delegated-domain requirements

Record the account, domain model, visible From, campaign or automation route, DNS owner and expected signing domain. If your account differs from the published workflow, obtain its current instructions rather than borrowing another customer's selector or trying to recreate the interface from an old screenshot.

Configure SPF for an authenticated domain without replacing other senders

For authenticated domains, Adestra documents include:msgfocus.com in the domain's existing SPF policy. It then directs you to Admin → Domains → Authenticated → Create Domain, enter the domain and save. The domain overview and Test Domains provide configuration feedback. Custom DKIM for this model is an On Demand feature arranged through account management or support, not an assumed universal self-service button. Adestra authenticated-domain setup

First read the existing TXT records at the exact proposed owner. If an SPF policy is already present, add the required authorization to that one policy, preserving legitimate senders and the established terminal qualifier. Do not create a second v=spf1 record, copy a sample IP, or place an include after an all mechanism.

For example, an authorized change to an existing policy has this shape, not a complete policy to paste:

Existing legitimate authorizations + include:msgfocus.com + existing terminal policy

A new policy requires a complete sender inventory. A minimal Adestra-only example would exclude any other legitimate mailbox or application sender, so it is not appropriate as a universal apex-domain recipe. SPF has a ten-term limit for DNS-lookup-causing mechanisms and modifiers during evaluation, including nested processing; it is not simply a count of visible includes. Multiple policies and an excessive lookup budget can produce permerror. SPF record rules, lookup limits

Adestra's older page uses “SPF/Sender-ID” terminology. Follow current SPF evaluation rather than deploying a separate historical Sender-ID record. SPF checks the SMTP MAIL FROM identity, not automatically the visible From domain. An acceptable domain status does not prove that a campaign uses an aligned envelope. Inspect the receiving system's smtp.mailfrom after setup. SPF identities

Arrange authenticated-domain DKIM for each From domain

Ask Adestra for the exact signing domain, selector, DNS owner, record type and public value for your account, plus the activation/completion step. Its authenticated-domain documentation requires DNS configuration for every authenticated domain used for signing. Preserve that scope when requesting setup; one brand's key does not automatically configure another brand.

Do not publish a key generated by an unrelated online tool and assume Adestra holds its matching private key. The DNS key must correspond to the key actually used by the sending system. Only public values belong in DNS. DKIM signs selected headers and message content; it does not encrypt the message for confidentiality. DKIM specification

Use the exact issued record. If it is TXT, retain the whole public key as one TXT resource record, even if the DNS editor splits it into quoted strings. If Adestra supplies a CNAME for your supported account configuration, use the supplied hostname target, not a TXT key or web URL, and check for conflicting records at that owner. The published authenticated-domain page does not establish one universal selector or key value.

Configure a delegated subdomain as a separate workflow

Adestra documents CNAME and NS methods. The CNAME convention replaces dots in the full delegated name with hyphens and appends .msgfocus.com. For example, email.example.com corresponds to email-example-com.msgfocus.com. Confirm the selected name and target with your account manager before and after setup. Do not copy that example as your account's value. For NS delegation, obtain and verify the current Adestra nameserver set and coordinate service-side completion. Direct A-record substitution is not the documented supported alternative. Adestra delegation methods

The two DNS designs have different boundaries:

• CNAME: publish the alias at the exact unused child owner. A CNAME cannot coexist with ordinary TXT, MX or other conflicting data at the same owner. Do not add a separate SPF record there.
• NS: publish the child-zone delegation in the parent zone. For email.example.com, that normally means NS records at email inside example.com, not replacing example.com's authoritative nameservers. Records inside the delegated child are then answered by its authoritative service, not your old parent-zone copies.

Adestra says the delegated route serves relevant MX/TXT/SPF records and warns against adding extras. It does not provide ordinary inboxes for the delegated domain. Keep replies on a supported reply-handling route or an existing mailbox domain, and test that separately from DKIM. Adestra delegated-domain FAQ

After DNS setup, the documented application path is Admin → Domains → Delegated → Create Domain. Save the domain and inspect its configuration status. Administrative options include Create DKIM Keys and View DKIM; the domain list can activate or deactivate DKIM signing. Complete the account-specific custom-signing setup, verify the public record, then activate and select the configured domain in Campaign Options. The default signing domain is msgfocus.com when custom DKIM is absent. Domain registration and signing controls

For a CNAME-based setup on Cloudflare, keep the required alias DNS only and unflattened. Check both the record's Flatten option and any zone-wide flatten-all setting; DNS-only status alone does not ensure the CNAME is returned. Coordinate changes to shared zone settings with the DNS owner because other applications may depend on them. Verify that the actual authoritative zone returns the required alias; do not remove an intentional NS delegation to force a parent-zone record to appear. Cloudflare CNAME verification troubleshooting

For that CNAME branch, turn the per-record Flatten control off where available and ensure applicable zone settings preserve the literal issued alias. Cloudflare flattens apex CNAMEs by default and same-zone targets regardless of that setting. If mandatory behavior prevents the required answer, stop and coordinate a supported configuration with the DNS owner and Adestra; do not blindly alter shared zone settings or replace an NS delegation. These controls do not apply to Adestra’s separate NS-delegation branch. Cloudflare flattening behavior.

A tracking domain matching your brand does not, by itself, prove which d= value signs the message. Keep domain registration, campaign selection and signing activation as separate checks.

Put every record in the correct DNS zone

Prepare a change worksheet before editing:

For a DKIM signature with d=news.example.com and selector campaign2026, the lookup owner is campaign2026._domainkey.news.example.com. In an example.com zone's relative-name editor, enter campaign2026._domainkey.news; in a separately authoritative news.example.com zone, enter campaign2026._domainkey. These are illustrative names only.

Check whether the DNS editor appends the zone. A duplicated suffix produces a valid-looking record at the wrong place. Preserve unrelated selectors. If an existing record conflicts, stop and resolve the name with both owners rather than deleting it. Avoid web-proxying an authentication alias. Confirm the saved public answer after any editor-specific quoting or name normalization. DKIM DNS lookup

Check DNS and activation independently

Run these read-only examples with your actual names. Use the appropriate branch, not all delegation methods at once:

# Identify authority and the selected delegation model.
dig example.com NS +noall +answer
dig email.example.com CNAME +noall +answer
dig email.example.com NS +noall +answer

# Delegated campaign mail routing; use the confirmed mail-routing owner.
dig email.example.com MX +noall +answer

# Authenticated-domain SPF, when this is the documented chosen owner.
dig news.example.com TXT +noall +answer

# Account-specific DKIM owner, not a universal Adestra selector.
dig campaign2026._domainkey.news.example.com TXT +noall +answer
dig campaign2026._domainkey.news.example.com CNAME +noall +answer

# Compare an authoritative answer with the recursive result.
dig @AUTHORITATIVE-NS campaign2026._domainkey.news.example.com TXT +noall +answer

# From-domain policy plus any applicable parent policy.
dig _dmarc.news.example.com TXT +noall +answer
dig _dmarc.example.com TXT +noall +answer

Expected results are the intended public key, exact alias/delegation targets, and one applicable SPF policy per SPF owner, not a prewritten “pass” output. Follow an issued DKIM CNAME to its public-key TXT target. For NS delegation, confirm that the delegated authority answers the child zone correctly. For delegated mail routing, compare the exact MX owner, priority and target against Adestra-confirmed values, following any supported CNAME resolution where applicable. Do not invent an MX target or copy delegated campaign routing onto the corporate apex; preserve employee-mail MX records. A cache may lag behind authoritative DNS until TTL expiry; a wrong owner will remain wrong after waiting.

Both current-path Adestra pages describe a 24–72 hour DNS allowance. That is not a promise that custom signing activates within the same window. Validate the authoritative data and Adestra-side completion separately; waiting does not fix the wrong name or record. Authenticated-domain timing, delegated-domain timing

Keep response status as well as answers when diagnosing empty results. Check for NXDOMAIN, SERVFAIL, DNSSEC problems, conflicting data and the wrong zone. Provider status confirms what that provider checked; it does not establish visibility from every resolver or prove live signing.

Verify the actual campaign and require branded DKIM alignment

Use an authorized controlled recipient and the production-equivalent campaign path. Retain the original message and the receiving server's trusted authentication results. Avoid interpreting an injected or forwarded copy of an Authentication-Results field as the destination's verdict. Authentication-Results trust boundary

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

For each route, capture:

1. The intended visible From domain and actual From domain.
2. The evaluated SMTP MAIL FROM domain, sender IP and SPF result.
3. All DKIM signing domains/selectors and the result associated with each.
4. The intended branded signature's alignment with From.
5. The receiver's DMARC result and applicable alignment mode.
6. The campaign, account, timestamp and activation confirmation.

Acceptance requires the intended branded DKIM signature to pass and align, plus a passing DMARC result. A valid d=msgfocus.com signature alone is not sufficient for an unrelated customer From domain. A DMARC pass through aligned SPF also does not prove that the newly configured branded DKIM key works.

SPF should pass in a direct, unforwarded test. Distinguish spf=pass with an unaligned domain from actual fail, softfail, permerror, temperror or unexpected none. For a customer-owned evaluated domain, inspect the single effective policy, authorized sender and lookup budget. For a delegated/provider-owned domain, investigate with Adestra using the route, time and redacted header. Do not overwrite your apex policy to fix an unrelated envelope domain. Forwarding can break SPF; compare direct and forwarded evidence. SPF results

DMARC passes through aligned SPF or aligned DKIM. Relaxed alignment permits an organizational-domain match; strict alignment requires exact equality. A signature at news.example.com may align with From example.com under relaxed rules but not adkim=s. Current organizational-domain discovery is defined by the standard, not by a visual suffix match. DMARC alignment

Retain DMARC policy and reporting

Inspect the From-domain policy and any inherited parent policy. Preserve established enforcement, reporting destinations and alignment modes. Do not create a child p=none override that weakens a parent's protection just to onboard Adestra.

For a genuinely new, approved monitoring deployment without an existing applicable policy, a sample is:

Owner: _dmarc.news.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example domain and mailbox. Publish one DMARC policy at its owner and arrange authorization for an external report destination when required. For a delegated zone, coordinate policy publication with the authoritative operator instead of adding a non-authoritative parent-zone copy. p=none requests monitoring; it neither converts failures to passes nor guarantees delivery. DMARC specification, reporting specification

For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names. For Adestra’s provider-managed NS-delegation branch, arrange publication with the delegated authoritative operator; do not add an inactive copy at the parent or replace that delegation.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Review reports across normal campaigns and all other legitimate senders before enforcement changes. Valid DKIM is required for domains publishing p=reject under RFC 9989, and indirect mail flows need particular care. Do not rely on the removed legacy pct tag for a new rollout. For practical follow-up, see reading aggregate DMARC reports.

Troubleshooting and frequently asked questions

Adestra says SPF is valid, but DMARC fails. Why?

The status is not message-level alignment evidence. Compare the receiver's smtp.mailfrom, every passing DKIM d=, and the actual From domain. Confirm custom signing and the selected campaign domain, rather than adding more SPF includes blindly.

Why is the campaign still signed by msgfocus.com?

The documented default applies when custom DKIM is not configured. Check whether the correct domain's custom key exists, signing is activated, and the intended route uses it. A default signature cannot establish your branded setup's acceptance.

Should I use an online DKIM generator?

Not as a substitute for the hosted provider's key-generation and activation workflow. The signing service must possess and use the matching private key. Publish only the public record issued for the actual account.

Can I add TXT and MX records beside the delegated CNAME?

Not at that same CNAME owner. Follow the selected delegation model. If an existing mailbox or website needs that name, choose a safe unused subdomain and resolve the design before changing anything.

What if DNS is correct but DKIM fails?

Compare the signature's exact d=/s= with the published key, confirm activation and current key version, and check whether a gateway modified signed content. Do not discard old keys before checking queued mail and rotation state. The selector identification guide can help locate the relevant owner.

Can a passing campaign still go to spam?

Yes. Authentication is not an inbox guarantee. Inspect recipient complaints, list quality, sender reputation and actual rejection responses separately. Keep old tracking/branding dependencies until their owners approve retirement; already-delivered messages may still use them.