Debugging DMARC, SPF & DKIM Failures: The Developer Guide to Email Deliverability

With Google, Yahoo, and Microsoft enforcing strict email authentication requirements for sender domains, unauthenticated or misconfigured emails are immediately rejected with 550 5.7.26 bounce codes or routed directly to spam folders.

Achieving 100% email deliverability requires configuring and aligning the Email Authentication Trinity: SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting, and Conformance).

This guide walks through how the three protocols work together, diagnoses the most common DNS configuration errors, and provides practical troubleshooting steps to pass DMARC compliance.

---

1. The Email Authentication Trinity Explained

                     Incoming Email (MTA)
                              |
        +---------------------+---------------------+
        |                                           |
   1. Check SPF                                2. Check DKIM
Does Sender IP match domain?             Is cryptographic signature valid
(Checks Return-Path header)              via public DNS key? (DKIM-Signature)
        |                                           |
        +---------------------+---------------------+
                              |
                        3. Check DMARC
        - Does SPF or DKIM PASS?
        - Do the domains ALIGN with the From: header?
        - If FAIL -> Apply policy: p=none | p=quarantine | p=reject

1. SPF (RFC 7208)

Defines which IP addresses and mail servers are authorized to send email on behalf of your domain's Return-Path (envelope sender address).

• Example DNS TXT Record: v=spf1 include:_spf.google.com include:sendgrid.net ~all

2. DKIM (RFC 6376)

Attaches a cryptographic signature to the email header using an asymmetric key pair. The sending server signs the message with its private key; the receiving server verifies the signature against the public key published in your DNS TXT or CNAME record.

• Example DNS Selector: s1._domainkey.example.com

3. DMARC (RFC 7489)

Instructs receiving mail servers what to do if SPF or DKIM checks fail and alignment is broken. It also sends aggregate XML telemetry reports (rua) back to the domain owner.

• Example DNS TXT Record: _dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"

---

2. Top 5 DMARC & Deliverability Failures and Fixes

1. The SPF 10-Lookup Limit (PermError)

• The Issue: RFC 7208 specifies a hard limit of 10 DNS lookups when evaluating an SPF record. Mechanisms like include:, a, mx, ptr, and exists trigger DNS lookups.
• Symptom: Receiving servers return SPF PermError: too many DNS lookups, causing SPF to fail completely.
• Common Cause: Nesting multiple third-party transactional email providers (e.g. Google Workspace, SendGrid, Zendesk, HubSpot, AWS SES) in a single record.
• The Fix:
  1. Remove legacy or unused email providers.
  2. Flatten SPF records using dedicated CIDR IP blocks (ip4:198.51.100.0/24) where appropriate.
  3. Validate your SPF lookup count with a DNS lookup tool.

2. Domain Alignment Failure (SPF vs. From Header)

• The Issue: SPF passes for mail.sendgrid.net (the envelope Return-Path), but fails DMARC evaluation because the visible header says From: [email protected].
• Why DMARC Requires Alignment: DMARC requires that the domain in the visible From: header matches the domain authenticated by SPF or DKIM.
• The Fix: Set up custom reverse-path / Return-Path branding (CNAME delegation like em.yourbrand.com) in your email service provider so the Return-Path shares your root domain.

3. DKIM Signature Breakage on Email Forwarding

• The Issue: When a user forwards an email (e.g., from an alias or mailing list), the forwarding server changes the sender IP. Consequently, SPF almost always fails on forwarded emails.
• The Fix: Ensure DKIM is properly enabled and aligned. Unlike SPF, DKIM signatures survive forwarding as long as the message headers and body content are not modified in transit. DMARC only requires either SPF or DKIM to pass with alignment.

4. Syntax Errors in the _dmarc DNS Record

• The Issue: Placing DMARC records on the root domain instead of the _dmarc subdomain, or using invalid tags.
• Common Mistakes:
  • ❌ Creating TXT record on example.com instead of _dmarc.example.com.
  • ❌ Missing the mandatory p= policy tag: v=DMARC1; rua=mailto:... (invalid).
  • ❌ Capitalizing tags: V=DMARC1; P=REJECT (some parsers fail on uppercase tags).
• The Fix: Publish standard lowercase format on _dmarc.yourdomain.com:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=reject; sp=reject; adkim=r; aspf=r; rua=mailto:[email protected]; pct=100"

5. Relaxed vs. Strict Alignment Mismatches (adkim / aspf)

• Relaxed Alignment (adkim=r / aspf=r - Default): Allows subdomains (e.g., DKIM signed by mail.example.com aligns with From: example.com).
• Strict Alignment (adkim=s / aspf=s): Requires exact domain equality. If set to strict, mail.example.com will NOT align with example.com, causing unexpected DMARC rejections.

---

3. Step-by-Step DMARC Rollout Strategy

Deploying DMARC with p=reject immediately can accidentally block legitimate transactional emails. Follow this phased rollout:

Phase	DMARC Policy Tag	Purpose	Action
Phase 1: Monitor	p=none	Gather telemetry without blocking	Analyze aggregate rua reports to identify all legitimate senders.
Phase 2: Quarantine	p=quarantine; pct=25	Soft enforcement	Route suspicious emails to spam for 25% of traffic, gradually ramping to 100%.
Phase 3: Reject	p=reject; pct=100	Full protection	Completely block unauthorized spoofing and phishing attempts.

---

4. Production DNS Configuration Template

; 1. SPF Record (Root domain TXT)
@   IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

; 2. DKIM Records (Selector CNAMEs provided by your email service)
s1._domainkey.yourdomain.com. IN CNAME s1.domainkey.u12345.sendgrid.net.
s2._domainkey.yourdomain.com. IN CNAME s2.domainkey.u12345.sendgrid.net.

; 3. DMARC Record (_dmarc TXT)
_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; aspf=r; adkim=r"

---

Frequently Asked Questions

What is the difference between ~all (SoftFail) and -all (HardFail) in SPF?

• ~all (SoftFail): Suggests the receiver accept the email but mark it as suspicious if the sending IP is not listed.
• -all (HardFail): Instructs the receiver to reject the message outright if it does not match the SPF record. When DMARC is active, ~all is recommended to prevent deliverability drops during intermediate mail routing.

How can I verify my DMARC and DNS records before sending emails?

You can inspect real-time DNS TXT records and test your selector configurations with the DMARC Checker Tool and the DNS Lookup Tool.