[ Sending-service guides ]

Authenticate email sent through 34SP: configuration and verification

Activate 34SP DKIM on supported hosting, verify any automatic DNS changes, and protect existing SPF authorizations.

By the EmailAuth research team · 4 min read

[ Key points ]

  • Keep the documented hosting scope separate from Private SMTP.
  • Inspect automatic DNS changes rather than assuming safe merging.
  • A panel status does not establish a passing aligned message.
On this page
  1. Key points
  2. Takeaway
  3. By role
  4. Frequently asked questions
  5. Sources
  6. Glossary
  7. Related guides

[ Takeaway ]

A panel status does not establish a passing aligned message.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Verify the actual route

Inspect automatic DNS writes and compare real outbound headers with the enabled site.

Next steps

  1. Capture DNS before using Add SPF Records.
  2. Compare Enable DKIM output with a received signature from the supported route.
  3. Retest after a sending-domain or DNS-provider change.

CISO / SecOps

Control the authorization boundary

Require scoped rollback and separate approval for any domain-wide policy change.

Next steps

  1. Keep Private SMTP outside this procedure.
  2. Approve rollback limited to the records and setting actually changed.
  3. Retain the approved recovery and supplier-retirement decisions.

Founder / Non-technical

Own the sending decision

Confirm which hosting product owns critical email before accepting the change.

Next steps

  1. Confirm the hosting plan rather than relying on the 34SP brand alone.
  2. Schedule the change away from critical notification sends.
  3. Require the controlled-message acceptance record before launch.

[ FAQs ]

Frequently asked questions

Does this work for 34SP Private SMTP?

No. The cited DKIM procedure excludes Private SMTP; obtain that product’s current instructions.

34SP DKIM signing

Where is the DKIM switch?

Under the selected site’s Advanced section, in DomainKeys Identified Mail.

34SP DKIM signing

What if my DNS is hosted elsewhere?

Publish the public records shown on screen at the authoritative host and verify them there.

34SP DKIM signing

Can Add SPF Records be trusted without inspection?

Compare the actual result with your existing sender inventory. Automatic publication is not a multi-provider audit.

34SP SPF publishing

Does an additional verification TXT break SPF?

Not merely because it is TXT. The problem is multiple selected v=spf1 policies at the same owner.

Why does enabled DKIM still fail?

Possible causes include missing public DNS, the wrong selector, mismatched keys or a different outbound route. Use a received message to distinguish them.

Should I copy the key into every domain?

No. Use each domain’s generated configuration and verify the signing identity.

What must be retested after SPF changes?

Every legitimate service using that SPF owner, not just the 34SP message.

[ Sources ]

Sources

  1. 34SP DKIM signing

    Sections Applies to · Enabling DKIM Signing

  2. 34SP SPF publishing

    Sections How to create an SPF record

  3. RFC 7208 SPF

    Sections §3.2 Multiple DNS Records · §4.6.4 DNS Lookup Limits

  4. RFC 6376 DKIM

    Sections §3.5 The DKIM-Signature Header Field · §3.6 Key Management and Representation · §6 Verifier Actions

  5. RFC 9989 DMARC

    Sections §4.4 Identifier Alignment Explained · §5.3 Mail Receiver Actions

  6. RFC 2308 DNS negative caching

    Sections §5 Caching Negative Answers

[ Glossary ]

Glossary

Alignment
The required relationship between a passing authentication domain and the visible From domain for DMARC.
Selector
The DKIM label used with the signing domain to locate its public key in DNS.
Authoritative DNS
The nameserver service responsible for publishing the relevant zone records.
Return-Path
The received-message trace of the SMTP reverse path, useful when investigating the envelope identity.

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