# Email authentication: SPF, DKIM, and DMARC explained URL: https://samva.dev/guides/email-authentication > Understand how SPF, DKIM, and DMARC work together, set them up in the right order, and pass the Gmail and Yahoo bulk-sender rules. - Published: 2026-07-07 Email authentication is how a mailbox provider decides whether a message comes from the domain it claims to. Three DNS records answer that question: SPF, DKIM, and DMARC. Publish them correctly and your mail carries a verifiable identity that providers can trust. Skip them and your messages arrive with no proof of origin, which increasingly means the spam folder or an outright rejection. This guide explains what each record does, how they reinforce each other, the order to set them up, and the mistakes that leave authentication half-working. If you want to check the current state of a domain, run it through the [email authentication checker](/tools/email-auth-checker) before you start changing records. ## The three records, and what each one proves [#the-three-records-and-what-each-one-proves] Authentication works because the receiver checks records you publish in DNS against the message that arrives. Each record answers a different question. ### SPF: which servers may send for you [#spf-which-servers-may-send-for-you] SPF, the Sender Policy Framework, is a DNS TXT record that lists the servers authorized to send mail on behalf of your domain. A record looks like this: ``` v=spf1 include:_spf.your-provider.com -all ``` When a message arrives, the receiver reads the return-path domain (the envelope sender, not the visible From address), looks up its SPF record, and checks whether the connecting server is on the list. The `-all` at the end tells receivers to treat mail from any other server as unauthorized. SPF has one structural weakness: it authenticates the return-path, which is not the address your recipient sees, and it breaks when mail is forwarded, because the forwarding server is not on your list. SPF is necessary but not sufficient on its own. Use the [SPF checker](/tools/spf-checker) to inspect the published record, including duplicate-record and lookup-budget findings. It diagnoses DNS evidence; it cannot prove that a specific message passed SPF. ### DKIM: a signature that survives the trip [#dkim-a-signature-that-survives-the-trip] DKIM, DomainKeys Identified Mail, attaches a cryptographic signature to every message. The sending server signs selected headers and the body with a private key, and adds a `DKIM-Signature` header. You publish the matching public key in DNS as a TXT record under a selector: ``` selector._domainkey.your-domain.com ``` The receiver reads the selector from the signature, fetches your public key, and verifies the signature. A valid signature proves two things: the message was authorized by your domain, and its signed content was not altered in transit. Because the signature travels with the message, DKIM keeps passing even when mail is forwarded. That durability is why DKIM is the stronger of the two authentication signals. DKIM selectors are message-specific. If you know a selector, use the [DKIM checker](/tools/dkim-checker) to inspect its public key and record shape; then inspect a fresh message to confirm that your sender is signing with it. ### DMARC: policy and reporting on top [#dmarc-policy-and-reporting-on-top] DMARC, Domain-based Message Authentication, Reporting and Conformance, sits above SPF and DKIM. It is a TXT record published at a fixed location: ``` _dmarc.your-domain.com ``` A starting record looks like this: ``` v=DMARC1; p=none; rua=mailto:dmarc-reports@your-domain.com ``` DMARC does two jobs. It tells receivers what to do with mail that fails authentication, set by the policy tag `p` (`none`, `quarantine`, or `reject`). And it asks receivers to send you aggregate reports, set by `rua`, so you can see who is sending as your domain and whether that mail authenticates. Without DMARC, you have authentication with no policy and no visibility. The [DMARC checker](/tools/dmarc-checker) shows the effective public policy and inheritance evidence. It cannot prove alignment for a real message, so use message headers as the final check. ## How the three fit together: alignment [#how-the-three-fit-together-alignment] The piece that makes DMARC meaningful is alignment. SPF and DKIM each authenticate a domain, but that domain is not always the one your recipient sees in the From field. A phisher can pass a plain SPF check on a return-path they control while the visible From address impersonates your brand. DMARC closes that gap. It passes only when at least one of SPF or DKIM both authenticates and aligns with the domain in the From header. Alignment means the authenticated domain matches the From domain. So a message satisfies DMARC when: - DKIM verifies against a domain that aligns with the From domain, or - SPF passes for a return-path domain that aligns with the From domain. Either path is enough. This is why a custom MAIL FROM subdomain on your own domain matters: it makes SPF align, and it stops your mail from appearing as sent through a shared provider domain. Between the two, DKIM alignment is the more reliable path, since it holds through forwarding. ## Set them up in the right order [#set-them-up-in-the-right-order] Authentication rewards a deliberate sequence. Rushing to a strict DMARC policy before the earlier records are clean will block your own mail. 1. **Publish SPF.** Add the TXT record listing your sending sources, ending in `-all`. Keep it to a single SPF record; multiple SPF records for one domain is an error. 2. **Publish DKIM.** Add the public-key records your sending platform provides, and confirm the platform is signing outgoing mail. Verify a test message shows a passing DKIM signature on your domain. 3. **Publish DMARC at p=none.** This changes nothing about how your mail is handled. It turns on reporting so you can watch. 4. **Read the aggregate reports.** For a few weeks, review the `rua` reports to find every service sending as your domain: your app, your CRM, your support tool, your invoicing platform. Confirm each one authenticates and aligns. This is where you catch the forgotten subdomain or the vendor sending unsigned mail. 5. **Move to p=quarantine.** Once legitimate mail passes cleanly, raise the policy so failing mail lands in spam rather than the inbox. Watch the reports again. 6. **Move to p=reject.** When quarantine has run without collateral damage, set the policy to reject so mail that fails authentication is refused outright. This is the posture that stops impersonation. Each step depends on the one before it. Skipping the reporting window between p=none and p=quarantine is what blocks legitimate mail later. If you send through Samva, this guide explains the protocol choices, while [verifying your sending domain](/docs/channels/email/verify-your-domain) gives the product-specific DNS workflow. For the larger operating picture, including suppression and engagement, see [Deliverability](/docs/channels/email/deliverability). ## Rotating a DKIM key [#rotating-a-dkim-key] Rotate a signing key on a schedule or after any suspicion the private key was exposed. A rotation never replaces the current key in place. Samva publishes the new public key under a new selector, so both keys stand in DNS at once: 1. Samva generates the new key pair and shows a second `_domainkey` TXT record, tagged **New key**, in the domain's DNS table. Publish it. The current key keeps signing. 2. Once the new record resolves publicly, Samva switches signing to the new selector and asks the provider to verify it. Sending is held for that verification alone. 3. The former record stays in the table tagged **Keep published**. Messages signed before the switch, including delayed, queued, and forwarded mail, still carry the old selector and only verify while that record exists. Retiring the former record is a separate decision. Keep it published for at least a week and for at least two full TTLs of the record as your DNS host actually serves it, then confirm no mail signed with the old key is still in flight. Samva shows the earliest date that could apply but never removes the record itself. ## Common failure modes [#common-failure-modes] A few mistakes account for most broken authentication. - **SPF passes but DMARC fails.** The return-path domain does not align with the From domain. Fix it with a custom MAIL FROM subdomain on your own domain, or lean on DKIM alignment instead. - **Too many SPF lookups.** SPF allows at most ten DNS lookups. Chained `include:` statements from several vendors blow past the limit and cause a permanent SPF error. Flatten or consolidate your includes. - **Two SPF records.** A domain may have only one SPF TXT record. A second one published by a different team invalidates both. Merge them. - **DKIM signing turned off.** The public key is in DNS but the platform is not signing, so verification finds nothing. Confirm signing is enabled and a real message carries the header. - **DMARC stuck at p=none forever.** Reporting without enforcement leaves the door open to impersonation. Treat p=none as the first step toward enforcement. - **Forwarded mail failing SPF.** Expected, and the reason DKIM matters. A DMARC pass via DKIM covers the forwarded case that SPF cannot. ## The Gmail and Yahoo bulk-sender rules [#the-gmail-and-yahoo-bulk-sender-rules] Google's current sender guidelines treat a sender of close to 5,000 messages or more a day to personal Gmail accounts as a bulk sender, which must: - Authenticate with both SPF and DKIM. - Publish a DMARC policy. `p=none` meets the requirement, though a stricter policy is the safer posture. - Send from a domain that aligns with SPF or DKIM. - Offer one-click unsubscribe following RFC 8058, using `List-Unsubscribe` and `List-Unsubscribe-Post` headers. - Keep the spam rate reported in Google Postmaster Tools below 0.10 percent, and never reach 0.30 percent. Google's [sender guidelines](https://support.google.com/mail/answer/81126?hl=en) and [sender FAQ](https://support.google.com/mail/answer/14229414?hl=en) are the primary source for its current thresholds and enforcement. [Yahoo's sender requirements](https://senders.yahooinc.com/best-practices/) are a separate primary source with comparable bulk-sender expectations. Our [bulk sender rules explainer](/blog/one-click-unsubscribe-rfc-8058) sets the two providers side by side and covers the RFC 8058 mechanics that this authentication overview leaves out. ## Plan the first sends after verification [#plan-the-first-sends-after-verification] Use the [DKIM checker](/tools/dkim-checker) with the selector from a real test message, then confirm the receiving mailbox reports aligned authentication. Once that works, plan a gradual increase in legitimate sending volume with the [email domain warm-up guide](/blog/warm-up-a-new-sending-domain). Authentication and a sensible sending ramp address different parts of deliverability; neither guarantees inbox placement. ## When authentication is ready: BIMI [#when-authentication-is-ready-bimi] SPF, DKIM, and DMARC establish a verifiable sending identity. BIMI is an optional next step for domains that want a supporting mailbox provider to consider displaying a brand indicator. It requires effective DMARC enforcement and an aligned real message, then adds a BIMI DNS record, hosted logo, and certificate evidence. Start with the [BIMI checker](/tools/bimi-checker) to inspect the public DNS and asset evidence. For Gmail's logo and verified-checkmark requirements, including VMC versus CMC, read [Gmail BIMI requirements](/blog/gmail-bimi-brand-logo-verified-checkmark). Neither a successful DNS inspection nor a technically valid BIMI setup guarantees that a provider will display an indicator. Authentication is the entry requirement for reaching the inbox at scale, and the three records in this guide are how you meet it. Once they are in place and your DMARC reports are clean, you have the durable identity that every other part of deliverability builds on. ## FAQ ### What is the difference between SPF, DKIM, and DMARC? SPF lists the servers allowed to send mail for your domain, published as a DNS TXT record and checked against the message's return-path. DKIM adds a cryptographic signature to each message and publishes the matching public key in DNS, so a receiver can confirm the message was authorized by your domain and was not altered in transit. DMARC ties the two together: it tells receivers what to do when a message fails authentication and sends you reports on who is sending as your domain. You want all three. ### Do I need all three records, or is SPF enough? SPF alone no longer clears the bar. Gmail and Yahoo require bulk senders to publish SPF, DKIM, and a DMARC policy, and DMARC only functions when at least one of SPF or DKIM passes and aligns with your visible From domain. SPF also breaks when mail is forwarded, while DKIM survives forwarding. Publishing all three, with DKIM as the durable signal, is the setup that holds up in practice. ### What does DMARC alignment mean? Alignment is the check that the domain authenticated by SPF or DKIM matches the domain in the From header your recipient sees. A message can pass a raw SPF check on the return-path while the From address shows a different domain, which is exactly the trick phishers use. DMARC passes only when an authenticated domain lines up with the From domain, so alignment is what makes DMARC meaningful rather than cosmetic. ### Should I start DMARC at p=reject? No. Start at p=none, which asks receivers to report on your mail without changing how it is handled. Read the aggregate reports for a few weeks to find every service sending as your domain and confirm they authenticate. Once legitimate mail passes cleanly, move to p=quarantine, then to p=reject. Jumping straight to reject before your reports are clean will bounce your own mail. ### Why does my SPF pass but DMARC still fails? Almost always an alignment gap. SPF authenticates the return-path (envelope sender) domain, which a sending platform often sets to its own domain rather than yours. If that domain does not match your From domain, SPF passes on its own terms but does not align, so it cannot satisfy DMARC. The fix is either a custom MAIL FROM subdomain on your own domain so SPF aligns, or a valid DKIM signature on your domain, since DKIM alignment satisfies DMARC independently. ### What do bulk-sender rules require? Google treats a sender of close to 5,000 messages or more a day to personal Gmail accounts as a bulk sender. Bulk senders must authenticate with SPF and DKIM, publish a DMARC policy, align the visible From domain with SPF or DKIM, support one-click unsubscribe for marketing and subscribed messages, and keep the Postmaster spam rate below 0.10 percent without ever reaching 0.30 percent. Yahoo publishes comparable requirements, with a 0.3 percent spam rate ceiling and unsubscribes honored within two days. Confirm current guidance before changing a high-volume program. ## Related - [Check an SPF record](/tools/spf-checker): Inspect one domain's SPF record, lookup budget, and mechanisms before changing DNS. - [Verify your sending domain](/docs/channels/email/verify-your-domain): Publish the exact DNS records Samva generates for a sending domain. - [Gmail BIMI requirements](/blog/gmail-bimi-brand-logo-verified-checkmark): Prepare for Gmail brand-logo and verified-checkmark eligibility after DMARC enforcement.