ANS SPF, DKIM and DMARC setup, step by step

No customer account, DNS change or sending test was performed.

This is a TXT-record publication guide for an existing authoritative ANS SafeDNS zone. The verified steps cover adding TXT records for SPF, TXT-based DKIM and DMARC. CNAME-based DKIM and changes to an existing record require a separately confirmed account or support procedure; this guide does not establish those controls or complete every DKIM setup route.

Use ANS SafeDNS to publish authentication records issued by your email sender. Do not look for a universal “ANS SPF include” or an ANS-generated DKIM key just because your DNS or virtual server is hosted there. This guide covers an existing authoritative ANS SafeDNS zone, not installing a mail server or moving your domain's nameservers.

SPF authorizes sending infrastructure. DKIM lets a receiver verify a message signature. DMARC checks whether a passing identity matches the domain people see in From. Publishing their records is one stage of setup; the sending service must also use the intended identity and sign actual messages.

Before changing anything

Confirm that you control the domain and have permission to edit its DNS in the correct ANS account. Obtain your email provider's current authentication instructions for the actual account, sending domain, product and region. Save the complete record types, names, values and any activation steps. A screenshot from someone else's account is not your record packet.

Identify the authoritative zone, not merely the company that registered the domain. ANS's SafeDNS domain guide identifies its nameservers as ns0.ukfast.net and ns1.ukfast.net. This UKFast naming remains in the current ANS documentation. An existing zone in ANS Glass is not proof that the public domain delegates to it. Check the live authority before editing; a separately delegated child can have different DNS ownership.

If another provider is authoritative, make the changes there or plan a separate, approved migration. Do not change nameservers, MX, DNSSEC, forwarding or mail routing merely to follow this guide. Those changes can affect the website and inbound email as well as authentication.

Record the existing values and TTLs at every affected owner. Keep a change log with the approved before-and-after values, owner, timestamp and person responsible. Preserve existing selectors, verification tokens, legitimate SPF senders and direct or inherited DMARC policy.

Add authentication TXT records in ANS Glass

Open Services → SafeDNS in ANS Glass and select the existing authoritative domain. This is the SafeDNS service, not ANS Co-Managed Cloudflare or a server's local DNS panel. If your account does not expose the relevant service, ask the authorized administrator or ANS support; do not create a replacement zone.

The official SafeDNS SPF instructions document these TXT controls:

1. In the TXT section, choose Add TXT Record for a genuinely new record. If the section is absent, choose Add New Record Type → Add TXT Record.
2. Enter the hostname and complete value. For an apex SPF policy the documented hostname is blank.
3. Check the full owner, value and any other pending changes, then choose Save Records.

The same TXT record type carries sender-issued TXT DKIM and DMARC data, but their hostnames are not blank: use the appropriate selector or _dmarc owner below. These are DNS-publication applications of the documented TXT editor, not evidence of native signing activation in ANS Glass.

Do not follow the source's broad instruction to add a TXT record if an SPF policy already exists at that owner. Preserve one reviewed policy. The cited page documents adding records, not a precise existing-record edit control. Confirm the account's supported update/restoration workflow before changing existing SPF; do not delete a working policy in anticipation of an unverified replacement.

For sender-issued CNAME DKIM, SafeDNS documents the record type but the sources reviewed here do not establish the exact CNAME-add screen or its name-normalization rules. Obtain the confirmed ANS account/support workflow, then publish the original CNAME packet. Do not substitute TXT, A or ALIAS records to fit the TXT instructions. This is an explicit procedural boundary, not a claim that SafeDNS lacks CNAME support.

Map the issued name to the right zone

Think in full DNS names first. For example, the full DKIM owner could be selector._domainkey.example.com. The selector in this example is illustrative: replace it with the sender's issued selector, not an arbitrary word.

When the editor uses names relative to its selected zone, the mapping is:

For a zone-root TXT policy, ANS's documented Glass workflow leaves hostname blank; confirm the resulting owner is the zone name. Do not assume every DNS interface treats blank, @ and a full name interchangeably. The decisive check is the complete saved owner and its DNS answer, not what looks plausible in a text box. Avoid duplicated suffixes such as example.com.example.com.

ANS's delegation guide specifically warns that edits for a delegated child in the parent zone are ignored. If _domainkey or a child domain is delegated, select its actual authoritative zone and coordinate with its administrator. Do not remove existing NS records to force a new record into the parent zone. A record below a delegation must be published through the authority that actually serves it.

Choose SPF for your sender, not the sample policy

First determine the real SMTP MAIL FROM domain used by your sender, normally reflected in the delivered Return-Path. SPF evaluates that identity, or HELO in the relevant cases, not automatically the visible From address. Adding a service to apex SPF cannot fix an unrelated envelope domain.

Use the sender's documented authorization for that route. There is no universal value to infer from DNS hosting. If you operate your own mail server, authorization must match its actual approved outbound infrastructure, not every IP associated with your ANS account.

At the evaluated owner, publish one TXT record starting v=spf1. If a policy exists, incorporate only the required legitimate authorization while preserving the other valid senders and intentional qualifiers. Do not add a second policy or replace the existing one with a tutorial example. Other, unrelated TXT records can coexist at that owner.

An SPF policy is not merely a list of includes. Evaluate its complete path against the ten DNS-dependent-term limit, including nested mechanisms and redirects. ip4 and ip6 do not consume that particular budget; other SPF limits still apply. An all mechanism causes redirect to be ignored. Do not add a or mx simply because they appear in a sample: that may authorize infrastructure which should not send mail.

ANS shows v=spf1 a mx -all as a basic example, but it is not a universal ANS authorization. It can authorize the wrong infrastructure or omit an external sender. Use an approved route-specific policy rather than copying that example.

