Why email needs these at all

Here is the uncomfortable truth about email: it was designed in the early 1980s for a small network of people who trusted each other. Out of the box, anyone can send an email that says it is from [email protected]. There is nothing in the basic protocol that stops them.

SPF, DKIM and DMARC were added later to fix that. Together they let the receiving side, such as Gmail, Outlook or Yahoo, answer one question: is this email really from the domain it claims to be from? When the answer is no, the email goes to spam or gets rejected. When your own domain does not have them set up, your real emails can get treated like fakes.

A quick comparison helps:

SPF is the guest list: which servers are allowed to send email for your domain.
DKIM is the wax seal: a signature that proves the email was not changed on the way.
DMARC is the instructions for the bouncer: what to do when an email fails the checks, and who to tell about it.

SPF: the guest list

SPF (Sender Policy Framework) is a single line of text you publish in your domain's DNS. It lists the servers and services that are allowed to send email on your behalf. When Gmail receives an email from your domain, it looks up that list and checks whether the server that sent it is on it.

A typical SPF record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Reading it left to right:

v=spf1: "this is an SPF record".
include:_spf.google.com: Google Workspace is allowed to send for me.
include:sendgrid.net: so is SendGrid (say, for my app's emails).
~all: everything else is probably not me, so treat it with suspicion. (-all means "definitely not me, reject it".)

The two most common SPF mistakes: having two SPF records on the same domain (you must merge them into one line), and forgetting a service. If your newsletter tool or your helpdesk sends email as your domain, it needs to be in the list too.

There is also a limit of 10 DNS lookups inside one SPF record. Each include: counts, and so do the includes inside them. If you use lots of services, you can hit the limit without noticing, and SPF then fails for everyone.

DKIM: the wax seal

SPF checks where an email came from. DKIM (DomainKeys Identified Mail) checks that the email itself was not tampered with. Your email service signs every outgoing message with a private key that only it knows. You publish the matching public key in your DNS. The receiving server uses that public key to check the signature.

If someone changed the email on the way, even a single word in the body, the signature no longer matches. It is like the wax seal on an old letter: if the seal is broken, you know someone opened it.

A DKIM record is published at a special name, for example google._domainkey.yourdomain.com, and its value looks roughly like this:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1...

The good news: you never write this yourself. Your email provider generates it, and you just copy it into your DNS. The word before ._domainkey (here google) is called the selector. It simply lets you have several keys, one per service.

DMARC: the instructions for the bouncer

SPF and DKIM give the receiving server facts. DMARC (Domain-based Message Authentication, Reporting and Conformance) tells it what to do with those facts. It also adds one important rule called alignment: the domain that passes SPF or DKIM has to match the domain the reader actually sees in the "From" line. Without that rule, a scammer could pass SPF with their own domain while showing yours.

A DMARC record lives at _dmarc.yourdomain.com and looks like this:

v=DMARC1; p=none; rua=mailto:[email protected]

p=none: watch only, do not block anything yet. Perfect for starting out.
p=quarantine: send failing emails to spam.
p=reject: refuse failing emails completely. The strongest protection.
rua=mailto:...: where receivers should send you daily summary reports.

Those reports are the hidden gem. They show you every server that is sending email using your domain, including services you forgot about and anyone trying to impersonate you.

Setting them up, step by step

Let us say you own myshop.com, you use Google Workspace for your mailbox and a service like SendGrid or Mailgun for order confirmations. Here is the order I would do it in:

List everything that sends email as your domain: your mailbox provider, your website or app, newsletter tool, helpdesk, invoicing software. This list is the step people skip, and the one that causes most problems later.
Create one SPF record in your DNS (a TXT record on myshop.com) that includes all of them, ending with ~all.
Turn on DKIM in each service. Each one gives you a record to copy into DNS. Then press "verify" or "start authenticating" in that service.
Add a DMARC record with p=none and a reporting address, on _dmarc.myshop.com.
Wait one to two weeks and read the reports. Fix anything legitimate that is failing.
Tighten the policy to p=quarantine, and later to p=reject, once you are confident all your real email passes.

DNS changes can take anywhere from a few minutes to a couple of hours to show up everywhere. If a check fails right after you added a record, give it a little time before changing anything.

How to check them on any email you receive

You do not need any tools. Your email app already shows the results:

Gmail: open the email, click the three dots, then Show original. At the top you will see lines like SPF: PASS, DKIM: PASS and DMARC: PASS.
Outlook: open the message, then View and View message details (or Message source), and look for the Authentication-Results header.
Apple Mail: View, then Message, then All Headers.

A real header looks something like this:

Authentication-Results: mx.google.com; dkim=pass header.d=myshop.com; spf=pass smtp.mailfrom=myshop.com; dmarc=pass (p=QUARANTINE) header.from=myshop.com

Three passes and matching domains: that email is the real thing. If you see fail, or the domains do not match the sender you see, be careful. That is one of the warning signs I cover in how to spot a phishing email.

If you are setting up your own domain, a quick way to test is to send an email to a temporary inbox and to a Gmail address, then check the headers on the Gmail copy. It takes two minutes and shows you exactly what the outside world sees.

Common problems and quick fixes

"SPF: softfail" or "neutral": the server that sent the email is not in your SPF record. Add the service with the include: it gives you.
"SPF permerror": usually two SPF records, or more than 10 lookups. Merge into one record and remove services you no longer use.
"DKIM: fail" after editing a template: something rewrote the email after it was signed (some forwarding services and email footers do this). Send directly and test again.
DMARC fails even though SPF passes: alignment. SPF passed for your sending service's domain, not for yours. Turn on DKIM with your own domain in that service, or set a custom return-path domain.
Emails still go to spam with everything passing: authentication proves who you are, not that people want your email. Content, sending reputation and complaint rates matter too. I have written more about that in why app emails land in spam.

Do you really need all three?

Yes. Since 2024, Gmail and Yahoo require SPF, DKIM and a DMARC record for anyone sending email in larger volumes, and even small senders get much better delivery with all three in place. More importantly, DMARC with p=reject is what stops scammers from sending fake emails in your name to your own customers.

The setup takes an afternoon. After that it quietly protects your domain every single day. If you have a domain and have been putting this off, this is your sign. Start with p=none today. You can tighten it later.

Blog

SPF, DKIM and DMARC Explained in Plain English (With Examples)