[ Sending-service guides ]

Authenticate email sent through DuoCircle: configuration and verification

Enable or rotate DuoCircle outbound DKIM with a clear distinction between first activation and a staged key rollover.

By the EmailAuth research team · 3 min read

[ Key points ]

  • First activation and rotation have different signing timing.
  • Publish and verify the proposed key before switching rotation.
  • Keep old public keys while old signed messages remain in transit.
On this page

Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.

Choose the correct operation

DuoCircle's outbound relay supports per-domain DKIM signing. First activation and rotation have different timing risks, so decide which you are performing before touching DNS. Record the sending domain, applications using the relay, current selector if any, DNS owner and a safe pause mechanism for new submissions.

The DKIM setup guide places controls in the service's Sender Domains & DKIM page in the client area. Each domain must be listed and enabled. It warns that first activation begins signing immediately, before recipients necessarily can resolve the new public key. A green signing toggle is therefore not a completed deployment.

Plan first activation around publication

References: RFC 6376 §3.6.2.

Arrange a change window that limits exposure while the generated TXT record is published and checked. View the domain's DKIM settings and use the generated owner and value at the authoritative DNS provider. Do not reuse a selector or key from another tenant, and never publish private signing material.

If the first-activation workflow cannot stage the public key before signing starts, pause affected submissions until DNS and a controlled message have been checked. Do not assume a switch to YES means public resolvers already have the record. Save the prior route and toggle state so the team can restore the last approved configuration if necessary.

Rotate with overlap rather than replacement

References: RFC 6376 §3.6.2.

For an existing signer, DuoCircle documents generating a new selector and public key without immediately switching active signing. Publish the new TXT record, verify it, then complete rotation in the domain's DKIM tools. Leave the old selector intact while queued messages signed with that key may still be delivered.

Its 2048-bit key update explains selecting 2048-bit strength through a new rotation, using generated record-format options as needed, and checking with Retry DKIM check before moving signing. Do not extrapolate the announcement's historic default to every current account; inspect the actual selected key strength.

A long TXT value may require multiple character strings inside one TXT record. That is different from publishing several competing key records at the same selector. Follow the DNS provider's input rules and verify that the logical public-key value is intact. An attractive line break in a ticket is not necessarily harmless when pasted into a DNS editor.

Prove the active key changed

References: RFC 9989 §4.4, RFC 6376 §6.

Original acceptance worksheet: record the old selector, proposed selector, public DNS answer, provider verification result, activation time and first controlled message using the new selector. Retain the receiver's DKIM result and d= domain alongside the visible From. A passing signature with an unrelated signing domain does not by itself satisfy DMARC alignment.

Illustrative scenario: the new key is correctly published, but the operator never completes rotation. Existing messages continue to verify under the old key. Deleting the old TXT record at this point converts a harmless incomplete rollover into an authentication failure. The delivered s= selector reveals which key is actually in use.

Define recovery and retirement separately

If publication fails before rotation, leave the active signer and its DNS untouched while correcting the proposed record. If a failure occurs after switching, pause the affected route and consult the supported recovery controls rather than assuming the old private key can be selected again. Keeping a public key does not guarantee that the service retains the corresponding signing key.

Retire the old record only after new signing is observed and queued-message dependencies are resolved. Recheck after application additions or sender-domain changes. Documentation was reviewed on 8 November 2026. No DuoCircle account, live key rotation, DNS update or message delivery was executed here.

[ Takeaway ]

Keep old public keys while old signed messages remain in transit.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Track the selector in use

DNS publication alone does not switch the signer.

Next steps

  1. Publish the proposed key.
  2. Verify before rotation.
  3. Inspect s= on received mail.

CISO / SecOps

Keep key handling disciplined

Public verification records and private signing keys have different roles.

Next steps

  1. Keep private keys out of DNS.
  2. Review key strength deliberately.
  3. Record the supported recovery path.

Founder / Non-technical

Schedule the signing transition

First activation has a different exposure window from rotation.

Next steps

  1. Approve a change window.
  2. Name the application pause owner.
  3. Require evidence before retirement.

[ FAQs ]

Frequently asked questions

Where are DuoCircle signing controls?

In the service’s Sender Domains & DKIM configuration page in the client area.

DomainKeys Identified Mail (DKIM) : DuoCircle

Does first activation wait for DNS?

The setup guide warns that signing begins immediately. Plan publication and a submission pause accordingly.

DomainKeys Identified Mail (DKIM) : DuoCircle

Is rotation the same as first activation?

No. The documented rotation creates a proposed key before active signing moves to it.

DomainKeys Identified Mail (DKIM) : DuoCircle

How do I choose a 2048-bit key?

Use the key-strength option in a new rotation and verify the generated record before moving signing.

2025-12-13: Outbound SMTP DKIM signing with 2048-bit keys : DuoCircle

Can I delete the old selector as soon as DNS validates?

No. Confirm the active signing switch and account for queued messages using the old key.

DomainKeys Identified Mail (DKIM) : DuoCircle

Should I split a long key into several TXT records?

No. DNS character-string chunks belong to one logical TXT record; follow the host’s input format.

2025-12-13: Outbound SMTP DKIM signing with 2048-bit keys : DuoCircle

What proves that rotation actually happened?

A controlled delivered message with the new s= selector and successful receiver verification.

DomainKeys Identified Mail (DKIM) : DuoCircle

Does retaining the old public key guarantee rollback?

No. It preserves verification for old messages but does not prove the service retains a usable old private key.

[ Sources ]

Sources

  1. DomainKeys Identified Mail (DKIM) : DuoCircle

    Sections Configuring DKIM for a sending domain · Rotating your DKIM Key · Restarting the key rotation process

  2. 2025-12-13: Outbound SMTP DKIM signing with 2048-bit keys : DuoCircle

    Sections §13 December 2025 update: 2048-bit rotation and Retry DKIM check

  3. RFC 7208

    Sections §2.4 Checking authorization · §3.2 Multiple DNS records · §4.6.4 DNS lookup limits

  4. RFC 6376

    Sections §3.5 DKIM-Signature header · §3.6.2 DNS binding · §6 Verifier actions

  5. RFC 9989

    Sections §4.4 Identifier alignment · §4.10 DNS tree walk · §5.3.5 Determine DMARC pass or fail

[ Glossary ]

Glossary

SPF
DNS authorization for the SMTP envelope-sender domain, subject to protocol limits.
DKIM
A signature verified using a public key at a selector under the signing domain.
DMARC alignment
The required relationship between the visible From domain and a passing SPF or DKIM authentication domain.
Authoritative DNS
The delegated DNS service responsible for the published zone answers.
Selector
The DKIM identifier used with the signing domain to locate the public key.

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base