Email Authentication in 2026: The Complete SPF, DKIM, and DMARC Guide

In February 2024, Google and Yahoo began enforcing new sender requirements: bulk senders (5,000+ messages/day to either provider) must have valid SPF, DKIM, and DMARC records. Unauthenticated mail gets rejected, not just filtered to spam. Microsoft followed with similar requirements for Outlook.com in 2025.

This is not news to anyone who has been paying attention to email deliverability. But the enforcement escalation means that authentication is no longer a best practice — it is table stakes. If you are sending email programmatically and your authentication is misconfigured, your messages are not arriving.

SPF: who is allowed to send

Sender Policy Framework (SPF) is a DNS TXT record that declares which IP addresses and hostnames are authorised to send email on behalf of your domain. When a receiving server gets a message claiming to be from [email protected], it looks up yourdomain.com's SPF record and checks whether the sending server's IP is in the authorised list.

A typical SPF record looks like this:

v=spf1 include:relay.maielr.com ~all

The include: mechanism delegates to Senthop's SPF record, which lists our sending IPs. The ~all at the end is a softfail for all other sources — meaning mail from unlisted IPs should be treated with suspicion but not outright rejected.

Common mistakes:

• Too many DNS lookups: SPF has a 10-lookup limit. Each include:, a:, mx:, and redirect= counts as a lookup. If you use multiple email providers (transactional + marketing + corporate), you can exceed this limit. Use dig +short TXT yourdomain.com and count the chain.
• Using +all: This authorises the entire internet to send as your domain. We have seen this in production. Do not do it.
• Forgetting subdomains: SPF records do not inherit. If you send from notifications.yourdomain.com, it needs its own SPF record.

DKIM: proving the message was not tampered with

DomainKeys Identified Mail (DKIM) is a cryptographic signature added to the message headers. The sending server signs a hash of specific headers and the body using a private key; the receiving server retrieves the corresponding public key from DNS and verifies the signature.

A DKIM signature header looks like this (abbreviated):

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=default;
  h=from:to:subject:date:message-id;
  bh=abc123...;
  b=xyz789...

The d= is the signing domain, s= is the selector (used to look up the public key at default._domainkey.yourdomain.com), bh= is the body hash, and b= is the signature.

DKIM proves two things: the message genuinely originated from a system that holds the private key for your domain, and the signed headers and body have not been modified in transit.

Common mistakes:

• Shared signing domains: Some providers sign with their own domain (e.g., d=sendgrid.net) instead of yours. This means DKIM alignment fails for DMARC (see below), and you are building reputation for their domain, not yours.
• Key rotation: RSA keys should be rotated periodically (every 6-12 months). If you have been using the same DKIM key since 2019, it is time to rotate.
• Body length limits: The l= tag limits how much of the body is signed. Attackers can append content after the signed portion. Avoid using l= in production.

Senthop handles DKIM automatically: when you add a domain, we generate a 2048-bit RSA key pair, give you the DNS record to publish, and sign every outgoing message with your domain's private key. No shared signing domains.

DMARC: the policy layer

Domain-based Message Authentication, Reporting, and Conformance (DMARC) ties SPF and DKIM together with a policy declaration. It tells receiving servers what to do when authentication fails and where to send aggregate reports.

v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s

The p= tag is the policy: none (monitor only), quarantine (send to spam), or reject (block entirely). The adkim and aspf tags control alignment strictness — whether the authenticated domain must exactly match the From domain (s for strict) or can be a subdomain (r for relaxed).

DMARC alignment is the key concept. A message passes DMARC if either SPF or DKIM passes and the authenticated domain aligns with the From header domain. This is why shared DKIM signing domains are problematic: the DKIM signature might verify, but d=sendgrid.net does not align with from: [email protected].

The recommended rollout path:

1. Start with p=none and a rua= address to collect aggregate reports.
2. Monitor reports for 2-4 weeks. Identify legitimate sending sources that are failing authentication.
3. Fix all authentication issues (add SPF includes, configure DKIM for each provider).
4. Move to p=quarantine for another 2-4 weeks.
5. Once you are confident all legitimate mail passes, move to p=reject.

Senthop's dashboard includes DMARC report parsing — we ingest your aggregate reports and surface authentication failures by source IP and sending domain, so you can identify and fix issues before tightening your policy.

How the three protocols work together

Think of authentication as a three-layer defence:

1. SPF validates the sending server's IP against the domain's authorised list.
2. DKIM validates the message's cryptographic signature against the domain's public key.
3. DMARC checks that at least one of the above passes with proper domain alignment, then enforces the domain owner's policy.

All three are DNS-based, all three are checked by receiving servers in real-time, and all three are required by the major mailbox providers as of 2024-2025. Getting them right is the single most impactful thing you can do for your email deliverability.

If you are not sure about your current authentication setup, Senthop's domain verification wizard checks all three protocols when you add a domain and tells you exactly what DNS records to add or fix. Try it free — no credit card required.