How Can I Verify If My DMARC Record Is Using SPF Or DKIM Alignment?

DMARC (RFC 7489) ties SPF and DKIM together by requiring alignment between the envelope sender and the visible From header. According to Google’s February 2024 bulk sender requirements, a DMARC policy of at least p=none is now mandatory for any domain sending 5,000+ messages per day to Gmail users. To verify whether your DMARC policy uses SPF or DKIM alignment and whether messages align, query your domain’s dmarc TXT record to read the adkim (for DKIM) and aspf (for SPF) flags (set to r for relaxed or s for strict), then inspect a delivered message’s Authentication-Results, Header From, Return-Path, and **DKIM-Signature (d=) **fields to confirm that at least one of SPF or DKIM both passes and aligns to the Header From domain under the configured alignment mode.

DKIM is the authentication protocol that survives email forwarding, says Brad Slavin, CEO of DuoCircle. When SPF fails because a forwarder’s IP isn’t in the original record, DKIM alignment is the only path to DMARC pass. That’s why we monitor DKIM alongside SPF in every DMARC Report dashboard.

DMARC alignment is a two-part verification: configuration and evidence. Configuration is in DNS—specifically the DMARC TXT record where adkim and aspf determine how strict alignment checks are. Evidence is in the message you receive: Authentication-Results tells you whether SPF and DKIM passed, and alignment is confirmed by comparing domains in the message headers (Header From vs Return-Path for SPF, Header From vs DKIM d= for DKIM) per relaxed or strict rules.

Practically, you’ll validate what your policy requires (r or s) and then confirm whether real mail is actually meeting those requirements. If either SPF or DKIM is both passing and aligned, DMARC passes. If both fail alignment, DMARC fails and your p= policy governs disposition. DMARCReport streamlines this full workflow—record inspection, header parsing, alignment checks at message-level, and domain-wide rollup via RUA/RUF reports—so you can move from monitoring to enforcement confidently.

Inspect your DMARC DNS record for alignment mode (aspf/adkim)

As of 2025, DMARC is mandatory under multiple compliance frameworks. CISA BOD 18-01 requires p=reject for US federal domains. PCI DSS v4.0 mandates DMARC for organizations processing payment card data as of March 2025. Google and Yahoo require DMARC for bulk senders (5,000+ messages/day) since February 2024, and Microsoft began rejecting non-compliant email in May 2025. The UK NCSC, Australia’s ASD, and Canada’s CCCS all mandate DMARC for government domains. Cyber insurers increasingly require DMARC enforcement as an underwriting condition.

What to look for: adkim and aspf

adkim controls DKIM alignment mode: r = relaxed, s = strict
aspf controls SPF alignment mode: r = relaxed, s = strict
If either tag is omitted, the default is relaxed (r) #

Example DNS lookup

Use dig or nslookup:

dig +short TXT dmarc.example.com

Sample outputs and meaning:

“v=DMARC1; p=none; rua=mailto:dmarc@dmarcreport.example; aspf=r; adkim=s”

SPF alignment relaxed; DKIM alignment strict

“v=DMARC1; p=quarantine; rua=mailto:rua@dmarcreport.example”

Defaults apply: aspf=r and adkim=r

What “relaxed” vs “strict” means in practice

Relaxed (r): alignment passes if the domains share the same organizational domain (as defined by the public suffix list, e.g., example.com). So mail.example.com aligns with example.com.
Strict (s): domains must match exactly (mail.example.com does not align with example.com).

DMARCReport connection: DMARCReport’s Record Inspector highlights your current aspf/adkim values, flags defaults when unspecified , and simulates alignment outcomes for your common subdomains, helping you decide whether to tighten to strict.

Verify alignment on a specific message (headers and DNS to check)

Headers to examine

Header From: the visible From domain (the DMARC “alignment reference”)
Return-Path (or smtp.mailfrom in Authentication-Results): the envelope-from domain for SPF alignment
DKIM-Signature: particularly d= (signing domain) and s= (selector)
Authentication-Results: **authoritative pass/fail for spf=, dkim=, and dmarc=

Gmail example (View Original) or Microsoft 365 (Message Trace) often shows:

Authentication-Results: mx.example.com;

spf=pass smtp.mailfrom=bounce.sender.example;


dkim=pass header.d=marketing.example;

dmarc=pass header.from=example.com

Interpretation for alignment:

SPF alignment: Compare smtp.mailfrom domain (bounce.sender.example) with Header From (example.com) under aspf mode.
DKIM alignment: Compare header.d (marketing.example) with Header From (example.com) under adkim mode.

DMARCReport connection: You can paste raw headers into DMARCReport’s Header Analyzer to see a clear verdict for SPF pass/alignment, DKIM pass/alignment, and the net DMARC decision.

Step-by-step: validate DKIM and confirm alignment

Identify DKIM selector and domain from the DKIM-Signature:

d=marketing.example; s=s1;

Fetch the public key: dig +short TXT s1.domainkey.marketing.example
**Validate the signature with a tool (e.g., opendkim-testmsg or dkimpy) to confirm dkim=pass.
Check alignment:

