SPF, DKIM, and DMARC Explained (With Record Builder)
You send a quote to a customer, they never see it, and three days later they tell you they went with someone else. The email was in their spam folder, or it was silently dropped before it ever got filed. SPF, DKIM, and DMARC are the three DNS records that stop that from happening. They prove to Gmail, Outlook, and Yahoo that mail claiming to come from your domain actually came from you, and they tell those servers what to do with anything that does not check out. This guide explains what each one does in plain terms, how to publish them for your sending provider, how to roll out DMARC without accidentally blocking your own invoices, and the mistakes that quietly undo all three.
The short version
SPF lists which servers may send as your domain. DKIM signs each message so it cannot be altered or faked. DMARC ties the two together, tells receivers what to do with failures, and mails you reports. Publish all three, start DMARC at p=none, read the reports for two or three weeks, then tighten to p=quarantine and finally p=reject. Build your records with the tool below.
Why email authentication stopped being optional
For years these records were a nice-to-have that only IT departments worried about. That changed in February 2024, when Gmail and Yahoo both began requiring bulk senders to authenticate with SPF and DKIM, publish a DMARC record, keep spam complaints low, and offer one-click unsubscribe. Miss those and your mail gets throttled or rejected outright, no warning email, no dashboard alert.
Even if you are nowhere near bulk volume, the same signals feed ordinary inbox placement. A domain with no authentication looks exactly like a domain being spoofed by a scammer, because mailbox providers cannot tell the two apart. That is the real cost of skipping this: your appointment confirmations, quotes, and follow-ups compete for inbox space against every phishing attempt that has ever used your name.
It also protects your customers. Without DMARC enforcement, anyone can send an invoice that appears to come from your billing address, and the first you hear of it is an angry phone call. One TXT record ends that category of fraud for your domain.
SPF, DKIM, and DMARC in plain English
All three live in your domain's DNS, and all three are read by the receiving server before your message reaches a human. They answer different questions.
| Record | Question it answers | Where it lives | What happens without it |
|---|---|---|---|
| SPF | Is this server allowed to send mail for this domain? | One TXT record on your root domain | Any server on earth can claim to be you |
| DKIM | Was this exact message signed by the domain, and unmodified since? | A TXT or CNAME record at selector._domainkey | Content can be tampered with in transit and still look valid |
| DMARC | What should I do with a message that fails, and who do I tell? | One TXT record at _dmarc.yourdomain.com | Failures are ignored, spoofing continues, you see nothing |
The piece most people miss is alignment. DMARC does not just want SPF or DKIM to pass, it wants the domain that passed to match the From address your recipient sees. A newsletter tool can pass SPF perfectly well for its own domain while your From line reads yourcompany.com, and DMARC counts that as a failure. Authenticating your domain inside the sending tool is what brings those two into line.
Build your SPF and DMARC records
You do not need to memorize the syntax. Choose your sending provider, enter your domain, and copy what the builder produces into your DNS host.
Email authentication record builder
Pick where your mail is sent from, type your domain, choose how strict you want to be, and the records below update as you go. Paste them into your DNS host as TXT records.
Your records
SPF, TXT record on yourdomain.com
v=spf1 include:_spf.google.com ~all
DMARC, TXT record on _dmarc.yourdomain.com
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r
DKIM, published by Google Workspace as google._domainkey (TXT)
Google Admin console, then Apps, Google Workspace, Gmail, Authenticate email. Generate a 2048-bit key and publish the TXT value it gives you.
p=none: Nothing is blocked. Mail that fails still lands exactly as it does today, and you simply start collecting reports. Every rollout begins here.
Worth doing before you automate outreach: Intellure sends lead follow-ups on your behalf, and an authenticated domain is what keeps those messages in the inbox.
If you already send through more than one service, merge their include statements into the single SPF record rather than publishing a second one.
Setting up SPF without breaking it
An SPF record is a single line of text listing the services permitted to send on your behalf, ending with an instruction about everything else. The two endings worth knowing are ~all, a soft fail that says treat unlisted senders with suspicion, and -all, a hard fail that says reject them. Start with ~all while you confirm nothing legitimate is missing, then tighten to -all.
One record, no exceptions
A domain gets exactly one SPF record. Publish two and receivers treat both as invalid, which is worse than having none. When you add a new tool, add its include statement to the record you already have.
Mind the ten lookup limit
Every include, a, mx, and redirect costs a DNS lookup, and the standard caps you at ten. Go over and the whole record fails. Drop includes for services you no longer use, and replace a bare mx with the include your mail host actually publishes.
List every real sender
Mail leaves your domain from more places than you think: your mailbox provider, your invoicing software, your booking system, your help desk, your website contact form. Each one needs to be in the record or its mail starts failing.
Protect domains you never send from
Own a parked domain or an old brand name? Give it an SPF record of v=spf1 -all and a DMARC record of p=reject. Unused domains are a favorite target precisely because nobody is watching them.
Setting up DKIM
DKIM is less work than it sounds, because you never handle the cryptography yourself. Your sending provider generates a key pair, keeps the private half, and hands you a public half to publish in DNS. From then on every outgoing message carries a signature in its headers, and the receiver verifies it against the record on your domain. If anything in the signed portion changed on the way, verification fails.
The record sits at a subdomain called a selector, written as selector._domainkey.yourdomain.com. Selectors exist so one domain can run several keys at once, which is exactly what you want when Google Workspace handles your staff mail while a separate platform sends your campaigns. Enable DKIM in each service, publish each selector, and both sign cleanly under the same domain.
Two details catch people out. First, enabling DKIM in a dashboard does nothing until the DNS record is live, and some providers make you come back and flip a switch after publishing. Second, 2048-bit keys are the current norm, and their value is long enough that DNS hosts sometimes mangle it on paste, so verify with a DKIM lookup rather than assuming.
Rolling out DMARC without blocking your own mail
Here is where people get nervous, and reasonably so. Publish p=reject on day one and any legitimate service you forgot to authenticate stops delivering immediately. The fix is to treat DMARC as a staged rollout rather than a switch.
| Stage | Record | Effect on failing mail | How long to sit here |
|---|---|---|---|
| Monitor | p=none with rua reporting | Nothing changes, you only collect data | Two to four weeks |
| Partial enforcement | p=quarantine; pct=25, then raise it | A share of failing mail goes to spam | One to two weeks per step |
| Full quarantine | p=quarantine | All failing mail goes to spam | Two weeks of clean reports |
| Reject | p=reject | Failing mail is refused and never delivered | Stay here |
The reports that arrive at your rua address are XML, which is unpleasant to read by hand. Any DMARC reporting service will turn them into a plain list of who sent mail as you and whether it passed. What you are looking for is a report where every passing sender is one you recognize and every failing one is either a service you forgot to authenticate or someone you are happy to block.
Do this groundwork before you turn on any automated outreach. When Intellure follows up with a lead who went quiet, the message only earns you a reply if it reaches the inbox, and an aligned domain is what decides that. Businesses that authenticate first see follow-up reply rates that reflect their offer rather than their DNS.
Mistakes that quietly undo all three records
Leaving DMARC at p=none forever
This is the most common state on the internet, and it satisfies a checkbox while protecting nothing. p=none tells receivers to take no action. If you never move past it, spoofing continues exactly as before.
Ignoring forwarded mail
Forwarding breaks SPF, because the forwarding server is not on your list. DKIM usually survives it, which is precisely why you need both rather than one. A domain on SPF alone generates mysterious failures every time a recipient forwards to a personal address.
Sending from a lookalike domain
Campaigns sent from mail.yourcompany.com while the rest of your mail comes from yourcompany.com need their own records and their own DMARC consideration. A subdomain inherits your policy unless you set sp, and it does not inherit your SPF record at all.
Never checking again after setup
Every new tool you connect becomes a new sender. Six months of signing up for invoicing apps and scheduling platforms is how a working setup turns into one with three unauthenticated senders. Re-check whenever you add something that emails your customers.
Put a recurring reminder in your calendar to pull one DMARC report a quarter and compare the sender list against the tools you actually use. It takes ten minutes and catches drift before a customer tells you their receipt never arrived.
Frequently asked questions
What is the difference between SPF, DKIM, and DMARC?+
Do I really need all three?+
What DMARC policy should I start with?+
Why do my emails still land in spam when SPF and DKIM pass?+
Can I publish two SPF records for one domain?+
How long do these DNS changes take to work?+
The bottom line
Three DNS records, published once, decide whether your quotes and confirmations get read or get filed as spam. Publish SPF and DKIM, then walk DMARC from p=none up to p=reject while the reports tell you what you forgot. Once the domain is trusted, the follow-up itself is the work that remains, and that is the part an Intellure AI employee takes off your hands: it answers customers, chases the leads that went quiet, and books appointments around the clock, on a domain that now actually lands.