DMARC Analyzer

TL;DR

SPF is encoded at the DNS layer as a single TXT record whose body begins with v=spf1 followed by space-separated mechanism and modifier tokens, terminating in a qualified all token. The DNS-record-level syntax is governed by RFC 7208 section 3 and the underlying DNS specification in RFC 1035.

• TXT record only — the legacy SPF resource-record type 99 was removed by RFC 7208 section 14.1. Modern receivers query TXT exclusively.
• Mandatory v=spf1 prefix — the version tag is case-insensitive but conventionally lowercase. Records lacking the prefix are not SPF records.
• 255-octet character-string limit — per CHARACTER-STRING, not per TXT record. A TXT record can contain multiple character-strings concatenated at lookup time (RFC 7208 section 3.3).
• Exactly one SPF record per domain — multiple TXT records starting with v=spf1 produce permerror (RFC 7208 section 3.2).
• No subdomain inheritance — example.com SPF does not apply to mail.example.com. Publish a per-subdomain record or an explicit v=spf1 -all for non-sending subdomains.
• No comments — the # character is a literal character in the SPF body, not a comment introducer. Comments live in the zone-file source, not in the record body.

The Domain Security Checker surfaces every syntactic drift class documented on this page: missing v=spf1 prefix, multiple SPF records, 255-character overflow without chunking, and subdomains without their own SPF record.

1. What "DNS record syntax" means for SPF (and where the semantics live)

SPF is a layered specification. The SYNTAX LAYER defines how the policy is encoded at the DNS: which record type to use, what character set is valid, how tokens are separated, where to publish the record, and how DNS-level constraints (the 255-octet character-string limit, the response size cap, the lookup count) bound the encoding. The SEMANTIC LAYER defines what each token means once it has been parsed: which IPs the ip4 mechanism authorises, what the include mechanism does, how the qualifier prefixes shape the result code.

This page covers the SYNTAX LAYER exhaustively. The semantic layer is covered by the sibling reference pages:

• SPF protocol pillar — the whole-protocol survey (what SPF does and does not do, the seven result codes, alignment, the deployment workflow).
• SPF mechanisms explained — the COMPLETE 8-mechanism + 4-qualifier + 2-modifier semantic reference.
• SPF qualifiers explained — the focused per-qualifier semantic deep dive (Pass / Fail / SoftFail / Neutral).
• include vs ip4 vs a vs mx — the focused 4-way decision view for the IP-providing mechanisms.

Why the syntax layer matters independently: a syntactically malformed SPF record produces permerror (RFC 7208 section 4.5), which counts as a non-pass for DMARC and may cause receiver-side rejection. The syntactic failure modes documented below — multiple SPF records, missing v=spf1 prefix, 255-character overflow without chunking, leading whitespace — are operator-introduced and trivially avoidable once the syntax is understood. Most "my DMARC is failing" tickets where the SPF semantics are correct trace back to a syntactic drift at the DNS layer.

The canonical SPF DNS record: a single TXT resource record at the publishing name whose body is a single character-string (or multiple character-strings concatenated by the resolver) beginning with v=spf1, followed by space-separated mechanism and modifier tokens, terminated by a qualified all token. Example minimum well-formed record:

example.com.    IN  TXT  "v=spf1 -all"

This record publishes "no sender is authorised for MAIL FROM @example.com" — appropriate for a null-sender domain. The seven sections below enumerate every syntactic rule that constrains how this record can be modified to authorise actual senders.

2. The mandatory v=spf1 version tag (RFC 7208 §4.5)

Rule: Every SPF record MUST begin with the literal token v=spf1. Records that do not begin with v=spf1 are not SPF records and are ignored by every SPF receiver. This is the version discriminator that distinguishes SPF from other TXT-based protocols (DKIM signature records use v=DKIM1; DMARC records use v=DMARC1; BIMI records use v=BIMI1; SiteVerification records have no version tag).

Syntax: The literal four-character token v=spf1 followed by at least one space, then the first mechanism or modifier. The comparison is case-insensitive per RFC 7208 section 4.6.1, so V=SPF1 and v=SPF1 are also valid — but convention is strict lowercase v=spf1.

v=spf1 ip4:198.51.100.42 -all      # valid
V=SPF1 ip4:198.51.100.42 -all      # valid (case-insensitive)
spf1 ip4:198.51.100.42 -all        # NOT a valid SPF record (no v= prefix)
v=spf2 ip4:198.51.100.42 -all      # NOT a valid SPF record (only v=spf1 is recognised)

Why: the version tag exists to allow the DNS resolver to discriminate SPF records from other TXT records at the same name. A modern domain typically has multiple TXT records at the apex (one for SPF, one for the _dmarc subdomain, possibly one for SiteVerification, one for DKIM at the selector subdomain, one for MTA-STS, etc.). The v=spf1 prefix lets the SPF processor walk the TXT RRset and pick out the SPF record deterministically.

How to check: Run dig +short TXT example.com and look for a quoted string starting with "v=spf1. Or use the Domain Security Checker which surfaces the parsed version tag explicitly.

When it breaks: the most common drift class is publishing a record that starts with a mechanism token directly (e.g., ip4:198.51.100.42 -all) — the v=spf1 prefix was omitted during a copy-paste. The record is technically a TXT record but is not an SPF record, so every receiver treats the domain as having NO SPF policy. The symptom: DMARC fails because SPF returns "none" rather than "pass" for legitimate senders.

Common pitfalls: (1) Omitting the v=spf1 prefix after migrating between DNS providers. (2) Writing v=SPF1 (valid but non-canonical) and triggering false-flag warnings from naive SPF validators. (3) Writing v=spf2 hoping for a "newer" SPF — only v=spf1 is defined; there is no SPF 2. (4) Misreading the prefix as v=dkim1 or v=dmarc1 when copying from a template. (5) Leading whitespace before v=spf1 — the ABNF in RFC 7208 section 12 forbids leading whitespace, and some strict receivers reject the record.

3. The TXT record type and the deprecated SPF type 99 (RFC 7208 §3.1, §14.1)

Rule: SPF policies MUST be published as TXT records (DNS RR type 16). The experimental SPF resource-record type (RR type 99, sometimes labelled SPF in older DNS-management UIs) was deprecated and formally removed by RFC 7208 section 14.1. Modern receivers query TXT only and ignore type 99 entirely.

Syntax: the TXT record is published at the canonical DNS name (apex or subdomain) with a quoted body. Example zone-file syntax:

example.com.    3600    IN  TXT  "v=spf1 ip4:198.51.100.42 -all"

The TTL (3600 seconds shown here) is operator-controlled; lower TTLs (300-600 seconds) are recommended during deployment for fast rollback, higher TTLs (3600-86400 seconds) are appropriate after the record stabilises.

Why: the experimental SPF type 99 was defined in RFC 4408 (the prior SPF specification) as the "future-correct" record type. In practice it never gained universal resolver support, and many DNS providers refused to add UI support for it. RFC 7208 (the current SPF specification, April 2014) section 14.1 formally deprecated type 99 and mandates TXT-only publication. The benefit of using only TXT: every DNS provider supports TXT records, every resolver queries TXT for SPF, and there is no risk of divergence between two records.

How to check: Run dig +short TXT example.com — the SPF record appears in the TXT RRset. Also run dig +short SPF example.com — modern authoritative servers return NOERROR with no records (type 99 is unused). If type 99 returns a record, your DNS provider is still publishing the legacy type — remove it and keep only the TXT record.

When it breaks: if you publish the same SPF policy at both TXT and type 99, and later update only one (e.g., the TXT record adds a new SaaS sender, but type 99 still has the old list), the two records diverge. Modern receivers query only TXT and see the updated record; legacy middleboxes that still query type 99 see the stale record. The divergence is undetectable until a receiver behaves unexpectedly.

Common pitfalls: (1) Publishing at both TXT and type 99 from a DNS-management UI that offers both. (2) Forgetting to remove a stale type 99 record after migrating to TXT. (3) Publishing the SPF record at an A or CNAME record by mistake (the record body looks like an IP or hostname). (4) Publishing the SPF record as type ANY (which is not a publication type, only a query type). (5) Using a DNS provider that auto-converts TXT to SPF type 99 silently — switch providers or disable the conversion.

4. The 255-octet character-string limit and multi-string concatenation (RFC 1035 §3.3, RFC 7208 §3.3)

Rule: A single DNS character-string cannot exceed 255 octets (RFC 1035 section 3.3 — one length byte plus up to 255 content bytes). To publish an SPF record longer than 255 characters, split the body across MULTIPLE character-strings in a single TXT resource record; the resolver concatenates the character-strings into the logical record before returning it to the SPF processor (RFC 7208 section 3.3).

Syntax: in BIND zone-file syntax, multiple character-strings appear as multiple quoted strings separated by whitespace inside the TXT record body. Each quoted string is one character-string; the resolver concatenates them by joining the strings end-to-end with no additional whitespace.

example.com.    3600    IN  TXT  "v=spf1 ip4:198.51.100.0/24 ip4:203.0.113.0/24 "
                                 "ip4:192.0.2.0/24 include:_spf.google.com "
                                 "include:spf.protection.outlook.com -all"

The above publishes ONE TXT record (one resource record) containing THREE character-strings. The resolver returns the three strings; the SPF processor concatenates them into the logical record:

v=spf1 ip4:198.51.100.0/24 ip4:203.0.113.0/24 ip4:192.0.2.0/24 include:_spf.google.com include:spf.protection.outlook.com -all

Why: the 255-octet cap is a DNS protocol-level constraint, not an SPF-specific constraint. Every TXT record in DNS is subject to it. SPF inherits this constraint and adds the multi-string concatenation rule on top so that long SPF policies can still be published. The concatenation happens at the SPF processor (the receiver-side software), not at the resolver — so the resolver returns the multi-string TXT record verbatim, and the SPF processor reassembles the logical record.

How to check: Run dig +short TXT example.com — if the SPF record is multi-string, dig prints multiple quoted strings separated by spaces. Or use dig TXT example.com (without +short) to see the full TXT RRset with character-string boundaries. The Domain Security Checker surfaces the chunked form explicitly.

When it breaks: the typical failure mode is attempting to publish a single character-string longer than 255 octets — most DNS providers reject this at zone-file validation time with an error like "TXT string too long". The correct fix is to split into multiple character-strings. The second failure mode: some DNS provider UIs accept a long string from the user but silently truncate it to 255 octets at publish time — the published record is missing the tail mechanisms and produces unexpected permerror or false-negative SPF results.

Common pitfalls: (1) Publishing a single 300-character string without chunking and getting silent truncation. (2) Joining character-strings with extra whitespace ("v=spf1 ip4:..." " ip4:...") that creates a double-space in the concatenated record — the ABNF tolerates this but some strict receivers do not. (3) Splitting mid-token across character-strings ("v=spf1 i" + "p4:198.51.100.42 -all") which produces a malformed token after concatenation. (4) Using a UI that represents the record as a single field and cannot express the multi-string syntax. (5) Mistakenly publishing multiple TXT records starting with v=spf1 thinking that multi-string = multi-record (it does NOT; see §6 below).

5. Whitespace separators and case-sensitivity (RFC 7208 §4.6.1, §12 ABNF)

Rule: Mechanism and modifier tokens are separated by exactly one space character per the ABNF in RFC 7208 section 12. The ABNF tolerates multiple spaces between tokens but receivers may be strict. Tabs, newlines, and other whitespace characters are forbidden inside the record body. Mechanism names, modifier names, and qualifier prefixes are case-insensitive per RFC 7208 section 4.6.1, but convention is strict lowercase.

Syntax: single space between tokens; no leading or trailing whitespace inside the record body; all mechanism names (a, mx, ptr, ip4, ip6, exists, include, all) and modifier names (redirect, exp) written lowercase by convention.

v=spf1 ip4:198.51.100.42 include:_spf.google.com -all      # canonical
v=spf1  ip4:198.51.100.42  -all                            # tolerated (multiple spaces)
v=spf1	ip4:198.51.100.42 -all                              # MALFORMED (tab between v=spf1 and first mechanism)
v=spf1 IP4:198.51.100.42 INCLUDE:_spf.google.com -ALL      # valid (case-insensitive)
v=spf1 ip4:198.51.100.42 include:_spf.google.com -all      # canonical lowercase

Why: the SPF grammar in the RFC 7208 section 12 ABNF defines mechanism tokens as sequences separated by whitespace. The grammar is intentionally simple so that the parser can be written in a few hundred lines of code in any language. Case-insensitivity is inherited from the underlying DNS convention (DNS names are case-insensitive) and applied uniformly to all SPF keyword tokens. The case-insensitivity DOES NOT extend to the domain-name arguments inside mechanisms — include:_SPF.Google.com works because DNS itself is case-insensitive at the lookup layer, not because SPF normalises the case.

How to check: Run dig +short TXT example.com — the output is the record body verbatim. Look for any tab characters (typically rendered as \t in escaped output), leading whitespace inside the quoted string, or unusual case on the mechanism names. The Domain Security Checker flags non-canonical case as a "style" warning, not a hard error.

When it breaks: the most common whitespace drift is copy-pasting a multi-line SPF record from a documentation source into a DNS-management UI that does not strip leading whitespace. The record is published as v=spf1 ip4:... with leading spaces; strict SPF processors return permerror on the malformed prefix. The second common drift: a tab character creeps in between tokens (often from a markdown-style "indented code block" being copy-pasted). The third common drift: trailing whitespace inside the quoted body — the receiver may interpret the trailing space as a separator before a missing final token.

Common pitfalls: (1) Leading whitespace from copy-paste of indented examples. (2) Tab characters from markdown code blocks. (3) Trailing whitespace producing implicit empty token. (4) Newlines inside the record body (forbidden; the body must be a single line at the SPF layer, even if the TXT record uses multiple character-strings for chunking). (5) Confusing case-insensitivity of keywords with case-insensitivity of domain arguments — both are case-insensitive but for different reasons, and SPF strictly normalises neither.

