MYDNSREPORT RESOURCE

Email Deliverability Guide: SPF, DKIM & DMARC Explained

Understand authentication, sender reputation and delivery checks before investigating why a message is rejected or filtered.

Sending server: SMTP connection → Receiving server: Reply or error code → Mailbox: Delivery or filtering
Read the SMTP response to locate a failure. DNS, connectivity, authentication and mailbox policies can each affect delivery.

Why Email Authentication Matters

Email was designed in the 1970s with no authentication whatsoever. Anyone can send an email claiming to be from any address. To address this, three DNS-based standards were developed over the past two decades: SPF, DKIM, and DMARC. Together they form the modern email authentication stack that major mail providers (Gmail, Outlook, Yahoo) use to decide whether to deliver, quarantine, or reject incoming messages.

Large mailbox providers publish sender requirements covering authentication and sending practices. Consult Google’s sender guidelines and your recipients’ provider guidance for current thresholds and requirements; authentication alone does not guarantee delivery.

Email Authentication Flow (SPF + DKIM + DMARC)

Your mail server sends a message and signs it with a DKIM private key.

Receiving server verifies the sender IP is listed in your domain's SPF record.

Receiving server retrieves your public key from DNS and validates the message signature.

Checks that SPF or DKIM aligns with the From domain, then applies your policy (none / quarantine / reject).

SPF — Sender Policy Framework

SPF is a TXT record in your DNS zone that lists the IP addresses and hostnames that are authorized to send email on behalf of your domain. When a receiving mail server gets an email from your domain, it looks up the SPF record and checks whether the sending IP is on the approved list.

Example SPF record (Google Workspace):

v=spf1 include:_spf.google.com ~all

The ~all at the end is a "soft fail" — messages from unlisted IPs will be marked as suspicious but not outright rejected. Using -all (hard fail) tells receiving servers to reject messages from unlisted IPs.

Common SPF mistakes:

  • Having more than one SPF TXT record (only one is allowed per domain — merge them)
  • Exceeding 10 DNS lookups (each include: counts toward the limit)
  • Forgetting to add third-party senders like Mailchimp, SendGrid, or your CRM
  • Using +all which allows anyone to send on your behalf (never do this)

DKIM — DomainKeys Identified Mail

DKIM adds a cryptographic signature to every outgoing email. The sending server signs the message with a private key, and publishes the matching public key in DNS. The receiving server looks up the public key and verifies the signature. If the signature is valid, it proves the message was sent by an authorized server and was not modified in transit.

DKIM keys are published as TXT records under a selector subdomain, like:

selector._domainkey.yourdomain.com  →  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3D..."

The selector name (e.g., google, s1) is determined by your email service provider. If you use Google Workspace, the selector is typically google. For SendGrid it might be s1 or s2.

DKIM key rotation is important for security. Most email providers handle this automatically, but if you self-host your mail server you should rotate keys at least annually.

DMARC — Domain-based Message Authentication

DMARC builds on top of SPF and DKIM. It tells receiving servers what to do when an email fails both SPF and DKIM authentication checks, and provides a reporting mechanism so you can see who is sending email using your domain.

Example DMARC record:

_dmarc.yourdomain.com  →  "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100"

The key parameters:

  • p=none — Monitor mode. No action taken, reports only. Use this to start.
  • p=quarantine — Suspicious messages go to spam folder.
  • p=reject — Failed messages are rejected outright. Maximum protection.
  • rua= — Email address to receive aggregate reports (daily digest of all sending activity).
  • pct= — Percentage of messages the policy applies to (100 = all).

DMARC alignment: For DMARC to pass, either SPF or DKIM must "align" with the From header domain. This means the domain in the From header must match the domain that was used for SPF authorization or DKIM signing. This is the most frequently misunderstood part of DMARC.

Verification Checklist

Use our DNS Lookup tool to check each of these for your domain:

  • TXT record starting with v=spf1 exists at the root domain
  • SPF record has fewer than 10 DNS lookup mechanisms
  • DKIM TXT record exists at selector._domainkey.yourdomain.com
  • DMARC TXT record exists at _dmarc.yourdomain.com
  • Your sending IP is not on any RBL blacklist — check with our Blacklist Checker

Frequently Asked Questions

What is the difference between SPF and DKIM?

SPF verifies which mail servers are allowed to send for your domain by checking the sender's IP against a DNS list. DKIM adds a cryptographic signature so the recipient can verify the message was not tampered with in transit. Both are needed for strong email authentication.

What DMARC policy should I start with?

Start with p=none to collect aggregate reports without affecting delivery. After reviewing the reports and confirming all legitimate senders pass SPF and DKIM, move to p=quarantine, then eventually p=reject.

Why are my emails still going to spam after adding SPF and DKIM?

Check that DMARC is present and that SPF and DKIM are aligned with the From header domain. Also verify your sending IP is not blacklisted using our RBL Blacklist Checker.