SPF, DKIM and DMARC explained (with examples)

Three short DNS records decide whether Gmail, Yahoo and Outlook believe your email really comes from your business. Here is what each one does, in plain English, and how to set them up without blocking your own mail.

By David Ray · Updated November 5, 2026 · 11 min read · How we research

Why these records exist

Email was designed in an era when everyone on the network trusted each other. Anyone can type any address into the From line, just as anyone can write any return address on an envelope. Scammers use that to send invoices, password resets and "urgent" requests that look like they come from your business.

SPF, DKIM and DMARC let the receiving mail server check the claim. You publish them in your domain's DNS, the public settings for your domain that live at your registrar, Cloudflare or your web host. You don't install anything, and the people you email don't need to do anything.

SPF: the guest list

Analogy: SPF (Sender Policy Framework) is the guest list at the door. The receiving server looks at which server is delivering the message and checks whether it is on your list.

Your SPF record names every service allowed to send mail for your domain: your mailbox provider (such as Google Workspace or Microsoft 365), your newsletter tool, your invoicing app, your website's contact form. A server that isn't on the list fails.

One catch: SPF checks the hidden "envelope" sender (shown as Return-Path in headers), not the From address people see. Many newsletter tools use their own domain there. That is why SPF alone can't stop someone faking your From line, and why DMARC exists.

Example only. Don't copy this; your own services will be different.

Type:  TXT
Host:  @   (your domain itself)
Value: v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all

• v=spf1 marks this as an SPF record. It must come first.
• include:_spf.google.com allows Google Workspace's servers.
• ip4:203.0.113.10 allows one specific server (this address is a documentation example).
• ~all means "anything else is suspicious" (soft fail). -all means "anything else is not allowed" (hard fail).

Build your own with the SPF record generator.

DKIM: the wax seal

Analogy: DKIM (DomainKeys Identified Mail) is a wax seal on a letter. Your mail server presses a seal (a digital signature) onto every message using a private key that only it holds. The receiver checks the seal against your public key in DNS. If the seal matches, the message really was signed by your domain and wasn't changed on the way.

You don't write DKIM records by hand. Your email provider generates the key pair and gives you the record to publish; then you switch signing on in the provider's settings. Each service gets its own selector, a short name such as google or selector1, so several DKIM records can sit side by side.

Example only. A real key is much longer and comes from your provider.

Type:  TXT
Host:  google._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

• google is the selector. It appears as s=google in each signed message.
• k=rsa is the key type.
• p= is the public key. Gmail requires keys of at least 1024 bits; 2048 bits is the usual choice today.

Some providers, including Microsoft 365, ask you to add CNAME records that point to keys they host, instead of a TXT record. For testing or a self-hosted server, the DKIM key generator makes a key pair in your browser. If DKIM is failing, see DKIM fail: why it happens and how to fix it.

DMARC: the house rules

Analogy: DMARC (Domain-based Message Authentication, Reporting and Conformance) is the instruction you leave with the doorman: "Only let in people whose name matches the one on their invitation, and here's what to do with anyone who doesn't. Also, send me a note about everyone who knocked."

DMARC does three things:

1. It checks that a passing SPF or DKIM result belongs to the same domain as the From address (this is alignment, explained next).
2. It tells receivers what to do with mail that fails: deliver it, put it in spam, or refuse it.
3. It asks receivers to send you reports showing which servers are sending mail as your domain and whether they pass.

Example only. Use your own domain and a mailbox you read.

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

• v=DMARC1 must come first.
• p=none is the policy: monitor only, change nothing.
• rua= is where daily summary reports go. They arrive as XML files, so many people send them to a free or paid DMARC report reader.

Make your own with the DMARC record generator. If a checker says you have none, see No DMARC record found.

How they work together (alignment)

Here is what happens when you email a customer at Gmail:

1. Gmail sees which server is delivering the message and checks it against the SPF record for the envelope sender's domain.
2. Gmail checks the DKIM signature against the public key named in the signature (d= domain and s= selector).
3. Gmail looks at the From address, finds that domain's DMARC record, and asks: did SPF or DKIM pass for this same domain?
4. If at least one did, DMARC passes. If neither did, Gmail applies your policy.

