DMARC Alignment Explained: SPF, DKIM, and From

DMARC checks the domain people can see

A message can pass SPF and still fail DMARC. That surprises teams because SPF and DMARC answer different questions.

SPF asks whether the sending server is allowed by the envelope sender domain. DKIM asks whether the message has a valid signature from the domain in the DKIM d= tag. DMARC asks whether at least one passing check uses a domain that aligns with the visible From domain.

If your message says it is from billing@example.com, DMARC uses example.com as the author domain. A pass from mail.vendor.net may prove the vendor handled the mail, but it does not help DMARC unless that domain aligns with example.com. That is why a vendor dashboard can show "SPF passed" while Gmail or Outlook still sees weak authentication for your From domain.

What SPF alignment means

SPF alignment compares the visible From domain with the envelope sender domain used during SMTP.

The envelope sender is also called the return-path or RFC5321.MailFrom domain. Most recipients never see it. SPF checks whether the sending IP is allowed by that domain's SPF record.

DMARC uses relaxed alignment by default. In relaxed mode, the organizational domains must match, so bounces.example.com can align with example.com. In strict mode, set with aspf=s, the domains must match exactly, so bounces.example.com would fail alignment for mail from example.com.

• Aligned in relaxed mode: From is news@example.com, return-path is bounces.example.com, and SPF passes.
• Unaligned: From is news@example.com, return-path is mail.vendor.net, even when SPF passes for the vendor domain.
• Aligned in strict mode: From is news@example.com, and the return-path domain is exactly example.com.

SPF also has DNS limits. RFC 7208 limits SPF evaluation to 10 DNS-querying mechanisms and modifiers, including include, a, mx, ptr, exists, and redirect. ip4, ip6, and all do not count because they do not need DNS lookups. Too many old vendors can trigger a permanent SPF error. Publish one SPF TXT record per domain, remove senders you no longer use, and avoid +all. ~all means softfail. -all means fail for sources you did not authorize.

What DKIM alignment means

DKIM alignment compares the visible From domain with the signing domain in the DKIM signature.

A DKIM signature has a selector, shown as s=, and a signing domain, shown as d=. The selector points receivers to the public key in DNS, usually at selector._domainkey.example.com. The signing domain is what DMARC uses for DKIM alignment.

For mail from alerts@example.com, DKIM aligns if the message has a valid signature with d=example.com. In relaxed alignment, d=mail.example.com can also align with example.com. In strict mode, set with adkim=s, the signing domain must match exactly.

DKIM is often the cleanest fix for third-party senders. Your email platform can send from its own servers while signing with your domain. SPF can break when mail is forwarded because the connecting IP changes. DKIM is more likely to survive forwarding, unless a forwarder changes signed headers or the signed body.

• Turn on DKIM in Google Workspace, Microsoft 365, or your email service provider.
• Publish the DKIM selector TXT record the provider gives you.
• Send a test message and confirm the DKIM d= domain aligns with the visible From domain.
• When rotating keys, add the new selector before removing the old one so recent mail can still verify.

How DMARC decides pass or fail

DMARC passes when SPF passes and aligns, or DKIM passes and aligns. One aligned pass is enough.

Your DMARC record lives at _dmarc.example.com. A monitoring record often starts like this: v=DMARC1; p=none; rua=mailto:dmarc@example.com. The p= tag tells receivers what you ask them to do with mail that fails DMARC. p=none asks for monitoring only. p=quarantine asks receivers to treat failures as suspicious, often by putting them in spam. p=reject asks receivers to reject failing mail. Receivers can still use their own local policy.

The rua= tag asks for aggregate reports. These reports show which sources send as your domain and whether SPF, DKIM, and alignment passed. Raw reports are XML and can be noisy, but they are the safest way to find real senders before moving from monitoring to enforcement. If reports go to a different domain, DMARC requires that external report destination to allow it.

Alignment mode is controlled by aspf= for SPF and adkim= for DKIM. If you omit them, relaxed alignment is the default. Strict mode is useful for domains with tight control, but it can break normal subdomain setups.

• Start with p=none and a working report mailbox or parser.
• Confirm every real sender has aligned SPF or aligned DKIM.
• Fix vendor bounce domains, missing DKIM signing, and stale SPF includes.
• Move to p=quarantine, then p=reject, only after reports show your real mail is passing.

Common alignment failures

Most DMARC failures come from plain setup drift.

The first common failure is a vendor's default bounce domain. SPF passes for the vendor, but the return-path does not align with your From domain. Fix it by setting up a custom return-path or bounce domain under your own domain.

The second common failure is DKIM signing on the vendor's domain. A signature from d=vendor.net may prove the vendor handled the message, but it does not prove your domain signed it. Fix it by adding the DKIM DNS record for your domain and enabling domain signing in the vendor account.

The third common failure is an SPF record that has grown past the 10-lookup limit or split into multiple SPF TXT records on the same name. Either problem can cause SPF permanent errors. Remove unused providers. Prefer direct ip4 and ip6 entries only when your provider gives stable IPs.

Authentication is also only part of inbox placement. MX records matter for receiving mail. Reverse DNS can matter for sending IPs. Blocklists can hurt shared or dedicated IPs. Gmail's sender guidelines say unauthenticated mail may be marked as spam or rejected, and they require SPF or DKIM for all senders to Gmail. For direct bulk mail to Gmail, Google also requires DMARC and alignment. Microsoft says high-volume senders to Outlook.com, Hotmail.com, and Live.com must meet SPF, DKIM, and DMARC requirements.

If you want a fast outside check, run your domain through the free InboxRadar scorecard. It reads live SPF, DKIM, DMARC, MX, and blocklist signals, then shows the record that needs attention.

How to read a test message header

The fastest proof is in the Authentication-Results header of a delivered test message.

Look for spf=pass, dkim=pass, and dmarc=pass. Then check the domains next to each result. For SPF, look for the smtp.mailfrom or return-path domain. For DKIM, look for the header.d or d= domain. For DMARC, look for the header.from domain.

A clean result might show SPF passed for bounces.example.com, DKIM passed for example.com, and DMARC passed for example.com. That means at least one aligned path worked. If DMARC failed, compare the domains. The mismatch is usually visible in that header.

• If SPF passes but DMARC fails, check whether the return-path domain aligns with your From domain.
• If DKIM passes but DMARC fails, check whether the DKIM d= domain aligns with your From domain.
• If both SPF and DKIM fail, fix authentication before changing DMARC policy.
• If authentication passes but mail still goes to spam, check complaints, list quality, sending volume, content, PTR records, and blocklists.

The main references are RFC 7208 for SPF, RFC 6376 for DKIM, RFC 9989 for the current DMARC specification, and RFC 7489 for the older DMARC specification. Also check the current Google sender guidelines and Microsoft sender guidance. For a broader checklist, see the related guide index at InboxRadar guides.