SPF, DKIM, and DMARC Explained

SPF, DKIM, and DMARC in plain English

SPF, DKIM, and DMARC are the core email authentication checks mailbox providers use to decide whether mail that claims to be from your domain is believable.

They do not guarantee inbox placement. Gmail, Outlook, Yahoo, and other mailbox providers still look at complaints, engagement, spam traps, blocklists, message content, sending history, and volume. But if authentication is missing or misaligned, the rest of your deliverability work has a weak base.

SPF answers: is this server allowed to send for this domain? DKIM answers: did a domain take responsibility for this message with a valid signature, and were the signed parts preserved? DMARC answers: does SPF or DKIM line up with the visible From domain, and what policy did the domain owner publish for failures?

If you want the short version, run a free InboxRadar domain check. It reads your live SPF, DKIM, DMARC, MX, and blocklist signals, then shows what to fix first.

SPF: who is allowed to send

SPF, short for Sender Policy Framework, is a DNS TXT record that lists the mail servers and services allowed to send email for a domain.

A normal SPF record starts with v=spf1, then lists sources such as IP addresses and provider includes, then ends with a qualifier such as ~all or -all. For example, a Google Workspace domain might use an include supplied by Google, while a marketing platform will give you its own include or IP range.

~all is a soft fail. It tells receivers that unlisted senders are probably not authorized, but the receiver can still accept the message. -all is a hard fail. It says unlisted senders are not authorized. Many domains start with ~all while they are confirming every legitimate sender, then move to -all once the list is complete.

The common SPF failures are simple: no record, more than one SPF record, a missing third-party sender, a stale include, or too many DNS-querying terms. RFC 7208 sets a limit of 10 DNS-querying SPF mechanisms and modifiers during evaluation, including nested includes and redirects. The mechanisms include, a, mx, ptr, and exists, plus the redirect modifier, count toward that limit. If you exceed it, SPF returns a permanent error.

• Publish one SPF TXT record for the domain used in the envelope sender.
• Include every service that sends mail for you, including support, billing, CRM, and marketing tools.
• Keep the SPF DNS-querying term count below 10. Flattening can help, but stale flattened records create their own risk.
• Do not use +all. It authorizes everyone and defeats the point of SPF.

DKIM: sign the message

DKIM, short for DomainKeys Identified Mail, adds a cryptographic signature to the message so a receiver can verify that a domain took responsibility for it.

Your email provider signs outgoing messages with a private key. The public key lives in DNS under a selector, usually at a name like selector1._domainkey.example.com. The selector lets one domain run multiple keys at the same time for different providers or key rotations.

DKIM matters because forwarding, mailing lists, and security gateways can break SPF by changing the sending path. A valid DKIM signature can survive those hops if the signed headers and body are not changed beyond what DKIM canonicalization allows. For DMARC, the DKIM signing domain in the d= tag also needs to align with the visible From domain, either exactly or at the organizational domain level depending on your DMARC alignment mode.

• Turn on DKIM in every sending platform, not only your primary mailbox provider.
• Publish the exact DNS record each provider gives you for each selector.
• Use 2048-bit keys when the provider and DNS host support them. Google says sending to personal Gmail requires a DKIM key of 1024 bits or longer.
• Rotate keys on a planned schedule and leave old keys in place until old mail is unlikely to be verified again.

DMARC: align authentication with the From domain

DMARC ties SPF and DKIM to the address people actually see in the From header, then publishes a policy for mail that fails.

A basic DMARC record lives at _dmarc.example.com. It starts with v=DMARC1 and includes a policy: p=none, p=quarantine, or p=reject. p=none monitors without asking receivers to filter failures. p=quarantine asks receivers to treat failures as suspicious, often by placing them in spam. p=reject asks receivers to reject failing mail.

DMARC passes when SPF passes and aligns, or DKIM passes and aligns. SPF alignment compares the envelope sender domain to the visible From domain. DKIM alignment compares the DKIM d= signing domain to the visible From domain. That alignment rule is why a message can show SPF pass but DMARC fail if SPF passed for a vendor-owned return-path domain that does not align with your From domain.

Aggregate reports use the rua tag, such as rua=mailto:dmarc@example.com. These reports show which sources are sending as your domain and whether SPF, DKIM, and DMARC are passing. They are noisy XML files, but they are the safest way to move from monitoring to enforcement without breaking legitimate mail.

• Start with p=none and a working rua address so you can see real sending sources.
• Fix every legitimate sender until either SPF or DKIM passes with alignment.
• Move gradually to p=quarantine, then p=reject when reports show the domain is clean.
• Use strict alignment only when you understand every subdomain and sending path.

How Gmail and Outlook use these checks

Mailbox providers route mail to inbox or spam based on trust. Authentication is not the whole score, but it is now a baseline requirement for serious senders.

Google says all senders to Gmail must use SPF or DKIM, and bulk senders must use SPF, DKIM, and DMARC. For bulk direct email, Google also requires the From domain to align with either the SPF domain or DKIM domain. Its sender guidelines say unauthenticated mail might be marked as spam or rejected.

Microsoft has also tightened requirements for high-volume senders to its consumer mail services. Microsoft Support says those senders need SPF, DKIM, and DMARC, with at least one aligned identifier for DMARC. Microsoft 365 guidance also says final filtering can use reputation, sender history, recipient history, behavior, and other signals, so authentication is necessary but not the only factor.

That is why the right question is not only whether records exist. The right question is whether your real mail passes authentication at the providers receiving it.

Do not ignore MX, DNS drift, and blocklists

SPF, DKIM, and DMARC protect outbound identity, but deliverability also depends on the rest of your domain's mail posture.

MX records tell the internet where inbound mail for your domain should go. Broken MX records usually do not stop you from sending, but they can break replies, verification loops, and abuse desk mail. A domain used for outbound mail should have working MX records unless you have a deliberate reason not to receive mail there.

Blocklists are another signal. A listed IP or domain does not automatically mean every message goes to spam, but it can explain sudden drops, especially if the listing follows a compromised account, purchased list, or burst of complaints. Fix authentication first, then check the listed reason before asking for removal.

DNS drift is the quiet failure. Someone removes a provider include, rotates a DKIM selector without publishing the new key, changes the return-path domain, or adds a second SPF record. Everything looked fine last month, then Gmail and Outlook start filtering. A periodic check catches that before revenue mail disappears.

A practical setup order

If you are fixing a domain today, do it in the order receivers evaluate trust: identify senders, authenticate them, align them, then enforce.

• List every service that sends mail using your domain: mailbox, billing, product, support, recruiting, CRM, cold outbound, and newsletter tools.
• Check SPF for one valid record, complete sender coverage, no +all, and fewer than 10 DNS-querying terms.
• Enable DKIM signing in every sender and publish each selector record exactly as provided.
• Add DMARC with p=none and rua reporting, then review whether SPF or DKIM aligns for each source.
• Move to p=quarantine and then p=reject only after legitimate sources pass.
• Check MX records, blocklists, and provider dashboards when inbox placement still looks weak.

The official specs are worth keeping close: RFC 7208 for SPF, RFC 6376 for DKIM, and RFC 7489 for DMARC. For provider behavior, compare your setup against the Google sender guidelines and Microsoft Outlook sender guidance.

You can also skip the manual DNS hunt and start with the InboxRadar scorecard. It checks the live records and tells you whether the problem is SPF, DKIM, DMARC, MX, or a blocklist signal.