DNS Made Easy SPF, DKIM and DMARC setup, step by step

DNS Made Easy publishes the DNS records your sending service supplies. It does not turn an arbitrary domain into an authenticated sender merely because a TXT record was saved. In Managed DNS, use TXT for SPF, DMARC and provider-issued DKIM TXT records; use CNAME when the sender explicitly issues a DKIM alias. Verify the public answers, then finish the sending service's verification and signing steps.

This guide covers an existing authoritative DNS Made Easy Managed DNS zone. It does not configure the separate DNS Made Easy SMTP service, migrate nameservers, or invent tenant-specific DKIM values.

Before editing: establish authority and keep a recovery copy

Confirm which service is authoritative for the exact record owner, not just where the domain was purchased. Check the parent delegation and any child-zone or _domainkey delegation. A zone appearing in your account does not prove the public DNS uses it. If another provider controls the relevant zone, publish there instead. Do not change nameservers, DNSSEC or a working NS delegation to make these instructions fit.

Use an account permitted to edit the selected zone. Record the existing owner, type, value and TTL of every affected record; keep website, MX, verification TXT and unrelated sender records intact. Agree the exact change and rollback with the domain owner. A sender's packet that includes MX, A, forwarding or delegation changes needs separate routing approval; adding authentication is not permission to reroute incoming mail.

Obtain the current record packet from the actual sending account: product/region, sending domain, full DNS owner, type, complete value and verification instructions. Keep private keys out of DNS and tickets. DNS Made Easy's own DKIM guidance directs customers to obtain the public key from their mail service. Its generic TXT description does not override a sender that issues CNAME records.

Translate the full owner into the selected zone

DNS Made Easy appends the selected domain to its Name field. The apex uses a blank Name, not a full-domain label. For a zone example.com, these illustrative translations apply:

• SPF at example.com: leave Name blank.
• SPF at bounce.example.com: enter bounce, but only if this is the sender's actual evaluated envelope domain and the approved packet calls for a TXT policy there.
• DKIM at SELECTOR._domainkey.example.com: enter SELECTOR._domainkey.
• DMARC at _dmarc.example.com: enter _dmarc, never blank.
• DKIM at SELECTOR._domainkey.news.example.com in the parent zone: enter SELECTOR._domainkey.news.
• DMARC at _dmarc.news.example.com in the parent zone: enter _dmarc.news.

If news.example.com is separately delegated, select that child zone: its SPF apex is blank, its DKIM Name is SELECTOR._domainkey, and its DMARC Name is _dmarc. If _domainkey.example.com itself is delegated, publish SELECTOR in that authoritative zone. Do not add a shadow record below a parent delegation or delete the delegation. These are translations, not instructions to create new zones or choose selectors.

Before saving, reconstruct the full owner by joining Name and zone. A duplicated suffix such as example.com.example.com is wrong. The documented CNAME Name and Alias to behavior distinguishes the owner from its destination: an external target needs its absolute spelling, including the final dot to prevent the zone suffix being appended.

Publish TXT records in Managed DNS

1. Open the DNS menu and choose Managed DNS.
2. Select the authoritative domain from the domain list or Select Domain search.
3. Locate TXT Records (SPF) and use its plus button for a genuinely new owner/value. If revising an existing policy, preserve the other records rather than adding a conflicting second policy.
4. Enter the zone-relative Name, complete approved Value and agreed TTL in seconds.
5. Submit, then inspect the saved entry. A success notification confirms the editor accepted it, not that a receiver has authenticated a message.

The official TXT procedure documents this route and multiple quoted strings for long TXT content. Each DNS character-string is limited to 255 octets; multiple strings can belong to one TXT record. Do not turn a long key into several TXT records. Preserve the full tagged DKIM value, including p=, punctuation and key characters. Use ordinary straight quotes for the editor's documented chunk representation; inspect the joined DNS value afterwards. Presentation quotes are not extra characters in the key.

SPF: one policy at the evaluated owner

SPF authenticates the SMTP MAIL FROM domain, or HELO in relevant cases, not automatically the visible From address. A provider-owned envelope may use the provider's SPF rather than your apex. Ask the sender which owner is actually evaluated before adding its mechanism.

At that owner, retain one v=spf1 TXT policy containing all legitimate approved authorizations. Merge changes into the existing policy without discarding mechanisms or changing qualifiers casually. The DNS-dependent evaluation budget is ten terms, including nested evaluation, not ten top-level includes. An all mechanism causes redirect to be ignored. -all expresses SPF failure; it does not dictate a universal receiver rejection outcome. Review the actual expanded policy before saving. These constraints come from RFC 7208, not the DNS editor's labels.

The section label TXT Records (SPF) does not mean the obsolete SPF-specific DNS record type should be used. Nor does hosting DNS here justify adding a guessed DNS Made Easy SPF include.

Publish provider-issued DKIM CNAMEs without changing their meaning

For each required alias, use Managed DNS, select the zone, and add it in CNAME Records. Enter the translated Name and the complete sender-issued target in Alias to; make an external target absolute with a trailing dot. Preserve all required selectors. Do not copy a sample selector or target from someone else's screenshot. The sender's DNS Made Easy implementation example independently confirms these fields and the trailing-dot issue; its own account-specific records are not universal values for other services.