6. The "exactly one SPF record per domain" rule (RFC 7208 §3.2)

Rule: A domain MUST NOT have more than one TXT record beginning with v=spf1. If a receiver retrieves two or more such records during a single SPF check, the result is permerror (RFC 7208 section 4.5 explicitly mandates this) and the SPF check fails. This counts as a non-pass for DMARC and may cause receiver-side rejection.

Syntax: if a domain needs to authorise multiple sets of senders (the on-prem server, a SaaS sender, a marketing platform), combine them into a single TXT record with multiple mechanism tokens. Do NOT publish separate TXT records.

# WRONG — two SPF records cause permerror:
example.com.    IN  TXT  "v=spf1 ip4:198.51.100.42 -all"
example.com.    IN  TXT  "v=spf1 include:_spf.google.com -all"

# RIGHT — one merged SPF record:
example.com.    IN  TXT  "v=spf1 ip4:198.51.100.42 include:_spf.google.com -all"

Why: the SPF processor needs a deterministic single policy per domain. Multiple records would create ambiguity: which policy applies when the sender matches one record but not another? The RFC removes the ambiguity by mandating permerror on the multi-record case and forcing operators to express the policy as a single document. The constraint also makes SPF auditable: one record per domain = one document to review = one decision to make.

How to check: Run dig +short TXT example.com | grep '^"v=spf1' — the output should be exactly ONE line. Two or more lines is the drift case. The Domain Security Checker surfaces this drift class as "multiple SPF records detected" with the full list of conflicting bodies.

When it breaks: the canonical cause is incremental sender additions where each addition published a NEW TXT record rather than EDITING the existing one. Common scenario: the on-prem mail team publishes v=spf1 ip4:198.51.100.42 -all; the marketing team adds Mailchimp by publishing a second record v=spf1 include:servers.mcsv.net -all "to authorise Mailchimp". The result is two records, permerror, and broken delivery for both senders. The fix is to merge into one record.

Common pitfalls: (1) Two teams publishing separate SPF records without coordination. (2) An old SPF record left in place after a vendor migration. (3) A CNAME at the apex (forbidden but occasionally present) resolving to a name with its own SPF record, producing apparent multi-record behaviour. (4) Confusing the single-record rule with the single-character-string rule (they are independent — one record can contain multiple character-strings; multiple records is the violation). (5) Believing that publishing a NEW record automatically supersedes an OLD record — DNS has no replacement semantics; the old record persists until explicitly removed.

7. Publication: apex, subdomain, wildcards, and the no-inheritance rule (RFC 7208 §3.4)

Rule: The SPF record applies ONLY to the queried name. There is NO inheritance from parent to child in the DNS hierarchy. A record at example.com does not apply to mail.example.com or any other subdomain. The SPF receiver queries the EXACT name extracted from the SMTP MAIL FROM domain (and falls back to HELO/EHLO if MAIL FROM is empty per RFC 7208 section 2.3); whatever it finds at that name is the SPF record, and whatever is absent is "no SPF record".

Syntax: publish one TXT record per name that needs an SPF policy. For non-sending subdomains, publish an explicit v=spf1 -all to prevent spoofing.

example.com.        IN  TXT  "v=spf1 ip4:198.51.100.42 -all"
mail.example.com.   IN  TXT  "v=spf1 include:_spf.google.com -all"
api.example.com.    IN  TXT  "v=spf1 -all"                            # explicit null
news.example.com.   IN  TXT  "v=spf1 include:servers.mcsv.net -all"
*.example.com.      IN  TXT  "v=spf1 -all"                            # wildcard backstop

Why: the no-inheritance rule forces operators to make an explicit policy decision for each subdomain. SPF cannot guess whether mail.example.com is the legitimate outbound server (requiring its own sender authorisation) or a marketing subdomain that sends nothing (requiring -all). The explicit per-subdomain record removes the ambiguity. The DNS protocol itself supports inheritance via NS delegation but TXT records (and SPF records by extension) explicitly do not.

How to check: Enumerate every subdomain that appears as a MAIL FROM in your outbound traffic and confirm each has an SPF record. Run dig +short TXT mail.example.com for each candidate subdomain — the record should exist if the subdomain sends mail, or be an explicit v=spf1 -all if it does not. The Domain Security Checker surfaces per-subdomain SPF coverage in its multi-subdomain audit mode.

When it breaks: the canonical drift class is "spoofable subdomain" — an attacker sends mail from billing-confirmation@news.example.com where news.example.com has no SPF record. The receiver checks SPF, finds no record, returns "none", and DMARC then evaluates against the ORG-DOMAIN policy at _dmarc.example.com. If DMARC is at p=none the spoofed mail is delivered. If DMARC is at p=quarantine or p=reject the spoof is rejected — but only because DMARC made up the gap; SPF alone failed to block. The fix: publish explicit v=spf1 -all on every non-sending subdomain.

Wildcards: a wildcard TXT record at *.example.com matches any subdomain that has NO other RR set at that name. So *.example.com IN TXT "v=spf1 -all" applies to random.example.com only if that name has no A, AAAA, MX, CNAME, or any other RR — a constraint most subdomains do not satisfy. Wildcards are useful as a belt-and-suspenders backstop but never as the primary coverage mechanism. The reliable posture is explicit per-subdomain records for every name that ever appears in MAIL FROM.

Common pitfalls: (1) Believing that the apex SPF record covers subdomains (it does not). (2) Publishing only the apex record and leaving subdomains spoofable. (3) Relying on wildcard TXT records that fail to match because the subdomain has an A or CNAME record. (4) Publishing _spf.example.com IN TXT "v=spf1..." thinking that prefix scopes the record to "SPF" — in reality nothing queries _spf.example.com for SPF; the record must be at the actual name used in MAIL FROM. (5) Publishing example.com IN CNAME spf.example.net at the apex (forbidden by DNS — apex CNAMEs are invalid) and getting unpredictable behaviour from the resolver.

8. Six worked syntactic examples

Each example shows a complete TXT record body illustrating one syntactic feature. The body is presented as it would appear in a BIND zone file after the IN TXT directive; the quoted-string boundaries are explicit.

8.1 Minimum well-formed record (null-sender domain)

The shortest valid SPF record. Appropriate for a domain that sends no mail at all (a parked domain, a domain used only for receiving mail on a separate name, an organisational placeholder).

example.com.    IN  TXT  "v=spf1 -all"

Syntactic features: mandatory v=spf1 prefix, single space separator, terminal qualified -all, no chunking needed (well under 255 octets).

8.2 Apex record authorising on-prem + SaaS senders

A typical mid-size deployment: one on-prem mail server (ip4 mechanism), Microsoft 365 (include mechanism), and a marketing SaaS (second include). All under 255 characters so no chunking is needed.

example.com.    IN  TXT  "v=spf1 ip4:198.51.100.42 include:spf.protection.outlook.com include:servers.mcsv.net -all"

Syntactic features: single character-string, three space-separated mechanisms, strict lowercase, terminal -all. Cumulative DNS-lookup count: 1 (M365 include) + 1 (Mailchimp include) = 2; well under the 10-lookup ceiling.

8.3 Multi-string chunking for a long record

When the record exceeds 255 characters, split into multiple character-strings in a single TXT resource record. The resolver concatenates the strings end-to-end at lookup time.

example.com.    IN  TXT  "v=spf1 ip4:198.51.100.0/24 ip4:203.0.113.0/24 ip4:192.0.2.0/24 "
                                 "ip4:192.0.2.128/26 include:_spf.google.com "
                                 "include:spf.protection.outlook.com include:servers.mcsv.net "
                                 "include:_spf.salesforce.com -all"

Syntactic features: ONE TXT resource record (single RR), FOUR character-strings (each quoted independently), one logical SPF policy after concatenation. Note the trailing space inside the first three character-strings to ensure a space separator survives concatenation — omit the trailing space and the resulting body has no space between the last token of string N and the first token of string N+1, producing a malformed token.

8.4 Per-subdomain records with explicit null on non-sending names

Every subdomain that appears in MAIL FROM needs its own SPF record. Non-sending subdomains get an explicit v=spf1 -all to prevent spoofing. Wildcard backstop for any subdomain not explicitly enumerated.

example.com.        IN  TXT  "v=spf1 ip4:198.51.100.42 -all"
mail.example.com.   IN  TXT  "v=spf1 include:_spf.google.com -all"
news.example.com.   IN  TXT  "v=spf1 include:servers.mcsv.net -all"
api.example.com.    IN  TXT  "v=spf1 -all"
support.example.com. IN TXT  "v=spf1 -all"
*.example.com.      IN  TXT  "v=spf1 -all"

Syntactic features: five explicit per-name records plus one wildcard. The wildcard fires only for names with no other RRs, which is rare in practice but valuable as a backstop for forgotten subdomains.

8.5 Internationalised domain names (IDN): ASCII vs U-label

Domain names inside SPF mechanisms must use the ASCII A-label form (Punycode), not the UTF-8 U-label form. RFC 7208 section 3.4 inherits this constraint from the DNS protocol itself: DNS labels are bytes, and SPF mechanism arguments are interpreted as DNS names.

# U-label form (FORBIDDEN in SPF mechanisms):
example.com.    IN  TXT  "v=spf1 include:_spf.möbel.example -all"

# A-label form (correct, Punycode encoding):
example.com.    IN  TXT  "v=spf1 include:_spf.xn--mbel-5qa.example -all"

Syntactic features: all mechanism-argument domain names in A-label (Punycode xn-- prefix) form. The SPF receiver will not perform UTF-8 to A-label translation; the record body must contain pre-encoded names.

8.6 The redirect= modifier for cross-organisation policy delegation

The redirect= modifier (RFC 7208 section 6.1) instructs the receiver to abandon the current record and re-evaluate against the SPF record of the named target. Useful for centralised SPF management across many domains owned by the same organisation. Syntactically, redirect= is a MODIFIER (key=value form), not a mechanism.

marketing.example.com.    IN  TXT  "v=spf1 redirect=_spf.example.com"
sales.example.com.        IN  TXT  "v=spf1 redirect=_spf.example.com"
support.example.com.      IN  TXT  "v=spf1 redirect=_spf.example.com"
_spf.example.com.         IN  TXT  "v=spf1 ip4:198.51.100.0/24 include:_spf.google.com -all"

Syntactic features: the redirect= modifier appears at the end of the record (per RFC 7208 it is processed only if no mechanism matched, so position matters semantically but not syntactically). The target record at _spf.example.com has its own -all terminator that governs the delegating records' enforcement. The delegation reduces zone-file maintenance: update one _spf.example.com record to update SPF for all delegating subdomains.

9. The seven most common syntax mistakes

Documented from production drift across hundreds of audits: the syntactic failure modes operators introduce when authoring or editing SPF records. Each is trivially avoidable once the rule from the sections above is understood.

1. Missing v=spf1 prefix — typically after migrating between DNS providers. The record looks like a plausible SPF body (ip4:198.51.100.42 -all) but is not an SPF record at all. Every receiver treats the domain as having no SPF policy. Detection: dig +short TXT example.com returns a string that does not start with "v=spf1. Fix: prepend v=spf1 + space to the existing body.
2. Multiple TXT records starting with v=spf1 — the most common permerror cause. Two teams publish separate records, or an old record is left in place after a vendor migration. Detection: dig +short TXT example.com | grep -c '^"v=spf1' returns 2 or more. Fix: merge into one record with all required mechanisms; remove the extras.
3. Single character-string longer than 255 octets — the DNS provider may reject the record at publish time or silently truncate it. Detection: count characters in the published record body; if greater than 255 and no multi-string chunking appears in dig TXT example.com, the record is broken. Fix: split into multiple character-strings (see §4 above), or reduce record length by flattening.
4. Tab character or leading whitespace inside the record body — typically from markdown-style code blocks being copy-pasted. The strict SPF processor returns permerror. Detection: dig TXT example.com shows the verbatim body with escaped whitespace (\t). Fix: re-author the record with single-space separators and no whitespace before v=spf1.
5. UTF-8 / U-label domain names inside mechanisms — non-ASCII characters in include / a / mx mechanism arguments. The SPF receiver does not translate U-labels to A-labels. Detection: any non-ASCII byte in the record body. Fix: pre-encode every internationalised domain in Punycode A-label form (xn--...).
6. Apex CNAME pointing to a name with its own SPF record — DNS forbids apex CNAMEs but some operators publish them anyway via DNS-provider-specific "ALIAS" or "ANAME" records. The result is unpredictable SPF behaviour because the resolver may return the CNAME target instead of querying TXT at the apex. Detection: dig example.com shows a CNAME at the apex. Fix: remove the apex CNAME; publish A/AAAA records at the apex and the SPF TXT directly on example.com.
7. Publishing the SPF record at the wrong name — typically at _spf.example.com (which is not a canonical SPF location) instead of example.com. The receiver queries the MAIL FROM domain directly; whatever appears at _spf.example.com is never consulted unless explicitly referenced by a redirect=_spf.example.com in another record. Detection: dig +short TXT example.com returns no SPF record. Fix: publish the SPF TXT at the actual name used in MAIL FROM.

10. FAQ

Why does my SPF record need to be published as a TXT record and not a SPF record?

The legacy SPF resource-record type (RR type 99) was experimentally defined in RFC 4408 but never gained universal resolver support. RFC 7208 section 14.1 formally deprecated and removed it: modern SPF deployments publish the policy as a TXT record only. The TXT record type (DNS RR type 16) is universally supported by every authoritative server and resolver, and every SPF receiver queries TXT only. Publishing the same policy at both record types is unnecessary, doubles DNS-query cost on every lookup, and risks divergence between the two records if one is updated and the other is forgotten. The canonical action is: publish as TXT, never as type 99.

What is the 255-character SPF record limit and how do I work around it?