Alignment in plain words: a pass only counts for DMARC if it was earned by the domain in your From line. Suppose your newsletter tool sends as news@yourshop.com but signs with its own domain, d=newslettertool.com. DKIM passes, but for the tool's domain, not yours. SPF passes, but for the tool's bounce domain. Neither lines up with yourshop.com, so DMARC fails. The fix is to set up "custom domain authentication" (the name varies) in that tool so it signs as yourshop.com.

By default alignment is relaxed: subdomains count, so d=mail.yourshop.com aligns with news@yourshop.com. Strict alignment (adkim=s or aspf=s) needs an exact match, and most small businesses don't need it.

The three DMARC policies and a safe rollout

The safe way to get from nothing to full protection:

1. Publish p=none with a rua address. Nothing changes for your mail.
2. Read the reports for two to four weeks. They list every server that sent mail claiming to be you. You'll usually find services you forgot about.
3. Fix each real sender. Add it to SPF or, better, turn on DKIM for your domain in that service, until reports show it passing with alignment.
4. Move to p=quarantine. Watch the reports and your own inbox for a few more weeks.
5. Move to p=reject. Faked mail using your domain is now refused.

A domain that never sends email (a parked domain, or one used only for a website) can skip straight to v=DMARC1; p=reject together with an SPF record of v=spf1 -all, since there is no real mail to break.

Gmail, Yahoo and Outlook rules for bulk senders

The big mailbox providers now require authentication. These are the published rules as of November 2026:

If you send less than this, the rules still help: Gmail requires SPF or DKIM from everyone, and authenticated mail is simply trusted more. For the full list of what providers check, see the email deliverability checklist.

Bounces that point to authentication problems:

• 550 5.7.26: Gmail couldn't authenticate the message (DMARC, SPF or DKIM failed).
• 421 4.7.26: Gmail is temporarily limiting unauthenticated mail.
• 550 5.7.23: the sending server isn't in the domain's SPF record.
• 550 5.7.27: SPF failed for a bulk sender at Gmail.
• 550 5.7.509: Microsoft refused the message because of your own p=reject policy.

Common mistakes

• Two SPF records. A domain may have only one. If you add a second for a new service, SPF returns an error (permerror) and counts as failing. Merge them: v=spf1 include:first.example include:second.example ~all.
• Going over the 10 DNS-lookup limit. Each include:, a, mx, exists:, ptr and redirect= makes the receiver look something up, and includes inside includes count too. More than 10 and SPF fails with permerror. ip4: and ip6: entries don't count. Remove services you no longer use, or rely on DKIM for those that support it.
• Forgotten senders. Your website's contact form, booking system, invoicing software, help desk or CRM may all send as your domain. If they aren't covered by SPF or DKIM, tightening DMARC will send their mail to spam. DMARC reports show them.
• DKIM never switched on at the provider. Publishing the DNS record isn't enough in many services; Google Workspace and Microsoft 365 both need you to start signing in their admin settings. Until then, mail goes out unsigned or signed only with the provider's own domain.
• Jumping straight to p=reject. If one real sender isn't aligned, its mail is refused with no warning to you. Always start at p=none and step up.
• Record on the wrong name. DMARC goes at _dmarc, DKIM at selector._domainkey, and SPF on the domain itself. Typing the full domain into a field that adds it automatically gives you _dmarc.yourdomain.com.yourdomain.com.

How to check your own domain

1. Run a quick check. Enter your domain in the free DMARC, SPF, DKIM and MX checker. It reads your records and explains each problem in plain English.
2. Send yourself a test. Email a personal Gmail address from your domain. Open it, select the three dots, then Show original. Gmail shows a summary with SPF, DKIM and DMARC each marked PASS or FAIL.
3. Check each service. Repeat the test from your newsletter tool, invoicing app and anything else that sends for you. Each needs its own aligned pass.
4. Look up a record directly if you want to. On Windows, open Command Prompt and type nslookup -type=txt _dmarc.yourdomain.com, or use the DNS lookup tool.

How to read Authentication-Results

