SPF, DKIM & DMARC for email senders
A plain-English explanation of the three DNS records that prove your emails are legitimate and protect your domain from being spoofed.
- Difficulty
- Intermediate
SPF, DKIM, and DMARC are three security records that live in your domain's DNS settings. Together, they prove to receiving mail servers that emails from your domain are genuine — and instruct them on what to do if they're not.
You don't need to fully understand how they work, but you should know what they are, why they matter, and whether yours are set up correctly.
Quick summary
SPF, DKIM, and DMARC are DNS records that authenticate your email. They prevent others from sending fake emails pretending to be from your domain (spoofing), and they improve your deliverability. If Chykalophia set up your email, these should already be configured. Ask us to verify if you're unsure.
Why these records exist
Without authentication records, anyone in the world could send an email that appears to come from yourbusiness.com. They could impersonate you to defraud your clients, spread phishing attacks, or damage your reputation.
Authentication records let receiving servers verify: "Did this email actually come from someone authorized to send on behalf of yourbusiness.com?"
They are also increasingly not optional. Google's guidance for senders is that if you send email to personal Gmail accounts you must set up email authentication for your mail to be delivered as expected: every sender needs SPF or DKIM, and senders of more than 5,000 messages a day need SPF, DKIM and DMARC.
SPF — who is allowed to send?
SPF (Sender Policy Framework) is a DNS TXT record that lists all the mail servers that are authorized to send email from your domain.
What it does: When someone receives an email claiming to be from yourbusiness.com, their mail server checks your domain's SPF record to see if the sending server is on the approved list.
What it looks like in DNS:
v=spf1 include:_spf.google.com ~allThis example says: "Emails from this domain may be sent by Google's mail servers. Treat anything else with suspicion."
What you need to do: Your SPF record should list every service that sends email on your behalf — your email platform (Google Workspace or Microsoft 365), your website's form notifications, any marketing email service you use (Mailchimp, Klaviyo, etc.).
If you have multiple sending services, they all need to be included in one SPF record. Only one SPF record is allowed per domain: Microsoft's documentation warns that two records for the same domain make SPF return an error, because the receiving system can't tell which one to use.
DKIM — is this email genuine?
DKIM (DomainKeys Identified Mail) adds a digital signature to every email you send. It works like a tamper-evident seal: if the email is modified in transit, the signature breaks.
What it does: When your mail server sends an email, it adds a hidden DKIM signature. The receiving server looks up your domain's DKIM public key, which you publish in your DNS — a TXT record with Google Workspace, a pair of CNAME records with Microsoft 365 — and uses it to verify the signature. If it matches, the email is genuine.
What you need to do: Your email platform (Google Workspace, Microsoft 365) does the signing for you, but it isn't automatic. You generate the key in the platform's admin console, publish the record it gives you in your DNS, and then switch DKIM signing on. Chykalophia sets this up when we configure your email.
DMARC — what should happen if authentication fails?
DMARC (Domain-based Message Authentication, Reporting & Conformance) is a policy that tells receiving mail servers what to do with emails that fail the DMARC check.
A message passes that check if at least one of SPF or DKIM passes and the domain it passed for matches the domain in the From address. So a message doesn't have to pass both — but passing one on the wrong domain isn't enough either.
The three DMARC policies:
| Policy | What you are asking receiving servers to do |
|---|---|
none | Take no particular action. Pair it with a reports address so you can watch what's happening |
quarantine | Treat failing mail as suspicious. In practice that usually means the spam or junk folder, but each provider decides |
reject | Refuse failing mail outright, during the delivery attempt |
What it looks like in DNS:
v=DMARC1; p=quarantine; rua=mailto:reports@yourbusiness.comThis says: "Quarantine emails that fail authentication, and send reports to reports@yourbusiness.com."
Start with 'none' before tightening
If you set DMARC to reject before your SPF and DKIM are correctly configured, you risk blocking your own legitimate emails. A good setup starts with none (monitoring mode) for a few weeks, then moves to quarantine, then reject once everything is confirmed working.
How they work together
SPF and DKIM are two separate checks on the same email — one on the sending server, one on the signature. DMARC is not a third check: it is the policy that tells receiving servers what to do with emails that fail SPF or DKIM.
Read this as text
An email arrives claiming to be from your domain. The receiving mail server runs two checks on it. SPF checks the envelope: is this mail server on the approved list? DKIM checks the letter: was this email signed by the claimed domain, and is the signature still intact?
If both checks pass, the email has been authenticated and there is nothing for your DMARC policy to act on. Authentication on its own is not a promise of the inbox — spam filters also weigh things like your message content.
If either check fails, your DMARC policy tells the receiving server what to do. A policy of none delivers the email anyway and sends reports to you as the domain owner. Quarantine puts it in the spam or junk folder. Reject blocks it entirely, so it never reaches the recipient.
Think of it this way:
- SPF checks the envelope: "Is this mail server on the approved list?"
- DKIM checks the letter: "Was this email signed by the claimed domain?"
- DMARC is the policy: "What do we do if neither check passes for the domain this claims to be from?"
All three working together gives receiving servers a clear, checkable answer about whether your email is genuine. It isn't a guarantee of delivery — a receiving server can still filter a message that passes — but without authentication you're relying on luck.
Do I need to set these up myself?
No. Chykalophia handles this as part of setting up your email platform. If you're migrating email or adding a new sending service, we'll update your records.
What you should do: ask Chykalophia to confirm all three records are in place. We can also check with a public record checker such as MXToolbox.
What about sending email from my website?
Your website also sends email — form notifications, order confirmations, etc. Those emails need to be covered by your SPF record too. See Email sent from your website explained and What is SMTP?.
Common questions
How do I know if my records are set up correctly?
Free checkers such as MXToolbox and Mail-tester will look up your records and report what they find. Or just ask Chykalophia to audit your configuration.
My emails pass SPF but still land in spam. What else should I check?
Passing SPF alone isn't always enough. Check that DKIM is also working, that your DMARC policy is set, and review your message content for spam-like patterns. See How to improve email deliverability.
Do I need to update these records if I change email providers?
Yes. When you switch email platforms, your SPF record needs to be updated to include the new provider's mail servers, and a new DKIM key will need to be added. Chykalophia handles this during email migrations.
I use Mailchimp for newsletters. Does that need to be in my SPF record?
Yes — any service that sends email from your domain (Mailchimp, Klaviyo, your website's SMTP service, etc.) should be authorized in your SPF record. If you add a new email service, let us know so we can update it.
Related guides
- Why your emails land in spam (deliverability)
- How to improve email deliverability
- Email DNS records (MX, SPF, DKIM, DMARC)
- SPF records explained
- DKIM records explained
- DMARC records explained
- Setting up a new email address — the step before this one
- Email not sending or receiving? — if something is already broken
- Give us access to manage your DNS
Need a hand?
Learn more
Last updated
How to improve email deliverability
Practical steps to make sure your business emails reach the inbox instead of the spam folder.
Email sent from your website explained
How your website sends automatic emails — form submissions, order confirmations, password resets — and what needs to be set up for them to work reliably.