DuoCircle SPF, DKIM and DMARC setup, step by step

For DuoCircle's SMTP Monthly Outbound SMTP service, add your sending domain, merge the service's SPF authorization into its existing SPF policy, generate and publish the domain's DKIM TXT record, verify it, then explicitly select Turn On Signing. A green DKIM verification label alone does not mean DuoCircle is signing messages. DuoCircle domain validation

This guide covers customer-domain email sent through DuoCircle Outbound SMTP. It does not configure inbound spam filtering, Backup MX, forwarding, AutoSPF, or Microsoft 365 connectors. Buying another DuoCircle product does not establish that its mail follows this outbound route.

For mailbox mail that also uses Microsoft 365, keep that separate transport authenticated with the Microsoft 365 SPF and DKIM guide.

Before changing DNS

Identify the Outbound SMTP service in the Client Admin Portal, the application that uses it, and every visible From domain. Confirm access to the authoritative public DNS zone, not merely a registrar account. Export the current relevant DNS records and record the application owner, change window, rollback values, and a controlled external recipient for later testing.

DuoCircle's instructions distinguish SMTP Monthly validation from an older DKIM interface. Use the current validation workflow below when it matches your service. If you see red NO and green YES signing controls instead, consult the legacy-interface section before clicking them. Those controls can start signing immediately.

Do not replace your domain's MX records to enable outbound DKIM. Incoming mailbox routing is a separate task.

1. Register and verify the outbound sending domain

Open the intended Outbound SMTP service in the Client Admin Portal. Choose Add and verify or Sender Domains & DKIM, add the domain, and save. Open its row or edit control to inspect the separate SPF and DKIM statuses. Repeat for each domain used by the actual application. A domain configured under another service instance is not evidence that this instance is ready. DuoCircle validation workflow

2. Reconcile SPF without removing other senders

The monthly-service instructions document include:outbound.mailhop.org. DuoCircle's newer SPF overview directs Standard SMTP customers to the Sending Domains configuration page for domain-specific recommendations. Compare those live instructions with the documented include rather than applying it to every DuoCircle product. DuoCircle SPF guidance

At the instructed owner, inspect all TXT records. If a policy beginning v=spf1 already exists, add only the required authorization to that policy before its terminal all mechanism. Do not add a second SPF policy or remove another application's authorization. If the same include is present already, do not duplicate it.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

For a domain with no existing policy, the monthly-service documentation supplies this standalone pattern:

Type: TXT
Owner: YOUR_ACTUAL_SENDING_DOMAIN
Value: v=spf1 include:outbound.mailhop.org ~all

The owner is a placeholder, not a hostname to publish. Retain an existing policy's ending unless your domain administrator has reviewed the change. DuoCircle discusses using ~all with enforcing DMARC, but that recommendation is not permission to weaken an established organization-wide policy automatically.

SPF evaluates the SMTP envelope MAIL FROM domain, which can differ from the visible From domain. An SPF pass for a provider-owned or otherwise unrelated envelope does not authenticate your visible From identity for DMARC. This guide does not assume a custom Return-Path feature or promise a particular envelope rewrite: inspect the actual delivered message. SPF specification

Keep one SPF policy per owner and stay within the limit of 10 evaluated DNS-query-causing terms, including nested include and redirect processing. That is not ten TXT records or ten configured vendors. Do not replace includes with a one-time list of IP addresses without an ongoing maintenance plan. Back in DuoCircle, run Retry SPF Check after public DNS reflects the intended policy.

3. Generate, publish, verify and enable DKIM

In the monthly workflow, select Not Configured, then Generate a DKIM key. Publish a TXT record with the displayed Record Name and Record Text. Run Retry DKIM Check. Once verification succeeds, select Turn On Signing and confirm signing is enabled. These are distinct gates, not interchangeable green labels. DuoCircle activation instructions

Use only the public DNS text provided by DuoCircle. Never publish SMTP passwords, private keys, or keys from a documentation screenshot. Before saving, determine whether your DNS panel expects a relative name or a complete hostname. Check the resulting fully qualified owner to catch a missing domain suffix or a suffix appended twice. DuoCircle DKIM lookup guidance

For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

A long TXT record may be represented as multiple quoted strings within one record. That is different from creating multiple independent DKIM records at the same selector. DuoCircle documents DNS-provider-specific quoting and whitespace problems. Adapt the presentation to the DNS host's input rules while preserving the complete logical key value; do not delete arbitrary characters or truncate p=. DuoCircle key-format troubleshooting

If your interface has the older NO/YES control