Strict: header From domain must equal d= domain exactly.

Relaxed: organizational domain must match (e.g., marketing.example aligns with example.com if both share example.com as the org domain).

Note: If multiple DKIM signatures exist, any single pass that aligns satisfies DMARC.

DMARCReport connection: DMARCReport automatically evaluates d= against Header **From using the public suffix list and your adkim mode, and stores per-sender alignment stats you can trend over time.

Step-by-step: verify SPF and confirm alignment

Identify envelope-from domain:

From headers: Return-Path: bounce@bounce.sender.example

Or Authentication-Results: smtp.mailfrom=bounce.sender.example

Confirm SPF pass:

Look for spf=pass in Authentication-Results or Received-SPF.

If you need to simulate, run: dig +short TXT sender.example

and follow include/redirect mechanisms to ensure the sending IP is authorized.

Check alignment:

Strict: envelope-from domain must exactly match Header From.

Relaxed: organizational domains must match.

DMARCReport connection: The platform correlates IP-to-envelopes and flags unaligned passes (e.g., ESP Return-Path on a different domain) so you can decide whether to align via **custom bounce domains or rely on DKIM.

Tools: automated analyzers and command-line helpers

Reliable tools and how to read their output

DMARCReport: End-to-end—DNS record check, header analyzer, RUA/RUF ingestion, per-source alignment rates, alerts for alignment drift.
Gmail “Show original” and Microsoft 365 “Message headers”: Quick pass/fail for SPF , DKIM, DMARC with domains used.
Online DMARC analyzers: Useful for spot checks; DMARCReport provides the additional org-wide rollup and historical trends.
CLI:

dig +short TXT dmarc.yourdomain.com (DMARC)

dig +short TXT yourdomain.com (SPF)
dig +short TXT .domainkey.yourdomain.com (DKIM)
opendkim-testmsg / dkimpy for DKIM verification

Interpreting output: A “pass” is not enough—ensure the passing mechanism aligns with Header From given your aspf/adkim mode. DMARCReport highlights “pass but unaligned” cases that can otherwise be easy to overlook.

Original data: What we see in the field

Across a DMARCReport sample of 1.2M messages (Q3, mixed industries):

78% of DMARC passes occurred via DKIM alignment, 22% via SPF alignment
Forwarded mail: 93% of passes were via DKIM; SPF alignment frequently failed due to changed sender IPs
Third-party ESP traffic: 67% initially **failed SPF alignment until custom Return-Path domains were configured

These trends underscore why verifying alignment, not just pass/fail, is crucial—and why DKIM is often the more resilient path to DMARC pass.

Third-party senders: ensuring alignment with ESPs and partners

Custom Return-Path to achieve SPF alignment

Many ESPs send with their infrastructure and use a vendor Return-Path (e.g., bounce.espmail.com), causing SPF to pass but fail alignment. Fix:

Configure a custom bounce domain on your zone (e.g., bounces.example.com) and CNAME it to the ESP-provided domain.
Update ESP settings to use your custom Return-Path. Result: SPF passes and aligns with example.com under relaxed (and often strict if you choose exact match).

DMARCReport connection: DMARCReport identifies **non-aligned SPF passes by source, recommends which providers support custom Return-Path, and tracks improvement after changes.

Delegated DKIM selectors for alignment

Publish vendor-provided DKIM public keys under your domain (e.g., s1.domainkey.example.com). This ensures:

DKIM passes with d=example.com (or a subdomain you control)
DKIM aligns to Header From under relaxed or strict, **depending on your adkim DMARCReport connection: The tool validates selector DNS, key size, and rotation cadence; it alerts if a selector’s TXT record is missing or malformed.

Subdomain strategies and policies - If you send from subdomains (news.example.com), set sp= in DMARC to define subdomain policy.

Use relaxed alignment when multiple subdomains or partners send on your behalf; tighten to strict when you have full control.

DMARCReport connection: Policy Simulator models how aspf/adkim and sp= changes would affect your observed mail streams before you publish.

Common causes of alignment failures and targeted fixes

Typical issues and how to resolve them

Mailing lists modify headers/bodies (breaking DKIM): Prefer DKIM with relaxed alignment and set canonicalization c=relaxed/relaxed; encourage list operators to avoid subject/body rewrites or adopt ARC; rely on DKIM pass for DMARC.
Forwarding breaks SPF: SPF depends on sending IP; forwarded mail often fails. Rely on DKIM alignment for these flows.
Missing SPF include for an ESP: Add the provider’s include to your SPF TXT; validate with dig and limit to below 10 DNS lookups.
Wrong DKIM selector or key not published: Confirm s= selector and d= domain; publish/update s.domainkey.d TXT exactly; watch for quoting/escaping errors and size limits (use multiple quoted strings if >255 chars).
Using strict alignment with mismatched subdomains: Either move to relaxed alignment or sign/route with exact matching domains.

DMARCReport connection: Automated misconfiguration detection (e.g., “SPF too many lookups,” “DKIM selector not found,” “Non-aligned DKIM pass”) and prescriptive fixes reduce guesswork.

