Source: https://cli.nylas.com/guides/email-spf-dkim-dmarc-explained

# SPF, DKIM, and DMARC Explained

Three DNS records decide whether your email reaches the inbox or the spam folder. SPF authorizes which servers may send for your domain, DKIM signs each message cryptographically, and DMARC tells receivers what to do when a message fails. This is the reference: record syntax, the limits that trip people up, and the 2024 Gmail and Yahoo rules.

Written by [Prem Keshari](https://cli.nylas.com/authors/prem-keshari) Senior SRE

Updated June 8, 2026

> **TL;DR:** SPF lists the servers allowed to send for your domain (one TXT record, 10-lookup limit). DKIM signs each message with a private key (public key published at `selector._domainkey`). DMARC, at `_dmarc`, sets the policy receivers enforce on failures and asks for reports. Since February 2024, Gmail and Yahoo require all three for bulk senders. The unanswered question most people miss: which one do you actually control when you send through a user's own mailbox?

Command references used in this guide: [`nylas email send`](https://cli.nylas.com/docs/commands/email-send), [`nylas doctor`](https://cli.nylas.com/docs/commands/doctor), and [`nylas email list`](https://cli.nylas.com/docs/commands/email-list).

## What are SPF, DKIM, and DMARC?

SPF, DKIM, and DMARC are three DNS TXT records that together authenticate the sender of an email. SPF declares which mail servers may send for your domain, DKIM attaches a cryptographic signature that survives forwarding, and DMARC ties the two to the visible `From` address and tells receivers how to handle failures. A message that passes all three is hard to spoof; one that fails can be quarantined or rejected.

The three are defined in separate IETF standards: SPF in [RFC 7208](https://www.rfc-editor.org/rfc/rfc7208) (2014), DKIM in [RFC 6376](https://www.rfc-editor.org/rfc/rfc6376) (2011), and DMARC in [RFC 7489](https://www.rfc-editor.org/rfc/rfc7489) (2015). Receivers check all three at delivery time, in milliseconds, before the message lands in a folder. You publish each as a DNS record; there is no software to run.

| Record | DNS location | Proves | RFC |
| --- | --- | --- | --- |
| SPF | Root TXT (`example.com`) | Server is authorized to send | 7208 |
| DKIM | `selector._domainkey` TXT | Message wasn't altered in transit | 6376 |
| DMARC | `_dmarc` TXT | What to do when SPF/DKIM fail | 7489 |

## How does SPF work?

SPF (Sender Policy Framework) publishes the list of IP addresses and hostnames allowed to send mail for your domain in a single root TXT record. When a receiving server gets a message, it reads the envelope sender domain, fetches that domain's SPF record, and checks whether the connecting IP is listed. A match passes; anything else returns `softfail` (`~all`) or `fail` (`-all`).

The trap is the 10-lookup limit. RFC 7208 caps SPF evaluation at 10 DNS lookups, and every `include:`, `a`, `mx`, and `redirect` mechanism counts. Chaining Google Workspace, a marketing platform, and a help-desk tool often blows past 10, which produces a `permerror` and silently breaks authentication. Flatten nested includes or use a subdomain to stay under the cap.

```text
; Root TXT record for example.com
; v=spf1 marks an SPF record; mechanisms are checked left to right.
"v=spf1 include:_spf.google.com include:sendgrid.net ~all"

; -all = hard fail (reject unlisted senders)
; ~all = soft fail (mark suspicious but accept)
; Each include: counts toward the 10-lookup limit.
```

## How does DKIM work?

DKIM (DomainKeys Identified Mail) signs each outgoing message with a private key held by the sending server. The matching public key is published in DNS at `selector._domainkey.example.com`. The receiver reads the `DKIM-Signature` header, fetches the public key named by its `s=` selector, and verifies the signature over selected headers and the body. A valid signature proves the message wasn't modified after sending.

Unlike SPF, DKIM survives forwarding, because the signature travels in the message rather than depending on the connecting IP. Most providers now use 2048-bit RSA keys; [RFC 8301](https://www.rfc-editor.org/rfc/rfc8301) sets 1024 bits as the floor and deprecates SHA-1. The selector (for example `google` or `s1`) lets a domain rotate keys by publishing a new one before retiring the old.

```text
; Public key published at google._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

; The DKIM-Signature header on the message names the selector:
; DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=google;
;   h=from:to:subject:date; bh=...; b=...
```

## How does DMARC work?

DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM. It requires that at least one of them passes *and* aligns with the visible `From` domain, then applies the policy you set: `p=none` (monitor only), `p=quarantine` (spam folder), or `p=reject` (bounce). The record also asks receivers to send aggregate reports to a mailbox you name with `rua=`.

Alignment is what makes DMARC strict. SPF can pass for a bulk sender's own domain while the `From` header shows yours; DMARC catches that mismatch. Start at `p=none` with reporting on, read a week of reports to find every legitimate sender, then move to `quarantine` and finally `reject`. The [DMARC.org overview](https://dmarc.org/overview/) documents the full tag set.

```text
; TXT record at _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"

; p=     policy on failure: none | quarantine | reject
; rua=   where to send aggregate reports
; adkim/aspf=s   require strict alignment (exact domain match)
; pct=   percent of failing mail the policy applies to
```

## What do Gmail and Yahoo require in 2024?

In February 2024, Gmail and Yahoo began enforcing identical bulk-sender rules: any domain sending more than 5,000 messages per day to their users must publish SPF, DKIM, and DMARC, keep its spam-complaint rate below 0.3%, and offer one-click unsubscribe ([RFC 8058](https://www.rfc-editor.org/rfc/rfc8058)). Messages from domains missing any of the three are rejected with a `5.7.26` error.

Google's [Email sender guidelines](https://support.google.com/a/answer/81126) spell out the thresholds. Even below 5,000/day, SPF or DKIM plus a valid forward-and-reverse DNS (PTR) record is now required for all senders. The spam-rate cap is the one most teams trip on: a single bad campaign can push a domain over 0.3% and get its mail quarantined for weeks.

| Requirement | All senders | Bulk (5,000+/day) |
| --- | --- | --- |
| SPF or DKIM | Required (at least one) | Both required |
| DMARC | Recommended | Required (min `p=none`) |
| Spam rate | Keep low | Below 0.3% |
| One-click unsubscribe | Good practice | Required |

## Do you need SPF, DKIM, and DMARC with Nylas?

It depends on which address you send from. When you run `nylas email send`, the message leaves through the connected user's own provider (Gmail's servers for a Gmail grant, Microsoft's for Outlook). That provider applies its own SPF and DKIM for its domain, so you don't manage DNS for those sends. The user's organization already owns the records.

You own the records only when you send from a domain you control, such as a custom domain on an Agent Account. There, you publish SPF, DKIM, and the DMARC policy yourself, exactly as the tables above describe. The CLI won't edit DNS, but `nylas doctor` verifies that a grant authenticates and can send, which confirms the provider-side path works before you debug records.

```bash
# Confirm the connected account can send (provider handles its own SPF/DKIM)
nylas doctor

# Send from the user's own mailbox — their domain's records apply
nylas email send --to recipient@example.com \
  --subject "Deliverability test" \
  --body "If this lands in the inbox, the provider path authenticates."

# Inspect the authentication results header on a received message
nylas email list --json --limit 1 | jq -r '.[0].headers["Authentication-Results"]'
```

One honest limitation: the CLI reports whether a message sent, not whether it passed DMARC at the far end. For domains you own, pair these records with a monitoring inbox on `rua=` and read the aggregate reports. See the [email deliverability guide](https://cli.nylas.com/guides/email-deliverability-cli) for inspecting authentication headers, and [custom domains for Agent Accounts](https://cli.nylas.com/guides/agent-account-custom-domain) for the records an agent's own domain needs.

## Next steps

- [Check email deliverability from the CLI](https://cli.nylas.com/guides/email-deliverability-cli) — read Authentication-Results headers and spot SPF/DKIM/DMARC failures
- [Custom domains for Agent Accounts](https://cli.nylas.com/guides/agent-account-custom-domain) — the DNS records an agent's own sending domain needs
- [Gmail SMTP settings](https://cli.nylas.com/guides/gmail-smtp-settings) — ports, TLS, and app passwords for direct SMTP sends
- [Password reset emails: choosing an API](https://cli.nylas.com/guides/password-reset-email-api) — meeting Gmail's sender rules for latency-critical mail
- [Full command reference](https://cli.nylas.com/docs/commands) — every flag and subcommand documented