At a CNAME owner, do not retain conflicting TXT, A, AAAA, MX or another CNAME. Investigate any existing record before replacement; it may serve another application or key rotation. A normal DKIM alias resolves toward a public-key TXT record. Do not reinterpret it as a website address because the DNS Made Easy generic CNAME page discusses A-record destinations.

Use a literal DNS CNAME, not an ANAME or HTTP redirect. DNS Made Easy's ANAME documentation explains that ANAME synthesizes A answers. That is not a substitute when the sender checks for a CNAME. Keep mail-authentication aliases DNS-only rather than behind any HTTP proxy layer.

If another DNS layer applies flattening, inspect per-record, whole-zone, apex and same-zone behavior. Where a literal CNAME is required, disable the relevant per-record flattening when supported and ensure applicable zone behavior preserves the alias. Do not invent a DNS Made Easy switch or globally disable website behavior. If mandatory apex or same-zone processing cannot return the issued CNAME, stop and arrange a supported configuration with the DNS and sending providers. Never move shared delegations as a shortcut.

Add DMARC only within the domain owner's policy plan

Inspect the direct policy and any applicable inherited policy first. Preserve working enforcement, alignment modes and authorized reporting destinations. Do not downgrade protection to p=none, publish a second policy, or paste someone else's reporting address. The DNS Made Easy DMARC page establishes the TXT owner _dmarc; protocol requirements and policy selection come from current standards.

Only when no direct or applicable inherited policy exists, the owner approves a monitoring phase, and someone will review the reports, this is an illustrative first policy:

Type: TXT
Full owner: _dmarc.YOUR-DOMAIN.example
Value: v=DMARC1; p=none; rua=mailto:APPROVED-REPORT-MAILBOX

Replace APPROVED-REPORT-MAILBOX with an approved mailbox address, not another mailto: URI. Translate the owner using the selected zone as above. This is not a recommendation to modify an existing policy or add obsolete percentage rollout tags. Current DMARC specification RFC 9989 governs policy and alignment.

If the report destination is in a different Organizational Domain from the policy domain, the report-generating receiver must check DNS authorization. Destinations within the same Organizational Domain are excepted; a different hostname alone is not the test. Coordinate any required authorization with the report operator instead of inventing a record. Protocol authorization does not replace the domain owner's data-sharing decision. See RFC 9990 section 4.

Verify DNS first, then verify the sender

Use read-only lookups after substituting actual approved names. These commands are examples, not recorded results:

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

Query every authoritative server for consistency, then a recursive resolver. Confirm the exact owner, required type, complete TXT content or issued alias target, and absence of conflicting records. With a CNAME, inspect both the alias and the key reached through it. With split TXT strings, compare their concatenation to the approved value. Old cached answers can persist for the previous TTL; do not promise one universal propagation deadline.

Return to the sending service. Complete its documented domain verification and signing activation. A DNS Made Easy success message cannot perform those actions. Send a controlled test through each intended production path to valid mailboxes you control or are authorized to use. Do not test on customer lists.

Use Authentication-Results produced inside the receiving service's known processing boundary. Establish from receiver documentation or its administrator how inbound forged fields are removed or disregarded and how its genuine results are exposed. A familiar authserv-id or a header's position alone proves nothing; ignore attacker-supplied results. RFC 8601 explains that trust boundary.

For a new branded DKIM route, require the intended signature to pass, its d= domain to align with the intended visible From under the current adkim mode, and trusted dmarc=pass. SPF-only DMARC success is insufficient proof of DKIM. Do not accept a rewritten provider From as your brand's success. Relaxed alignment compares Organizational Domains; strict alignment requires identical domains. Evaluate SPF and its actual envelope domain separately under aspf; a child envelope domain does not guarantee strict alignment. For diagnosis, use EmailAuth's raw versus aligned DKIM guide.

Troubleshoot and roll back the exact change

• Record exists only in the dashboard: check public authority, delegated child zones and the fully reconstructed owner.
• CNAME target ends in your domain twice: correct the absolute target representation, then query authoritative DNS again.
• Long DKIM TXT fails: compare joined strings, check truncation or smart quotes, and ensure it is one TXT record rather than several keys at the selector.
• SPF permerror: examine duplicate policies, syntax and evaluated DNS-term budget. SPF temperror calls for transient DNS investigation; SPF fail means the evaluated authorization did not pass. Fix the actual cause even if DKIM currently saves DMARC.
• DKIM passes but DMARC fails: compare d= with the visible From and policy mode. DNS publication alone cannot change a provider-owned signing identity.
• Provider remains pending: confirm every issued record, saved target and activation step before escalating with the public record packet. Never send a private key.

If a change breaks an established route, restore only the approved prior values and TTLs from your recovery copy. Coordinate sender-side rollback too; do not remove a selector while that service still signs with it. Leave unrelated website, inbound mail and delegation records untouched. Recheck DNS and controlled received mail after recovery.