Must I add website forwarding before DKIM?

No. The CNAME tutorial's forwarding step is optional and website-specific. Preserve the approved root configuration and resolve any editor constraint without altering unrelated traffic.

Does this configure Dynadot Email?

No. This is the DNS-publishing task. A sending service's account, keys, activation and message identities require its own supported workflow.

Does saved DNS prove DMARC success?

No. Public publication, sender activation and trusted received-message authentication are distinct checkpoints. None was executed for a customer by this documentary guide.

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

Use Dynadot's DNS editor only when Dynadot DNS is authoritative for the record you need to publish. Put apex TXT data under Domain Record; put a selector or _dmarc label under Subdomain Records. Take SPF authorizations and public DKIM records from the actual sending service, preserve existing policies, and verify public DNS before testing received mail.

This guide covers DNS publication in an existing Dynadot DNS configuration, not configuration of Dynadot Email as a sender. It does not authorize a nameserver migration, disabling mail settings or adding website forwarding. No customer account, DNS edit or real-message test was performed.

Identify the zone and the change before opening the form

A domain registered with Dynadot may use third-party DNS. Check the delegation and identify the authoritative zone for each full owner. Include any separately delegated child or _domainkey namespace. Where another DNS host is authoritative, edit there; do not switch DNS modes simply to expose this editor. Dynadot's DNS setup guidance explicitly distinguishes these cases.

Make a recovery record of the domain's current DNS mode, root configuration, owner/type/value/TTL for affected records, and relevant sender settings. Record who approved each change. The operator needs access to the correct domain and permission to save its DNS, not merely an account login.

Request the sender's exact current record packet: full owner, type, complete value, product/account scope and activation steps. Do not infer a selector or include from the sender's company name. Preserve private keys at the signer; DNS receives only public material. Mail routing, MX, website destinations, forwarding, NS and DNSSEC are separate dependencies, not incidental cleanup.

Use the documented Dynadot DNS route

In the account, open My Domains and Manage Domains.
Select only the intended domain, then Action and DNS Settings.
Confirm that the existing mode is Dynadot DNS. If it is a different service or mode, stop rather than changing it under an authentication-only request.
Review the current root and subdomain rows before editing. Use the section and record type appropriate to the full owner.
After reviewing the exact difference, choose Save Settings and inspect the resulting configuration.

The primary TXT instructions call the value field IP Address / Destination; the DKIM instructions use IP Address or Target Host. Both describe a value field, not permission to replace a public key with an IP address. If the actual form differs, confirm its semantics rather than guessing.

Respect the root-record constraint without inventing a destination

Dynadot's TXT documentation says a root A, AAAA, CNAME or forwarding configuration is also required. This is an editor constraint, not a general requirement of SPF or DMARC. Keep the real approved root configuration. If a mail-only domain has no suitable entry and the form refuses the intended TXT record, stop and obtain a supported design from Dynadot and the domain owner. Do not enter a dummy address or forwarding URL.

The generic CNAME walkthrough includes an optional website-forwarding example. It is not an authentication prerequisite. Likewise, the setup page's instruction to disable Dynadot Email Setting describes a consequential mode change, not a safe shortcut for existing mail. Do not disable email, reset the zone or activate forwarding without a separately approved migration plan.

Map complete DNS owners to Domain and Subdomain records

For the illustrative zone example.com, prepare this translation card before saving:

example.com SPF TXT belongs in Domain Record. A supplied @ means that section; do not type a literal @ label.
bounce.example.com SPF TXT belongs in Subdomain Records with bounce, but only when the approved sender configuration actually evaluates that envelope domain.
SELECTOR._domainkey.example.com belongs in Subdomain Records with SELECTOR._domainkey, using the issued TXT or CNAME type.
_dmarc.example.com belongs in Subdomain Records with _dmarc and type TXT.
SELECTOR._domainkey.news.example.com in the parent zone uses SELECTOR._domainkey.news; _dmarc.news.example.com uses _dmarc.news.

Remove only the selected zone suffix. A full name in a prefix-only field can become example.com.example.com. Keep the selector intact and do not replace it with Dynadot's example google._domainkey unless that is what your sender issued.

If news.example.com is separately delegated, use its actual authoritative provider and child zone instead: its apex SPF maps to that zone's apex, its DKIM prefix is SELECTOR._domainkey, and its DMARC prefix is _dmarc. If _domainkey.example.com is separately delegated, the key owner is SELECTOR relative to that zone. Do not assume Dynadot provides a separate-zone UI for every delegation; use the provider that actually hosts it. Retain shared NS delegations and never create an ineffective parent-side shadow record.

The first-party TXT owner rules establish apex versus prefix behavior. The translation examples above apply those rules; they are not tenant values or instructions to create a new delegation.

Enter SPF as one TXT policy at the right owner

Dynadot's SPF procedure selects TXT and places the supplied policy in the destination field. Do not create an obsolete SPF-specific DNS record type. The policy owner must correspond to the actual SMTP MAIL FROM domain, or HELO in relevant cases, rather than automatically the visible From domain.

Keep one v=spf1 policy at that owner and preserve all legitimate authorizations when adding a sender. Do not replace the apex policy with a vendor example or add a second policy to avoid editing the first. Retain unrelated TXT verification tokens.

Evaluate the complete policy's DNS-dependent terms, including nested mechanisms: the limit is ten evaluated terms, not ten includes. Preserve qualifiers deliberately; redirect is ignored when an all mechanism exists. -all produces an SPF fail, not a universal delivery rejection guarantee. A provider-owned envelope may use its own SPF, so adding a mechanism to your apex might not affect that route. See RFC 7208.

