SPF, DKIM, and DMARC are separate email-authentication checks that use DNS records. Correct records help receiving systems evaluate whether messages are authorized and whether their authenticated domains match the visible From domain. They do not guarantee inbox placement or prevent every form of spoofing. This guide explains where the records belong and how to get provider-specific values; it does not supply a universal SPF, DKIM, or DMARC policy.

Start with the DNS provider and every sender

1. Find the DNS provider that hosts the domain's active nameservers. It may be your registrar, web host, or a separate DNS service. Add records in that provider's authoritative zone, not automatically in the email admin console or the company where you bought the domain.
2. List every service that sends using your domain: mailboxes, website forms, billing systems, newsletters, CRM tools, scanners, and other devices. Ask each provider for its current SPF and DKIM instructions for your exact domain and sending setup.
3. Record each provider's exact TXT owner/name and value, and any verification or activation step in its console. Values can be account-specific, rotate over time, and differ between root and sending subdomains. Do not copy another organization's key or a generic example.
4. Save the current DNS zone or capture the existing values before editing. Add only records your mail provider specifies; preserve unrelated verification and service TXT records.

What each record does

• SPF lets a receiving system check whether a sending host is authorized for the domain used in the SMTP HELO or MAIL FROM identity. It is published as TXT at the relevant domain name. If more than one service sends for the same domain, account for all of them in a single SPF policy at that owner name. Multiple separate SPF policies for one owner name cause SPF evaluation problems. SPF alone does not authenticate the visible From domain in every situation.
• DKIM lets a receiving system verify a cryptographic signature and the signing domain. The sending service provides the public-key DNS value and selector. The lookup owner is formed from that selector plus ._domainkey. and the signing domain; for example, a provider might issue a selector name without that suffix and instruct you to add it. Follow its exact owner/name convention. The DNS public key is not the private signing key.
• DMARC publishes a policy for mail using the domain in the visible From header and can request aggregate reports. It checks whether SPF or DKIM passes with a domain aligned to that From domain. The policy record is a TXT record at _dmarc beneath the domain it covers. The current DMARC specification is RFC 9989, published in May 2026, which obsoletes RFC 7489. Choose policy and reporting details for your mail flows; do not paste a policy from a tutorial without understanding its effect.

Publish in a safe order

1. Confirm all legitimate senders and follow their current setup steps. Configure each service to sign with your domain where supported, then publish the exact DKIM selector/key records and complete any provider-side verification or activation.
2. Review the existing SPF TXT value at each sending domain. Merge authorized services according to their instructions instead of publishing another SPF record. SPF has DNS-lookup processing limits, so do not keep appending mechanisms without checking the complete policy against RFC 7208 and the senders' documentation.
3. Check that test messages show the expected SPF and DKIM results and that at least one passing identifier aligns with the visible From domain. A pass for an unrelated provider domain may not satisfy DMARC alignment.
4. Only after inventorying senders and reviewing reporting needs, publish a DMARC record at the correct _dmarc owner. Select the policy, subdomain handling, and report destinations deliberately. Monitor reports and investigate legitimate senders that fail before tightening enforcement; a stricter policy can affect legitimate mail that is not correctly authenticated or aligned.
5. After saving DNS changes, query the exact TXT owner names or use the DNS provider's record view, then verify again with the email provider. DNS caching and provider verification schedules vary, so use the provider's stated status rather than assuming a fixed propagation time.

Common TXT-record mistakes

• Adding records at a registrar that is not hosting the active DNS zone.
• Entering the full domain into a DNS form that automatically appends the zone name, producing a duplicated suffix. Check how that provider handles relative names and fully qualified names.
• Publishing two SPF records at the same owner instead of carefully combining sender authorization into one record.
• Replacing the entire root TXT set and accidentally removing domain verification or another service's record.
• Putting DKIM at the wrong selector, domain, or subdomain, or wrapping/truncating a long value in a way the DNS control panel does not support.
• Publishing DMARC at the apex rather than the required _dmarc name, or setting enforcement before identifying every legitimate sender.

For a limited local syntax review of pasted SPF values, use the SPF syntax checker; it does not query DNS or follow nested policies. For A, AAAA, CNAME, and MX formatting, see the DNS record format checker; it does not inspect TXT records. Use the website email cost comparison to itemize mailbox and hosting costs separately from DNS configuration.

Provider setup documentation

Use the admin console and documentation for the service that sends your mail. These pages explain provider-specific setup; their record values and steps can change, so confirm them in your account before publishing:

• Google Workspace: set up SPF, DKIM authentication, and DMARC.
• Microsoft 365: external DNS records and DMARC setup and reports.
• Cloudflare: set up email records, including links to security-record instructions.

Sources checked November 3, 2026

• RFC 7208: Sender Policy Framework — SPF TXT publication, record selection, and processing requirements.
• RFC 6376: DKIM Signatures — selector-based DNS public-key lookup and TXT key records.
• RFC 9989: DMARC — current policy-record location, alignment, policy, and reporting framework; published May 2026 and obsoletes RFC 7489.
• Cloudflare DNS: Set up email records — overview of SPF, DKIM, and DMARC roles and provider-specific setup links.