The 255-octet limit is a property of a single DNS character-string (RFC 1035 section 3.3), not the SPF record as a whole. A TXT record can contain MULTIPLE character-strings, each up to 255 octets, which the resolver concatenates at lookup time (RFC 7208 section 3.3). So to publish an SPF record longer than 255 characters, split it across multiple quoted strings in your DNS zone-file. The practical ceiling: a well-engineered SPF record at the 10-DNS-lookup limit (RFC 7208 section 4.6.4) is typically under 1000 characters, so the working ceiling is dictated by mechanism count, not byte count. See SPF 10 DNS lookup limit and SPF flattening for the canonical remediation playbook.

Can I have two SPF records on the same domain?

No. RFC 7208 section 3.2 explicitly forbids multiple TXT records starting with v=spf1 on the same name. If a receiver retrieves two TXT records starting with v=spf1, the SPF check produces permerror (RFC 7208 section 4.5), which counts as a non-pass for DMARC and may cause receiver-side rejection. The most common cause is accidentally publishing one SPF record for the on-prem server and a second for a SaaS provider. The fix: merge into a single TXT record with multiple include / ip4 / ip6 mechanisms. The Domain Security Checker surfaces this drift class as "multiple SPF records detected".

Is the SPF v=spf1 prefix case sensitive?

No. RFC 7208 section 4.5 specifies v=spf1 as the canonical prefix, but the comparison is case-insensitive per RFC 7208 section 4.6.1. So V=SPF1, v=SPF1, and V=spf1 are all valid and produce the same behaviour. Convention is strict lowercase v=spf1 for consistency with the RFC examples. The mechanism names (a, mx, ptr, ip4, ip6, exists, include, all) are similarly case-insensitive but conventionally written lowercase. Best practice: write everything lowercase for consistency with every published authoritative source.

Where should I publish my SPF record — at the apex or per subdomain?

The SPF record applies ONLY to the queried name with no inheritance from parent to child (RFC 7208 section 3.4). So an SPF record at example.com governs mail with MAIL FROM example.com but NOT mail with MAIL FROM mail.example.com. The canonical posture is: (1) Publish a complete SPF record at the apex covering every sender that uses the apex as MAIL FROM. (2) For every subdomain that sends mail, publish an SPF record at that subdomain. (3) For every subdomain that does NOT send mail, publish an explicit v=spf1 -all to prevent spoofing. The lack of inheritance is the most common deployment mistake.

Are there comments in SPF records?

No. SPF has no comment syntax. The # character that introduces comments in many DNS zone-file editors is a comment in the ZONE FILE (consumed by the DNS server software), but the resulting TXT record body — which is what the SPF receiver sees — contains no comments at all. The ABNF grammar in RFC 7208 section 12 has no comment production. So you cannot write v=spf1 ip4:198.51.100.42 # office IP -all inside the record body. The workaround: keep comments in the zone-file source (in the line that publishes the TXT record but BEFORE the record-body quoting), in a separate documentation repository, or in a config-management commit message.

Does the SPF record have a maximum size?

There is no explicit byte-size cap in RFC 7208 — but there are three effective caps that constrain how large an SPF record can practically be. (1) The 255-octet DNS character-string limit. (2) The DNS response size limit (UDP traditionally 512 bytes, EDNS0 extends to 4096 bytes or more). (3) The 10-DNS-lookup ceiling of RFC 7208 section 4.6.4. In practice the lookup ceiling is reached long before the byte ceiling, so the working maximum is dictated by mechanism count rather than byte count. A well-engineered SPF record at the 10-lookup ceiling is typically under 1000 characters.

What is the difference between a TXT character-string and a DNS resource record?

A DNS resource record (RR) is the unit of DNS storage — a single TXT RR at a name. A TXT RR contains one OR MORE character-strings (RFC 1035 section 3.3), each a length-prefixed sequence of up to 255 octets. The resolver concatenates the character-strings into the logical TXT record when answering a query. So a "long" SPF record is technically one TXT resource record containing multiple character-strings, not multiple TXT records. Multiple TXT records starting with v=spf1 is a violation of RFC 7208 section 3.2 and produces permerror; a single TXT record with multiple character-strings is valid and is the canonical way to publish an SPF record longer than 255 characters.

Can SPF use wildcard DNS records?

Yes but with caveats. A wildcard TXT record at *.example.com matches any subdomain that has no explicit RR set at that name. So v=spf1 -all at *.example.com applies to mail.example.com and api.example.com only IF those names have no other RRs. DNS wildcards stop matching as soon as ANY RR exists at the name, so a subdomain with its own MX record will NOT inherit the *.example.com SPF record. The practical implication: wildcards are unreliable for SPF coverage of "all my non-mail-sending subdomains" because the wildcard only fires when the subdomain has no other RRs, and most subdomains do have at least A or CNAME. The reliable posture is: publish an explicit v=spf1 -all on every subdomain that does not send mail.

11. Related guides

