What is the DNSExit DKIM selector?

The documented selector is relay , published at relay._domainkey.YOUR-SENDER-DOMAIN as a CNAME to dkim.dnsexit.com . It is not a TXT key pasted at the domain apex.

Must DNSExit host my DNS?

The authentication instructions require records in your domain’s DNS, not a nameserver migration. Publish at the actual authoritative host and then complete DNSExit’s Sender Domains verification.

Is adding the CNAME enough to turn on DKIM?

No. The provider’s documented final step is to add the sender domain and verify both SPF and DKIM in the Mail Relay account. A received-message test is still needed after that.

Can I use these records for DNSExit forwarding or Business Email?

Do not assume that. This guide establishes the Mail Relay workflow only. Identify the actual sending product and its documented signing process before reusing any records.

Does DMARC pass prove the DNSExit DKIM change succeeded?

Not by itself. DMARC can pass through aligned SPF. Require the intended aligned DNSExit signature to pass as well, with the original intended From unchanged.

DNSExit SPF, DKIM & DMARC Setup: Step-by-Step Guide

For DNSExit Mail Relay, add include:dnsexit.com to the sender domain’s single SPF policy, publish relay._domainkey as a CNAME to dkim.dnsexit.com, and verify both records in Dashboard → Mail Relay → Sender Domains. DNSExit says it starts adding DKIM signatures after that verification succeeds. Publishing DNS alone is not the final step. DNSExit Mail Relay authentication instructions.

This guide covers an existing DNSExit Mail Relay account sending authorized custom-domain mail. It does not treat DNS hosting, email forwarding, Business Email or a server that bypasses the relay as the same authentication workflow. DNSExit can host a domain’s DNS without sending its mail; confirm the outgoing route before adding an authorization.

Confirm the relay and the domain you intend to authenticate

Start with one representative message type, such as application notifications or mail from an existing server routed through DNSExit. Record its intended visible From address, the application or mail-server owner, the DNS administrator and a controlled external recipient for a later test.

The documented outgoing relay hostname is relay.dnsexit.com. DNSExit’s client instructions describe SMTP authentication with the relay account. Confirm that the actual production route already uses the service; do not change credentials, switch to IP authentication or disable transport security as a side effect of adding SPF and DKIM. DNSExit relay client configuration.

You need:

An existing Mail Relay service and account access to Sender Domains.
Authority to use the intended sending domain and edit its authoritative DNS.
A record of every other legitimate service sending with that domain.
Access to externally received message headers after the change.
A saved copy of existing SPF, DKIM, DMARC, TTLs and relevant delegations.

The public authentication procedure does not identify a special administrator role or paid-tier requirement beyond access to the relay workflow. If the account lacks the documented controls, resolve that account-specific issue before changing records.

Do not authenticate a public mailbox provider’s domain simply because you own an address there. Domain authorization requires control of the domain, not just the ability to receive mail at one address.

Keep DNS ownership and mail identities separate

Determine the active authoritative nameservers before editing. The registrar, website host and DNSExit relay account may be three different services. Add records at the current DNS authority rather than moving nameservers to follow a tutorial.

There are also different email identities:

Visible From: the address recipients see and the domain DMARC protects.
SMTP MAIL FROM: the envelope identity normally evaluated by SPF and commonly represented by Return-Path after delivery.
DKIM signing domain: the d= value in a signature; its s= selector identifies the DNS key.

SPF can evaluate HELO in applicable cases, including a null reverse-path. Adding an SPF record for the visible From domain does not prove that this is the envelope domain used by every message. DNSExit’s public setup does not establish one universal MAIL FROM or rewrite pattern. Check the actual received result rather than promising SPF alignment from the DNS example. SPF identities, RFC 7208.

DNSExit asks you to configure and verify the sender domain in its workflow. Follow that requirement, then inspect the actual envelope independently. If a message uses a provider-owned envelope domain, do not attempt to edit that provider’s DNS or invent a custom bounce-domain setting.

Configure one SPF policy for DNSExit

The provider authorization is:

include:dnsexit.com

For a domain with no SPF policy and no other authorized sender, DNSExit documents this complete TXT value:

v=spf1 include:dnsexit.com -all

Publish it at the configured sender domain, using the correct owner for that DNS zone. The official instructions explicitly distinguish adding the include to an existing policy from creating a new policy when none exists. DNSExit SPF instructions.

Preserve existing senders

If a v=spf1 TXT record already exists at that owner, modify the approved policy rather than adding a second one. Preserve legitimate authorizations and the existing terminal policy unless the domain owner approves a deliberate change.

For example, staff mail might still use Microsoft 365 while an application uses DNSExit. Removing the staff-mail authorization would break an unrelated route. Its tenant configuration remains separate; see the Microsoft 365 authentication guide for that service’s setup.

