How To Set Up SPF, DKIM, and DMARC Records for Your Email-Sending Domain
Tricknowtech Team 10 min read
Goal
By the end of this tutorial your domain will have SPF, DKIM, and DMARC TXT records published in DNS, verified with dig, and a documented path for moving DMARC from monitoring to full enforcement.
Prerequisites
A registered domain name you control, with access to its DNS zone
Access to your DNS provider's control panel to add TXT records
A mail-sending service (mail server or transactional/marketing email platform) that will supply your SPF include/IP details and a DKIM selector plus public key
The dig command-line tool installed (part of bind-utils/dnsutils on most Linux distributions, or available via Homebrew on macOS)
Patience — DNS changes can take anywhere from minutes to a few hours to propagate, depending on record TTLs
Let an AI agent do this for you
Copy a ready-made prompt for an AI coding assistant with terminal access to your server (Claude Code, Cursor, or similar) — it can carry out the steps below for you. Review what it plans to run before it executes anything.
When you send email from your domain, receiving mail servers have no built-in way to know whether a message genuinely came from you or from someone spoofing your address. Three DNS-based standards work together to solve that: SPF (Sender Policy Framework) publishes which mail servers are authorized to send on your domain's behalf; DKIM (DomainKeys Identified Mail) lets a receiver cryptographically verify that a message was signed by your domain and wasn't tampered with in transit; and DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties the two together, telling receivers what to do when a message fails those checks and where to send reports about the results.
None of the three is strictly required to send mail, but together they form the baseline that spam filters and major inbox providers expect from a legitimate sending domain. This tutorial covers creating all three records, verifying them with dig, and safely tightening enforcement once you've confirmed your own mail is passing.
Step 1 — Create an SPF Record
An SPF record is a TXT record published at your domain's apex — the root domain itself, such as example.com, not a subdomain — that lists the mail servers and services authorized to send email for that domain. When a receiving server gets a message claiming to be from your domain, it looks up your domain's SPF record and checks whether the IP address of the server that connected to it appears among the authorized senders.
SPF Syntax
Every SPF record starts with v=spf1, followed by one or more mechanisms, and ends with a qualifier that decides what happens to anything not explicitly matched. include: authorizes another domain's SPF record — the usual way to authorize a third-party sender such as a transactional email or marketing platform. ip4: and ip6: authorize a specific address or CIDR range. a and mx authorize the domain's own A or MX records. The trailing all mechanism is qualified with - (hard fail, reject), ~ (soft fail, accept but flag), ? (neutral), or + (pass everything — never use this).
Start with ~all while you confirm every legitimate sending source is included, then tighten to -all once you're confident the record is complete — a hard fail with a missing sender causes legitimate mail to be rejected outright.
“DNS allows only one SPF record per domain. Publishing two separate v=spf1 TXT records doesn't merge them — most receivers treat that as invalid (a PermError) and skip SPF checking entirely. If you need to authorize multiple senders, combine them inside a single record with multiple include:/ip4:/ip6: mechanisms. Also watch the 10-DNS-lookup limit: each include, a, mx, ptr, and exists mechanism counts against it (nested includes count too), and exceeding it also produces a PermError. Keep your record lean and re-check the count whenever you add a new sending service.”
Tricknowtech Email Sending API
Order confirmations, receipts, OTPs and account alerts — every send LLM-verified as transactional, never marketing.
In your DNS provider's control panel, create a new TXT record. Set the host/name field to @ (or leave it blank, depending on the provider — both mean "the domain apex"). Paste the SPF string, including the surrounding quotes if your provider requires them for TXT values, into the value field, leave TTL at its default, and save. Propagation is usually fast, but can take up to a few hours depending on your record's TTL.
Step 2 — Create a DKIM Record
DKIM works differently from SPF: instead of authorizing sending IPs, it lets a receiver verify that a specific message was signed by a private key your sending service holds, using a public key it published for you in DNS. When your mail server or email service sends a message, it adds a DKIM-Signature header containing a hash of the message signed with its private key. The receiving server fetches your public key from DNS and checks the signature — confirming both that the message came from an authorized signer and that it wasn't altered in transit.
The public key is published at a selector subdomain under _domainkey, for example default._domainkey.example.com. The selector name (default in that example) is assigned by whichever service signs your mail — it might be default, mail, selector1, or a random string, and a domain can have several active at once. Because the key itself is generated and controlled by your sending service, you can't invent it here — you need to get the selector and public key value from that service's DKIM setup page.
text
default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB...(truncated placeholder — use the value your sending service provides)..."
The v=DKIM1 tag marks the record's version, k=rsa names the key algorithm, and p= holds the base64-encoded public key your sending service generated — copy that value exactly as given, since a single missing character breaks verification. An empty p= value is a valid, deliberate way to revoke a compromised key without deleting the record.
Adding the DKIM Record
Add another TXT record: host/name is the full selector, e.g. default._domainkey, and value is the quoted string your sending service gave you. If the key is long, some DNS panels require it split into multiple quoted strings under 255 characters each — most panels handle this automatically when you paste a long value.
Step 3 — Create a DMARC Record
DMARC is a TXT record at _dmarc.example.com that tells receivers what to do when a message fails to align with SPF and/or DKIM, and where to send reports about the results. "Alignment" means the domain that passed SPF or DKIM matches the domain in the message's visible From: header — a message can technically pass SPF for some unrelated domain and still fail DMARC if it doesn't align with what the recipient sees as the sender. DMARC is what actually turns SPF and DKIM into an enforceable anti-spoofing policy.
DMARC Syntax
v=DMARC1 must be the first tag and is required. p= sets the policy for the domain itself: none (take no action, just report), quarantine (treat as suspicious, e.g. deliver to spam), or reject (refuse the message outright). rua=mailto:address requests daily aggregate reports summarizing pass/fail results from receivers that support DMARC. ruf=mailto:address requests per-message forensic reports (less widely supported). pct= limits the policy to a percentage of mail, useful for a gradual rollout. sp= sets a separate policy for subdomains, and adkim=/aspf= choose strict (s) or relaxed (r, the default) alignment.
text
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"
Adding the DMARC Record
Create a TXT record with host/name _dmarc and the value above. Use a mailbox you actually monitor for rua — aggregate reports arrive daily and are the main tool you'll use in Step 5.
“Always start with p=none. It applies no enforcement, so nothing you haven't tested yet can get blocked, but receivers that support DMARC will still send you aggregate reports showing which sources send mail as your domain and whether they pass SPF/DKIM alignment — the visibility you need before turning enforcement on.”
Step 4 — Verify Your Records with dig
With all three records published, confirm they resolve correctly using dig's TXT lookup. Run each of the following from any machine with dig installed.
bash
# SPF — published at the domain apex
dig TXT example.com +short
# DKIM — published at the selector subdomain (replace 'default' with your actual selector)
dig TXT default._domainkey.example.com +short
# DMARC — published at _dmarc
dig TXT _dmarc.example.com +short
Each command should return exactly one quoted TXT string starting with v=spf1, v=DKIM1, and v=DMARC1 respectively. If the SPF lookup returns more than one v=spf1 string, merge them into one record. If the DKIM lookup returns nothing, double-check the selector name with your sending service — it's the most common source of DKIM verification failures. If the DMARC lookup returns nothing, dig is querying the wrong host; it must be _dmarc.<yourdomain>, not the apex.
Step 5 — Move DMARC from Monitoring to Enforcement
Leave p=none in place for at least one to two weeks — long enough to capture weekly batch mail like invoices or newsletters — and review the aggregate reports your rua address receives. These arrive as gzipped XML attachments from participating mail providers; a DMARC report viewer or parsing tool makes them far easier to read than raw XML. Confirm every legitimate source your domain sends from — your website's transactional mail, marketing platform, helpdesk, and so on — is passing SPF or DKIM alignment before changing the policy.
Once reports look clean, move to quarantine, optionally ramping up gradually with pct= so a misconfiguration doesn't quarantine all your mail at once:
“Don't jump straight to p=reject. Mailing lists, forwarders, and some third-party senders can break SPF or DKIM alignment even for legitimate mail, and reject discards affected messages with no chance to fix them after the fact. Keep watching aggregate reports at each stage, and only tighten the policy once a stage has run clean for a full reporting cycle.”
Conclusion
You've published SPF, DKIM, and DMARC records for your domain, verified each with dig, and moved DMARC from a monitoring-only policy to active enforcement. Together, these three records let receiving mail servers confirm your mail is genuinely yours, which improves deliverability and makes it much harder for anyone to spoof your domain in phishing mail. Revisit the SPF record whenever you add or remove a sending service, and keep an eye on DMARC aggregate reports periodically even after reaching p=reject.
