SPF, DKIM and DMARC are three DNS records that prove your email is really from you, and mailbox providers increasingly expect all three.
If emails from your domain land in spam, or recipients' mail servers reject them, the cause is often missing or incorrect DNS records for email authentication. Three standards do most of the work: SPF, DKIM and DMARC. They're all published as DNS records, which means you can check them in seconds with the DomainBulleter.
This guide explains each one, shows what correct records look like, and lists the mistakes we see most often.
Why SPF, DKIM and DMARC are now expected
Large mailbox providers have tightened their rules. Google's email sender guidelines require every sender to Gmail accounts to set up SPF or DKIM, and senders of more than 5,000 messages a day must have SPF, DKIM and DMARC in place. The guidelines also ask senders to keep spam rates below 0.3% and recommend 2048-bit DKIM keys. On the SPF side, the standard, RFC 7208, limits evaluation to 10 DNS lookups. Go over that and the check fails with a permanent error.
Why email authentication exists
Email was designed decades ago without any built-in way to prove who sent a message. Anyone could put your domain in the "From" line. Spammers and scammers still try. SPF, DKIM and DMARC let receiving mail servers verify that a message claiming to be from your domain really came from a server you approved and wasn't altered on the way.
Major mailbox providers increasingly expect senders to have these records, especially senders who send a lot of email. Even small senders benefit, because authenticated mail is less likely to be filtered.
SPF: who is allowed to send
SPF (Sender Policy Framework) is a TXT record that lists the servers allowed to send email for your domain.
A typical SPF record looks like:
v=spf1 include:_spf.example-mail.com include:sendgrid.net ~all
Reading it:
v=spf1marks it as an SPF record.- Each
include:adds the sending servers of a service you use, such as your email provider or a newsletter tool. ~allsays "anything else is probably not legitimate" (a soft fail).-allis stricter (a hard fail).
Common SPF mistakes
- More than one SPF record. A domain must have only one. If you add a new service, edit the existing record to include it rather than creating a second.
- Too many lookups. SPF allows at most ten DNS lookups when it's evaluated. Each
includecan add several. Long lists of services can exceed the limit and break SPF entirely. - Forgetting a service. If your website, help desk or invoicing tool sends email as your domain, it needs to be included.
- Using
+all. This allows anyone to send as you, which defeats the purpose.
DKIM: a signature on every message
DKIM (DomainKeys Identified Mail) adds a digital signature to each outgoing message. The receiving server checks the signature against a public key you publish in DNS. If it matches, the message really came from an authorized sender and wasn't modified in transit.
DKIM keys are published as TXT (or sometimes CNAME) records at a special name that includes a selector, for example:
selector1._domainkey.example.com
Your email provider tells you the selector and the value to publish. Each service that sends for you usually has its own selector, so a domain can have several DKIM records.
Checking DKIM
To look up a DKIM record, you need to know the selector. Your email provider's settings usually show it, or you can find it in the headers of an email you sent (look for s= in the DKIM-Signature header). Then look up selector._domainkey.yourdomain.com as a TXT record.
Common DKIM mistakes
- Not turning signing on. Publishing the record isn't enough; signing usually needs to be enabled in the email provider's settings too.
- Copy-paste errors. Keys are long. Missing a character, or adding quotes or spaces in the wrong place, breaks them.
- Old keys left behind after switching providers. They don't usually cause failures, but they're clutter worth cleaning up.
DMARC: the policy that ties it together
DMARC tells receiving servers what to do when a message fails SPF and DKIM checks, and where to send reports. It's a TXT record at _dmarc.yourdomain.com.
A starting DMARC record looks like:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
p=nonemeans "don't block anything yet, just report". It's the safe place to start.rua=is the address that receives daily summary reports from mailbox providers.
Once reports show that all your legitimate email passes, you can move to p=quarantine (send failures to spam) and eventually p=reject (refuse failures). This protects your domain from being used in phishing.
DMARC also checks alignment: the domain in the visible "From" address must match the domain that passed SPF or DKIM. A message can pass SPF for a service's own domain but still fail DMARC if it isn't aligned with yours. This is one reason DKIM signing with your own domain is important.
How to check your domain
- Enter your domain in the DomainBulleter. Look at the MX records (where you receive email) and the TXT records. You should see exactly one record starting with
v=spf1. - Look up
_dmarc.yourdomain.comfor your DMARC record. - Look up your DKIM selectors at
selector._domainkey.yourdomain.com.
The DNS checker also gives an email health summary based on the records it finds, which is a quick way to spot something missing.
A practical setup order
- List every service that sends email as your domain. Email provider, newsletter, website forms, CRM, invoicing, help desk.
- Build one SPF record that includes all of them and ends with
~all. - Enable DKIM in each service and publish the records they give you.
- Add DMARC with
p=noneand a reporting address. - Read the reports for a few weeks. Fix any legitimate sources that fail.
- Tighten DMARC to
quarantine, thenreject, when you're confident.
Other things that affect delivery
Authentication is necessary but not the whole story. Delivery also depends on your sending reputation, list quality, content and whether recipients actually want your email. If your server's IP is on a blocklist, that can also cause problems. And make sure the domain itself is in good standing; a WHOIS lookup shows when it expires, since an expired domain stops email entirely.
Email DNS can look intimidating, but it follows a clear logic once you know what each record is for. If you get stuck, contact us. For help setting up email systems and automations, you can also visit justinzwick.com.
Key takeaways
- SPF lists the servers allowed to send for your domain
- DKIM signs messages so receivers can verify them
- DMARC tells receivers what to do when checks fail
- Keep SPF under 10 DNS lookups and publish only one SPF record
- Start DMARC at p=none, monitor, then tighten
Frequently asked questions
Do I need all three records?
For reliable delivery, yes. Google requires bulk senders to have SPF, DKIM and DMARC, and they help smaller senders too.
Can I have two SPF records?
No. Multiple SPF records cause a permanent error. Combine everything into one record.
What DMARC policy should I start with?
p=none lets you monitor reports without affecting delivery. Move to quarantine or reject once everything passes.
Where do I find my DKIM record?
Your email provider generates it and tells you the selector name. It's published as a TXT record at selector._domainkey.yourdomain.
How can I check my email DNS records?
Use a DNS checker to look up the TXT records for your domain, your DKIM selector and _dmarc.