• SPF explained — the SPF protocol pillar (what SPF is, the seven result codes, alignment, the deployment workflow). Start here if you are new to SPF.
• SPF mechanisms explained — the COMPLETE 8-mechanism (a, mx, ptr, ip4, ip6, exists, include, all) + 4-qualifier + 2-modifier (redirect, exp) semantic reference. Once the syntax above is clear, this page covers what each token MEANS.
• SPF qualifiers explained — the focused per-qualifier deep dive (Pass, Fail, SoftFail, Neutral). The semantic complement to this syntactic reference.
• include vs ip4 vs a vs mx — the focused decision view for the four IP-providing mechanisms that operators routinely pick between.
• SPF lookup limit explained — the RFC 7208 §4.6.4 10-DNS-lookup cap, cumulative cost accounting, and the SPF flattening playbook. The dominant constraint on how large an SPF record can practically be (more constraining than the 255-octet character-string limit documented above).
• SPF permerror vs temperror — the focused diagnostic deep dive on the two SPF error result codes. Most syntactic drift classes documented above surface as permerror at the receiver.
• SPF forwarding issues — the SRS / ARC / MUNGE / .forward catalogue of forwarder-induced SPF failures. Distinct from the syntactic drift classes here, which are author-introduced.
• SPF for Microsoft 365 — the Microsoft-365-specific deployment guide. Includes the canonical apex SPF record syntax for M365 tenants.
• DMARC for Microsoft 365 — the M365-TENANT-SPF-RECORD-BYTE- GRAMMAR-AS-PRECONDITION-FOR-DMARC-SPF- ALIGNED-PASS companion to this SPF byte-syntax pillar reference. Where THIS page documents the RFC 7208 §3 SPF TXT record byte-grammar (the v=spf1 protocol version identifier, the per-mechanism per- qualifier verdict-cascade evaluation, the include:<domain> recursive macro-expansion at the receiver-side §5.2 reference resolver, the ~all softfail vs -all hardfail terminal qualifier semantics, the §4.6.4 10-DNS-lookup ceiling), the DMARC-for- M365 spoke documents the per-tenant DMARC publication discipline at four per-tenant-SPF-publication-to-DMARC- evaluation-coupling dimensions: (i) per-tenant include:spf.protection.outlook.com macro-expansion as M365-tenant per- message SPF-authenticated-envelope- identifier source — the canonical M365-tenant apex SPF record THIS page's byte-grammar produces delegates SPF authorisation to the Microsoft-managed spf.protection.outlook.com IP-set publication whose macro-expanded per-IP membership at the receiver-side §5.2 reference resolver is the upstream SPF-authenticated-envelope- MAIL-FROM authorisation contract the per-tenant DMARC SPF-alignment evaluation consumes — the per-tenant SPF-aligned-pass cascade depends on the per-tenant DNS-published TXT record THIS page documents being syntactically well-formed at the author-domain apex; (ii) per- tenant ~all vs -all terminal-qualifier choice as DMARC-rollout-phase-gated publication decision — the M365-tenant rollout discipline pairs the SPF terminal qualifier choice with the DMARC policy phase: the ~all softfail qualifier THIS page's RFC 7208 §4.7 byte-grammar admits is the canonical default during DMARC p=none monitoring mode (allowing per-IP transitional misconfigurations to surface in RUA reports without immediate receiver- side rejection), and advancement to DMARC p=reject ENFORCEMENT mode typically advances SPF to -all hardfail in lockstep — the DMARC-for-M365 spoke documents the per-phase advancement gate that maps the SPF byte-grammar terminal qualifier THIS page documents to the per-tenant DMARC enforcement contract; (iii) per-tenant 10-DNS-lookup ceiling discipline as M365-multi-vendor-include SPF flattening constraint — M365-tenant author-domains routinely ship a §3 SPF record THIS page documents that combines include:spf.protection.outlook.com with additional vendor includes (include:_spf.salesforce.com, include:mailgun.org, include:_spf.google.com, per-marketing-ESP includes); the §4.6.4 10-DNS-lookup ceiling THIS page's byte-grammar references can be exceeded when the per-tenant include-chain includes more than ~7 second-level vendor records, producing spf=permerror at the receiver-side — the DMARC-for-M365 spoke documents the M365-tenant SPF flattening discipline (sub-domain delegation, ESP consolidation, SPF-flattening services like scoutdns.com / powerdmarc.com) that ensures the per-tenant SPF byte-grammar publication stays under the §4.6.4 ceiling at every multi-vendor expansion event; (iv) per-tenant Feb 2024 Google/Yahoo bulk-sender SPF publication baseline as joint SPF-and- DMARC compliance gate — the Feb 2024 bulk-sender requirements enforce per-tenant SPF publication (the byte-grammar THIS page documents) AND per-tenant DMARC publication (p=none minimum) at the same compliance checkpoint for M365 tenants sending ≥5000 messages/day to Gmail/Yahoo recipients — the DMARC- for-M365 spoke documents the joint SPF-and-DMARC publication discipline that satisfies BOTH the per-author- domain SPF byte-grammar publication baseline AND the per-author-domain DMARC publication baseline at the same per-tenant rollout milestone. Read the DMARC-for-M365 spoke alongside this SPF byte-syntax pillar when the M365-tenant operator is designing the per-tenant apex SPF TXT record byte-grammar THIS page documents in service of the per-tenant DMARC SPF-aligned-pass cascade the M365 spoke's per-tenant DMARC publication discipline depends on.
• SPF for Google Workspace — the Google-Workspace-specific deployment guide. Includes the canonical apex SPF record syntax for Workspace tenants.
• Why SPF alone is insufficient — the four structural limitations of SPF that motivate the DMARC + DKIM + ARC additions. Syntactic correctness is necessary but not sufficient for spoofing protection.
• DKIM explained — the cryptographic-signing companion to SPF. DKIM records have their own TXT-record syntax that parallels SPF but uses different tag-value semantics.
• Email security glossary — the SPF-BYTE-SYNTAX-AND-MECHANISM- VOCABULARY-RESOLVES-TO-CROSS-CLUSTER-EMAIL- SECURITY-TERMINOLOGY-HUB companion to this SPF byte-syntax pillar. Where THIS page documents the RFC 7208 SPF-record TXT- record byte-syntax reference (the v=spf1 version-stamp, the seven §5 mechanism tokens, the four §4.6.2 qualifier prefixes, the §4.6.4 ten-DNS-lookup cap, the §3.3 255-octet character-string concatenation, the all-mechanism terminal- qualifier discipline), the email-security- glossary spoke is the cross-cluster TERMINOLOGY-RESOLUTION reference whose per-term canonical definitions establish the shared vocabulary every SPF-record authoring and verification discussion structurally depends on at FOUR per-term vocabulary-resolution dimensions: (i) per-term envelope-vs-header vocabulary canonical-definition reference — the glossary resolves the envelope-MAIL-FROM-vs- header-From-vs-return-path vocabulary distinction without per-page re-definition; per-publisher operator audit of per- publisher per-source-IP SPF-aligned-pass- rate evidence depends on consistent per- term envelope-vs-header semantic boundary across every sibling SPF / DMARC / forwarding spoke; (ii) per-term SPF-mechanism-vocabulary canonical- definition reference — the glossary resolves per-mechanism vocabulary (include, a, mx, ptr, exists, ip4, ip6, all) and per-qualifier-prefix vocabulary (+, -, ~, ?) so per-publisher operator cross-page reasoning preserves per-term RFC 7208 §5 semantics across every sibling SPF authoring / debugging / forwarding spoke; (iii) per-term SPF-evaluation-result-code vocabulary canonical-definition reference — the glossary resolves per-result-code vocabulary (pass, fail, softfail, neutral, permerror, temperror, none) per RFC 7208 §2.6 so per-publisher operator per- receiver per-day per-row evidence-decode preserves per-result-code semantics across every sibling DMARC-aggregate-report-decode / SPF-troubleshooting spoke; (iv) per-term SPF-publication-discipline operator-vocabulary canonical-definition reference — the glossary resolves per-publisher per-DNS-record SPF- publication-discipline vocabulary (single- record-per-domain invariant, ten-DNS- lookup cap, flattening, include-cascade, per-include-zone temperror cascade, terminal-qualifier commitment) so per- publisher operator per-zone publication- discipline preserves per-term invariant semantics across every sibling SPF- mechanism / lookup-limit / forwarding- issue spoke.
• DKIM DNS record syntax (RFC 6376 §3.6.2) — the DKIM-side BYTE-SYNTAX SIBLING of this SPF byte-syntax page. Where this page documents the RFC 7208 TXT-record encoding rules for the SPF policy record at the apex (v=spf1 …mechanisms… all, single-record-per-domain, ten-DNS-lookup cap, 255-octet character-string chunking, the seven qualifier+mechanism+modifier token grammar), the DKIM-DNS-syntax page documents the RFC 6376 §3.6.2 TXT-record encoding rules for the DKIM KEY record at the per-selector subdomain (v=DKIM1; k=rsa; p=<base64>; h=sha256; t=y; s=email tag-value list, published at <selector>._domainkey.<domain>). The two record formats share three DNS-publication conventions — (i) both require a case-sensitive v= version-tag preamble (v=spf1 vs v=DKIM1; both case- sensitive at the value but the SPF version is lowercase per RFC 7208 §4.5 while the DKIM version is uppercase per RFC 6376 §3.6.1 — a structural divergence operators routinely confuse), (ii) both inherit the RFC 1035 §3.3.14 255-octet character-string concatenation rule (a 2048-bit RSA DKIM public key exceeds 255 characters, a long SPF record with many include: tokens often does too, both MUST be split into multiple quoted strings in the zone file), (iii) both fail with permerror at the receiver under the same publication- defect classes (multiple records at the same DNS name, unquoted strings, mismatched quoting). The two record formats diverge structurally on three major axes — (i) SPF uses a SPACE-separated token list (mechanisms and modifiers separated by whitespace), DKIM uses a SEMICOLON-separated tag-value list (closer to DMARC's syntax), (ii) SPF's authoritative DNS name is the DOMAIN APEX (example.com TXT), DKIM's is the PER-SELECTOR SUBDOMAIN (selector._domainkey.example.com TXT), so DKIM admits arbitrarily many keys per domain via the selector hierarchy whereas SPF tolerates only one record per domain (the single-SPF-record permerror rule of RFC 7208 §4.5), (iii) SPF's payload is TEXTUAL TOKEN STRINGS the receiver evaluates at message-receipt time, DKIM's payload is OPAQUE BASE64 CRYPTOGRAPHIC KEY MATERIAL the receiver consumes only to verify the message's DKIM signature. Read both pages together when standing up the full SPF + DKIM + DMARC trinity DNS publication — the byte-syntax discipline operators apply to one record transfers verbatim to the other (character-string chunking, quoting discipline, TTL planning, single-source- of-truth publication-mechanism choice between zone-file vs DNS-API), even though the token-grammar layers above diverge.
• DKIM-Signature header anatomy (RFC 6376 §3.5) — the PER-MESSAGE-IN-TRANSIT BYTE-SHAPE COMPANION to this DNS-published-record byte-syntax reference, completing the publish-side vs verify-side DKIM byte- grammar pair. Where THIS page documents the RFC 7208 SPF TXT-record encoding rules published statically at the apex zone (a DNS-PUBLISHED byte-grammar the receiver FETCHES from authoritative DNS at SMTP evaluation time), the DKIM-Signatures- explained spoke documents the RFC 6376 §3.5 DKIM-Signature HEADER FIELD byte- grammar the signing MTA EMITS on every outbound message in transit (a PER- MESSAGE-DYNAMICALLY-GENERATED byte-grammar the receiver PARSES out of the message header for verification). The two byte- grammars pair across the SPF-record vs DKIM-Signature-header receive-side verification stack on FOUR cross-cluster dimensions: (i) publish-side vs in-transit-emission complementarity — SPF publishes the apex-zone TXT record ONCE (per zone-edit operation) and receivers fetch it many times per SMTP session, while DKIM emits a fresh DKIM-Signature header on EVERY outbound message and receivers parse it from the message header itself with no DNS round- trip for the signature data; (ii) tag-grammar parallel — DKIM-Signature header uses a SEMICOLON- separated tag-value list closely resembling the DKIM-key DNS-record tag- grammar this page's sibling help_dkim_dns_syntax.php documents (v=, a=, c=, d=, s=, h=, b=, bh=, t=, x= tags) — distinct from SPF's SPACE-separated token-list grammar this page documents, but operators authoring both record types benefit from understanding the parallel structure; (iii) publish-side-verify-side coordination contract — the DKIM-Signature header's d= and s= tags reference back to the DKIM-key DNS record that the DKIM-DNS-syntax sibling documents — a single-message signature is verifiable only if BOTH byte-grammars (publish-side DNS record + in-transit signature header) are correctly authored AND the values cross-reference; (iv) shared per-octet 255-character constraint domain — both the DKIM-key DNS record (RFC 1035 §3.3.14 255-octet character-string concatenation rule the long base64-encoded public-key value forces splitting under) AND the DKIM- Signature header's b= / bh= base64-encoded signature + body-hash tags share the same long- encoded-value byte-shape constraint domain, even though the DKIM-Signature header itself uses RFC 5322 message-header line folding for long values rather than DNS's string- concatenation rule. Read the DKIM- Signatures-explained spoke as the completing third leg of the DKIM-byte- grammar triangle (DKIM-key DNS record, DKIM-Signature header, SPF DNS record) — the three byte-grammars operate in concert across the publish-side and verify-side stages of the receiver's per-message authentication evaluation pipeline.
• MTA-STS policy-file byte syntax (RFC 8461 §3.2 policy-file grammar) — the TRANSPORT-SECURITY-POLICY-FILE-BYTE-SYNTAX-SIBLING-OF-THE-APEX-DOMAIN-SPF-TXT-RECORD-BYTE-SYNTAX companion documenting the per-field byte-level grammar (version: STSv1 / mode: enforce|testing|none / mx: <hostname> / max_age: <seconds>) of the MTA-STS policy file served at https://mta-sts.<domain>/.well-known/mta-sts.txt, completing the cross-protocol publication-byte- discipline parallel triangle alongside this SPF DNS byte-syntax page AND the DKIM / TLS-RPT byte-syntax siblings, across FOUR cross-protocol publication-byte-discipline parallel dimensions: (1) SPF TXT-record per-string 255-byte-limit chunk-split discipline vs MTA-STS policy-file HTTPS-served byte-stream contract parallel — both protocols face publication-byte-correctness gates at the publication-channel boundary: SPF at the DNS TXT-record per-string 255-byte limit (RFC 1035 §3.3.14 chunk-split discipline), MTA-STS at the HTTPS-served policy-file line-ending discipline (LF-only per RFC 8461 §3.2 — CRLF produces parse failure); both bytes-publication contracts are receiver- verified at the verifier-side fetch step; (2) SPF v=spf1 6-byte literal prefix vs MTA-STS version: STSv1 14-byte literal prefix as version-discriminator parallel — both protocols open their publication-byte- stream with a fixed version-literal that verifier-side parsers MUST match exactly to proceed; missing/malformed version prefix causes RFC-7208 (SPF) treats the whole TXT-record as non-SPF (skipped), RFC 8461 treats the whole policy-file as malformed (defaults to opportunistic-TLS); both version-byte-disciplines are load-bearing prerequisites; (3) SPF redirect=/include: cascade byte-vocabulary vs MTA-STS mx:-list byte-enumeration parallel — both protocols publish a per-policy enumeration of byte-tokens that determine receiver-side identity-resolution: SPF include: publishes the cascade-target domain-name string for per-include recursive evaluation, MTA-STS mx: publishes the canonical MX hostname string for per-MX TLS-enforcement decision; both are byte-exact identity anchors and both reject byte-formatting whitespace/case-divergence at the verifier; (4) SPF all-mechanism qualifier byte-token vs MTA-STS mode:-field byte-token as policy-strictness control parallel — both protocols expose a single byte-level control-token that determines policy-strictness at the verifier: SPF -all / ~all / ?all / +all (hardfail / softfail / neutral / pass-by-default), MTA-STS mode: enforce / mode: testing / mode: none (block-on-failure / report-only / disabled); both byte-tokens are the load-bearing publication-discipline control surface for ramp-to-enforce workflows. Byte-syntax correctness across these four cross-protocol publication-byte-discipline parallels is the load-bearing prerequisite for the cross-protocol DNS-published vs HTTPS-published publication-byte-correctness posture the apex-domain operator commits to at the SPF + MTA-STS co-deployment boundary.
• TLS-RPT record syntax — the TRANSPORT-SECURITY-CLUSTER BYTE- SYNTAX SIBLING of this SPF byte-syntax page, completing the cross-protocol DNS- record-byte-grammar reference triangle alongside the DKIM-DNS-syntax sibling above. Where this page documents the RFC 7208 TXT-record encoding rules for the SPF policy record at the APEX-domain owner-name (example.com IN TXT "v=spf1 …mechanisms… all", single-record- per-domain rule per RFC 7208 §3.1, the 10-DNS-lookup cap per §4.6.4, the 255-octet character-string chunking rule per RFC 1035 §3.3.14, the seven qualifier+mechanism+modifier token grammar per RFC 7208 §5-6, and the v=spf1 version-tag first- position requirement per §4.5), the TLS-RPT-record-syntax page documents the RFC 8460 §3 TXT-record encoding rules for the TLS-RPT publisher-side record at the _smtp._tls.<domain> underscore-prefixed sub-owner-name — a DELIBERATELY parallel byte-grammar choice the RFC 8460 designers made to ease operator adoption (the v=TLSRPTv1; rua=mailto:... tag-grammar shape mirrors DMARC and TLS-RPT shares the same first-position version-tag rule, the same comma-separated URI-list semantics for rua=, and the same external-domain-authorisation reciprocal publication requirement). The two records sit at DIFFERENT owner-names (SPF at apex, TLS-RPT at _smtp._tls. sub-name) and govern DIFFERENT authentication layers (SPF = sender-side envelope-IP- authorisation; TLS-RPT = receiver-side transport-encryption-reporting) but share the underlying DNS-record-grammar conventions (RFC 1035 §3.3.14 TXT encoding, 255-octet chunking, A-label encoding for international domains, the single-source-of-truth publication- mechanism choice between zone-file vs DNS-API). Operators routinely co-publish the SPF apex record documented on this page with the TLS-RPT record documented on the sibling spoke as part of a single DNS-record deployment workflow — the byte-grammar conventions transfer directly between the two records even though the token-grammar layers above diverge.
• TLS-RPT report format — the TRANSPORT-SECURITY-CLUSTER AGGREGATE-REPORT-SCHEMA SIBLING of this SPF DNS-byte-syntax page, completing the TLS-RPT publication-discipline reference pair started by the TLS-RPT-record-syntax sibling above. Where THIS page documents the RFC 7208 TXT-record encoding rules for the SPF policy record at the APEX- domain owner-name (single-record-per- domain rule per §3.1, 255-octet character- string chunking rule per RFC 1035 §3.3.14, the seven qualifier+mechanism+modifier token grammar per §5-6, and the v=spf1 version-tag first- position requirement per §4.5), the TLS-RPT-report-format spoke documents the RFC 8460 §4 JSON aggregate-report schema (the receiver-emitted per- publisher per-domain JSON document with organization-name, contact-info, report- id, date-range, policies array, per-policy-type success/failure counts, per-failure-type detail blocks) — a DELIBERATELY parallel publication- discipline reference structure to the DMARC aggregate-report XML schema that DMARC operators are already familiar with. FOUR cross-protocol publication- discipline-and-aggregate-evidence-stream downstream-consumer dimensions the spoke documents that THIS SPF-DNS-syntax page parallels at the byte-grammar level: (i) per-publisher per-domain JSON- report aggregate-evidence stream AS STRUCTURALLY-DOWNSTREAM CONSUMER of the per-publisher per-domain TLS-RPT TXT- record publication discipline — the JSON-report schema THIS spoke documents is the per-publisher per-domain aggregate-evidence stream the per-domain _smtp._tls.<d> TXT-record (the TLS-RPT-record-syntax sibling) operationally produces; (ii) per-publisher per-domain TLS-RPT JSON-report consumer-side ingestion pipeline as PARALLEL-INFRASTRUCTURE to DMARC aggregate-XML consumer-side ingestion pipeline — operators operating a DMARC RUA ingestion pipeline routinely extend the same pipeline to ingest TLS-RPT JSON reports, leveraging the parallel-publication-discipline structure THIS page's SPF-DNS-syntax pillar belongs to; (iii) per- publisher per-domain per-failure-type TLS-RPT detail-block as STRUCTURALLY- DOWNSTREAM CONSUMER of the per-MX-host TLS-handshake-failure observability primitive — the TLS-RPT report- format spoke documents the per-failure- type detail-block schema covering starttls-not-supported / certificate- host-mismatch / validation-failure / sts-policy-fetch-error / sts-policy- invalid / sts-webpki-invalid; (iv) per-publisher per-domain TLS-RPT report-cadence as PARALLEL-CADENCE to DMARC RUA report-cadence — the per-publisher per-domain TLS-RPT report- format spoke documents the per-receiver per-day cadence convention (RFC 8460 §4.4 receivers SHOULD emit one report per publisher per day) parallel to the DMARC RUA per-receiver per-day cadence the per-publisher operator coordinates receiving-end infrastructure for.
• DANE for SMTP (RFC 7672) explained - the TRANSPORT-SECURITY-CLUSTER DNS-RR- BYTE-SYNTAX SIBLING of this SPF DNS-byte- syntax page, extending the cross-protocol DNS-record-byte-grammar reference triangle established by the DKIM-DNS-syntax and TLS-RPT-record-syntax siblings above to the DANE protocol layer. Where THIS page documents the RFC 7208 TXT-record encoding rules for the SPF policy record at the APEX-domain owner-name (single-record-per- domain rule per §3.1, 10-DNS-lookup cap per §4.6.4, 255-octet character-string chunking rule per RFC 1035 §3.3.14, the seven qualifier+mechanism+modifier token grammar per §5-6, and the v=spf1 version-tag first- position requirement per §4.5), the dedicated DANE deep-dive documents the RFC 7672 / RFC 6698 TLSA-resource-record byte-level grammar at the _25._tcp.<mx-host> underscore-prefixed sub-owner-name - a STRUCTURALLY-DISTINCT byte-grammar choice whose four-field record layout differs from the TXT-record-based byte grammar of every other email-authentication record. The four-axis SPF-TXT-VS-DANE-TLSA comparison exposes the structurally-distinct CROSS-PROTOCOL-DNS-RR-PUBLICATION-BYTE- DISCIPLINE parallels: (i) SPF publishes a TXT record at the apex owner-name with text-based byte syntax, whereas DANE publishes a TLSA record (RR-type code 52, IANA-registered DNS RR type) at the _25._tcp.<mx-host> sub-owner-name with a structured binary 4-field byte layout (1 octet usage + 1 octet selector + 1 octet matching-type + variable-length cert-association-data) - the underlying RR-type difference between RFC 1035 §3.3.14 TXT and RFC 6698 §2 TLSA is the canonical byte-syntax distinction the cross-protocol byte- grammar reference triangle now extends to; (ii) SPF byte- publication is a SINGLE-STRING (with 255-octet chunking per RFC 1035 §3.3.14), whereas DANE TLSA publication routinely publishes MULTIPLE TLSA records at the SAME owner-name to cover the cert-rotation overlap window per RFC 7671 §8 - the single-RR-per-owner-name vs multi-RR-per- owner-name byte-publication discipline diverges structurally between SPF and DANE at the same byte-grammar layer; (iii) SPF byte-encoding choices (255-octet chunking, escape-quoting rules, A-label encoding for internationalised owner-names) apply at the TXT-record byte layer ONLY, whereas DANE byte-encoding choices (cert-association-data field binary encoding for SHA-256/SHA-512 hashes per §2.1.3) operate on the TLSA- record's binary cert-association-data field rather than text-encoded characters - the byte-encoding primitive differs between text-based TXT and binary-structured TLSA at the per-record-field layer; and (iv) SPF publication produces a SENDER-SIDE envelope-IP-authorisation surface visible to receivers performing envelope MAIL FROM evaluation, whereas DANE publication produces a RECEIVER-SIDE-OF-OUTBOUND-SMTP transport- security commitment surface visible to any SMTP client connecting to the publisher's MX hosts - the publication-side-vs-consumption-side directional flow diverges structurally between the two records' downstream consumption populations. Operators routinely co-publish the SPF apex record documented on THIS page with the DANE TLSA records documented on the sibling spoke as part of a single transport- security + sender-authentication co-deployment workflow - the byte-grammar conventions transfer between the two records' DNS-RR layers (zone-file vs DNS- API publication mechanism, the same A-label encoding for internationalised owner-names, the same TTL-bounded propagation model) even though the per-record byte-layout diverges structurally between text TXT and binary TLSA. Read the dedicated DANE deep-dive alongside this SPF byte-syntax page when scoping the cross-protocol DNS-RR publication discipline for a DANE-enabled email-authentication deployment - the spoke is the authoritative RFC 7672 / RFC 6698 TLSA-record-byte- grammar reference whose four-field record layout this SPF byte-syntax page is the cross-protocol byte-publication-discipline companion for.
• Reverse DNS / PTR records for mail servers — the REVERSE-ZONE DNS-INFRASTRUCTURE sibling of this SPF forward-zone DNS-byte- syntax page. Where this page documents the RFC 7208 TXT-record syntax for the forward-zone example.com IN TXT "v=spf1 …" policy publication (sender-side IP-authorisation enumeration), the reverse-dns-ptr spoke documents the RFC 1033 / RFC 1035 PTR-record syntax for the reverse-zone 1.2.3.4.in-addr.arpa IN PTR mail.example.com. publication (receiver-side IP-to-hostname resolution). The two records form the BIDIRECTIONAL DNS-INFRASTRUCTURE PAIR for any mail- sending IP: the SPF forward-zone record documented on this page DECLARES which IPs are authorised to send for the domain; the PTR reverse-zone record documented on the sibling spoke ANNOUNCES which hostname an IP claims, which the receiver-side forward-confirmed reverse DNS (FCrDNS) check then VERIFIES by resolving the PTR hostname back to an A/AAAA matching the connecting IP. SPF's deprecated ptr mechanism (RFC 7208 §5.5 — "SHOULD NOT BE PUBLISHED in new records") historically chained these two DNS classes at the policy-evaluation layer. Modern operators reading this SPF byte-syntax page when scoping the deployment of a new sending IP need the reverse-dns-ptr spoke as the OPERATOR- CHECKLIST companion — because every IP enumerated in the v=spf1 …mechanisms… all record on this page MUST also have a matching PTR-and-FCrDNS pair published in the corresponding in-addr.arpa / ip6.arpa reverse-zone, or the IP will fail the receiver-side FCrDNS check that Gmail / Outlook.com / Yahoo / iCloud / Apple Mail apply BEFORE the SPF check runs — the FCrDNS-fail gate is enforced INSTEAD of and BEFORE the SPF-fail gate on those receivers, so an IP that PASSES this page's SPF byte-syntax can still fail the receiver- side reputation gate purely on missing PTR. The reverse-dns-ptr spoke is the AUTHORITATIVE DNS-INFRASTRUCTURE REFERENCE for the operator workflow every IP enumerated on this page is subject to.
• MX records explained — the MX-DNS-RR-CLASS-AS-SPF-mx-MECHANISM- IP-RESOLUTION-INPUT companion to this SPF forward-zone DNS-byte-syntax reference, and the structurally-parallel DNS-RR-CLASS-LAYER sibling to the reverse-dns-ptr spoke listed adjacent. Where THIS page documents the forward-zone TXT-record byte-grammar for the v=spf1 …mechanisms… all SPF policy publication (the 255-octet character- string boundary, multi-string concatenation, v=spf1 version-token floor, the nine RFC 7208 §5 mechanism tokens — all / include: / a[:] / mx[:] / ptr[:] / exists: / ip4: / ip6: / redirect= / exp=), the mx-records spoke documents the RFC 1035 §3.3.9 MX resource-record syntax for the parallel example.com IN MX 10 mail.example.com. publication that the SPF mx mechanism (RFC 7208 §5.4) DEREFERENCES at policy-evaluation time. The mx mechanism is structurally distinct from the other SPF mechanism tokens documented on this page: where ip4: / ip6: enumerate IPs by literal value, a[:] dereferences a single A/AAAA record at the named hostname, and include: recurses into another domain's SPF policy, the mx mechanism uniquely dereferences the policy-publishing domain's MX RRset, then for EACH MX hostname dereferences THAT hostname's A/AAAA RRset, consuming up to 1+N DNS queries against the SPF policy's 10-DNS-lookup limit (RFC 7208 §4.6.4) per the lookup-limit spoke. The mx-records spoke documents the MX priority-byte field (16-bit unsigned integer, lower-priority MXs preferred per RFC 5321 §5.1), the MX-record-target FQDN that the SPF policy mx mechanism resolves through, the 255-byte DNS-label encoding constraint shared with the TXT-record syntax this page documents, the MX-RRset multi-record cardinality (multiple MX RRs at the same priority for load distribution), and the "null MX" pattern (example.com IN MX 0 . per RFC 7505) declaring the domain accepts no mail — a configuration that interacts with the SPF mx mechanism's behaviour on policy-publishing domains that themselves receive no mail. Read the mx-records spoke alongside this SPF byte-syntax page when authoring an SPF policy that uses the mx mechanism: the policy documented on this page references the MX RRset documented on the sibling spoke at every receiver-side policy-evaluation, and a broken or reorganised MX RRset silently re-authorises or de-authorises the IP set the SPF policy effectively publishes without any byte change to the SPF TXT record itself.
• DNS propagation explained — the SPF-TXT-RECORD-CHANGE-PROPAGATION- WINDOW-FOR-ENVELOPE-MAIL-FROM-EVALUATION companion reference. Where THIS page documents the byte-level SPF TXT publication grammar (the v=spf1 version-token floor, the 255-octet character-string chunking rule, mechanism / qualifier / modifier token forms, the -all / ~all / ?all / +all tail token catastrophe matrix), the DNS-propagation spoke documents the STRUCTURAL TIMING-MODEL that governs WHEN the receiver-side SPF engine observes the operator's just-published byte change: every Internet receiver that runs an SPF evaluation against the operator's domain queries that domain's TXT records via the receiver's local recursive resolver, whose cache is bounded by the SPF TXT's TTL — typically 3600s on operator-controlled zones but frequently 86400s on legacy-defaulted zones. The implication: an operator who removes an unauthorised sender's ip4: mechanism from their SPF record (in response to a compromised partner / sub-account- takeover / ESP-cutover) continues to see SPF=pass verdicts for that IP at receivers whose recursive resolver cached the OLD SPF record prior to the change — for up to the record's TTL — which means the compromised-partner mitigation DOES NOT TAKE EFFECT instantly across the receiver population. Symmetrically, an operator who ADDS a new ESP include: to authorise an outbound launch from a new sending platform will see the new platform's mail flagged SPF=fail or SPF=softfail at any receiver whose resolver cached the OLD (smaller) SPF record before the publication. The DNS-propagation spoke's email-auth-TTL recommendations (3600s for stable SPF records, 300s for records being actively modified during cutover events, with explicit guidance to pre-shorten the TTL 24-48 hours before any planned SPF change so the propagation window matches the operational cutover window) are the canonical operator-side framework for sizing the cutover window AGAINST the TTL-bounded resolver-cache aging model. The operator-verification workflow on the propagation spoke (dig +trace, dig +nocache, multi-resolver cross-checks via Google Public DNS / Cloudflare / Quad9) is the canonical post-publication audit pattern for confirming the new SPF record has propagated to the major receiver- side resolver populations. Read the DNS-propagation spoke alongside this page when scoping any SPF record modification — a syntactically- correct SPF change published at a long-TTL record value has hours-to- days of stale-cache lag before receivers consistently see the new authorisation surface, and the TTL-tuning playbook the propagation spoke documents is the gating control for compressing that lag to operational-cutover-friendly durations.
• DMARC alignment explained — the identifier-alignment deep dive. DMARC alignment depends on the SPF-authenticated MAIL FROM domain matching the From: header domain — independent of how the SPF record is encoded at the DNS layer.
• DMARC policy modes — the p=none / p=quarantine / p=reject ladder. Pair SPF -all with DMARC p=reject for the strongest enforcement.
• DMARC record tags explained — the DMARC tag-by-tag reference. DMARC consumes SPF as one of its two underlying authentication mechanisms.
• Email authentication ecosystem — the cluster-intro pillar surveying SPF + DKIM + DMARC + BIMI + MTA-STS + TLS-RPT + CAA + ARC interlocking.
• Email authentication glossary — the term-of-art reference covering character -string, TXT record, octet, A-label, U-label, Punycode, and every other DNS-syntax vocabulary item this page uses.
• DMARC for shared hosting — the SPF-DNS-BYTE-SYNTAX-AT-SHARED-HOSTING- CONTROL-PANEL-OPERATOR-EMPOWERMENT-CEILING companion to this RFC 7208 §3 SPF byte- publication grammar reference. Where THIS page documents the canonical SPF TXT-record byte-level publication rules (single-record rule per RFC 7208 §3.2, the 255-byte character-string boundary per RFC 1035 §3.3.14, the multi-string continuation concatenation semantics, the v=spf1 version-prefix requirement, the trailing-qualifier -all / ~all / ?all / +all publication discipline), the shared- hosting spoke is the per-provider deployment companion documenting FOUR shared-hosting-SPF-publication-constraint dimensions: (i) cPanel / Plesk / DirectAdmin SPF-record-editor UI as the OPERATOR-EMPOWERMENT-CEILING — many shared-hosting control panels truncate SPF records at 255 bytes WITHOUT presenting the multi-string continuation option, silently capping the operator's ability to author records beyond the single-character-string ceiling — the shared-hosting spoke documents the canonical operator failure pattern where the operator authors a 280-byte SPF record in the cPanel editor and the editor silently truncates at 255 bytes, leaving a record that's grammatically valid but semantically incomplete; the per-provider workaround discipline (request DNS-record-source-edit access, switch to a dedicated DNS provider, flatten the SPF record below the 255- byte ceiling, or split into multiple character-strings via an explicit DNS-record-source-edit interface); (ii) shared-hosting-provider- default SPF record COLLIDES with operator-authored additions — the provider publishes a default v=spf1 +a +mx +ip4:<provider-MTA-pool> ~all record that conflicts with the operator's intent to publish a stricter record (e.g., the operator's mail flows through a third-party ESP) — the shared-hosting spoke documents the operationally-significant per- provider override pattern (cPanel "Email Routing" → "Custom MX" → "Edit Authentication" disables the default SPF / DKIM / DMARC autopilot; Plesk "Mail Server Settings" → "Outgoing Mail Mode" → "Forwarded" + per-domain SPF override; DirectAdmin per-account SPF override via the "Edit DNS Zone" admin-tier escalation) and the canonical operator mistake where the operator publishes a stricter operator-authored record at the apex but the provider's autopilot RE-WRITES the record on the next provider-side config-deployment cycle; (iii) shared-hosting tenants typically cannot rotate SPF records on operator- controlled timing — the per-record TTL is provider-managed, not operator- managed, so the per-stream propagation window operators in dedicated-DNS environments control directly is gated by the shared-hosting provider's zone-publish cadence — the shared-hosting spoke documents the canonical operator-side delivery- SLA-vs-DNS-propagation-window coordination point at the shared- hosting boundary (shared-hosting operators publishing SPF for migration- critical or incident-response cycles face a 24-72-hour fixed propagation window the operator cannot shorten below the provider's default TTL ceiling); (iv) shared-hosting SPF-record per-subdomain-tree publication discipline at the OPERATOR-EMPOWERMENT-FLOOR — many shared-hosting control panels only expose APEX-LEVEL SPF editing, making per-subdomain SPF publication (e.g., mail.example.com SPF record distinct from example.com SPF record) operationally impossible without escalating to DNS-zone-source access — the shared-hosting spoke documents the canonical operator-side limitation on per-subdomain stream-isolation operators in dedicated-DNS environments use as the FIRST-LINE defence against cross-stream SPF-record bloat (the publish-marketing-stream-on-dedicated- subdomain pattern), and the per- provider escalation paths that unlock per-subdomain SPF editing at the shared-hosting boundary. Read the shared-hosting spoke when authoring SPF records on a cPanel / Plesk / DirectAdmin tenant — the spoke is the authoritative per-provider operational reference for the SPF- DNS-byte-syntax-meets-shared-hosting- control-panel-operator-empowerment- ceiling cross-cluster boundary.
• DMARC for cPanel hosts — the SHARED-HOSTING-CPANEL-PER-ACCOUNT- DEPLOYMENT-AS-LOAD-BEARING-EXECUTION- LAYER-CONSUMER-OF-EVERY-RFC-7208-SPF-V- EQUAL-SPF1-TXT-RR-BYTE-SYNTAX-PRIMITIVE- THIS-PILLAR-ESTABLISHES companion to this SPF-DNS-record-syntax pillar. Where THIS page architectures the RFC 7208 §3 SPF TXT-RR byte-syntax primitives (the version-tag v=spf1, the per-domain mechanism-list cardinality rule, the 255-octet character-string- fragmentation discipline, the per- subdomain SPF coverage discipline, the IDN A-label encoding discipline), the DMARC-for-cPanel spoke is the shared- hosting per-tenant execution-layer deployment-reference documenting how cPanel-per-account SPF publishing instantiates every SPF-DNS-byte-syntax primitive at FOUR per-cPanel-tenant-to- SPF-DNS-byte-syntax-primitive-coupling dimensions: (i) cPanel-per- account v=spf1 version-tag publication as the per-tenant instantiation of the RFC 7208 §3.1 version-tag publication primitive — the cPanel Email Deliverability default publishes the per-tenant v=spf1 a mx include:_spf... ~all TXT-RR at the tenant- domain apex via the cPanel DNS Zone Editor — the DMARC-for-cPanel spoke documents this per-tenant v=spf1 publication discipline as the execution-layer instantiation of THIS page's RFC 7208 §3.1 version-tag publication primitive; (ii) cPanel-per-account single-SPF-record cardinality as the per-tenant instantiation of the RFC 7208 §3.2 mechanism-list cardinality rule — the cPanel Email Deliverability interface enforces ONE v=spf1 TXT-RR per tenant- domain scope, with operator-guard rails preventing accidental duplicate v=spf1 records that would cause receiver-side permerror — the DMARC-for-cPanel spoke documents this per-tenant single-record-cardinality discipline as the execution-layer instantiation of THIS page's RFC 7208 §3.2 mechanism-list cardinality primitive; (iii) cPanel-per-account include: cascade publication as the per-tenant instantiation of the RFC 7208 §5.2 include: mechanism — the cPanel Email Deliverability default publishes the per-tenant include:_spf.<cpanel-host> mechanism that delegates the egress- IP-block enumeration to the cPanel- host-operator's authoritative _spf.<cpanel-host> publication — the DMARC-for- cPanel spoke documents this per-tenant include:-cascade publication discipline as the execution-layer instantiation of THIS page's RFC 7208 §5.2 include: mechanism primitive; (iv) cPanel-per- account per-subdomain SPF coverage as the per-tenant instantiation of the RFC 7208 §3.1 per-subdomain SPF publication discipline — the cPanel DNS Zone Editor allows per-tenant publication of subdomain-specific v=spf1 TXT-RRs (e.g. shop.<tenant-d> publishing its own v=spf1 include:ESP -all whose receiver-side per-subdomain SPF evaluation is scope-isolated from the tenant-domain-apex publication) — the DMARC-for-cPanel spoke documents this per-tenant per-subdomain SPF- coverage publication discipline as the execution-layer instantiation of THIS page's RFC 7208 §3.1 per-subdomain publication primitive. Read the DMARC- for-cPanel spoke alongside this SPF- DNS-record-syntax pillar when deploying SPF on a shared-hosting cPanel infrastructure — the spoke documents how every SPF-DNS-byte-syntax primitive THIS page architects instantiates concretely on the cPanel / WHM shared- hosting deployment architecture.
• DMARC policy rollout — the SPF-DNS-RECORD-BYTE-SYNTAX-AS- LOAD-BEARING-PHASE-1-PUBLICATION- BASELINE-PREREQUISITE companion to this SPF TXT-record byte-syntax reference. Where THIS page documents the RFC 7208 §3 SPF-TXT-record byte- level publication grammar at the apex- domain owner-name (the v=spf1 first-position version tag, the mechanism token-list with ip4: / ip6: / a / mx / include: / ptr / exists / all qualifiers, the single-record-per-domain rule per RFC 7208 §3.2, the 255-octet character- string chunking per RFC 1035 §3.3.14, the 10-DNS-lookup mechanism budget per RFC 7208 §4.6.4, the redirect= and exp= modifier semantics), the DMARC- policy-rollout spoke documents the per-publisher five-phase deployment workflow whose every per-pct=-ramp- stage advancement and per-phase cutover gate depends on the SPF-TXT- record byte-syntax-publication- discipline floor at FOUR per-SPF-byte- shape-publication-discipline-to-DMARC- policy-rollout coupling dimensions: (i) Phase-1 SPF-TXT-record- publication-baseline as load-bearing receiver-side spf=pass-verdict- availability prerequisite — the Phase-1 publication-baseline floor REQUIRES the RFC 7208 §3 byte-shape THIS page documents (correct v=spf1 first-position tag, valid mechanism token-list, single- record-per-domain compliance, valid 255-octet character-string chunking, mechanism-budget under the 10-DNS- lookup ceiling, terminal all-qualifier well-formed) for the receiver-side spf=pass verdict to be emitted in the FIRST place — any byte- shape defect THIS page enumerates (truncated chunking, malformed mechanism token, missing v=spf1 prefix, multiple- SPF-record violation, 10-DNS-lookup- budget breach causing spf=permerror) collapses the entire Phase-1 publication- baseline to spf=permerror / spf=temperror / spf=fail and blocks every downstream phase from advancing; (ii) Phase-2 p=none baseline- observability SPF-aligned-pass-rate- floor enforcement as per-source-IP per-receiver per-day rua aggregate-XML row/policy_evaluated/spf=pass AND row/auth_results/spf/result=pass row-count input — the Phase-2 observability baseline REQUIRES the SPF-TXT-record publication-discipline floor THIS page documents to be in place across every per-publisher per- domain per-sending-IP deployment before advancing into Phase-3 — the per- source-IP per-receiver per-day rua aggregate-XML row/policy_evaluated/spf=pass row-count distribution alongside the row/auth_results/spf/domain= envelope-MAIL-FROM-attribution evidence is the gate-keeping observability surface that confirms the per-publisher per-domain SPF-byte-shape-publication- discipline is reliably translating into receiver-side spf=pass verdicts at the floor required for Phase-3 advancement; (iii) Phase-3 pct=-ramp per- stage advancement gate-keeping SPF- aligned-pass-rate-floor enforcement as per-ramp-stage-cutover-confidence input — every Phase-3 per- stage advancement (pct=10 → pct=25 → pct=50 → pct=75 → pct=100) REQUIRES the SPF- aligned-pass-rate floor to remain stable across the per-publisher per- domain per-sending-IP deployment; any per-stage SPF-aligned-pass-rate regression caused by a byte-shape publication-discipline drift THIS page enumerates (include:-cascade-mechanism- budget-creep above the 10-DNS-lookup ceiling, multiple-SPF-record-merge violation introduced by a third-party sender onboarding, terminal-all- qualifier-flip from ~all to +all, chunking- truncation regression) must be remediated BEFORE advancing the per- stage cutover; (iv) Phase-4- p=quarantine and Phase-5-p=reject cutover-confidence floor as per- receiver per-source-IP SPF-aligned- pass-rate-coverage-completeness prerequisite — the terminal- state Phase-4-p=quarantine and Phase- 5-p=reject cutovers REQUIRE the SPF- TXT-record-publication-discipline floor THIS page documents to be in place across every per-publisher per-domain per-sending-IP per-receiver deployment with zero outstanding byte-shape publication-discipline defects — the terminal-state cutover is the point where any remaining SPF-byte-shape- publication-discipline drift translates directly into legitimate-mail-bounce- rate uplift, so the per-receiver per- source-IP SPF-aligned-pass-rate- coverage-completeness floor must be empirically confirmed via the rua aggregate-XML stream BEFORE the terminal-state cutover. Read the DMARC-policy-rollout spoke alongside THIS page when the publisher asks "how does the SPF-TXT-record byte- syntax-publication-discipline floor translate into the per-publisher five- phase DMARC-policy-rollout cadence" — the answer is FOUR-LAYERED: THIS page documents the RFC 7208 §3 SPF-TXT- record byte-syntax-publication- discipline floor, the DMARC-policy- rollout spoke documents the per- publisher five-phase deployment workflow whose every per-pct=-ramp- stage advancement and per-phase cutover gate consumes the SPF-aligned- pass-rate floor THIS page's byte- syntax-publication-discipline underpins.
• CAA records explained — the sibling apex DNS-policy-record companion. SPF and CAA both publish at the domain apex as DNS-level policy records the operator publishes to constrain who can act on the domain's behalf — SPF (RFC 7208 TXT record) constrains which IPs may send mail FROM your domain; CAA (RFC 8659 CAA RR) constrains which Certificate Authorities may issue TLS certificates FOR your domain. Both records share the same apex-zone publication workflow (apex zone edit + TTL discipline + DNSSEC signing) and the same drift-resistance problem (silent regressions when zone owners change CAs or rotate sender infrastructure without updating the policy record). Read this CAA reference when expanding the SPF-byte-syntax zone-publication discipline to the TLS-cert-issuance authorisation surface the same operator owns.
• BIMI explained — the PER-PUBLISHER-PER-DOMAIN- DEFAULT._BIMI-TXT-RR-BYTE-GRAMMAR- PUBLICATION-DISCIPLINE-AS-STRUCTURAL- AUTHENTICATION-RECORD-BYTE-GRAMMAR- PUBLICATION-DISCIPLINE-COUSIN-OF-THE- PER-PUBLISHER-PER-DOMAIN-SPF-TXT-RR- BYTE-GRAMMAR-PUBLICATION-DISCIPLINE companion documenting the BIMI TXT-RR byte-grammar publication discipline (the per-publisher per-domain default._bimi.<domain> IN TXT "v=BIMI1; l=<logo-URL>; a=<VMC-URL>" per-record tag-list byte-grammar with the v=BIMI1 version-prefix-byte sequence + l= logo-URL operand + a= VMC-URL operand) whose four per-authentication- record-class byte-grammar publication- discipline parallel dimensions structurally PARALLEL the per- publisher per-domain SPF TXT-RR byte- grammar publication discipline THIS page documents at the per-publisher per-domain authoritative DNS zone boundary: (i) per-publisher- per-record-version-prefix-byte- sequence-as-load-bearing-protocol- magic-byte-sequence — both protocols mandate a per-record version- prefix-byte sequence at the per-record byte-grammar leading position (SPF: v=spf1 per RFC 7208 §4.5 leading 6-byte sequence; BIMI: v=BIMI1 per BIMI draft leading 7-byte sequence) that receiver-side parsers use as the per- record protocol-identifier MAGIC BYTE SEQUENCE distinguishing per-protocol records from per-record TXT-RR siblings sharing the same FQDN-target; per-publisher per-record version- prefix-byte sequence authoring defects (typo'd v=spf2 / v=BIMI2, missing v= tag, leading- whitespace-before-version-prefix) collapse per-receiver-side parser per- record identification at the per- record protocol-identifier MAGIC BYTE SEQUENCE boundary; (ii) per- publisher-per-record-FQDN-publication- boundary-vs-per-publisher-per-record- sub-owner-name-publication-boundary — SPF records publish at the per- publisher per-domain apex FQDN (<domain> owner-name per RFC 7208 §3.2); BIMI records publish at the per-publisher per- domain default._bimi.<domain> sub-owner-name per BIMI draft; both per-record FQDN-publication-boundary disciplines require per-publisher per- domain authoritative DNS zone-editor coordination at the per-record FQDN publication-event boundary; (iii) per-publisher-per-record-tag- list-byte-grammar-vs-per-publisher- per-record-mechanism-token-byte- grammar-as-cross-protocol-record- body-byte-grammar-discipline — BIMI records publish per-record tag- list byte-grammar (tag-name=tag-value; tag-name=tag-value semicolon-separated per-record tag- list); SPF records publish per-record mechanism-token-byte-grammar (qualifier-prefix-byte + mechanism-token + : + operand-byte- sequence space-separated per- record mechanism-list per RFC 7208 §4.6.1); both byte-grammar publication disciplines require per-publisher per- record per-token byte-correctness at the per-record byte-grammar publication boundary — per-publisher per-record per-token byte-grammar defects produce per-receiver-side parser permerror verdict on the per-record evaluation; (iv) per- publisher-per-domain-SPF-record-as- load-bearing-upstream-DKIM-aligned- pass-rate-floor-determinant-of-per- publisher-per-domain-BIMI-eligibility — BIMI logo-display eligibility at BIMI-consuming receivers is GATED on per-publisher per-domain DMARC enforcement at p=quarantine+ which is gated on per-publisher per-domain DMARC-aligned-pass-rate floor; per- publisher per-domain SPF TXT-RR byte- grammar publication discipline correctness THIS page documents IS the per-publisher per-domain SPF- aligned-pass-rate floor contributing primitive whose green-state baseline IS the per-publisher per-domain DMARC- aligned-pass-rate baseline IS the per- publisher per-domain BIMI logo-display eligibility prerequisite. Read THIS page when AUTHORING per-publisher per- domain SPF TXT-RR byte-grammar publication discipline; read the BIMI- explained spoke when EXTENDING the per-publisher per-domain authentication- record byte-grammar publication discipline to per-publisher per-domain BIMI logo-publication eligibility at the per-publisher per-domain default._bimi sub-owner-name boundary.
• MTA-STS explained — the per-publisher per-policy-domain transport-layer MTA-STS policy-publication- discipline companion to this SPF TXT- record byte-grammar reference. Where THIS page documents the RFC 7208 §3 per- publisher per-domain SPF TXT-record byte- syntax-publication discipline (the v=spf1 version-prefix-byte sequence, the 8 mechanism tokens include: / a: / mx: / ip4: / ip6: / ptr: / exists: / all, the 4 qualifier-prefix bytes, the 2 modifiers redirect= / exp=, the per-record TXT-RR byte-length budget, the single-record- per-owner-name rule, the per-character- string 255-byte chunk discipline), the MTA-STS-explained spoke is the PER- PUBLISHER-PER-POLICY-DOMAIN-TRANSPORT- LAYER-MTA-STS-POLICY-PUBLICATION reference documenting the RFC 8461 per- publisher per-policy-domain _mta-sts.<d> TXT-RR publication + HTTPS-policy-host file publication + per-policy-domain mode: enforce commit choice publication discipline at the per-hop transport-layer SMTP STARTTLS enforcement boundary. Four PER-PUBLICATION-DISCIPLINE coupling dimensions the MTA-STS-explained spoke documents: (i) per-publisher per-domain TXT-RR-byte-grammar publication-discipline parallel at distinct DNS-scope coordinates and protocol layers — both the per-publisher per-domain v=spf1 ... ~all TXT-RR at the per-domain owner-name (the envelope-layer per-message MAIL-FROM-domain IP- authorisation byte-grammar publication primitive THIS page documents) and the per-publisher per-policy-domain _mta-sts.<d> TXT-RR at the _mta-sts-prefixed sub-owner- name (the transport-layer per-hop policy- ID version-pointer byte-grammar publication primitive the spoke documents) are per-publisher per-domain TXT-RR-byte-grammar publication primitives at distinct per-publisher per-domain DNS-scope coordinates and distinct protocol layers; (ii) per-publisher per-domain single-record-per-owner-name publication discipline parallel at distinct sub- owner-name scopes — both the per-publisher per-domain RFC 7208 §3.2 single-SPF-record-per-owner-name rule THIS page documents (the per-publisher per-domain permerror-on-multiple-SPF- TXT-RR-publication failure-mode the per-receiver SPF evaluation enforces) and the per-publisher per-policy-domain RFC 8461 §3.1 single-MTA-STS-policy-ID- per-_mta-sts-sub-owner-name rule the spoke documents (the per-publisher per- policy-domain policy-fetch-error-on- multiple-_mta-sts-TXT-RR-publication failure-mode the per-receiver MTA-STS discovery enforces) are per-publisher per-domain single-record-per-owner-name publication-discipline primitives at distinct per-publisher per-domain sub-owner-name scopes; (iii) per-publisher per-domain DNS-publication-vs-HTTPS-publication scope-asymmetry parallel at distinct publication-primitive boundaries — the per-publisher per-domain SPF- TXT-RR publication discipline THIS page documents publishes the ENTIRE per- message authorisation contract in the per-publisher per-domain DNS-TXT-RR-byte- sequence (no HTTPS-side asset publication is required), while the per-publisher per-policy-domain MTA-STS-policy publication discipline the spoke documents publishes the per-policy- domain DNS-TXT-RR-byte-sequence (the version-pointer) PLUS a per-policy- domain HTTPS-published-policy-file (the actual per-policy-file byte-grammar) — the per-publisher per-domain dual- publication discipline asymmetry is load-bearing for the per-publisher per- domain authentication-and-encryption publication-stack coordination; (iv) per-publisher per-domain publication-discipline correctness receiver-side-failure-mode-row-emission parallel at distinct aggregate-reporting- protocol boundaries — both the per-publisher per-domain SPF-publication- discipline-correctness failure-mode receiver-side row-emission discipline (the per-publisher per-domain spf=permerror per-row emission in the per-day per-publisher per-domain DMARC aggregate-report XML stream) and the per-publisher per-policy- domain MTA-STS-publication-discipline- correctness failure-mode receiver-side row-emission discipline (the per-policy- domain result-type: sts-policy- fetch-error / result-type: sts-policy-invalid per-row emission in the per-day per-policy- domain TLS-RPT JSON-aggregate-report stream) are per-publisher per-domain publication-discipline-correctness receiver-side-failure-mode-row-emission primitives at distinct per-publisher per-domain aggregate-reporting-protocol boundaries. Read THIS page when AUTHORING the per-publisher per-domain RFC 7208 §3 SPF TXT-record byte-grammar publication discipline; read the MTA-STS-explained spoke when CO- AUTHORING the per-publisher per-policy- domain RFC 8461 MTA-STS-policy transport-layer publication discipline whose per-policy-domain _mta-sts.<d> TXT-RR + HTTPS-policy-file publication- discipline composes operationally with the per-publisher per-domain SPF TXT-record byte-grammar publication- discipline THIS page documents at the per-publisher per-domain cross-protocol- pillar authentication-record-byte- grammar-publication-discipline- composition boundary.
• Domain Security Checker — verifies your SPF record at the DNS layer (version tag presence, single-record rule, character-string length, per-subdomain coverage, A-label encoding) plus the full SPF / DKIM / DMARC / BIMI / MTA-STS / TLS-RPT / CAA stack.
• DMARC for Office 365 hybrid — the LOAD-BEARING per-hybrid-Exchange- tenant HYBRID-EXCHANGE-DUAL-EGRESS- APEX-SPF-RECORD-BYTE-COMPOSITION- DISCIPLINE-AS-DOWNSTREAM-CONSUMER-OF- RFC-7208-§3-SPF-TXT-RECORD-BYTE-GRAMMAR- PUBLICATION companion documenting the per- hybrid-Exchange-tenant DMARC + SPF + DKIM publication tutorial — specifically the per-tenant apex SPF TXT record that MUST compose both the Exchange Online cloud- egress authorization (the canonical include:spf.protection.outlook.com directive whose macro-expansion enumerates the per-region EOP egress IP pool) AND the on-prem Edge Transport / Mailbox server outbound IP authorization (operator- managed ip4: literals or operator-controlled secondary include: tokens to a per-org SPF-include sub-domain) at a single per- org-domain apex SPF TXT publication. Where THIS page documents the per- publisher per-domain RFC 7208 §3 SPF TXT-record byte-grammar publication (the v=spf1 version tag, the eight mechanism types all/include/a/mx/ptr/ip4/ip6/exists, the four qualifier prefixes +/-/~/?, the modifier tags redirect=/exp=, the 255-octet per-string TXT-RR limit, the multi-string concatenation rules, and the per-domain single-record uniqueness constraint), the DMARC-for-O365-hybrid spoke documents the per-hybrid-tenant per-org-domain APEX SPF-RECORD BYTE- COMPOSITION DISCIPLINE — the per-tenant operator-side challenge of composing a single apex SPF TXT record whose byte- grammar conforms to RFC 7208 §3 (this page's reference) while simultaneously authorising both the Microsoft-managed cloud-egress and the operator-managed on-prem-egress at distinct mechanism slots. Read THIS page when AUTHORING the per-publisher per-domain SPF TXT-record byte-grammar; read the DMARC-for-O365- hybrid spoke when COMPOSING the per- hybrid-tenant per-org-domain apex SPF record whose byte-composition strategy consumes the byte-grammar primitives this page documents to publish the dual- egress authorisation in a single apex TXT record.
• DNS Record Generator — the SPF record-generator wizard (Enterprise plan). Outputs syntactically correct records with automatic chunking, A-label encoding for international domains, and per-subdomain null publication.
• MTA-STS for Google Workspace — the TRANSPORT-LAYER per-publisher per-policy-domain TXT-RR-byte-grammar- publication peer to this ENVELOPE-LAYER per-publisher per-domain SPF TXT-RR byte-grammar reference. Where THIS page documents the per-publisher per-domain apex SPF TXT-RR byte-grammar (the v=spf1 version tag, the mechanism cascade include: / a / mx / ip4: / ip6:, the terminal qualifier -all / ~all, the 255-octet per-string cap and the multi-string concatenation rule), the GW MTA-STS spoke documents the per- Workspace-tenant per-custom-domain _mta-sts.<d> TXT-RR byte-grammar (the v=STSv1 version tag, the id=<token> policy- ID coupling) AND the per-tenant https://mta-sts.<d>/.well-known/mta-sts.txt HTTPS-policy-host file publication listing mx: *.aspmx.l.google.com as the enforced-mode MX cone. Read the GW MTA-STS spoke as the per- publisher per-domain TRANSPORT-LAYER TXT-RR byte-grammar companion to this page's per-publisher per-domain ENVELOPE-LAYER SPF TXT-RR byte- grammar reference — together they cover the per-publisher per-domain cross-layer authentication-and- transport record-publication byte-grammar surface.
• TLS-RPT explained — the per-publisher per-domain SPF TXT-RR byte-grammar this page covers is an apex-zone authoritative publication primitive whose receiver-side first-hop SPF-evaluation verdict feeds the DMARC composite. TLS-RPT publishes a parallel per-publisher per-domain underscored-leaf TXT-RR at _smtp._tls.<d> advertising the JSON failure-report delivery endpoint. Joint apex-zone + underscored-leaf TXT-RR publication discipline is the per-publisher per- domain DNS-zone-editor commit cadence for the cross-layer authentication-and- transport record-publication surface.
• DMARC deployment checklist — the PRE-FLIGHT-CHECKLIST-ITEM-SPF-RECORD- PUBLISHED-AND-WITHIN-BUDGET companion to this SPF DNS-syntax reference. Where THIS page documents the per-publisher per-domain SPF TXT-record byte-grammar (RFC 7208 §3 single-record-per-domain constraint + §3.3 multi-string concatenation form + §5 mechanism-token taxonomy: `ip4:`, `ip6:`, `a`, `mx`, `include:`, `exists:`, `ptr` + §4.6.2 qualifier-prefix byte-syntax: `+`, `-`, `~`, `?` + terminal `all` mechanism), the DMARC-deployment-checklist spoke is the per-publisher per-domain DMARC deployment process-reference whose pre-flight checklist-items the per-publisher per-domain SPF-record byte-grammar reference THIS page documents structurally enables. FOUR per- publisher per-domain deployment-checklist- vs-SPF-DNS-syntax coupling dimensions: (i) per-publisher per-domain Pre- flight checklist-item: per-publisher per- domain SPF TXT-record published-and-grammar- valid verified via `dig +short TXT <d> | grep '^"v=spf1'` as load-bearing per- publisher per-domain DMARC ramp-readiness gate — the deployment-checklist spoke documents the per-publisher per- domain pre-flight verification step (single `v=spf1` record per per-publisher per- domain apex, no duplicate records, RFC 7208 §3.3 multi-string concatenation conformance) the per-publisher per-domain DMARC deployment operator MUST execute BEFORE advancing past `p=none` to `p=quarantine`; the per-publisher per- domain SPF byte-grammar reference THIS page documents is the LITERAL pre-flight verification reference the deployment- checklist operator consults at the per- publisher per-domain SPF-record verification step; (ii) per-publisher per-domain Pre- flight checklist-item: per-publisher per- domain SPF RFC 7208 §4.6.4 ten-DNS-lookup budget compliance verified via per- publisher per-domain SPF include-cascade DNS-query-count enumeration as load-bearing per-publisher per-domain DMARC ramp- readiness gate — the deployment- checklist spoke documents the per-publisher per-domain RFC 7208 §4.6.4 ten-DNS-lookup budget pre-flight verification step (per- publisher per-domain SPF include-cascade DNS-query-count enumeration, per-publisher per-domain `void-lookup` cap audit, per- publisher per-domain `include:` / `redirect=` / `a` / `mx` / `ptr` / `exists` mechanism token DNS-query-count contribution) the per-publisher per-domain DMARC deployment operator MUST execute BEFORE advancing the per-publisher per-domain DMARC ramp; the per-publisher per-domain SPF byte-grammar reference THIS page documents is the LITERAL pre-flight budget- compliance verification reference the deployment-checklist operator consults at the per-publisher per-domain budget-audit verification step; (iii) per-publisher per-domain Ramp-phase checklist-item: per-publisher per-domain SPF qualifier-strictness ramp (`~all`-soft Phase 1 → `-all`-strict Phase 5) cross-checked during the per-publisher per-domain DMARC ramp as load-bearing per- publisher per-domain joint authentication- strictness ramp coordination gate — the deployment-checklist spoke documents the per-publisher per-domain SPF qualifier- strictness ramp coordination discipline (per-publisher per-domain SPF `~all`-soft Phase 1 retained through DMARC `p=none` Phase 1 + DMARC `p=quarantine pct=10/25/50` Phase 3 + upgraded to SPF `-all`-strict concurrent with DMARC `p=reject pct=100` Phase 5) the per-publisher per-domain DMARC deployment operator MUST coordinate DURING per-phase ramp advancement; the per- publisher per-domain SPF byte-grammar reference THIS page documents is the LITERAL per-qualifier-strictness reference the deployment-checklist operator consults at the per-phase qualifier-strictness audit step; (iv) per-publisher per-domain Post-flight checklist-item: per-publisher per-domain per-receiver `spf=pass + aligned=true` evidence-floor cross-checked in the per-receiver aggregate-report RUA stream as load-bearing per-publisher per- domain DMARC-aligned-pass-rate-floor empirical-observability primitive — the deployment-checklist spoke documents the per-publisher per-domain per-receiver post-flight `spf=pass + aligned=true` evidence-floor the per-publisher per-domain DMARC deployment operator MUST verify in the per-receiver RUA evidence stream BEFORE advancing to terminal `p=reject pct=100`; the per-publisher per-domain SPF byte- grammar reference THIS page documents is the LITERAL per-publisher per-domain SPF publication primitive the per-receiver `spf=pass + aligned=true` evidence rate empirically observes. Read the DMARC-deployment-checklist spoke alongside this SPF DNS-syntax reference when AUTHORING the per-publisher per-domain DMARC deployment pre-flight checklist whose per-publisher per-domain SPF-record byte- grammar conformance + RFC 7208 §4.6.4 budget compliance is the load-bearing pre-flight gate, when PLANNING the per-publisher per- domain DMARC ramp-progression calendar with explicit per-publisher per-domain SPF qualifier-strictness ramp coordination checklist items, or when VALIDATING the per-publisher per-domain DMARC terminal- state `p=reject pct=100` ramp-readiness against the post-flight per-receiver `spf=pass + aligned=true` evidence-floor checklist gate.
• DKIM alignment with DMARC — the PER-PUBLISHER-PER-DOMAIN-DKIM-D- EQUALS-VS-FROM-DOMAIN-IDENTIFIER-ALIGNMENT- AS-STRUCTURAL-PARALLEL-TO-SPF-ENVELOPE- MAIL-FROM-VS-FROM-DOMAIN-IDENTIFIER- ALIGNMENT companion to this SPF DNS-record byte-syntax reference. Where THIS page documents the per-publisher per-domain SPF DNS-record byte-grammar at the envelope-MAIL-FROM IP-authorisation layer (the RFC 7208 v=spf1 sentinel token, the per-mechanism include: / a: / mx: / ip4: / ip6: / exists: / redirect= tag-list publication discipline, the per-publisher per-domain TXT-RR character-string chunking rules per RFC 1035 §3.3.14, the per-publisher per-domain qualifier-prefix + / ~ / - / ? selection discipline), the DKIM-alignment-with- DMARC spoke is the APPLICATION-LAYER- CRYPTOGRAPHIC-BINDING-BASED-AUTHENTICATION- LEG-WITH-DMARC-ALIGNMENT-EVALUATION companion documenting the per-message DKIM-Signature d=-tag vs RFC 5322 From-header organisational- domain alignment evaluation per RFC 7489 §3.1.1 — the structurally-parallel application-layer authentication-leg-with- DMARC alignment to the per-publisher per- domain envelope-layer SPF authentication- leg-with-DMARC alignment THIS page documents the byte-grammar of. Four DKIM-alignment- vs-SPF-alignment coupling dimensions matter at the per-publisher per-domain DMARC composite-evaluator boundary: (i) per-publisher per-domain DMARC composite- verdict pass requires AT LEAST ONE aligned-pass leg — both DKIM-alignment- with-DMARC AND SPF-alignment-with-DMARC are structurally-parallel authentication legs at the per-receiver per-message DMARC composite-evaluator boundary, and the per-publisher per-domain DMARC composite verdict pass requires at least one of them to pass + align; (ii) per-publisher per-domain forwarder-hop alignment-leg differentiation — when per-publisher per-domain mail is forwarded through ESP-operated mailing- list relays, per-publisher per-domain envelope-MAIL-FROM is rewritten breaking SPF alignment at the forwarder; the per- publisher per-domain DKIM-aligned-pass leg the DKIM-alignment-with-DMARC spoke documents BECOMES THE LOAD-BEARING per- publisher per-domain authentication-leg- of-last-resort the per-publisher per- domain DMARC composite verdict survives on; (iii) per-publisher per-domain organisational-domain identification at per-receiver per-message alignment evaluation — both SPF aspf=relaxed / aspf=strict AND DKIM adkim=relaxed / adkim=strict alignment-modes per RFC 7489 §6.7 consume the per- publisher per-domain Public-Suffix-List- anchored organisational-domain identification rule when relaxed-mode is in effect; the per-publisher per-domain SPF v=spf1 publication discipline THIS page documents AND the per-publisher per-domain DKIM-Signature d=-tag publication discipline the DKIM-alignment-with-DMARC spoke documents together IS the per-publisher per-domain DMARC composite-alignment publication-discipline foundation; (iv) per-publisher per-domain adkim= AND aspf= DMARC-tag publication coordination — the per-publisher per-domain _dmarc.<domain> TXT-RR's adkim=relaxed + aspf=relaxed publication discipline IS the per-publisher per- domain operator-side per-message DMARC composite-evaluator-alignment-mode control surface the per-publisher per- domain SPF byte-grammar publication discipline THIS page documents AND the per-publisher per-domain DKIM-Signature d=-tag emission discipline the DKIM-alignment-with-DMARC spoke documents together feed at the cross- protocol DMARC composite-evaluator boundary. Read THIS page when AUTHORING the per-publisher per-domain SPF DNS- record byte-syntax + per-mechanism publication discipline; read the DKIM- alignment-with-DMARC spoke when AUTHORING the per-publisher per-domain DKIM-Signature d=-tag publication discipline whose per- publisher per-domain application-layer DKIM-aligned-pass leg is the structurally- parallel application-layer companion to the per-publisher per-domain envelope- layer SPF-aligned-pass leg THIS page documents the byte-grammar publication discipline of.
• DMARC monitoring
• DKIM canonicalization — the canonical RFC 6376 §3.4 reference on DKIM c= tag header-and-body canonicalization mode-selection (simple/simple vs relaxed/relaxed) whose per- publisher per-selector application-layer DKIM- Signature byte-normalisation discipline is the structurally-parallel application-layer publication companion to the per-publisher per- domain envelope-MAIL-FROM SPF DNS-TXT-RR byte- grammar publication discipline THIS page documents. Both are per-publisher per-domain publication-discipline reference floors whose mis-publication produces silent per-message authentication-leg-fail verdicts surfacing as per-receiver per-day DMARC aggregate-XML row attribution under policy_evaluated/spf and policy_evaluated/dkim respectively.
• DMARC troubleshooting
• DMARC multi-domain strategy
• Phishing protection
• MTA-STS vs DANE — the per-publisher per-domain transport-layer DNS-publication-discipline protocol-choice decision-matrix companion at four per-publisher per-domain SPF-DNS-TXT-RR-byte-grammar-vs-MTA-STS-vs-DANE coupling dimensions: (i) per-publisher per-domain SPF DNS-TXT-RR at apex-domain v=spf1 envelope-MAIL-FROM-layer byte-grammar publication-discipline per RFC 7208 §3.1 IS structurally parallel application-layer DNS-publication-discipline cousin to per-publisher per-domain MTA-STS _mta-sts.<d> underscore-prefixed TXT-RR v=STSv1; id=<rotation-id> byte-grammar publication-discipline per RFC 8461 §3.1 vs per-publisher per-domain DANE TLSA-RR _25._tcp.<mx> underscore-prefixed RDATA byte-grammar publication-discipline per RFC 7672 §3 — all three per-publisher per-domain DNS-published authentication-and-transport-discipline byte-grammar references coordinate at the per-publisher per-domain composite DNS-publication-discipline coordination boundary; (ii) per-publisher per-domain SPF mechanism-vocabulary publication-discipline (include:/ip4:/ip6:/a:/mx:/exists:/ptr:/all) + qualifier-publication-discipline (-all hard-fail vs ~all soft-fail) per RFC 7208 §4.6.2 IS structurally parallel envelope-MAIL-FROM-layer authentication-leg byte-grammar publication-discipline to per-publisher per-domain MTA-STS policy-file mode: enforce/mx:/max_age: byte-grammar publication-discipline vs per-publisher per-domain DANE TLSA-RR cert-usage/selector/matching-type 3-field byte-grammar publication-discipline; (iii) per-publisher per-domain SPF TXT-RR RFC 7208 §4.6.4 10-DNS-lookup-cap budget IS structurally parallel per-publisher per-domain envelope-MAIL-FROM-layer DNS-publication-discipline budget to per-publisher per-domain MTA-STS HTTPS-served-policy fetch + cache budget (typically 1 fetch per max_age: rotation cadence) vs per-publisher per-domain DANE TLSA-RR DNSSEC-validation budget (RRSIG-chain verification per receiver) — all three per-publisher per-domain DNS-publication-discipline budget references coordinate at the per-publisher per-domain composite cross-layer DNS-publication-budget coordination boundary; (iv) per-publisher per-domain SPF DNS-TXT-RR publication-discipline drift (mechanism-misclassification / qualifier-mis-publication / 10-DNS-lookup-cap exhaustion surfacing as per-receiver per-day per-source-IP DMARC RUA policy_evaluated/spf=permerror attribution) IS structurally parallel publication-discipline-drift class to per-publisher per-domain MTA-STS policy-file publication-discipline drift (mode-mis-publication / mx:-allow-list drift / max_age:-too-short rotation surfacing as per-receiver per-policy-domain TLS-RPT sts-policy-fetch-error/sts-policy-invalid attribution) vs per-publisher per-domain DANE TLSA-RR publication-discipline drift (DNSSEC-RRSIG drift / TLSA-RR-rotation-overlap-window-too-short surfacing as per-receiver per-policy-domain TLS-RPT dnssec-invalid/dane-mismatch attribution) the per-publisher per-domain MTA-STS-vs-DANE protocol-choice decision-matrix companion documents the per-publisher per-domain transport-layer publication-discipline drift catalogue of structurally parallel to the per-publisher per-domain SPF DNS-TXT-RR envelope-MAIL-FROM-layer byte-grammar publication-discipline THIS page documents the per-publisher per-domain envelope-MAIL-FROM-layer authentication-leg publication-discipline of.
• DKIM failures explained — the PER-PUBLISHER-PER-DOMAIN-SPF-DNS-TXT-RR-BYTE-GRAMMAR-PUBLICATION-DISCIPLINE-AS-STRUCTURALLY-PARALLEL-ENVELOPE-MAIL-FROM-LAYER-AUTHENTICATION-LEG-PRIMITIVE-COMPANION-TO-PER-PUBLISHER-PER-SELECTOR-DKIM-APPLICATION-LAYER-AUTHENTICATION-LEG-FAILURE-VERDICT-CATALOGUE companion at four per-publisher per-domain SPF-DNS-TXT-RR-byte-grammar-vs-DKIM-failures-verdict-catalogue coupling dimensions: (i) per-publisher per-domain SPF DNS-TXT-RR byte-grammar publication-discipline THIS page documents IS structurally parallel envelope-MAIL-FROM-layer authentication-leg publication-discipline to per-publisher per-selector DKIM-Signature application-layer authentication-leg whose verdict-fail-class catalogue the DKIM-failures explained spoke documents the diagnostic ladder of — both per-publisher per-domain authentication-leg publication-discipline references jointly underpin per-publisher per-domain composite DMARC aligned-pass disjunction (any-leg-aligns-wins) per RFC 7489 §3.1.1; (ii) per-publisher per-domain SPF permerror per RFC 7208 §8 verdict-class (mechanism-misclassification / 10-DNS-lookup-cap exhaustion / malformed-SPF-syntax) IS structurally parallel envelope-MAIL-FROM-layer verdict-fail-class to per-publisher per-selector DKIM permerror per RFC 8601 §2.7.1 verdict-class (mis-published TXT-RR / unparseable public-key / unsupported algorithm) the DKIM-failures explained spoke documents the diagnostic-root-cause ladder of; (iii) per-publisher per-domain SPF temperror per RFC 7208 §8 verdict-class (transient DNS-resolver-timeout / SERVFAIL) IS structurally parallel envelope-MAIL-FROM-layer verdict-fail-class to per-publisher per-selector DKIM temperror per RFC 8601 §2.7.1 verdict-class (transient public-key DNS-lookup failure / DNS-resolver-side TTL-expiry) the DKIM-failures explained spoke documents the diagnostic-root-cause ladder of; (iv) per-publisher per-domain SPF DNS-TXT-RR byte-grammar publication-discipline drift surfacing as per-receiver per-day per-source-IP DMARC RUA policy_evaluated/spf attribution-distortion IS structurally parallel publication-discipline-drift class to per-publisher per-selector DKIM-Signature application-layer publication-discipline drift surfacing as per-receiver per-day per-source-IP DMARC RUA policy_evaluated/dkim attribution-distortion the DKIM-failures explained spoke documents the per-publisher per-selector DKIM publication-discipline-drift diagnostic ladder of. Read the DKIM-failures explained spoke when DIAGNOSING per-publisher per-domain DMARC aligned-fail attribution at the per-publisher per-domain envelope-MAIL-FROM-layer SPF-leg-fail OR per-publisher per-selector application-layer DKIM-leg-fail root-cause-attribution boundary every per-publisher per-domain DMARC operator-side aligned-pass-rate floor preservation discipline depends on.
• DMARC for transactional email
• DMARC for Google Workspace — the Google-Workspace-specific deployment guide. Includes the canonical apex SPF record (v=spf1 include:_spf.google.com ~all) whose include: mechanism byte-grammar this RFC 7208 §3 syntax reference produces, plus the DKIM (google selector) and DMARC publication steps for a Workspace tenant.
• DKIM selectors — the sibling DNS-TXT-RR byte-grammar reference for the other DNS-published authentication leg. Where this page documents the apex v=spf1 TXT-record syntax, the DKIM public key lives in a TXT-RR of the same RFC 1035 §3.3.14 character-string format, just published one label deeper at <selector>._domainkey.<domain>. The selector subdomain is what lets a domain run several signing keys at once and rotate them — the application-layer counterpart to the single apex SPF record this page produces. Read the DKIM selectors spoke to see how selector naming and rotation work alongside the SPF leg under the same DMARC alignment evaluation.
• DMARC forensic reports — when the SPF record this page produces fails for a real message, a ruf= failure (forensic) report carries the redacted message headers and the spf= result that pinpoint which sending host fell outside the published mechanisms. It is the per-message complement to aggregate reporting when you need to see the exact envelope that triggered an SPF-fail. Read the forensic-reports spoke to learn how to enable and interpret these failure samples.
• Microsoft SNDS + JMRP monitoring — SPF PASS does not clear Microsoft's IP-reputation gate: SNDS shows the per-IP GREEN/YELLOW/RED filter verdict Outlook.com assigned to each authorized address and JMRP reports the Junk clicks behind a degraded one.

12. Audit your SPF record syntax now

The fastest way to confirm your SPF record is syntactically well-formed at the DNS layer:

1. Confirm the TXT record exists at the right name. Run dig +short TXT example.com — the SPF record should appear as a quoted string starting with "v=spf1. If no such string appears, the record is missing.
2. Verify exactly one SPF record. Run dig +short TXT example.com | grep -c '^"v=spf1' — the count should be exactly 1. Any value greater than 1 is a §6 violation producing permerror.
3. Check character-string chunking for long records. Run dig TXT example.com (without +short) — if any character-string is longer than 255 octets, the publish failed or was silently truncated. Re-author with explicit chunking.
4. Audit per-subdomain coverage. For every subdomain that appears in your outbound MAIL FROM traffic, confirm an SPF record exists. Use the Domain Security Checker's multi-subdomain audit mode for the full enumeration.
5. Inspect a real outbound message with the Email Header Analyzer to confirm the Authentication-Results header reports the expected spf=pass for legitimate senders — confirming both the SPF semantic layer (the right IP authorised) and the SPF syntactic layer (the record parsed cleanly).