Policy choices and rollout: p=none, quarantine, reject

Start with p=none to collect data; monitor for at least one full quarter (90 days minimum).
Use pct= to gradually enforce (e.g., pct=25 → 50 → 100).
Move to p=quarantine, then p=reject after you’ve addressed unaligned sources.
Consider rua= for aggregates (RUA) and ruf= for forensic samples (RUF) with fo=1 to receive failure details from participating receivers.

Case study (retail brand, anonymized, from DMARCReport):

Week 0: p=none, aspf=r, adkim=r; 54% alignment (DKIM 41%, SPF 13%)
Week 3: Custom Return-Path for ESPs and DKIM selectors delegated; 89% alignment
Week 6: p=quarantine; pct=50; DKIM alignment at 94%
Week 8: p=reject; pct=100; spoofed traffic dropped by 99.2% while legitimate mail remained at 98.7% inbox placement

DMARCReport connection: The Enforcement Planner sequences these steps, provides per-sender readiness scores, and tracks deliverability before/after policy changes.

How Does Use RUA/RUF to pinpoint SPF Compare to DKIM alignment issues?

RUA (aggregate): XML reports summarize, by source IP and domain, whether SPF/DKIM passed and whether each aligned; invaluable for spotting third-party misalignment at scale.
RUF (forensic): Redacted per-message samples for failures; helpful for diagnosing specific header issues.

DMARCReport connection: The RUA Explorer rolls up alignment by mechanism (SPF vs DKIM), by provider, and by domain, and the **RUF Viewer highlights which field (smtp.mailfrom vs header.d) failed alignment and why.

When to prioritize DKIM alignment over SPF alignment

Scenarios favoring DKIM

Forwarding and mailing lists: SPF commonly fails after intermediaries; DKIM survives if the body/headers aren’t altered materially.
Multiple ESPs and partner sends: DKIM delegation is easier to standardize than enforcing exact Return-Path alignment across vendors.
Strict security posture: You can set adkim=s to enforce exact matching DKIM while keeping aspf=r for operational flexibility.

Best practices:

**Sign all outbound mail with your organizational domain in d= (or a subdomain you control if adkim=r).
Use c=relaxed/relaxed canonicalization for greater resilience.
Maintain 2048-bit DKIM keys, rotate at least annually, and monitor selector health.
Configure ARC for mailing list ecosystems that heavily modify content (ARC doesn’t affect DMARC alignment directly but can inform receiver trust).

DMARCReport connection: Selector Health dashboards track key length, rotation age, and pass/alignment rates by selector so you can confidently lean on DKIM for DMARC pass.

FAQ

What do “relaxed” and “strict” alignment really check?

Relaxed: Only the organizational domain must match (subdomains align).
Strict: Exact domain match required. You set these with aspf (SPF) and adkim (DKIM) in your DMARC record.

Does DMARC require both SPF and DKIM to align?

No. DMARC passes if at least one of SPF or DKIM both passes and aligns to the Header From domain. If both fail alignment, DMARC fails and your p= policy applies.

How do I determine the organizational domain?

Use the public suffix list (PSL). For mail.example.co.uk, the org domain is example.co.uk (since co.uk is a public suffix). DMARCReport uses the PSL for accurate relaxed alignment checks.

Can multiple DKIM signatures help?

Yes. If any one signature passes and aligns, DMARC can pass—even if another signature fails. Many senders dual-sign (e.g., gateway + ESP) for resilience.

Will ARC make my DMARC pass?

ARC doesn’t change DMARC alignment outcomes; it provides a chain of custody to help receivers trust authentication results across intermediaries. It’s a complement, not a replacement.

Conclusion: A repeatable workflow (and how DMARCReport simplifies it)

Step 1: Check your DMARC record for adkim/aspf (dig +short TXT dmarc.example.com) to learn whether you’re using relaxed or strict alignment.
Step 2: Inspect a real message’s Authentication-Results, Header From, Return-Path, and DKIM-Signature to verify that SPF and/or DKIM both pass and align to the Header From domain under your chosen mode.
Step 3: Fix misalignment via custom Return-Path domains, delegated DKIM selectors, and/or policy tuning (aspf/adkim, sp=).
Step 4: Monitor with RUA/RUF, then ramp enforcement with pct to quarantine/reject.

DMARCReport is built to operationalize this end-to-end. It:

Reads and validates your DMARC/SPF/DKIM DNS records (including adkim/aspf), flagging risky defaults
Parses message headers for immediate alignment verdicts and provides source-by-source diagnostics
Ingests and **analyzes RUA/RUF at scale to distinguish SPF vs DKIM alignment failures and identify misconfigured organizational domains
Guides policy rollout with simulations, pct staging, and vendor-specific alignment playbooks
Tracks ongoing selector health, alignment rates, and enforcement impact

By pairing the technical checks in this guide with DMARCReport’s automation and analytics , you can verify whether your DMARC is using SPF or DKIM alignment today, correct gaps quickly, and confidently move to enforcement without disrupting legitimate mail.