Publish the exact DKIM TXT or CNAME record

For TXT, use the issued selector prefix under Subdomain Records and paste the complete public value. Dynadot documents removing surrounding presentation quotes. Preserve the key, tags, semicolons and other actual data. Do not paste the private key or a screenshot's example key. If a long value is rejected or truncated, stop and confirm the supported input representation; do not shorten it or create several competing TXT records. Multiple DNS strings may compose one record, but they are not multiple keys. For DKIM, concatenate those strings without adding whitespace before processing the key, as specified in RFC 6376 section 3.6.2.2.

If the sender issues CNAMEs, use CNAME in Subdomain Records and the full issued destination, not TXT and not www. Preserve every required selector. The native CNAME walkthrough provides the section and Save Settings route; its website-oriented preference for A records does not justify replacing an authentication CNAME with an address.

Check that the CNAME owner has no conflicting TXT, A, AAAA, MX or other CNAME. Inspect existing selectors and shared dependencies before removing anything. A sender's expected public-key lookup may follow an alias; verify the resulting target rather than assuming an editor success means a usable key.

Do not substitute ANAME, forwarding or an HTTP proxy for a literal DKIM CNAME. Dynadot's ANAME guidance describes a separate apex-only option with its own conflicts, not an equivalent selector record. If another authoritative layer applies flattening, consider per-record, whole-zone, apex and same-zone behavior. Where a literal CNAME answer is required, disable the applicable per-record flattening when supported and ensure zone behavior preserves the alias. Do not invent a Dynadot flattening switch or globally disrupt website settings. If mandatory behavior cannot retain the required CNAME, coordinate a supported design rather than moving shared delegations.

Keep DMARC policy and reporting decisions explicit

Check the direct policy and any applicable inherited policy first. Preserve existing enforcement, alignment modes and authorized reports. Do not publish two policies or downgrade a working policy to monitoring because a tutorial shows p=none.

Only if there is no direct or applicable inherited policy, the owner approves monitoring and someone will review its reports, an illustrative first entry is:

Section: Subdomain Records
Subdomain: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:APPROVED-REPORT-MAILBOX

This example assumes the selected zone is the intended policy domain; translate a child policy as described above. Replace APPROVED-REPORT-MAILBOX with a mailbox address, not an additional mailto: URI. Never copy another organization's reporting destination. Use current RFC 9989, not obsolete percentage-rollout advice.

For an aggregate-report destination in a different Organizational Domain from the policy domain, the report-generating receiver must verify DNS authorization. A destination in the same Organizational Domain is excepted, even when its hostname differs. Coordinate required authorization with the report operator, and separately obtain the owner's data-sharing approval. RFC 9990 section 4 defines the protocol check.

Verify public answers and the intended message path

Substitute actual approved names in these read-only examples. They are not fabricated test results:

dig @AUTHORITATIVE-NS.example FULL-OWNER.example TXT +noall +answer
dig @AUTHORITATIVE-NS.example SELECTOR._domainkey.YOUR-DOMAIN.example CNAME +noall +answer
dig SELECTOR._domainkey.YOUR-DOMAIN.example TXT +noall +answer
dig _dmarc.YOUR-DOMAIN.example TXT +noall +answer

Check each authoritative server and a recursive resolver. Compare full owner, exact type, complete joined TXT content, alias destination and absence of conflicts. Keep query timestamps and the prior TTL; cached answers can remain stale after an authoritative update. Do not repeatedly edit a correct record merely because one resolver has not expired its cache.

Next, return to the actual sending service, finish its documented verification and activate signing. A Dynadot DNS save does neither. Send a controlled, non-sensitive test through each intended production route to valid authorized test recipients.

Read results generated inside the receiving service's known processing boundary. Confirm its documented treatment of externally supplied Authentication-Results with its administrator or documentation. A matching authserv-id or header position alone does not authenticate the header; disregard attacker-inserted results. This operational boundary is explained in RFC 8601.

For new branded DKIM, require the intended signature to pass and its d= to align with the intended visible From under the actual adkim mode, plus trusted dmarc=pass. SPF-only DMARC success cannot prove DKIM works; a rewritten provider From is not successful authentication of your intended brand. Relaxed alignment compares Organizational Domains, while strict alignment requires identical domains. For example, with visible From sender@example.com, a passing intended signature with d=mail.example.com aligns only in relaxed mode when both share the Organizational Domain example.com; d=example.com matches in both modes. These are illustrative identities, not observed results. Evaluate SPF separately using the actual envelope and aspf; a child envelope domain does not promise strict alignment. EmailAuth's raw versus aligned DKIM explanation helps distinguish the two outcomes.

Troubleshooting and precise recovery

The form refuses TXT: preserve the real root configuration and resolve the provider's constraint; never invent a website target.
The expected owner is empty: check prefix duplication, DNS mode and delegated child-zone authority.
The key exists but DKIM fails: verify complete key data, selector and sender activation. A DNS record cannot repair message modification after signing.
SPF permerror: investigate duplicate policies, syntax or lookup-budget violations. Temperror indicates a temporary evaluation problem; fail means the evaluated authorization did not pass. Do not ignore SPF defects because DKIM currently provides DMARC success.
A signature passes but DMARC fails: compare the actual signing domain, visible From and alignment mode before editing DNS again.

Restore only the approved previous owner/type/value/TTL if rollback is needed. Coordinate any sender-side change and selector rotation; keep a key available while legitimate messages still depend on it. Do not use Clear Settings or change DNS mode as a shortcut. Recheck public records and controlled received mail after recovery.

Dynadot SPF, DKIM and DMARC setup, step by step