SPF, DKIM & DMARC Explained: Email Authentication Guide

Every day, criminals send billions of emails that pretend to come from someone else — your bank, your boss, or your own domain. The technology that stops them is email authentication, and it rests on three DNS records: SPF, DKIM and DMARC. Get all three right and you protect your recipients from forged mail, improve your deliverability, and stop your domain being used in phishing attacks. Get them wrong — or leave them out — and your legitimate email lands in spam while spoofed messages sail through.

This guide explains each record in plain English: what it does, how it works, how to set it up, and how to check it. You can test any domain's setup in seconds with the free SPF, DKIM & DMARC Checker, and inspect the underlying records with the DNS Lookup tool.

Why email needs authentication

The email protocol (SMTP) was designed in the early 1980s, when the internet was a small, trusted network. It has a glaring weakness: the "From" address you see is just text that the sender types in. Nothing in the original protocol checks whether the server sending the message is actually allowed to send on behalf of that domain. That is why spoofing is so easy — anyone can put support@yourbank.com in the From field.

Email authentication adds the missing checks. Instead of trusting the From address blindly, receiving mail servers ask three questions:

• Is this server allowed to send mail for this domain? — answered by SPF.
• Was this message actually signed by the domain, and has it been altered in transit? — answered by DKIM.
• What should I do if the checks fail, and who should I tell? — answered by DMARC.

Together these turn the honour-system "From" field into something a receiver can verify cryptographically.

SPF: who is allowed to send

SPF (Sender Policy Framework) is a single DNS TXT record that lists the mail servers permitted to send email for your domain. When a receiving server gets a message, it looks at the envelope sender's domain, fetches that domain's SPF record, and checks whether the connecting server's IP address is in the allowed list.

What an SPF record looks like

A typical SPF record is published at the root of your domain and starts with v=spf1:

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

Reading it left to right:

• v=spf1 — the version tag; every SPF record begins with this.
• include:_spf.google.com — authorises Google Workspace's sending servers. include pulls in another domain's SPF record.
• include:sendgrid.net — authorises SendGrid, a transactional email provider.
• ~all — the catch-all at the end. It tells receivers what to do with any server not listed.

The "all" mechanism — the most important part

The qualifier on all decides how strict your policy is:

SPF limitations

SPF has two well-known weaknesses. First, it checks the envelope sender (the hidden "Return-Path"), not the visible From address, so on its own it does not stop a spoofed From. Second, SPF has a hard limit of ten DNS lookups — too many include statements and the record stops working. This is why SPF is necessary but not sufficient, and why DKIM and DMARC exist.

DKIM: a tamper-proof signature

DKIM (DomainKeys Identified Mail) adds a digital signature to every message. Your mail server signs each outgoing email with a private key; the matching public key is published in your DNS. The receiver recomputes the signature using the public key and confirms two things: the message really came from your domain, and it was not altered in transit.

Selectors and the DKIM record

DKIM public keys live at a special DNS name that includes a selector — a label your email provider chooses so you can rotate keys and run several at once. The record is published at:

<selector>._domainkey.yourdomain.com

For example, Google Workspace commonly uses the selector google, so the key lives at google._domainkey.yourdomain.com. The record itself is a TXT entry that looks like:

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

where p= is the public key. Because the selector is chosen by your provider, a DKIM check that says "not found" simply means the tool looked at the wrong selector — not necessarily that DKIM is missing. The DMARC checker probes the most common selectors automatically and lets you enter a custom one.

Why DKIM survives forwarding

Unlike SPF, DKIM is tied to the message content, not the connecting server. That means a DKIM signature usually survives when a message is forwarded, whereas SPF breaks the moment a forwarder relays your mail from its own servers. This difference is exactly why DMARC accepts a pass from either SPF or DKIM.

DMARC: the policy that ties it together

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the record that makes SPF and DKIM useful against real spoofing. It does three things:

• Alignment — it requires that the domain in the visible From address matches the domain validated by SPF or DKIM. This is what finally protects the From field.
• Policy — it tells receivers what to do when a message fails: nothing, quarantine (spam), or reject.
• Reporting — it asks receivers to send you reports about who is sending mail using your domain, so you can see spoofing attempts and misconfigured systems.

What a DMARC record looks like

DMARC is published at _dmarc.yourdomain.com as a TXT record:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100; adkim=s; aspf=s

• p=quarantine — the policy. none monitors only, quarantine sends failing mail to spam, reject blocks it outright.
• rua=mailto:... — where aggregate reports are sent. This is how you discover every service sending as your domain.
• pct=100 — the percentage of failing mail the policy applies to; useful for a gradual rollout.
• adkim / aspf — alignment strictness for DKIM and SPF (s = strict, r = relaxed).

Roll out DMARC in stages

Do not jump straight to p=reject — you risk blocking your own legitimate mail. The safe path is:

• Monitor: start with p=none and an rua address. Collect reports for a few weeks and fix any legitimate senders that fail.
• Quarantine: move to p=quarantine, optionally with a low pct that you raise over time.
• Reject: once reports are clean, switch to p=reject for full protection.

How the three work together

When an email arrives, the receiver runs all three checks:

• SPF verifies the sending server against your published list.
• DKIM verifies the cryptographic signature.
• DMARC checks that whichever one passed is aligned with the visible From domain, then applies your policy and logs a report.

A message only needs one of SPF or DKIM to pass and align for DMARC to pass. That redundancy is deliberate: SPF covers direct delivery, DKIM covers forwarded mail, and DMARC makes sure at least one of them vouches for the address your recipient actually sees.

Checking and monitoring your setup

You cannot fix what you cannot see. Start by looking at what your domain publishes today:

• Run your domain through the free SPF, DKIM & DMARC Checker for a plain-language verdict on all three records plus your MX.
• Use the DNS Lookup to read the raw TXT records at your domain and at _dmarc and <selector>._domainkey.
• Keep an rua reporting address in your DMARC record and review the aggregate reports — they reveal shadow IT, forgotten marketing tools and real spoofing attempts.

Common mistakes to avoid

• More than one SPF record. A domain must have exactly one v=spf1 record; two will break authentication. Merge them.
• Exceeding ten SPF lookups. Too many include statements cause a permanent error. Flatten or consolidate providers.
• Forgetting a sender. Marketing platforms, help desks, invoicing tools and CRMs all send "as" your domain. Enumerate them from your DMARC reports before moving to reject.
• DMARC stuck on p=none. Monitoring forever gives you reports but zero protection. Advance to quarantine or reject once reports are clean.
• Using the wrong DKIM selector when testing. "Not found" often just means you guessed the selector; check your provider's documentation.

What about BIMI?

Once DMARC is at enforcement (quarantine or reject), you can add BIMI (Brand Indicators for Message Identification), which displays your logo next to authenticated messages in supporting inboxes. BIMI is a reward for getting authentication right — it only works on domains with an enforced DMARC policy, which is one more reason to complete the journey to p=reject.

Key takeaways

• SPF lists who may send for your domain; end it with -all or ~all.
• DKIM signs each message so it can be verified and shown to be unaltered; it lives at <selector>._domainkey.
• DMARC ties them to the visible From address, sets the policy, and sends you reports; roll it out from none to quarantine to reject.
• All three are DNS TXT records you control — and you can verify them in seconds with the PAYATE email authentication checker.

Email authentication is one of the highest-impact security steps a domain owner can take: it protects your customers, defends your brand from impersonation, and measurably improves whether your real mail reaches the inbox. Set up all three, verify them, and keep an eye on the reports.