SPF, DKIM and DMARC Explained: How Email Authentication Works

Q: Can DMARC pass if SPF fails?

Yes. DMARC passes if either SPF or DKIM passes and is aligned with the From: domain. A forwarded message often fails SPF but still passes DMARC through an aligned DKIM signature, which is why DKIM is so important.

SPF, DKIM and DMARC are three DNS records that prove email really comes from your domain. SPF lists the servers allowed to send for you, DKIM adds a cryptographic signature that receivers verify with a public key, and DMARC tells receivers what to do when a message fails both and where to send reports. Together they stop spoofing and help your mail reach the inbox.

Why email needs authentication at all

SMTP, the protocol that moves email between servers, was designed in the early 1980s for a small network of trusted machines. It has no built-in way to check that the sender is who they claim to be. Anyone can connect to a mail server and write From: ceo@example.com in a message header, and the protocol itself will not object.

That gap is exactly what phishing and invoice fraud exploit. SPF, DKIM and DMARC were added on top of SMTP over the following decades to close it. None of them changes how you write or read mail; they are records you publish in DNS and checks that receiving servers run automatically.

Since February 2024, Gmail and Yahoo have required every sender to have at least SPF or DKIM, and bulk senders (roughly 5,000+ messages a day to Gmail addresses) to have SPF, DKIM and a DMARC record, with the visible From domain aligned. Microsoft announced similar requirements for Outlook.com in 2025. In practice, a business domain without all three is now at a real disadvantage.

SPF: which servers may send for your domain

SPF (Sender Policy Framework, RFC 7208) is a single TXT record on your domain that lists the IP addresses and services allowed to send mail for it. A typical record looks like this:

example.com.  TXT  "v=spf1 include:_spf.zomail.io include:_spf.billingtool.example ~all"

When a message arrives, the receiving server looks at the envelope sender (the MAIL FROM address, also visible later as Return-Path), fetches that domain's SPF record and checks whether the connecting IP is on the list. The result is pass, fail, softfail, neutral, none, or an error.

Three things trip people up with SPF:

One record only. A domain must have exactly one v=spf1 record. Two records cause a permerror, which receivers treat like having no SPF at all.
The 10-lookup limit. Mechanisms that need DNS lookups (include, a, mx, ptr, exists and the redirect modifier) may total no more than 10 during evaluation, including nested includes. Go over and the result is permerror. ip4, ip6 and all do not count.
Forwarding breaks it. When a message is forwarded, the forwarding server's IP is not in your record, so SPF fails. That is why SPF alone is never enough.

We cover syntax, qualifiers and lookup counting in depth in how to set up an SPF record.

DKIM: a signature that travels with the message

DKIM (DomainKeys Identified Mail, RFC 6376) signs each outgoing message with a private key held by your mail provider. The signature is added as a DKIM-Signature header that names the signing domain (d=) and a selector (s=). The receiver uses those two values to fetch the public key from DNS at selector._domainkey.domain, then checks that the signed headers and body have not been altered.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=zm1; c=relaxed/relaxed;
  h=from:to:subject:date:message-id; bh=...; b=...

Because the signature lives inside the message, DKIM usually survives forwarding, as long as the forwarder does not rewrite the body or signed headers (mailing lists that add footers are the classic exception). That makes DKIM the more robust of the two authentication methods.

With Zomail, DKIM is published as two CNAME records, zm1._domainkey and zm2._domainkey, pointing to keys that Zomail hosts and rotates automatically, so you never paste a long public key by hand. See how to set up DKIM for the step-by-step.

DMARC: alignment, policy and reports

SPF and DKIM each verify a domain, but not necessarily the one your recipient sees. A fraudster can send from their own server with a valid SPF pass for attacker.example, while the visible From: header says accounts@example.com. DMARC (RFC 7489) closes this gap with alignment.

A message passes DMARC when at least one of these is true:

SPF passes and the envelope-sender domain aligns with the From: domain, or
DKIM passes and the d= signing domain aligns with the From: domain.

In the default relaxed mode, aligned means "same organisational domain", so mail.example.com aligns with example.com. In strict mode (aspf=s, adkim=s) the domains must match exactly.

The DMARC record lives at _dmarc.example.com:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