The receiving server writes what it found into a header called Authentication-Results. Here is a typical one from Gmail, with example values:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@yourshop.com header.s=google header.b=AbC123xy;
       spf=pass (google.com: domain of bounce@yourshop.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=bounce@yourshop.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourshop.com

To spot an alignment problem, compare the domains: header.from should be the same domain as, or share the same main domain with, the domain in header.i or header.d for DKIM, or the domain in smtp.mailfrom for SPF. Microsoft adds its own line too, such as compauth=pass, its overall verdict.

Only trust the Authentication-Results header added by your own mail provider, which is normally the top one. Anyone can put a fake one lower down. Paste the full headers into the email header analyzer to have them read for you, and see email header fields explained for the other lines.

Authentication isn't deliverability

Passing SPF, DKIM and DMARC proves who sent a message. It doesn't prove anyone wants it. Mailbox providers still decide between inbox and spam based on your sending reputation, spam complaints, how many messages bounce, and how people engage with your mail. A perfectly authenticated message can still land in spam.

Authentication isn't list verification either. It can't tell you whether the addresses you're sending to exist. Sending to dead or mistyped addresses causes bounces that hurt your reputation no matter how good your DNS is, so a clean list matters just as much: see email list hygiene best practices. For everything else that affects the inbox, start at the deliverability hub.

Once DMARC is at quarantine or reject, you can also look at BIMI, which can show your logo next to your emails in some inboxes. New to the jargon? The email glossary explains SPF, DKIM, DMARC and the rest.

The 2026 DMARC update

DMARC was first published in 2015 as RFC 7489. In May 2026 the IETF published an updated version, often called "DMARCbis", as RFC 9989, with aggregate reports in RFC 9990 and failure reports in RFC 9991. It obsoletes RFC 7489 and, unlike the original, is on the IETF standards track.

For a small business, little changes. Records still start with v=DMARC1, so your existing record keeps working, and p=none, p=quarantine and p=reject mean the same. The pct tag (apply the policy to only a percentage of mail) was removed; a new t=y "testing" tag replaces part of what it did. The standard now also includes an np tag for subdomains that don't exist, and receivers now find a domain's parent policy by walking up the DNS instead of using a fixed list of domain suffixes. SPF (RFC 7208) and DKIM (RFC 6376) are unchanged.

Questions people ask

Do I need all three: SPF, DKIM and DMARC?

Yes, if your domain sends email. Gmail and Yahoo require all three from bulk senders, and Outlook.com requires them from domains sending more than 5,000 emails a day. Smaller senders still get better delivery and protection from spoofing with all three in place.

Can my domain have two SPF records?

No. A domain must have only one SPF record. With two, SPF returns an error and is treated as failing. Merge everything into one record that starts with v=spf1.

Can my domain have more than one DKIM record?

Yes. Each sending service uses its own selector, such as google._domainkey or s1._domainkey, so several DKIM records can live side by side.

What is the difference between ~all and -all in SPF?

~all is a soft fail: mail from servers not on the list is suspicious but not refused by SPF alone. -all is a hard fail: those servers are not allowed. With DMARC in place, the DMARC policy decides what actually happens, so ~all is a common, safe choice.

Will SPF, DKIM and DMARC keep my email out of spam?

Not on their own. They prove the mail really comes from you. Inbox placement also depends on your sending reputation, spam complaints, bounces from bad addresses and whether people want your mail.

Does forwarding break SPF, DKIM or DMARC?

Forwarding usually breaks SPF, because the forwarding server is not in your SPF record. DKIM often survives if the message is not changed, so DMARC can still pass. Mailing lists that add footers or edit the subject break DKIM too.

Has the DMARC standard changed?

Yes. In May 2026 DMARC was updated as RFC 9989, with reporting moved to RFC 9990 and RFC 9991, replacing RFC 7489. Records still start with v=DMARC1, so existing records keep working. The pct tag was removed and a t (testing) tag replaces part of what it did.

How long do new SPF, DKIM or DMARC records take to work?

Usually within an hour, sometimes up to 24 to 48 hours, depending on your DNS provider and caching.