E
Email Deliverability

Email Authentication Guide: SPF, DKIM, DMARC and Beyond

Everything you need to set up and maintain email authentication. Covers SPF, DKIM, DMARC, MTA-STS, TLS, and PTR records with setup guides, troubleshooting, and best practices.

If your emails are landing in spam, there's a good chance the problem isn't your content. It's that you haven't proven you're allowed to send them in the first place.

Email authentication is the set of protocols that prove your messages actually come from you and haven't been tampered with in transit. As of 2024, every major inbox provider requires authentication for bulk senders. Gmail and Yahoo both enforce it for anyone sending more than 5,000 messages per day. [1] [2] Microsoft followed with its own enforcement in May 2025. [3] Messages that fail authentication get rejected outright or routed to spam with no second chance.

This guide covers every authentication protocol in depth, from the core three (Sender Policy Framework, or SPF; DomainKeys Identified Mail, or DKIM; and Domain-based Message Authentication, Reporting, and Conformance, or DMARC) to the supporting standards that strengthen your setup. You'll find real record examples, step-by-step explanations of how each protocol works, practical troubleshooting for multi-ESP environments, and a full setup checklist at the end.

For the broader picture of how authentication fits into deliverability alongside reputation, content, and compliance, see our complete email deliverability guide.

The Core Three Protocols

SPF, DKIM, and DMARC work as layers. SPF verifies the sending server. DKIM verifies message integrity. DMARC enforces policy when either fails and ties them together through alignment. You need all three. Skipping one is like locking your front door but leaving the back door wide open.

For a side-by-side comparison of how they differ and why each one matters, see SPF vs DKIM vs DMARC.

SPF (Sender Policy Framework)

SPF lets you publish a DNS TXT record listing every server authorized to send email from your domain. When a receiving server gets a message claiming to be from your domain, it checks your SPF record to see if the sending server's IP address is on the list. If it's not, the check fails.

SPF is defined by IETF RFC 7208. [4] It's the oldest of the three protocols, dating back to 2006, and the most commonly misconfigured.

Walking Through a Real SPF Record

Here's an actual SPF record for a company that uses Google Workspace for internal email, Mailchimp for marketing, and SendGrid for transactional messages:

v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net ~all

Let's break down each part:

v=spf1 declares this is an SPF record. Every SPF record starts with this. If it's missing, receivers won't recognize the record as SPF at all.

include:_spf.google.com authorizes all of Google Workspace's sending servers. The include mechanism tells the receiving server to also look up the SPF record at _spf.google.com and treat those IPs as authorized. Google's SPF record chains to additional sub-records that cover their entire sending infrastructure.

include:servers.mcsv.net authorizes Mailchimp's sending infrastructure. Every ESP has its own include value, and you need to use exactly what they specify in their documentation.

include:sendgrid.net authorizes SendGrid's servers for transactional email.

~all is the policy for everything else. The tilde means "softfail," which tells receivers that any server not listed should be treated with suspicion but not outright rejected. The alternative, -all (hardfail), tells receivers to reject unauthorized senders completely. See SPF softfail vs hardfail for when to use each.

Each include counts toward SPF's 10-lookup limit. That limit includes nested lookups, so if Google's SPF record chains to three additional records, those all count too. In practice, the record above uses about 7 of your 10 lookups. Add two more ESPs and you'll likely hit the limit. See SPF too many lookups for strategies to handle this.

Setup and Configuration

Common Problems

Test Your SPF

Use SPF Record Check to verify your record, check your lookup count, and identify configuration issues.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to your outgoing emails. Unlike SPF, which checks where a message came from, DKIM checks whether the message itself is authentic and hasn't been altered. This is a critical difference because DKIM survives email forwarding, while SPF does not.

DKIM is defined by IETF RFC 6376. [5]

How DKIM Signing and Verification Works

The DKIM process has two sides: signing (what your sending server does) and verification (what the receiving server does). Here's how they work step by step.

Signing (outbound):

  1. You generate a public/private key pair. The private key stays on your sending server (or your ESP holds it). The public key gets published as a DNS TXT record at a specific selector location, like s1._domainkey.yourdomain.com.
  2. When your server sends an email, it hashes the message body and specific headers (From, To, Subject, Date, and others specified in the signature).
  3. It encrypts that hash using the private key, producing the signature.
  4. The signature is added to the email as a DKIM-Signature header, which includes the selector name (so the receiver knows where to find the public key), the algorithm used, and which headers were signed.

