DMARC, SPF & DKIM Explained: Email Authentication and Deliverability

Hero Summary

SPF, DKIM, and DMARC are three DNS-based email authentication standards that work together to prove an email really came from the domain it claims to be from. SPF lists which servers may send for a domain, DKIM adds a cryptographic signature to each message, and DMARC ties the two to the visible "From" address and tells receiving servers what to do when a message fails. Since 2024, Google has required these for bulk senders, and Microsoft began enforcing similar rules for high-volume senders to Outlook.com in May 2025 — so email authentication is now a deliverability requirement as well as a security control.

Executive Summary

Email was designed without sender verification, which is why attackers can forge the "From" address of a trusted domain. SPF, DKIM, and DMARC close that gap. This guide explains what each standard does, how they fit together, why legitimate email sometimes lands in spam or is rejected, what Google and Microsoft now require of high-volume senders, and a safe step-by-step path to a DMARC enforcement policy. It also covers how continuous monitoring of DNS and DMARC reporting keeps the configuration from drifting after it is set up.

Why email authentication exists {#why}

The protocol that moves email between servers (SMTP) does not verify that the sender is who they claim to be. Anyone can put any address in the "From" field, which is the basis of spoofing: a message that appears to come from a bank, a supplier, or your own executive. Spoofed messages are a common first step in phishing and business email compromise. Email authentication standards give receiving servers a way to check a sender's claim against records the real domain owner publishes in DNS.

SPF: which servers may send {#spf}

SPF (Sender Policy Framework) is a DNS record that lists the servers and services authorized to send email for a domain. When a message arrives, the receiving server checks whether the sending server is on that list. Two practical limits matter:

• A limit of 10 DNS lookups. An SPF record that references too many includes — for example, many third-party sending services — can exceed this limit and fail the check entirely.
• SPF checks the envelope sender, not the visible "From" address. On its own it does not stop someone forging the address a recipient actually sees; that gap is what DMARC alignment closes.

SPF also breaks when mail is forwarded, because the forwarding server is not on the original domain's list.

DKIM: a signature on every message {#dkim}

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing message. The sending system signs with a private key; the domain publishes the matching public key in DNS; the receiving server uses it to confirm that the message was signed by that domain and was not altered in transit. Because the signature travels with the message, DKIM generally survives forwarding better than SPF. Google's sender guidelines state that DKIM keys must be at least 1024 bits.

DMARC: policy, alignment, and reporting {#dmarc}

DMARC (Domain-based Message Authentication, Reporting, and Conformance), specified in RFC 7489, builds on SPF and DKIM and adds three things:

1. Alignment. DMARC passes only if SPF or DKIM passes and the domain that authenticated matches the visible "From" domain. This is what stops an attacker from passing SPF with their own domain while displaying yours.
2. A policy. The domain owner publishes what receivers should do with messages that fail: p=none (monitor only), p=quarantine (treat as suspicious, typically spam), or p=reject (refuse the message).
3. Reporting. Receivers send aggregate reports showing which sources are sending mail that claims to be from the domain and whether it passed — visibility that is otherwise very hard to get.

How the three work together {#together}

Standard	What it checks	What it does not do alone
SPF	The sending server is authorized for the domain	Does not protect the visible "From" address; breaks on forwarding
DKIM	The message was signed by the domain and not altered	Does not say what to do when a signature is missing or fails
DMARC	Alignment between the authenticated domain and the visible "From", plus policy and reporting	Depends on SPF or DKIM being correctly set up first

Used together, a receiving server can verify a message and know what the domain owner wants done if it fails. None of them filter spam content or guarantee inbox placement by themselves — they establish identity, which is one input to a receiver's decision.

What Google and Microsoft now require {#requirements}

Email authentication is no longer optional for organizations that send at volume.

Google (Gmail). Per Google's published sender requirements, effective from February 1, 2024:

• All senders must set up SPF or DKIM, use valid forward and reverse DNS records, send over TLS, and keep the spam rate shown in Postmaster Tools below 0.3%. Google also advises keeping it below 0.10%.
• Bulk senders — more than 5,000 messages per day — must set up SPF, DKIM, and DMARC (a policy of p=none is accepted), ensure the "From" domain aligns with the SPF or DKIM domain, and support one-click unsubscribe for marketing and subscribed messages.

Microsoft (Outlook.com, Hotmail, Live). Microsoft announced requirements for domains sending more than 5,000 emails per day to its consumer mail services, effective May 5, 2025: SPF and DKIM must pass, and DMARC must be at least p=none with alignment to SPF or DKIM. Messages that do not meet the requirements can be rejected with the error 550 5.7.515, indicating the sending domain does not meet the required authentication level.

Both providers' requirements are minimums. A p=none DMARC policy meets them, but it only monitors; it does not stop spoofing of your domain. Protection against spoofing requires moving to quarantine or reject.

Why legitimate email fails or lands in spam {#deliverability}

When real messages do not arrive, the cause is usually one of a short list:

• Authentication failures. A sending service that is missing from your SPF record, a DKIM signature that is not set up for a third-party sender, or a DMARC alignment mismatch.
• An SPF record over the 10-lookup limit, which makes the entire check fail.
• Forwarding and mailing lists that alter messages or change the sending server and break SPF or DKIM alignment. ARC (Authenticated Received Chain) exists to preserve the original authentication results across forwarding.
• Poor sender reputation. High complaint rates, sending to old or purchased lists, or sudden spikes in volume can lead providers to filter or block a domain or IP. Blocklist listings can come from a shared sending IP being misused, not only from your own behavior.
• Receiver-side filtering that gives no notice. Many receiving servers silently junk or drop suspected spam without sending a bounce, so a missing message is not always a sign of a configuration error on your side.
• Missing basics such as valid reverse DNS (PTR) records for sending IPs or an absent TLS connection.

A useful first step in any delivery investigation is to read the authentication results in the headers of a message that did arrive — they show whether SPF, DKIM, and DMARC passed and which domains aligned.

A safe path to DMARC enforcement {#rollout}

Jumping straight to p=reject can block your own legitimate mail. A safer sequence:

1. Inventory every system that sends email as your domain — your mail platform, marketing tools, ticketing and billing systems, and any third-party service.
2. Publish a DMARC record at p=none with a reporting address, and collect aggregate reports for a few weeks to see all sending sources.
3. Fix authentication for every legitimate source — add them to SPF, set up DKIM signing, and confirm alignment.
4. Move to p=quarantine, ideally ramping the percentage of mail the policy applies to, while watching reports for legitimate mail being affected.
5. Move to p=reject once reports show that legitimate mail passes consistently.
6. Keep monitoring. New sending services, DNS changes, and expiring DKIM keys can break authentication later, so reporting needs to be reviewed continuously rather than once.

How Threat ResQ's DomainShield IQ fits {#domainshield-fit}

DomainShield IQ is Threat ResQ's domain security platform. Its published capabilities include a DMARC analyzer that tracks SPF and DKIM alignment, DNS record change alerts (A, MX, NS, and TXT records — the record types that carry SPF and DMARC policy), SSL/TLS certificate lifecycle monitoring, brand and typosquat monitoring across 300+ domain variations, subdomain discovery, and attack surface mapping. It is cloud-based, with no agents and no DNS changes required to begin monitoring.

Because email authentication lives in DNS, a record that changes unexpectedly or an alignment that quietly breaks is easy to miss. Continuous monitoring is how that configuration stays correct after the initial rollout.

FAQ {#faq}

What is the difference between SPF, DKIM, and DMARC? SPF lists which servers may send email for a domain. DKIM adds a cryptographic signature to each message to prove it came from that domain and was not altered. DMARC checks that the authenticated domain aligns with the visible "From" address and tells receiving servers what to do with messages that fail.

Do I need DMARC if I already have SPF and DKIM? Yes. SPF and DKIM on their own do not tell receivers what to do when a check fails and do not protect the visible "From" address. DMARC adds alignment, a policy, and reporting. Google and Microsoft also require DMARC from high-volume senders.

What DMARC policy should I use? Start with p=none to collect reports without affecting delivery, fix any legitimate senders that fail, then move to p=quarantine and finally p=reject. Only quarantine and reject actively protect your domain from spoofing.

Why are my emails going to spam even though SPF and DKIM pass? Authentication establishes identity but not reputation. Complaint rates, list quality, sudden volume changes, blocklist listings, and recipient-side filtering all affect inbox placement independently of whether authentication passes.

What are Google's and Microsoft's bulk sender requirements? For more than 5,000 messages per day, Google requires SPF, DKIM, and DMARC, aligned From domains, and one-click unsubscribe for marketing mail, with a spam rate below 0.3%. For Outlook.com consumer domains, Microsoft requires SPF and DKIM to pass and DMARC at least at p=none with alignment, effective May 5, 2025.