Review existing a, mx, ip4, ip6, include and redirect terms for what they actually authorize. An inbound mail exchanger is not automatically an outbound sender. Do not add broad infrastructure merely to make a lookup tool turn green.

A policy using redirect= needs particular care. Adding an all mechanism causes SPF to ignore redirect; appending DNSExit’s complete example could silently discard the existing delegated policy. Have the DNS owner reconcile the complete policy, not just attach a suffix. SPF redirect behavior.

SPF limits evaluation to ten DNS-querying mechanisms and modifiers, including nested processing. This is not a budget of ten top-level includes. Terms such as a, mx, include, exists, ptr and redirect can consume that budget; ip4, ip6 and all do not. Excess evaluated terms can produce permerror. SPF DNS lookup limits.

The example’s -all produces SPF fail for an unmatched source. It does not compel every recipient to reject a message or guarantee delivery for matching sources.

Publish the DNSExit DKIM CNAME

DNSExit publishes this fixed record for its Mail Relay service:

Type: CNAME
Full owner: relay._domainkey.YOUR-SENDER-DOMAIN
Target: dkim.dnsexit.com

Replace YOUR-SENDER-DOMAIN with the actual domain being configured. This is a provider-published service target, not a tenant token or a public key to generate yourself. DNSExit DKIM record.

For a fictional sender domain example.com, the full owner is relay._domainkey.example.com. In an editor that automatically appends example.com, enter only relay._domainkey. Do not produce relay._domainkey.example.com.example.com.

For the fictional sender domain notify.example.com:

In the parent example.com zone, the relative DKIM owner is relay._domainkey.notify, and the SPF owner is notify.
In a separately delegated notify.example.com zone, the relative DKIM owner is relay._domainkey, and the SPF owner is the zone apex, often @.
In either case, the intended full DKIM owner is relay._domainkey.notify.example.com.

A DNS editor that requires fully qualified names may use a trailing dot to prevent suffix expansion. Check the saved full owner and target rather than relying on how the input box looks.

Check collisions and delegation before saving

Inspect the exact selector owner first. A CNAME cannot coexist there with TXT, A, AAAA, MX or another CNAME carrying conflicting data. Do not remove an existing record until its owner and purpose are established. Other selectors elsewhere under _domainkey can remain. CNAME rules, RFC 1034.

If _domainkey or a child namespace is already delegated with NS records, publish through the authority serving the selector name. Do not delete the delegation or add an ineffective record into the parent zone.

The selector is a DNS record, not a website. Use DNS-only handling rather than an HTTP proxy. If the DNS host flattens CNAMEs, ensure the required selector CNAME remains visible. Inspect per-record, zone-wide, apex-only and same-zone behavior before changing anything. Alter only the setting affecting this record; disabling flattening globally can disrupt unrelated services.

Leave MX, website records, parent nameservers, DNSSEC and other services’ keys unchanged.

Verify both records in Sender Domains

After the authoritative records are correct:

Sign in to the DNSExit account that owns the Mail Relay service.
Open Dashboard → Mail Relay → Sender Domains.
Add the intended sender domain to the list.
Run the provider’s verification for both SPF and DKIM.
Resolve either failure before treating setup as activated.

DNSExit explicitly states that successful verification is followed by automatic DKIM signing of mail sent through the service. Keep the successful provider status as one piece of evidence, separate from DNS answers and received-message authentication. DNSExit final verification and signing.

If DNS is correct but verification fails, check the account, exact domain, selector owner, target and cached responses before editing again. A typo does not disappear after a waiting period. The reviewed procedure does not provide a universal propagation deadline.

Check DNS without claiming a message passed

These are read-only examples for the fictional example.com. Replace it with the configured sender domain before running them:

dig TXT example.com
dig CNAME relay._domainkey.example.com
dig TXT relay._domainkey.example.com
dig TXT _dmarc.example.com

The SPF answer should contain one applicable v=spf1 policy at the intended owner. Multiple quoted strings can be parts of one TXT record; they are not automatically multiple policies. The selector CNAME should point to dkim.dnsexit.com. Follow its DNS chain when checking availability of the public verification key.

Compare authoritative answers with recursive answers if they disagree. Record the change time, old TTL, authoritative result and later provider verification. Do not repeatedly replace correct records while older cached answers expire.

None of these commands sends an email or proves that DNSExit signed your production message.

Require the intended signature and a trusted DMARC pass

Send a fresh authorized message through the actual DNSExit relay route to a controlled external mailbox. Preserve its raw headers and message identifier. Repeat for materially different applications or gateways; an unrelated staff-mail test does not validate the application route.

Record:

Intended and delivered visible From addresses.
Receiver-reported SPF identity, sending IP and SPF result.
Every DKIM signature’s d=, s= and verification result.
DMARC result and the policy’s alignment modes.
The final route, including any footer or security gateway.