The p= tag is your instruction for failing mail: none (monitor only), quarantine (treat as suspicious, usually the spam folder) or reject (refuse it). The rua= tag asks receivers to send daily aggregate reports, which show every source sending as your domain and whether it passes. The full rollout from p=none to p=reject is covered in our DMARC policy guide.

How SPF, DKIM and DMARC work together

	SPF	DKIM	DMARC
What it checks	Sending IP vs. allowed list	Cryptographic signature	Alignment with visible From
Domain it checks	Envelope sender (Return-Path)	`d=` in the signature	`From:` header
DNS location	`example.com` TXT	`selector._domainkey.example.com`	`_dmarc.example.com` TXT
Survives forwarding	Usually not	Usually yes	Yes, if DKIM survives
Tells receivers what to do	Weakly (`~all` / `-all`)	No	Yes (`p=`)
Gives you reports	No	No	Yes (`rua=`)

Think of it this way: SPF and DKIM produce evidence, DMARC judges that evidence against the address people actually read, and the reports tell you who is using your name.

A walk through one message

Anna in accounts at example.com sends an invoice to a customer on Gmail.

Her mail provider signs the message with the zm1 DKIM key for example.com and sends it from an IP covered by include:_spf.zomail.io.
Gmail checks SPF for the envelope domain example.com: the IP is listed, so SPF passes and is aligned.
Gmail fetches the public key at zm1._domainkey.example.com and verifies the signature: DKIM passes and d=example.com is aligned.
Gmail looks up _dmarc.example.com, sees DMARC passes, and records the result in tomorrow's aggregate report.

Now a fraudster sends a fake invoice with From: accounts@example.com from their own server. SPF for their envelope domain may pass, but it is not aligned; there is no valid DKIM signature for example.com. DMARC fails, and if your policy is p=reject, Gmail refuses the message before it reaches anyone.

Common mistakes to avoid

**Publishing DMARC p=reject on day one.** If your CRM, website contact form or billing tool sends as your domain and is not yet authenticated, its mail will be rejected. Start with p=none and read the reports.
Forgetting third-party senders. Newsletter tools, helpdesks and invoicing software each need their own SPF include and, ideally, DKIM signing with your domain.
Two SPF records after switching providers. Merge them into one.
**Using +all** in SPF, which authorises the entire internet.
Treating authentication as a one-off. Every new tool that sends email is a new DNS change. DMARC reports are how you notice.

Authentication is only part of deliverability. Content, sending reputation and list hygiene matter too; see why emails go to spam for the wider picture, and MX records explained for the receiving side of DNS.

Setting it up with Zomail

When you add a domain in Zomail, the domain page lists every record you need (verification TXT, MX, SPF, the two DKIM CNAMEs and DMARC) and checks each one live, with a hint when something is wrong, such as a duplicate SPF record. You can download a DNS zone file to import into Cloudflare and similar providers, or use one-click Domain Connect setup where your DNS provider supports it. A DMARC reports dashboard then shows who sends as your domain and what to fix before you tighten your policy. The getting started guide walks through it, and plans are listed on the pricing page.

FAQ

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

Yes, for any business domain. SPF and DKIM authenticate the sending server and the message; DMARC ties them to the address your recipients see and lets you block spoofing. Gmail and Yahoo require all three for bulk senders, and missing any one of them hurts deliverability for everyone else too.

What is the difference between SPF and DKIM?

SPF checks whether the sending server's IP address is authorised for the envelope-sender domain. DKIM checks a cryptographic signature inside the message against a public key in DNS. SPF breaks when mail is forwarded; DKIM usually survives because the signature travels with the message.

Can DMARC pass if SPF fails?

Yes. DMARC passes if either SPF or DKIM passes and is aligned with the From: domain. A forwarded message often fails SPF but still passes DMARC through an aligned DKIM signature, which is why DKIM is so important.

How long do SPF, DKIM and DMARC take to work?

The records work as soon as receivers can see them in DNS, which usually takes minutes to a few hours depending on your record's TTL and your DNS provider. DMARC aggregate reports arrive about once a day from each large mailbox provider.

Does DMARC stop all phishing?

No. DMARC stops exact-domain spoofing of your own domain. It does not stop lookalike domains (such as examp1e.com) or display-name tricks, which need inbox-level protection such as impersonation and lookalike-domain detection. See the anti-phishing settings guide.