You moved email onto your own domain, sent your first real campaign, and a good chunk of it landed in spam. Before touching subject lines or send times, check the three DNS records that decide whether a receiving server believes the message came from you at all. SPF, DKIM and DMARC are not marketing extras — they are the difference between "this is from that domain" and "this claims to be from that domain". Get them right first, then clean the list with an email validator, then worry about content.
The one-paragraph version
SPF publishes which servers are allowed to send mail for your domain. DKIM attaches a cryptographic signature so the receiver can prove the message was not forged or altered on the way. DMARC ties the two to the address your recipients actually see, tells receivers what to do when nothing lines up, and asks them to send you reports about it. All three are plain TXT records in your DNS. None of them cost anything.
SPF: which servers may send
SPF is a single TXT record on your root domain. A minimal, correct one looks like v=spf1 include:_spf.google.com ~all — version, one mechanism per sending service, then a catch-all. The include: entries are the important part: you need one for every system that sends mail as your domain, including your mailbox provider, your newsletter platform, your CRM and your invoicing app.
The tail matters too. ~all is a softfail: mail from unlisted servers is accepted but marked suspicious. -all is a hard fail. Start with ~all until you are certain you have catalogued every sender, then tighten it.
DKIM: the cryptographic signature
DKIM lives on a selector — a subdomain such as selector1._domainkey.yourdomain.com — holding a TXT record like v=DKIM1; k=rsa; p=MIIBIjANBgkq…, where the long string is a public key. Your sending platform holds the matching private key and signs each outgoing message's headers and body. The receiver fetches the public key from DNS and verifies the signature.
You do not generate this by hand. Every serious sending platform will produce the record (or a CNAME pointing at their own) in its settings. Use 2048-bit keys where offered, give each platform its own selector so you can revoke one without breaking the others, and remember to remove the record when you stop using a service.
DMARC: policy and reporting
DMARC is a TXT record at _dmarc.yourdomain.com. A sensible starting point is v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. The policy tag p= tells receivers what to do with mail that fails: none (do nothing, just report), quarantine (spam folder) or reject (refuse outright). The rua= address receives daily aggregate XML reports listing who has been sending as your domain and whether it passed.
The intended path is a staircase: publish p=none, read reports for two to four weeks until every legitimate sender shows up passing, move to quarantine, and finish at reject. Stopping at none forever is the single most common mistake — it gives you visibility and precisely zero protection.
Alignment: the part everyone misses
SPF and DKIM can both pass while DMARC still fails. DMARC does not just ask "did a check pass?" but "did it pass for the domain in the From: header the recipient sees?" SPF is evaluated against the hidden Return-Path domain, which plenty of platforms set to their own domain by default. If Return-Path is the vendor's and From is yours, SPF passes but is not aligned, and only DKIM saves you.
Five mistakes worth checking for today
- Two SPF records. Publishing a second one instead of merging into the first is an automatic permanent error. One domain, one v=spf1 record, all includes inside it.
- More than ten DNS lookups. Each include:, a, mx and redirect counts, and nested includes count too. Cross ten and the whole evaluation returns permerror. Drop services you no longer use.
- Leaving p=none in place. See above. It is a diagnostic phase, not a destination.
- Ignoring subdomains. DMARC covers subdomains by inheritance, but if you publish sp=none you have opened a door attackers will happily use.
- Forgetting a sender. Ticketing systems, transactional mail and that one legacy server are usually what shows up unauthenticated in your first reports.
How to check what you have published
From a terminal, dig TXT yourdomain.com and dig TXT _dmarc.yourdomain.com show the live records (nslookup -type=TXT on Windows). For an end-to-end test, send a real message to an inbox you control and open the raw headers: the Authentication-Results line states plainly whether SPF, DKIM and DMARC passed. A disposable inbox from 1mail.lt works well for this because it keeps your test traffic out of your main mailbox and out of your own reputation history.
The right order: authenticate, clean, send
Authentication tells mailbox providers who you are. It does not make a bad list good. Once the records pass, the next lever is the list itself: remove addresses that no longer exist, because repeated hard bounces damage your sending reputation far faster than most people expect, and prune the dormant addresses that quietly become spam traps after a provider recycles them. Running the list through an address validator before a large send catches most of both. Only then does content optimisation actually pay off.
Frequently asked questions
Do I need all three, or is SPF enough?
You need all three. SPF alone breaks on forwarded mail, DKIM alone tells receivers nothing about what to do on failure, and without DMARC nobody is enforcing a link to the From: address your recipients read.
How long do DNS changes take to work?
Usually minutes to a few hours, governed by the TTL on the record. Lower the TTL before you make changes if you want to iterate quickly, then raise it again once things are stable.
Will DMARC at p=reject break my mail?
Only if something is still sending unauthenticated. That is exactly what the reporting phase is for: stay at p=none until every legitimate source appears in your aggregate reports as passing and aligned, then tighten in stages.
My records are correct and I still land in spam. Now what?
Authentication is the entry ticket, not the whole game. After that it comes down to list hygiene, complaint rate, sending consistency and engagement. Warm up new domains gradually and make unsubscribing easy.