Use Authentication-Results generated by receiving infrastructure you trust. A header’s position or an authserv-id string alone does not prove trust; an attacker can insert plausible-looking results. Use results produced inside the actual receiving service’s known processing boundary, and check its documented handling of externally supplied Authentication-Results. Ignore untrusted result fields supplied before that boundary. If the receiver’s handling is unclear, ask its administrator to identify the assessment rather than accepting a header by appearance. Authentication-Results trust boundary.

For this branded-DKIM setup, completion requires the intended DNSExit signature to pass, its d= domain to align with the unchanged intended visible From, and the trusted receiver to report dmarc=pass. Inspect the expected relay selector. A different provider’s passing signature, a rewritten provider From address or a DMARC pass through SPF alone does not prove this DKIM setup works.

DMARC can pass through either aligned SPF or aligned DKIM. Relaxed alignment uses the same Organizational Domain; strict alignment requires an exact domain match. A child domain can satisfy relaxed alignment without satisfying strict alignment. Evaluate actual identities against the domain’s policy instead of assuming a particular DNSExit envelope shape. DMARC identifier alignment.

If DKIM passes and carries DMARC while SPF fails, diagnose SPF separately. That result is not permission to leave a duplicate policy, broken DNS response or missing legitimate authorization unresolved.

Preserve DMARC and approve reporting separately

Read the TXT record at _dmarc of the exact visible From domain and determine whether an inherited policy applies when there is no direct record. Preserve existing enforcement, alignment settings and approved report destinations. Do not create a local p=none override that weakens inherited protection. DMARC policy discovery.

Only when there is no applicable direct or inherited policy, and the owner approves a monitored first deployment, a minimal example is:

v=DMARC1; p=none

Its type is TXT. For the fictional From domain example.com, the full owner is _dmarc.example.com; for notify.example.com, it is _dmarc.notify.example.com. In the example.com zone, those relative owners are _dmarc and _dmarc.notify, respectively. In a separately delegated notify.example.com zone, use _dmarc. Publish one policy at the chosen full owner, not a second competing record.

This minimal record requests no enforcement and no reports. If aggregate reporting is wanted, add rua=mailto: with an approved, functioning report address. Decide who may see sending IPs, volumes and authentication results, and how long reports will be retained.

When the report destination is in a different Organizational Domain from the policy domain, the report-generating receiver must check the destination’s DNS authorization. Destinations within the same Organizational Domain are excepted from that check. This protocol permission is separate from the owner’s privacy and data-sharing approval. External reporting authorization, RFC 9990 section 4.

Do not add failure reporting merely to complete a template; it can expose message information and needs a separate purpose and privacy review.

Troubleshoot the failing layer

Sender Domains rejects DKIM: compare the exact full owner and CNAME target. Look for a repeated domain suffix, conflicting data, a hidden delegation, a proxy or flattening behavior that removes the expected CNAME.

SPF returns permerror: check duplicate v=spf1 records, syntax and evaluated lookup terms, including nested includes. Do not add another SPF record to fix the first.

SPF returns temperror: investigate temporary DNS resolution problems. A permanent policy replacement is not the first response to a temporary failure.

SPF fails: compare the final sending IP and the actual MAIL FROM with the policy evaluated by the receiver. Confirm that the message really traversed the relay. Do not authorize an unexpected third-party forwarder just to hide a failure.

DNS is valid but the intended signature is missing: confirm successful verification in the correct Mail Relay account and domain, then check the complete outbound path. DNS publication alone cannot make a different server sign.

DKIM fails after a gateway: investigate changes to signed headers or body content after signing. Keep any existing local signature until its dependencies and replacement have been reviewed.

DMARC fails despite a DKIM pass: inspect which signature passed and whether its domain aligns with the intended From. Do not weaken DMARC to conceal a signing-domain mismatch.

Authentication passes but delivery remains poor: retain the recipient’s SMTP response and investigate reputation, content, sending permission and recipient filtering separately. Authentication does not guarantee inbox placement.

Roll back narrowly and retain evidence

Save the approved DNS diff, provider verification, public answers and redacted receiver evidence. Exclude passwords, relay credentials and private signing keys.

If the new route fails, pause the affected application’s sending or use an already approved, tested route. Restore only the changes belonging to this integration after reviewing shared dependencies. Do not remove a selector while delayed messages still need its public key, or remove an SPF authorization while another legitimate route still uses it.

Recheck after rollback, an application route change, domain migration or a provider signing change. Close the task only when the domain owner can distinguish successful DNS publication, successful DNSExit verification and successful delivered-message authentication.

Documentation and testing limits

The current first-party Mail Relay authentication answer and linked relay instructions were read in full. The authentication page does not provide a reliable publication or update date. This guide is based on documentary evidence; no customer account, DNS change, relay activation or test delivery was performed.

DNSExit SPF, DKIM and DMARC setup, step by step