Verification (inbound):

  1. The receiving server sees the DKIM-Signature header and extracts the selector and domain.
  2. It performs a DNS lookup at selector._domainkey.domain.com to retrieve the public key.
  3. It uses the public key to decrypt the signature, producing the original hash.
  4. It independently hashes the same message body and headers.
  5. If the two hashes match, the message is authentic and hasn't been modified. If they don't match, DKIM fails.

This is why modifying a message after signing breaks DKIM. Mailing lists that add footers, for example, change the body hash. Forwarding services that rewrite the Subject line break the header hash. Both cause legitimate DKIM failures.

Setup and Best Practices

  • DKIM Key Length explains why 2048-bit keys are now the minimum recommendation and why older 1024-bit keys are being phased out
  • DKIM Key Rotation covers when and how to rotate your signing keys without breaking email delivery

Troubleshooting

  • DKIM Fail walks through common causes of DKIM failures and their fixes
  • DKIM Errors Troubleshooting covers selector mismatches, missing DNS records, and signature verification problems

Test Your DKIM

Use DKIM Test to verify your DKIM signatures are valid and your public key is accessible.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC is the protocol that ties SPF and DKIM together. On its own, SPF can pass without matching the From domain the recipient sees. DKIM can pass with a signature from a completely different domain. DMARC adds the concept of alignment, requiring that the domain authenticated by SPF or DKIM actually matches the From address in the email header. It also tells receiving servers what to do when authentication fails and sends you reports about it.

DMARC is defined by IETF RFC 7489. [6]

DMARC Alignment Explained

Alignment is the part of DMARC that confuses people most. Here's how it works with concrete examples.

SPF alignment checks whether the domain in the Return-Path (envelope sender) matches the domain in the From header. When you send through an ESP, the Return-Path often uses the ESP's domain, like bounces.mailchimp.com. That passes SPF (because Mailchimp's servers are in their SPF record), but it doesn't align with your From address of [email protected]. SPF alignment fails.

DKIM alignment checks whether the domain in the DKIM signature's d= tag matches the From header domain. If Mailchimp signs with d=yourdomain.com (which they do when you configure a custom DKIM), alignment passes. If they sign with d=mailchimp.com, alignment fails.

Relaxed vs strict alignment. DMARC has two alignment modes. Relaxed alignment (the default, specified as aspf=r and adkim=r) allows subdomain matching. So if your From address is [email protected] and your DKIM signature uses d=mail.yourdomain.com, relaxed alignment passes because they share the same organizational domain. Strict alignment (aspf=s or adkim=s) requires an exact domain match. In the subdomain example, strict alignment would fail.

Subdomain scenario. Suppose you send marketing email from [email protected] and your DKIM signs with d=yourdomain.com. Under relaxed alignment, this passes because marketing.yourdomain.com and yourdomain.com share the organizational domain. Under strict alignment, it fails because the domains aren't an exact match. Most organizations should use relaxed alignment unless they have a specific security reason to require strict.

For DMARC to pass, you need either SPF or DKIM to both pass their check and align. Not both protocols, just one. This is why proper DKIM configuration through your ESP matters so much. Even when SPF can't align (because the Return-Path uses the ESP's domain), aligned DKIM saves you.

Policy and Enforcement

Reporting

Test Your DMARC

Use DMARC Record Checker to verify your DMARC policy, alignment settings, and reporting configuration.

Using Multiple ESPs Without Breaking Authentication

Most organizations don't send all their email through a single provider. You might use Google Workspace for internal email, HubSpot for marketing, SendGrid for transactional messages, and Salesforce for CRM notifications. Each one needs to be properly authenticated, and they all need to produce DMARC-aligned results.

Here's how to handle it.

SPF: add every ESP's include. Each provider needs its own include: mechanism in your SPF record. The challenge is the 10-lookup limit. With four ESPs, you can easily consume 8 or 9 lookups from includes alone, leaving no room for growth. Consider SPF record flattening (resolving includes to IP addresses) if you're running out of space, but be aware that flattened records require maintenance when ESPs change their IPs.

DKIM: configure custom signing for each ESP. Every ESP should sign with a DKIM key under your domain, not theirs. This typically means creating a CNAME record that points a selector under your domain to the ESP's key. For example, HubSpot might ask you to create hs1._domainkey.yourdomain.com pointing to their key server. Each ESP uses a different selector, so they don't conflict. This is the single most important step for multi-ESP authentication because it's what makes DKIM alignment work.

DMARC: it just needs one to align. Since DMARC passes when either SPF or DKIM aligns, you don't need both protocols to align for every ESP. In practice, focus on getting DKIM alignment right for each provider. SPF alignment is a bonus. For some ESPs, SPF alignment is impossible because they use their own Return-Path domain. That's fine as long as DKIM alignment works.

