DMARC adkim and aspf: strict vs relaxed

The two DMARC tags that trip up real senders

A vendor can pass SPF and DKIM and still fail DMARC if the domains do not line up with the visible From address.

adkim and aspf control that line-up. adkim sets DKIM alignment. aspf sets SPF alignment. Each tag can be relaxed with r or strict with s. If you leave the tags out, DMARC uses relaxed alignment for both.

For most domains, relaxed alignment is the right default. It allows normal subdomain sending, such as a DKIM signature from mail.example.com for mail with a From domain of example.com. Strict alignment is useful only when you know every sender uses the exact same domain as the visible From address.

Before changing either tag, run a fresh InboxRadar domain check and inspect real message headers. DNS alone does not tell you how every vendor signs and returns your mail.

What adkim and aspf mean

DMARC passes when SPF or DKIM passes and the passing domain aligns with the domain in the message From header.

• adkim=r means relaxed DKIM alignment. The DKIM d= domain and the From domain must share the same organizational domain.
• adkim=s means strict DKIM alignment. The DKIM d= domain must match the From domain exactly.
• aspf=r means relaxed SPF alignment. The SPF-authenticated return-path domain and the From domain must share the same organizational domain.
• aspf=s means strict SPF alignment. The SPF-authenticated return-path domain must match the From domain exactly.
• If both tags are missing, the default is adkim=r and aspf=r.

DMARC was published as RFC 7489. The current DMARC protocol is RFC 9989, with reporting split into companion RFCs. The alignment rule is the same practical rule admins use every day: relaxed means same organizational domain, strict means exact domain.

Relaxed vs strict in real records

Relaxed is forgiving with subdomains. Strict is exact.

A monitoring record often starts like this:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

That record omits adkim and aspf, so both use relaxed alignment. A stricter record might be:

v=DMARC1; p=quarantine; adkim=s; aspf=s; rua=mailto:dmarc@example.com

Strict alignment does not make p=none, p=quarantine, or p=reject stronger. It only narrows which authenticated domains can count for DMARC. That can be useful for a locked-down subdomain, but it can also break a normal vendor setup that signs as mail.example.com or returns bounces through bounces.example.com.

• Use relaxed alignment when senders use subdomains for DKIM signing or bounce handling.
• Use strict alignment only after headers and DMARC aggregate reports prove exact-domain alignment.
• Do not change both tags during a live launch or campaign. Test one change at a time.
• Remember that one aligned pass is enough. DMARC can pass with aligned DKIM even when SPF fails, or with aligned SPF even when DKIM fails.

How SPF, DKIM, and DMARC fit together

The tags matter because SPF and DKIM authenticate different identifiers.

SPF is a DNS TXT record that lists which servers can send for a domain. SPF checks the envelope sender, often shown as the return-path, not the visible From address. ~all is a soft fail for unlisted senders. -all is a hard fail. Use -all only when you are confident the SPF record covers all real senders. RFC 7208 also limits SPF evaluation to 10 DNS-querying mechanisms and modifiers. Too many nested includes can cause a permanent SPF error.

DKIM signs selected parts of a message with a private key. Receivers fetch the public key from DNS and verify the signature. Selectors let several systems sign for the same domain, such as selector1._domainkey.example.com. For DMARC alignment, the key value is the DKIM signing domain in d=. DKIM is defined in RFC 6376.

DMARC sits above SPF and DKIM. p=none monitors failures. p=quarantine asks receivers to treat failing mail as suspicious, often by placing it in spam or junk. p=reject asks receivers to reject failing mail. Receivers can still apply local policy. Add rua=mailto:... so aggregate reports show who is sending mail as your domain and where alignment fails.

What Gmail and Outlook check

Mailbox providers use authentication as one signal. Passing DMARC does not guarantee inbox placement.

Google's sender guidelines require SPF or DKIM for all senders to Gmail personal accounts, and SPF, DKIM, and DMARC for bulk senders. Google also says unauthenticated mail may be marked as spam or rejected.

Microsoft's Outlook.com sender policies also call for SPF, DKIM, and DMARC for high-volume senders. For exact thresholds and enforcement timing, use Microsoft's current page because mailbox-provider rules can change.

Authentication is only one part of filtering. Gmail, Outlook, and other providers also look at user complaints, wanted mail, sending history, domain and IP reputation, malware, links, sudden volume changes, and local policy. Blocklists can hurt delivery too, especially after abuse or a compromised account.

Check MX records during the same review. MX records do not make outbound DMARC pass, but bad inbound routing can break replies, abuse handling, and trust checks. A useful review covers SPF, DKIM, DMARC, MX, blocklists, and real message headers together. For more causes, read the related spam placement guide.

A safe change plan

Make alignment stricter only when the evidence says your mail can handle it.

• Start with p=none, relaxed alignment, and a working rua address.
• Send real mail from every platform that uses the domain.
• Inspect headers for spf=pass, dkim=pass, dmarc=pass, the SPF domain, the DKIM d= domain, and the From domain.
• Read aggregate reports to find vendors that pass SPF or DKIM but fail alignment.
• Fix each sender by using your domain for DKIM signing or return-path alignment where the vendor supports it.
• Move from p=none to p=quarantine after real mail passes.
• Use p=reject when legitimate mail has aligned SPF or aligned DKIM across all normal sending paths.
• Add adkim=s or aspf=s only for domains where exact-domain alignment is proven.

If you are unsure, leave adkim and aspf out. Relaxed alignment protects against unrelated domains while allowing normal subdomain sending.