DuoCircle's older DKIM article says clicking NO enables signing and generates a key if none exists; DNS publication comes afterward. That can create a period when outgoing signatures cannot be verified. Do not treat it as the newer generate-then-verify flow. Coordinate first activation with the mail owner, contain sending during the gap, and obtain current service-specific help if the displayed controls differ. DuoCircle legacy DKIM workflow

Rotate an existing key without invalidating queued mail

The same official article documents a staged rollover: use the refresh control and New Key, publish the newly generated selector's TXT record, verify public availability, then use Rotate Now. Retain the previous selector until new messages use the new key and older queued messages signed with the old key have finished delivery. Generating another candidate key invalidates the previous candidate, so match DNS to the candidate actually being activated.

4. Verify public DNS and a real message separately

Replace the uppercase placeholders before running these read-only checks:

dig +short TXT YOUR_SENDING_DOMAIN
dig +short TXT EXACT_DKIM_RECORD_NAME
dig +short TXT _dmarc.YOUR_FROM_DOMAIN

For SPF, expect one complete v=spf1 policy with the correct authorization and no syntax or lookup-limit error. For DKIM, expect the public key at the exact selector used by your account. Query the authoritative nameserver and an independent resolver if the portal disagrees with your DNS panel. A cached negative answer can outlive a recent correction.

Next send a new, authorized test through the same application and DuoCircle SMTP service used in production. Read the original message at a receiver you control. Use the receiving system's trusted Authentication-Results, not an arbitrary earlier header.

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.

Record the visible From domain, smtp.mailfrom, DKIM d= and s=, and the receiver's SPF, DKIM and DMARC results. Expect dkim=pass for the configured domain and selector after signing is enabled. Confirm the SPF result against the actual envelope identity. For DMARC, identify at least one passing and aligned identity, rather than merely counting pass labels. DMARC standard, RFC 9989

Accept this branded-DKIM setup only when the intended provider signature has trusted dkim=pass, its actual d= aligns with the intended visible From under the effective adkim mode, and the trusted receiver reports dmarc=pass for that From. SPF-only DMARC success does not complete the DKIM deployment. Independently diagnose SPF fail or softfail (authorization mismatch), temperror (transient evaluation failure, often DNS) and permerror (uninterpretable policy, duplicates or lookup limits) at the observed smtp.mailfrom, even when aligned DKIM supplies DMARC. A passing but unaligned provider envelope is a different outcome from an SPF error. DMARC alignment, SPF results.

A useful acceptance record contains the timestamp, application, Outbound SMTP service, configured domain, DNS results, signing state, redacted header evidence, and pass/fail decision. A portal screenshot alone does not complete it.

5. Keep DMARC policy changes deliberate

DMARC passes when either SPF or DKIM both passes and aligns with the visible From domain. Relaxed alignment permits the same organizational domain; strict aspf=s or adkim=s requires exact domain equality for that mechanism. An aligned DKIM pass can therefore satisfy DMARC even when SPF is unaligned.

Preserve an existing DMARC record and enforcement policy. If there is no policy, a monitored p=none deployment may be appropriate while inventorying all legitimate senders. It is not an instruction to downgrade an existing quarantine or reject policy. Do not use obsolete pct percentage rollout guidance under RFC 9989.

Choose an authorized aggregate-report destination and verify receipt and interpretation of reports before considering enforcement changes. External report destinations can require DNS authorization. Failure reports can expose message-related information, so do not add ruf as a routine setup step. Aggregate reporting, RFC 9990, failure reporting, RFC 9991

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.

Publish a first policy only after checking inheritance

First query the exact visible From domain's _dmarc name and check whether an organizational-domain policy already applies to this subdomain. An absent child record does not mean there is no policy. Do not create a child p=none record that overrides inherited enforcement without an explicitly reviewed policy change.

Only when no existing or inherited enforcement would be weakened, provision a reporting mailbox or reporting service your organization authorizes. Obtain its actual rua address and, for an external destination, complete the destination's authorization described in RFC 9990 section 4. Then publish one TXT record with this structural template, substituting every uppercase placeholder:

Full owner: _dmarc.YOUR_EXACT_FROM_DOMAIN
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:YOUR_AUTHORIZED_REPORT_ADDRESS

Use literal semicolons, not escaped backslashes; do not publish the placeholders. In the exact sender-domain DNS zone the relative owner is _dmarc; in a parent zone include the sender's subdomain labels after _dmarc. Preserve any existing DMARC record instead of creating a second one. Query the final full owner, check the effective policy, and confirm aggregate reports arrive before planning enforcement.

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.

Troubleshooting by failed gate

Review scope and next checks

Those dates describe the sources, not hands-on testing.

No customer account, DNS configuration or delivered message was tested or changed for this guide. Verify the current account interface, public records and real-message results using the checks above. Authentication does not guarantee inbox placement.