AUTHPROBLEM.comEmail Authentication Analysis

Email Authentication Reference

This page combines the key SPF, DKIM, and DMARC reference material used across the individual sites so you can review the main DNS syntax, macros, selectors, tags, and examples in one place.

SPF Syntax

This section explains the main SPF elements and qualifiers that appear in SPF records.

Element What It Does
v=spf1 Marks the TXT record as an SPF policy.
ip4 Authorizes a specific IPv4 address or CIDR range to send mail.
ip6 Authorizes a specific IPv6 address or CIDR range to send mail.
a Authorizes the IPs returned by the domain's A or AAAA records.
mx Authorizes the IPs of the domain's MX hosts.
include Imports another domain's SPF policy.
redirect Replaces the current policy with another domain's SPF policy.
exists Matches if a DNS lookup on the given name returns any record.
ptr Matches based on reverse DNS. Deprecated and generally discouraged.
all Catch-all mechanism, usually placed at the end of the record.
Qualifier Meaning Typical Result
~ SoftFail (probably not allowed) Accept but mark suspicious
- Fail (not allowed) Reject
+ Pass (allowed) Accept
? Neutral (no policy) Accept, no SPF signal

+ and ? should generally not be used in modern SPF records.

SPF Macros

This section explains the SPF macros that can be expanded by the receiving server during SPF evaluation.

Macro Meaning Typical Use
%{i} Connecting IP address Used to build per-IP DNS names in mechanisms like exists.
%{s} Envelope sender Expands to the full sender address used during the SMTP transaction.
%{l} Local part of sender The part of the envelope sender before the @ symbol.
%{o} Sender domain The domain part of the envelope sender address.
%{d} Current domain The domain currently being evaluated in the SPF record.
%{h} HELO/EHLO domain The hostname the sending server announced in HELO or EHLO.
%{v} IP version Expands to in-addr for IPv4 or ip6 for IPv6.

SPF macros are expanded by the receiving server at evaluation time. The mechanism stays the same, but the placeholder is replaced with data such as the connecting IP, sender address, current domain, or HELO host before the DNS lookup is made.

DKIM Syntax

This section explains the main DKIM DNS tags that appear in DKIM selector records.

Tag What It Does
v=DKIM1 Marks the TXT record as a DKIM selector record.
k=rsa Declares the key type. RSA is the most common DKIM key type.
p= Contains the Base64-encoded public key used to validate DKIM signatures.
t=s Strictly limits use of the selector to the exact domain rather than subdomains.
t=y Testing mode. Indicates the selector may still be in test use.
n= Optional notes field for administrators.
h= Optional list of acceptable hash algorithms.
s= Optional service type tag, commonly email.

A valid DKIM record normally includes at least v=DKIM1 and a p= value containing the public key.

Element Meaning
Selector A short label used to look up the DKIM public key in DNS, for example selector1.
Record Host The full DNS name queried for the DKIM key, such as selector1._domainkey.example.com.
Rotation Selectors make it easier to publish a new key alongside an old one during key rotation.
Mismatch Risk A DKIM record can exist in DNS but still fail if the sending platform signs with a different selector.

When checking DKIM, you usually need both the domain and the selector, because the public key is published at a selector-specific DNS name.

DMARC Syntax

This section explains the main DMARC DNS tags that appear in DMARC policy records.

Tag What It Does
v=DMARC1 Marks the TXT record as a DMARC policy record.
p= Sets the main DMARC policy for the domain and tells receiving systems how to handle mail that fails DMARC alignment checks. Valid values are none, quarantine, and reject.
sp= Optional subdomain policy. It tells receiving systems how to handle mail from subdomains that fails DMARC alignment checks. Valid values are none, quarantine, and reject. If omitted, subdomains inherit the main policy.
rua= Optional aggregate report destinations, usually mailto: URIs.
ruf= Optional forensic report destinations, usually mailto: URIs. Many email systems do not generate these reports because of privacy and security concerns.
adkim= Defines DKIM alignment mode. r is relaxed and s is strict.
aspf= Defines SPF alignment mode. r is relaxed and s is strict.
pct= Applies the policy to a percentage of matching mail from 0 to 100.
fo= Optional failure reporting options.
ri= Optional requested interval for aggregate reports, in seconds.

A valid DMARC record normally includes at least v=DMARC1 and a p= policy.

v=DMARC1; p=none

An absolute minimum DMARC record. It publishes a DMARC policy in monitoring mode without requesting quarantine or rejection.

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

A common starting point when first deploying DMARC, because it enables aggregate reporting while keeping enforcement disabled.

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=25

A staged rollout example. It asks receivers to quarantine failing mail, but only for 25% of matching traffic.

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

A stronger enforcement example using reject policy and strict DKIM/SPF alignment.

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com

An example where the main domain uses reject, but subdomains use a softer quarantine policy.

Element Meaning
Policy The p tag sets the main DMARC enforcement policy: none, quarantine, or reject.
Alignment The adkim and aspf tags control whether DKIM and SPF alignment are relaxed or strict.
Reporting The rua and ruf tags declare where aggregate and forensic reports may be sent.
Subdomains The sp tag lets you apply a separate policy to subdomains.
Rollout The pct tag can be used to roll a policy out to only part of the mail flow while testing.

When checking DMARC, the most important things to confirm are that the record exists at _dmarc.example.com, that the syntax is valid, and that the policy and reporting tags reflect the intended rollout.

SitemapDisclaimer
© 2026 authproblem.com