Keep the established -all, ~all or other intentional behavior unless a separate policy change is approved. Qualifiers affect SPF results; they do not guarantee that a recipient will accept or reject a message. See RFC 7208.

Publish the complete DKIM record packet

The sending service or your authorized mail-server administrator supplies the selector, signing domain and public DNS records. ANS SafeDNS stores those records; adding them does not turn on signing inside a separate mail application.

For TXT DKIM, preserve the complete tagged public value, including the entire public key. Do not publish a private key, a clipped screenshot value, an empty p= value or a different tenant's key. A long TXT record may be represented by multiple quoted character strings within one DNS record; these are not separate competing DKIM records. Verify that the concatenated result matches the supplied value.

For CNAME DKIM, preserve the issued type, full owner and destination. Do not convert the alias into an A record or insert the destination's current public key as a substitute. At a CNAME owner, do not add conflicting TXT, A, AAAA, MX or another CNAME. If there is already a record or delegation, resolve ownership and dependencies before replacing anything. RFC 2181 section 10.1 explains the CNAME constraint.

ANS's ALIAS documentation describes synthesized address answers. ALIAS is not a substitute for a DKIM CNAME that a sender requires to remain visible as a literal alias.

If any DNS layer offers HTTP proxying or CNAME flattening, ensure the required alias remains a literal CNAME answer when the sender requires one. Disable an applicable per-record flattening option if available, and examine zone-wide, apex and same-zone behavior that could hide the alias. This is a conditional compatibility check, not a claim that SafeDNS exposes a particular proxy or flattening switch. Do not make an unrequested global setting change. If mandatory behavior cannot preserve the issued answer, stop and coordinate a supported configuration.

Return to the sending product after DNS publication. Complete its own domain verification and signing activation steps. A generic DNS-host article cannot invent those account-specific controls. Preserve older selectors while they are still needed for in-flight messages or other approved senders.

Publish DMARC only with the right policy decision

Read the existing direct policy and any applicable inherited policy first. Preserve their protection and authorized report destinations. Do not replace a working enforcement policy with monitoring, create duplicate DMARC records or copy a reporting mailbox from a public example.

Only if no applicable policy exists and the domain owner approves a monitoring plan, a minimal first-policy example is:

Full owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none

Replace example.com with the actual policy domain. In an example.com zone the relative owner is _dmarc; in a parent zone for news.example.com, use _dmarc.news. This minimal example does not request reports. Add an authorized rua destination only as part of an agreed reporting and privacy plan. Monitoring is not an enforcement outcome.

For a report destination in a different Organizational Domain, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain is excepted. A different hostname alone does not determine this distinction. Follow RFC 9990 section 4; DNS authorization does not replace the owner's permission to share report data. Current policy and alignment behavior are defined in RFC 9989.

TTL and saving are not a propagation guarantee

The SafeDNS TTL guide documents a default of 86,400 seconds and locates its TTL setting under the selected domain's SOA heading. Do not change a zone-wide setting casually just to speed one DKIM record. Inspect the actual record answers and their TTLs, and approve any broader cache-setting change separately. A reduced TTL does not evict answers already cached with the old value. ANS also notes other propagation factors; do not treat 24 hours as a guaranteed universal deadline.

Verify publication, then verify a real message

Replace all example domains and selectors below before use. These are read-only query shapes, not fabricated successful results:

dig NS example.com
dig TXT example.com
dig CNAME selector._domainkey.example.com
dig TXT selector._domainkey.example.com
dig TXT _dmarc.example.com

Query the actual authoritative server as well as a public recursive resolver. For example, add @AUTHORITATIVE_SERVER using the server that really serves that zone. Match the full owner, type, target or concatenated TXT data against the approved packet. Check all issued selectors. Cached answers can remain until their TTL expires; a fixed waiting period is not proof that the change is correct. Distinguish an empty answer from NXDOMAIN, SERVFAIL or a timeout.

Next send a controlled test through the intended production application and route to a valid recipient you control. Inspect receiver-generated Authentication-Results inside that receiving service's known processing boundary. Use its documented handling of externally supplied result headers to establish trust. A familiar authserv-id, a high position in the header or a copied results field is not sufficient evidence; ignore attacker-supplied or otherwise untrusted fields. See RFC 8601 section 7.

For newly configured branded DKIM, require the intended provider signature to pass, its signing d= domain to align with the intended visible From under adkim, and the trusted receiver to report dmarc=pass. SPF-only DMARC success does not prove DKIM works. A rewritten provider-owned From address is not successful authentication of your brand.

SPF alignment compares the authenticated MAIL FROM domain with From under aspf. DKIM alignment compares its signing domain under adkim. Relaxed alignment allows the same Organizational Domain; strict alignment requires exact domains. Thus bounce.example.com and example.com can align under relaxed SPF but not strict SPF. Do not promise strict alignment simply because a sender offers a branded child envelope domain.

For more detail, read raw versus aligned DKIM results. A message's valid signature and its contribution to DMARC are separate questions.

Troubleshoot the failed layer

Do not change inbound MX records to troubleshoot outbound authentication unless a separately reviewed sender setup genuinely requires a routing change. Do not turn off DNSSEC to hide a validation failure.

Rollback and ongoing maintenance

If a change is wrong, use the saved before-state to plan restoration of only the affected record. Because the cited SafeDNS TXT guide does not specify an existing-record edit control, obtain the confirmed account or ANS-support restoration workflow before proceeding. Do not delete the entire zone, all TXT records or shared selectors. Retest authoritative DNS and an intended-route message after correction. Where a selector is shared or rotated, coordinate retirement with the sending administrator rather than guessing that an old record is unused.

Repeat checks when senders, outbound IPs, keys, DNS authorities or application routes change. Keep report evidence and controlled message samples without exposing private message content or credentials.