Subdomains as a strategy. Some organizations use subdomains to isolate reputation by email type: marketing.yourdomain.com for campaigns, transactional.yourdomain.com for receipts, support.yourdomain.com for help desk. Each subdomain can have its own SPF record (sidestepping the 10-lookup limit on the parent domain) and its own DMARC policy. See subdomain email strategy for implementation details.

For more on managing deliverability across multiple senders, see managing deliverability across multiple ESPs.

Common Authentication Failure Scenarios

When authentication fails, the evidence shows up in email headers. Knowing what to look for saves hours of guessing. Here are the scenarios we see most often.

SPF Fails But DKIM Passes

What you'll see in headers:

Authentication-Results: mx.google.com;
  spf=softfail (google.com: domain of [email protected] does not designate 192.0.2.1 as permitted sender) [email protected];
  dkim=pass header.d=yourdomain.com header.s=selector1;
  dmarc=pass (p=NONE) header.from=yourdomain.com

What happened: Your ESP sent the message using their own Return-Path domain. SPF checked against the ESP's domain, not yours, and the sending IP wasn't in their record (or you haven't added their include to your SPF). But DKIM was signed with your domain's key, so DKIM passed and aligned. DMARC passed because it only needs one aligned pass.

Should you worry? Not usually. This is normal for many ESP configurations. As long as DKIM is aligned and passing, you're fine.

DKIM Fails After Forwarding

What happened: A recipient's mailbox forwards to another address. The forwarding server relays the message but doesn't re-sign with DKIM. If the forwarding server modified the message (added a footer, changed encoding), the body hash no longer matches. DKIM fails. SPF also fails because the forwarding server's IP isn't in your SPF record.

The fix: This is what Authenticated Received Chain (ARC) was designed to solve. There's nothing you can do on the sender side. The forwarding server needs to implement ARC to preserve authentication results. See why email forwarding breaks authentication.

DMARC Fails Despite SPF and DKIM Both Passing

What happened: SPF passed, but for the ESP's domain (not yours). DKIM passed, but the signature used the ESP's domain (not yours). Neither result aligns with your From domain. This is the classic "we set up SPF and DKIM but didn't configure custom authentication" scenario.

The fix: Configure custom DKIM signing through your ESP so the d= tag uses your domain. For SPF, some ESPs offer custom Return-Path domains. Both give you alignment.

Everything Fails

What you'll see in headers:

Authentication-Results: mx.google.com;
  spf=fail;
  dkim=fail (no key for signature);
  dmarc=fail (p=REJECT)

What happened: Either someone is spoofing your domain, or your DNS records are misconfigured. If you recently changed DNS providers, the records may not have propagated. If you rotated DKIM keys, the old selector may still be referenced. Check DNS propagation and email and verify your records with our free deliverability checker.

For a detailed walkthrough of reading authentication results from email headers, see email header analysis.

The DMARCbis Changes Coming

The DMARC specification is being updated. The successor, informally called DMARCbis, has been working through the IETF process and is expected to be published as a Proposed Standard, replacing the original RFC 7489. [8] Here are the two changes that matter most for practitioners.

The pct tag is being removed. Currently, DMARC lets you set pct=10 to apply your policy to only 10% of failing messages (with the rest treated as p=none). This was meant to let senders gradually roll out enforcement. In practice, it created confusion and inconsistent behavior across receivers. DMARCbis removes the tag entirely. If you're currently relying on pct for a gradual rollout, you'll need a different strategy. The recommended approach is to use p=quarantine on subdomains first, verify with DMARC reports, then move the organizational domain to full enforcement.

A new t flag replaces testing mode. Instead of pct, DMARCbis introduces a simpler binary testing flag. When t=y is set, receivers treat the policy as informational only (similar to p=none) but still send aggregate reports. When t is absent or set to n, the policy is enforced. This is cleaner than the old approach and makes it obvious when a domain is in testing versus production.

If you're building DMARC policies today, avoid relying on pct for anything other than very short-term transitions. Design your rollout to work with binary enforcement, since that's where the standard is heading.

Supporting Protocols

The core three handle most of authentication. These additional protocols address specific gaps.

MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS forces encrypted Transport Layer Security (TLS) connections between mail servers, preventing downgrade attacks where an attacker could intercept unencrypted email in transit. See MTA-STS explained.

TLS (Transport Layer Security)

TLS encrypts email in transit between servers. All major providers now expect TLS connections, and Google, Yahoo, and Microsoft include TLS as part of their bulk sender requirements. [1] [2] [3] See TLS email encryption.

PTR Records (Reverse DNS)

PTR records map your sending IP address back to a hostname. Missing or mismatched PTR records are a red flag for spam filters. If your sending IP doesn't have a PTR record that resolves back to a domain you control, some providers will reject your email. See PTR records and email.

ARC (Authenticated Received Chain)

Email forwarding breaks SPF because the forwarding server's IP isn't in your SPF record. ARC preserves authentication results through forwarding chains, allowing receivers to trust the original authentication even after the message has been relayed. See why email forwarding breaks authentication.

Platform-Specific Setup

Each email platform has its own process for configuring SPF, DKIM, and DMARC. See the relevant guide for your platform:

Authentication Setup Checklist

Use this as a practical walkthrough when setting up authentication from scratch or auditing an existing configuration.

SPF

  • [ ] Identify every service that sends email from your domain (internal servers, ESPs, CRM, help desk, transactional platforms)
  • [ ] Create a single SPF record with an include: for each service
  • [ ] Verify the total DNS lookup count is 10 or fewer (use SPF Record Check to count)
  • [ ] Confirm you have exactly one SPF record per domain (multiple records cause all of them to fail)
  • [ ] Set the all mechanism to ~all (softfail) during setup, then move to -all (hardfail) once you're confident

DKIM

  • [ ] Enable DKIM signing for every ESP and sending service
  • [ ] Configure custom DKIM (signing with your domain, not the ESP's) for each service
  • [ ] Use 2048-bit keys minimum (1024-bit keys are increasingly rejected) [7]
  • [ ] Verify public keys are published and accessible at each selector's DNS location
  • [ ] Test signatures by sending an email and checking headers for dkim=pass (use DKIM Test)
  • [ ] Document your selectors so you can rotate keys without confusion

DMARC

  • [ ] Publish a DMARC record starting with p=none and a rua= tag pointing to an address where you'll read reports
  • [ ] Wait 2 to 4 weeks and review aggregate reports for unauthorized senders or alignment failures
  • [ ] Fix any alignment issues (usually DKIM configuration in ESPs)
  • [ ] Move to p=quarantine and monitor for false positives
  • [ ] Move to p=reject once you're confident all legitimate email passes
  • [ ] Verify your record with DMARC Record Checker

Supporting Protocols

  • [ ] Verify PTR records exist for your sending IPs and resolve to a domain you control
  • [ ] Enable TLS for all sending servers (most ESPs handle this automatically)
  • [ ] Consider MTA-STS if you need to enforce encrypted inbound delivery to your domain
  • [ ] Check your complete authentication setup with our free deliverability checker

Ongoing Maintenance

  • [ ] Set up monitoring to alert you when DNS records change unexpectedly
  • [ ] Review DMARC reports monthly for new unauthorized senders
  • [ ] Rotate DKIM keys annually or after any security incident
  • [ ] Re-verify after adding any new ESP or sending service
  • [ ] Check for 10 common authentication mistakes periodically

Check Your Authentication Now

Use our free deliverability checker to test all your authentication protocols in one lookup: SPF, DKIM, DMARC, BIMI, MX records, and blacklist status.

Monitor your authentication automatically

Get alerts when your SPF, DKIM, or DMARC records break. Unlimited domains, $39/month.

References

  1. Google, "Email sender guidelines," Google Workspace Admin Help, February 2024. https://support.google.com/a/answer/81126
  2. Yahoo, "Sender requirements & recommendations," Yahoo Sender Hub, February 2024. https://senders.yahooinc.com/best-practices/
  3. Microsoft, "Strengthening email ecosystem — Outlook's new requirements for high‑volume senders," Microsoft Community Hub, April 2025. https://techcommunity.microsoft.com/blog/outlookblog/strengthening-email-ecosystem--outlook%e2%80%99s-new-requirements-for-high-volume-luftpost/4399730
  4. IETF, "RFC 7208 — Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1," April 2014. https://datatracker.ietf.org/doc/html/rfc7208
  5. IETF, "RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures," September 2011. https://datatracker.ietf.org/doc/html/rfc6376
  6. IETF, "RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)," March 2015. https://datatracker.ietf.org/doc/html/rfc7489
  7. NIST, "SP 800-177 Rev. 1 — Trustworthy Email," February 2019. https://csrc.nist.gov/publications/detail/sp/800-177/rev-1/final
  8. IETF DMARC Working Group, "DMARCbis — Domain-based Message Authentication, Reporting, and Conformance," Internet-Draft. https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/

Related Articles