DMARC Analyzer

TL;DR

The four IP-providing SPF mechanisms operators actually pick between are include, ip4, a, and mx (RFC 7208 section 5). Quick rule:

• include — managed providers (Microsoft 365, Google Workspace, Mailchimp, SendGrid). Costs 1 DNS lookup at the parent plus the included records lookups. Always the right choice for a SaaS sender that publishes an include statement.
• ip4 — static IPs you own and control (on-prem Postfix, dedicated MTA). Costs zero lookups. Use for fixed IPs that do not rotate.
• a — self-hosted mail server identified by an A record under your control. Costs 1 DNS lookup. Use when you publish the A record yourself (a:mail.example.com).
• mx — historical "outbound also serves as MX" pattern. Costs 1 lookup for the MX query PLUS 1 lookup per MX target. Use only when your inbound MX server is also your outbound sender.

Cumulative DNS-lookup cost matters: the sum of include + a + mx (and per-MX-target) lookups must stay at or under 10 per RFC 7208 section 4.6.4 or the receiver returns permerror. The ip4 and ip6 mechanisms are FREE (zero lookups). The Domain Security Checker surfaces the live lookup count for your record.

1. When the include / ip4 / a / mx decision matters

Operators face this decision in five common scenarios:

1. Publishing your first SPF record. You need to authorise the sending infrastructure for a domain. Which mechanism reflects what you actually have?
2. Adding a third-party sender (a new ESP, transactional service, CRM, helpdesk). The provider typically gives you an include: statement to publish — but sometimes a list of IPs to add as ip4. Which is correct?
3. Migrating off a provider. Removing a stale include: for a vendor you no longer use — and replacing it with the new vendors mechanism.
4. Hitting the 10-DNS-lookup cap (RFC 7208 §4.6.4 permerror threshold). Replacing an expensive include tree with ip4 entries (SPF flattening) or consolidating multiple senders behind a single provider.
5. Migrating from an on-prem MTA to a cloud provider. Replacing legacy a or mx entries with the cloud providers include statement.

This page enumerates each mechanism with the canonical Definition / Syntax / Lookup cost / When to use / When NOT to use / Common pitfalls structure, then presents a side-by-side comparison table, a flow-chart decision matrix, three worked deployment examples, and the seven most common mechanism-choice mistakes.

Scope note: this page covers ONLY the four IP-providing mechanisms operators routinely pick between. The other RFC 7208 mechanisms (ip6, exists, all, deprecated ptr), the qualifiers (+ / - / ~ / ?), and the modifiers (redirect=, exp=) are covered in the comprehensive SPF mechanisms explained reference.

2. The four mechanisms at a glance

Side-by-side comparison of the four IP-providing SPF mechanisms (RFC 7208 section 5). Lookup-cost figures are per occurrence in the record; the per-MX-target multiplier applies to mx only.

3. The include mechanism (RFC 7208 §5.2)

Definition: The include mechanism delegates SPF evaluation to another domains SPF record. The receiver fetches the included domains TXT record, evaluates it recursively, and treats a pass there as a pass in your record.

Syntax: include:<domain>. The argument is the domain whose SPF record to evaluate (e.g. include:spf.protection.outlook.com for Microsoft 365, include:_spf.google.com for Google Workspace).

Lookup cost: ONE DNS lookup at the parent record, plus whatever lookups the included record requires. include:_spf.google.com expands to 4 lookups total (the parent + 3 netblock sub-records); include:spf.protection.outlook.com expands to 3 lookups total. The cumulative count is governed by the 10-DNS-lookup limit of RFC 7208 section 4.6.4.

When to use: Use include whenever a managed provider gives you an include: statement. This is the right answer for: Microsoft 365 / Exchange Online, Google Workspace / Gmail, Mailchimp (Mandrill), SendGrid, Mailgun, Postmark, Amazon SES, Salesforce Marketing Cloud, HubSpot, Marketo, Zendesk, Intercom, and the vast majority of commercial transactional ESPs.

When NOT to use: Do NOT use include for a static IP you own and control — that is what ip4 is for. Do NOT use include for a self-hosted server identified by an A record — that is what a is for. Do NOT use include for a domain whose SPF record you do not trust (the included domains record can be modified by its owner without notice — only delegate to providers under explicit business relationship).

Common pitfalls: (1) Stale includes for ex-vendors (the include for a CRM you stopped using 18 months ago is still costing 1+ DNS lookups against your 10-lookup budget). (2) Hitting the 10-lookup cap with multi-vendor stacks (Google Workspace + Microsoft 365 hybrid + 3 ESPs = 14+ lookups, triggers permerror). (3) Recursive include loops (rare but trigger permerror; RFC 7208 limits recursion depth). (4) Misspelled provider domains (include:spf.protection.outlock.com NXDOMAIN → permerror).

4. The ip4 mechanism (RFC 7208 §5.6)

Definition: The ip4 mechanism authorises a specific IPv4 address or CIDR range to send mail on behalf of the domain. The receiver compares the connecting MTAs IP to the listed address or range and returns a match if the IP falls within it.

Syntax: ip4:<ip-or-cidr>. The argument is either a single IPv4 address (ip4:198.51.100.42) or a CIDR range (ip4:198.51.100.0/24). The ip4 prefix is mandatory; just listing the address without ip4: is invalid SPF syntax.

Lookup cost: ZERO DNS lookups. The ip4 mechanism is evaluated entirely from the SPF record itself — the receiver does not query DNS for any subsequent record. This makes ip4 the cheapest mechanism in the 10-DNS-lookup budget.

When to use: Use ip4 for static IPs you own and control. Canonical scenarios: on-premises Postfix or Exchange server with a fixed public IP, self-hosted Mailman or Discourse list server, dedicated outbound MTA in your own data centre, bare-metal mail relay with a static IP, a third-party vendor that gives you a dedicated IP but does not publish an SPF record to include. Also appropriate as an SPF FLATTENING tactic when you are over the 10-lookup cap and need to convert an expensive include into the IPs it currently resolves to.

When NOT to use: Do NOT use ip4 for managed providers whose IPs rotate (Microsoft 365, Google Workspace, any SaaS ESP) — hardcoded ip4 lists go stale within weeks and start failing legitimate mail. Do NOT use ip4 when you have more than ~6-8 IPs from a single source — the resulting record becomes unmaintainable. Do NOT use ip4 for dynamic IPs (NAT pools, dynamic VPS allocations, consumer broadband — use a publication mechanism that tracks the address dynamically, or do not send mail from those IPs).

Common pitfalls: (1) Stale entries for IPs you no longer use (the ip4 for a decommissioned server is still authorising that IP range — a security risk if the IP is reassigned). (2) Overlapping CIDR ranges (no syntax error, but indicates sloppy maintenance). (3) Missing CIDR (writing ip4:198.51.100.0 without /24 authorises only the single host address). (4) Authorising ip4:0.0.0.0/0 (DO NOT — authorises every IPv4 address on the internet, defeats SPF entirely). (5) Forgetting IPv6 (if you have IPv6 senders, you also need ip6: entries — ip4 does NOT cover IPv6 traffic).

5. The a mechanism (RFC 7208 §5.3)

Definition: The a mechanism authorises every IPv4 and IPv6 address published as an A or AAAA record for a hostname. The receiver queries DNS for the hostnames A and AAAA records and treats the connecting IP as authorised if it appears in either response.

Syntax: Three forms: (a) a alone — authorises the A/AAAA records of the SPF records own domain (the domain the receiver is currently evaluating). (b) a:<hostname> — authorises the A/AAAA records of a specific hostname (a:mail.example.com). (c) a/<CIDR> or a:<hostname>/<CIDR> — authorises the CIDR range derived from the A/AAAA records.

Lookup cost: ONE DNS lookup per a mechanism occurrence (counted toward the RFC 7208 §4.6.4 10-lookup limit). The receiver queries one hostname and gets back the A and AAAA records in a single combined response — but the accounting still charges one lookup per a in your record.

When to use: Use a when the sending IP is identified by an A or AAAA record under your DNS control. Canonical scenarios: self-hosted Postfix where a:mail.example.com points at the mail server, an MTA cluster where each node has an A record and you list them as a:node1.example.com a:node2.example.com, a hosting provider that gives you a hostname (not an IP) to use. Also appropriate when the IP changes occasionally and you want SPF to track the change via A-record updates rather than manual SPF record edits.

When NOT to use: Do NOT use a for a managed provider (Microsoft 365, Google Workspace) — their outbound IPs are not published under YOUR A records. Do NOT use a if the hostname has many A records (each IP authorised; if the hostname is a load-balanced cluster with 20 backends, all 20 are authorised — fine if intentional, dangerous if not). Do NOT use bare a (no hostname) unless you want to authorise the A record of the SPF records own domain — this is rarely the right semantic for an enterprise deployment.

Common pitfalls: (1) Bare a when your domains apex A record points at a website (not a mail server) — authorises the web server IP for sending mail. (2) Authorising a hostname you do not control (a:somethirdparty.example — the third party can change their A record and silently change your authorised sender set). (3) Confusing a (A-record-based) with aaaa — there is no aaaa mechanism; a covers both A and AAAA records automatically.

6. The mx mechanism (RFC 7208 §5.4)

Definition: The mx mechanism authorises every IP address published as an MX records target hostname. The receiver queries the MX records, then resolves each MX-target hostname to its A/AAAA records, and treats the connecting IP as authorised if it appears in any of those responses.

Syntax: Three forms: (a) mx alone — uses the MX records of the SPF records own domain. (b) mx:<domain> — uses the MX records of a specific domain. (c) mx/CIDR or mx:<domain>/CIDR — restricts to a CIDR-derived range of each MX targets A/AAAA records.

Lookup cost: ONE DNS lookup for the MX query, PLUS one DNS lookup per MX target hostname resolution. A domain with five MX hosts behind one mx mechanism costs 1 + 5 = 6 lookups against the RFC 7208 §4.6.4 cap. This is the most expensive mechanism — be careful with multi-MX deployments.

When to use: Use mx only when your inbound MX server is ALSO your outbound mail server. This was the canonical 1990s/2000s pattern for self-hosted Postfix or Sendmail deployments where one box handled both directions. Still appropriate for small single-server self-hosted deployments — but rare in modern architectures.

When NOT to use: Do NOT use mx for cloud providers — Microsoft 365 inbound MX (your-tenant.mail.protection.outlook.com) is on a separate IP set from outbound sending (*.outbound.protection.outlook.com); mx would authorise the WRONG IPs. Do NOT use mx when your inbound MX is a spam-filtering gateway (Proofpoint, Mimecast, Barracuda) that terminates inbound mail but does not originate outbound. Do NOT use mx when your inbound/outbound architectures are split (an on-prem Exchange + a separate SendGrid for transactional — the MX and the senders share no IPs).

Common pitfalls: (1) Using mx for cloud-hosted mail (authorises the inbound spam filter, not the outbound sender — every legitimate outbound message fails SPF). (2) Hitting the 10-lookup cap with multi-MX deployments (5 MX hosts + 4 other lookups = 11). (3) Authorising a third-party MX target you do not control (mx:partner.example — the partner can change their MX list and silently expand your authorised sender set). (4) Using mx when a single a:mail.example.com would suffice and cost half as many lookups.

7. The decision matrix

Five questions, in order, to pick the right mechanism for a sender you are about to authorise:

1. Does the provider give you an include: statement to publish? → Use include. This is the canonical answer for managed SaaS providers (Microsoft 365, Google Workspace, Mailchimp, SendGrid, etc.) and the only choice that auto-tracks the providers IP changes.
2. Do you own and control a static IP that does not rotate? → Use ip4 (or ip6 for IPv6). Zero DNS lookups, cleanest semantic when you know the IP and the IP will not change.
3. Does the sender have an A or AAAA record you publish under your zone? → Use a:<hostname>. Tracks A-record updates automatically, one lookup cost.
4. Is the sending server ALSO your inbound MX server? → Use mx (only if questions 1-3 said no). Modern architectures rarely satisfy this condition; if you find yourself reaching for mx, double-check that your inbound MX and outbound sender genuinely share the same IPs.
5. None of the above? → You probably should not be authorising this sender. Verify the operational story (a sender without a static IP, without an include statement, without an A record, and not co-located with your MX is unusual and worth investigating before adding to SPF).

Cumulative-cost guardrail: after choosing the mechanism, sum the DNS-lookup cost against your 10-lookup budget. If your record would exceed 10, either consolidate senders (e.g. route transactional mail through Microsoft 365 instead of a separate ESP), flatten an expensive include to its constituent ip4 entries (with a maintenance cadence to refresh), or use the SPF lookup limit and flattening guide for the full playbook.

8. Three worked deployment examples

8.1 Single on-prem Postfix server

Scenario: a small business runs a single Postfix server on a static public IP (198.51.100.42). The server handles both inbound and outbound mail. No third-party senders.

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

Rationale: ip4 is the cheapest mechanism (zero lookups) and the IP is static + owned. No mx or a needed — listing the IP directly is cleaner than indirecting through DNS records. Alternative valid syntax: v=spf1 a:mail.example.com -all (one lookup cost, automatically tracks the A record).

8.2 Microsoft 365 + Mailchimp transactional

Scenario: company uses Microsoft 365 for corporate mail and Mailchimp (Mandrill) for transactional sends. No on-prem MTA.

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

Rationale: both providers are managed SaaS that publish their own SPF records and rotate IPs — use include. Cumulative lookup cost: 3 (Microsoft 365 expansion tree) + 1 (Mailchimp single record) = 4 lookups, well under the 10-lookup cap. Do NOT use mx (would authorise the M365 inbound spam filter, not the outbound sender). Do NOT hardcode IPs (Microsoft and Mailchimp rotate their outbound IP ranges; an ip4 list would break within weeks).

8.3 Hybrid deployment: Google Workspace + on-prem mailing-list server + SendGrid

Scenario: company uses Google Workspace for corporate mail, a self-hosted Mailman list server on a fixed IP (203.0.113.7), and SendGrid for marketing campaigns.

example.com.  IN  TXT  "v=spf1 include:_spf.google.com ip4:203.0.113.7 include:sendgrid.net -all"

Rationale: Google Workspace and SendGrid are managed providers (use include); the Mailman server is on a static IP under your control (use ip4 — zero lookup cost, no need for an a-record indirection). Cumulative lookup cost: 4 (Google Workspace expansion tree) + 0 (ip4) + 1 (SendGrid) = 5 lookups, half the 10-lookup budget.

9. The seven most common mechanism-choice mistakes

1. Using mx for cloud-hosted mail (Microsoft 365, Google Workspace). Cloud-mail inbound MX is the providers spam-filtering frontend, NOT the outbound sender — mx authorises the wrong IPs and every legitimate outbound message fails SPF. Fix: replace mx with include:spf.protection.outlook.com (M365) or include:_spf.google.com (Workspace).
2. Hardcoding cloud-provider IPs with ip4. Microsoft 365 and Google Workspace rotate their outbound IP ranges regularly; a hardcoded ip4 list goes stale within weeks and starts failing legitimate mail. Fix: replace ip4 blocks with the providers include: statement.
3. Stale include for ex-vendors. The include statement for a CRM you stopped using 18 months ago is still costing 1+ DNS lookups against your 10-lookup budget — and still authorising the ex-vendors infrastructure to send mail as your domain. Fix: audit your SPF record quarterly; remove any include for a vendor you no longer use.
4. Bare a on a domain whose apex points at a website. v=spf1 a -all on example.com whose apex A record points at the web server authorises the WEB server IP to send mail — almost never the intended semantic. Fix: use a:mail.example.com (the mail-specific hostname) or switch to ip4 / include.
5. Hitting the 10-DNS-lookup cap by stacking include statements. Google Workspace (4) + Microsoft 365 hybrid (3) + 3 third-party ESPs (3-5) = 10+ lookups, triggers permerror, every mail fails SPF. Fix: consolidate senders (route transactional through your primary mail provider), flatten one expensive include into its current IPs as ip4 entries, or use SPF flattening services with a refresh cadence.
6. Authorising ip4:0.0.0.0/0. Almost always a typo or copy-paste error — this authorises every IPv4 address on the internet and defeats SPF entirely. Fix: remove immediately; SPF offers no protection while this is in the record.
7. Forgetting IPv6 coverage. If your senders also publish AAAA records or your providers send over IPv6, an ip4-only record leaves IPv6 traffic unauthenticated. The a, mx, and include mechanisms cover both automatically; bare ip4 does not. Fix: add corresponding ip6: entries or switch to an IPv6-aware mechanism.

10. FAQ

What is the difference between SPF include and ip4?

The SPF include mechanism (RFC 7208 section 5.2) delegates evaluation to another domains SPF record — the receiver fetches the other domains TXT record, evaluates it, and treats a match there as a match in your record. The ip4 mechanism (RFC 7208 section 5.6) authorises a specific IPv4 address or CIDR range directly in your record without any DNS lookup. The two key differences: (1) include costs one DNS lookup at evaluation (counted against the 10-lookup cap of RFC 7208 section 4.6.4), plus the included records own lookups; ip4 costs zero lookups. (2) include automatically reflects the included providers infrastructure changes (when Microsoft 365 adds new outbound IPs to spf.protection.outlook.com, your record stays valid without edits); ip4 freezes the IP list at authoring time and requires manual updates when your providers IPs change. Pick include when delegating to a managed provider (Microsoft 365, Google Workspace, Mailchimp, SendGrid); pick ip4 when authorising static IPs you own and control (on-prem mail server with a known public IP).

What is the difference between SPF a and mx mechanisms?

The SPF a mechanism (RFC 7208 section 5.3) authorises every IPv4 and IPv6 address published as an A or AAAA record for a hostname. The mx mechanism (RFC 7208 section 5.4) authorises every IP address published as an MX records target hostname (after the MX-to-A/AAAA resolution). Key distinction: a points at hostnames you publish directly (a:mail.example.com authorises whatever IPs mail.example.com resolves to); mx points at the MX-list and follows it (mx with no argument means "the MX hosts of THIS domain"; mx:example.com means "the MX hosts of example.com"). Lookup cost: a costs one DNS lookup; mx costs one lookup for the MX query PLUS one lookup per MX target (so a domain with five MX hosts behind one mx mechanism costs six lookups against the 10-lookup cap). Use a for a single-server deployment where the outbound mail server publishes its own A record. Use mx for the historical "my MX server is also my outbound mail server" pattern — but be aware that modern best practice separates inbound MX from outbound sending IPs, in which case ip4 or include is the better choice.

Which SPF mechanism should I use for Microsoft 365?

Use include — specifically include:spf.protection.outlook.com — for Microsoft 365 (Exchange Online) outbound mail. The canonical first-party SPF record for a tenant is v=spf1 include:spf.protection.outlook.com -all. This delegates evaluation to Microsofts managed SPF record, which Microsoft updates as their outbound IP ranges change. Do NOT hardcode Microsoft 365 IPs with ip4 — Microsofts outbound IP set rotates and adds new ranges; a hardcoded ip4 list goes stale within weeks and starts failing legitimate mail. Do NOT use a or mx for Microsoft 365 — Microsofts inbound MX (your-tenant.mail.protection.outlook.com) is separate from their outbound sending infrastructure, and a or mx mechanisms would not authorise the right IPs. If you have additional third-party senders (Mailchimp, SendGrid, Salesforce, HubSpot), append additional include statements: v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net include:sendgrid.net -all. Each include costs one DNS lookup against the 10-lookup cap — monitor the cumulative count with the DMARC Analyzer Domain Security Checker.

Which SPF mechanism should I use for Google Workspace?

Use include — specifically include:_spf.google.com — for Google Workspace outbound mail. The canonical first-party SPF record is v=spf1 include:_spf.google.com -all. Google publishes a 3-level expansion tree (_spf.google.com includes _netblocks.google.com / _netblocks2.google.com / _netblocks3.google.com), which consumes 4 DNS lookups total — track this against the 10-lookup cap. Do NOT hardcode Googles outbound IPs — Google rotates and expands the netblocks; a hardcoded ip4 list goes stale and breaks delivery. Do NOT use a or mx — Googles inbound MX (aspmx.l.google.com etc.) is separate from outbound sending infrastructure. For additional third-party senders, append additional include statements: v=spf1 include:_spf.google.com include:mail.zendesk.com include:_spf.salesforce.com -all. Note that Google Workspace + multi-vendor deployments commonly hit the 10-lookup cap; SPF flattening or careful sender consolidation may be required (see help_spf_lookup_limit.php).

When should I use ip4 instead of include in my SPF record?

Use ip4 when you own and control the sending IP, the IP is static, and you want zero DNS-lookup cost. Canonical scenarios: (1) on-premises Postfix or Exchange server with a known public IP, (2) self-hosted Mailman or Discourse list server, (3) dedicated outbound MTA in your own data centre, (4) bare-metal mail relay with a fixed public IP, (5) self-hosted DKIM-signing mail gateway. The ip4 mechanism is also the right answer when you need to AUTHORISE a sender that does not publish a public SPF record — for example, a third-party transactional vendor that gives you a static dedicated IP but does not publish include-able SPF records. Avoid ip4 for managed providers (Microsoft 365, Google Workspace, any SaaS ESP) — their IPs rotate and ip4 lists go stale. Avoid ip4 when you have more than ~6-8 IPs from one source — the resulting record becomes unmaintainable; use include or a-record indirection instead.

Does the SPF a mechanism count against the 10-DNS-lookup limit?

Yes. The SPF a mechanism (RFC 7208 section 5.3) costs ONE DNS lookup per occurrence in the record, counted against the 10-DNS-lookup limit defined in RFC 7208 section 4.6.4. Each a mechanism in your record (whether a, a:hostname, a/CIDR, or a:hostname/CIDR) consumes one slot. The mx mechanism by contrast costs one lookup for the MX query PLUS additional lookups per MX target (each MX hostname must be resolved to an IP, and each resolution counts). The include and exists mechanisms also cost one lookup each. The ptr mechanism (deprecated, do not use) costs one lookup. The redirect= modifier also costs one lookup. The ip4, ip6, and all mechanisms and the exp= modifier cost ZERO lookups. Cumulative accounting matters: a record using v=spf1 include:_spf.google.com (4) include:spf.protection.outlook.com (3) a (1) mx (typically 2-3) -all reaches 10-11 lookups and triggers permerror. The DMARC Analyzer Domain Security Checker shows the cumulative lookup count for your record.

Can I mix include ip4 a and mx in the same SPF record?

Yes — combining all four mechanism types in one record is permitted by RFC 7208 and is common in production. A typical hybrid record looks like v=spf1 ip4:198.51.100.42 ip4:198.51.100.43 include:spf.protection.outlook.com include:servers.mcsv.net a:mail.example.com mx -all. The receiver evaluates each mechanism left-to-right and returns the first match (per RFC 7208 section 4.6.2 first-match-wins semantics). Combining is the right pattern when your sending stack mixes: (a) static IPs you own (ip4), (b) managed providers (include), (c) a self-hosted server identified by A record (a), and (d) the historical "outbound also serves as MX" deployment (mx). The constraint is cumulative DNS-lookup cost: every include / a / mx (and per-MX-target) costs one lookup against the 10-lookup cap. Order mechanisms by cost (cheapest first, ip4 before include) only for readability — the receivers behaviour is determined by first-match-wins, not by cost.

Why is SPF mx considered legacy?

The mx mechanism reflects a 1990s-era assumption that a domains inbound MX server and its outbound sending server were the same machine — and that authorising the MX hosts was therefore a useful proxy for authorising the senders. That assumption no longer holds for most modern deployments: (1) cloud mail providers (Microsoft 365 inbound MX is your-tenant.mail.protection.outlook.com but outbound goes through *.outbound.protection.outlook.com — different IPs entirely), (2) split inbound/outbound architectures (an on-prem Exchange + a separate SendGrid for transactional means the MX has no overlap with outbound senders), (3) MX-as-spam-filter deployments (Proofpoint, Mimecast, Barracuda terminate inbound mail but do not originate outbound mail). For modern deployments, ip4 (for self-managed static IPs) or include (for managed providers) is the right choice. The mx mechanism still has a valid use case: small single-server self-hosted Postfix where the same box handles inbound and outbound — but that is increasingly rare. The mx mechanism is NOT deprecated in RFC 7208 (only ptr is); it is simply a poor fit for most contemporary architectures.

How do I decide between SPF include and a record?

Use include when delegating to a managed provider that publishes its own SPF record (Microsoft 365, Google Workspace, Mailchimp, SendGrid, Mailgun, Postmark, Amazon SES, Salesforce). The include mechanism follows the providers SPF record at every evaluation, automatically reflecting their infrastructure changes. Use a when the sending IP is identified by an A or AAAA record under YOUR control — typically a self-hosted Postfix/Exchange/Exim server where you publish an A record like a:mail.example.com. Quick decision: (1) Is this a third-party SaaS that gives you an include statement to publish? → include. (2) Is this a server you own where you publish the A record? → a. (3) Is this a static IP you own without a corresponding A record? → ip4. (4) Is this the historical "my inbound MX is also my outbound server" pattern? → mx (but consider migrating to a or ip4 for clearer intent). The DMARC Analyzer DNS Record Generator wizard guides this decision interactively.

11. Related guides

• SPF explained — Sender Policy Framework (RFC 7208). The pillar page covering SPF end-to-end: the protocol overview, the seven result codes, alignment, the deployment workflow. Read first if you are new to SPF.
• SPF mechanisms explained — the COMPLETE 8-mechanism reference (a, mx, ptr, ip4, ip6, exists, include, all) + 4 qualifiers + 2 modifiers. The comprehensive vocabulary deep dive that complements THIS decision-view page.
• MX records explained — the dedicated DNS-record deep dive on the MX resource record class that the mx: mechanism on this decision-view page evaluates against. Where this page documents WHICH of the four IP-providing mechanisms to pick between (include: / ip4: / a: / mx:) and warns that the "MX is also outbound" pattern is the seven-most-common-mistakes-list #1 anti-pattern for cloud-mail tenants, the MX records page documents the underlying record class itself: the RFC 1035 section 3.3.9 wire format (16-bit preference + RDATA target), the canonical multi-MX failover pattern with preference values (10 / 20 / 30), the implicit-MX-from-A fallback rule when no MX is published (RFC 5321 section 5.1), and the cloud-mail "MX points at provider" pattern that breaks the "MX is also outbound" assumption — Google Workspace publishes aspmx.l.google.com + 4 backup MXs for INBOUND only, Microsoft 365 publishes example-com.mail.protection.outlook.com for INBOUND only, and neither provider accepts outbound mail FROM those MX targets. Reading the MX records page directly explains WHY using mx for cloud-mail tenants is the canonical mistake this decision page calls out: the IPs at the cloud-provider's inbound MX targets are inbound-only and will never appear as the connecting IP for outbound mail from your domain.
• SPF qualifiers explained (+, -, ~, ?) — the focused deep dive on the four RFC 7208 §4.6.2 qualifier prefixes (+ Pass, - Fail, ~ SoftFail, ? Neutral) that precede every mechanism token this decision-view page documents. Where this page answers "which of the four IP-providing mechanisms should I use", the qualifiers page answers "what enforcement strength should I attach to each mechanism" — the orthogonal axis of the SPF authoring decision tree. The qualifiers page covers per-mechanism qualifier overrides (e.g. +include:_spf.google.com -ip4:198.51.100.0/24 ~mx -all mixes Pass, Fail, SoftFail, and Fail across the same record), the ~all vs -all end-of-record decision (the single most consequential operator choice for SoftFail-vs-Fail enforcement posture), and the receiver-side enforcement behaviour each qualifier triggers (the ~ SoftFail semantics of "do not hard-reject but DO mark suspicious" per RFC 7208 §2.6.5 vs the - Fail semantics of "explicit reject" per §2.6.4). Read the qualifiers page alongside this mechanism-decision page when authoring your SPF record from scratch: pick the four IP-providing mechanisms HERE, attach the qualifier strength THERE — the full SPF authoring loop closes with both pages applied together.
• SPF DNS record syntax — TXT encoding, character-string boundaries, ABNF — the wire-format reference that complements this mechanism-choice page. Where this page documents WHICH of the four IP-providing mechanisms (include:, ip4:, a:, mx:) the operator should publish for their environment, the DNS-syntax page documents HOW the chosen mechanisms are encoded at the TXT-RR wire-format layer: the 255-octet character-string limit and the multi-string concatenation rule (RFC 7208 §3.3) that matter when a long ip4:-heavy record grows past one character-string, the single-TXT-RR rule (RFC 7208 §4.5) that prevents publishing two SPF records, the per-mechanism ABNF in RFC 7208 §12 that defines legal token syntax, and the worked examples that show valid multi-string-concatenated records, redirect= chains, and IDN A-label encoding. Read the DNS-syntax reference when publishing a freshly- chosen mechanism set: the choice this page recommends only takes effect at receivers after a syntactically-valid record reaches them.
• SPF lookup limit explained — the RFC 7208 §4.6.4 10-DNS-lookup cap, the cumulative cost accounting, and the SPF flattening playbook for stacks that exceed the cap.
• SPF permerror vs temperror — the focused diagnostic deep dive on the two error result codes. Exceeding the 10-lookup cap is the most common cause of permerror; choosing the wrong mechanism is a frequent contributor.
• SPF forwarding issues — the SRS / ARC / MUNGE / .forward catalogue. Mechanism choice does not fix forwarder failures — that requires ARC.
• SPF for Microsoft 365 — the Microsoft-365-specific deployment guide. The canonical answer is include:spf.protection.outlook.com; this guide expands on third-party-sender configuration and hybrid deployments.
• MTA-STS for Microsoft 365 — the M365-TENANT-CROSS-LAYER-AUTHORIZATION COMPANION reference. Where THIS page documents the SPF mechanism-selection decision tree at the SENDER-SIDE OUTBOUND-IP-AUTHORISATION layer (the operator authoring the SPF record selects among include: / ip4: / a: / mx: mechanisms to authorise which sender IPs may use the apex domain in the MAIL-FROM envelope), the MTA-STS-for-M365 spoke is the STRUCTURALLY-ORTHOGONAL AUTHORISATION REFERENCE at the M365-tenant RECEIVER-SIDE INBOUND-MX-AUTHORISATION layer — the policy-file mx:-line allow-list per RFC 8461 §3.2 (e.g. mx: *.mail.protection.outlook.com) authorises which sending MTAs may TLS-handshake with the M365-tenant inbound MX, structurally orthogonal to the SPF mechanism-choice this page covers at FOUR M365-tenant-specific cross-layer-authorisation-coordination dimensions: (i) SPF include:spf.protection.outlook.com authorising the M365-tenant outbound-IP pool → MTA-STS mx: *.mail.protection. outlook.com authorising the M365-tenant inbound-MX hostname-pattern — the outbound IP authorisation is per-IP at the SPF check (receiver looks up _spf.-published IP ranges and matches the connecting client IP), the inbound MX authorisation is per-hostname at the MTA-STS check (sender looks up MTA-STS policy file and matches the receiver MX hostname pattern against the mx: allow-list); BOTH bind the M365-tenant traffic at the per-tenant transport boundary but at structurally-distinct identity layers; (ii) SPF mx: mechanism co-authoring an outbound IP-set from the domain's MX records → MTA-STS mx: directive co-authoring an inbound MX-hostname-set published at the policy file — the SAME token mx: means two structurally- distinct things at the two protocol layers this cross-layer companion documents: SPF mx: in the v=spf1 record authorises the sender-side outbound IPs that the MX-record-published mail-servers resolve to (typically used to authorise the domain's own outbound mail servers at the SMTP-RCPT-TO boundary), MTA-STS mx: in the policy file authorises the receiver-side inbound MX hostname-patterns the sending MTAs may TLS- handshake with — the same token semantics diverge per protocol RFC; (iii) SPF 10-DNS-lookup-budget vs MTA-STS HTTPS- fetch-budget at M365-tenant publication boundary — the SPF authorisation- chain has the RFC 7208 §4.6.4 10-DNS-lookup ceiling the operator must guard against (each include: token costs at least 1 lookup; the spf.protection.outlook.com sub-include chain consumes ~2-3 lookups out of the 10-budget); the MTA-STS authorisation- chain has a structurally-distinct HTTPS-fetch- budget at the receiver-MX publication-side (the sending MTA fetches https://mta-sts.<m365-tenant>/. well-known/mta-sts.txt with a single HTTPS request per max_age window, no 10-lookup ceiling); the two authorisation-chain budget profiles complement each other at the M365-tenant publication boundary; (iv) SPF permerror vs MTA-STS mode: testing/enforce/none progression discipline at M365-tenant operator boundary — the SPF publication-time-syntax-error class produces spf=permerror at the receiver verifier (a binary success/fail outcome modulated by the receiver's local policy), the MTA-STS publication-time- error class is structurally-distinct because the RFC 8461 §3.2 mode-progression discipline (mode: none → mode: testing → mode: enforce) lets the M365- tenant operator validate the policy-file byte-shape AND mx: allow-list accuracy at the testing-mode boundary BEFORE escalating to enforce-mode where a publication-error blocks inbound traffic. Read THIS page when authoring the M365- tenant SPF record's outbound-IP authorisation mechanism choice; read the MTA-STS-for-M365 spoke for the M365- tenant-specific receiver-MX-allow-list authoring discipline that closes the transport-layer authorisation that SPF structurally does not address.
• MTA-STS for Google Workspace — the Workspace-tenant twin of the M365 cross-layer reference above: where this page documents the sender-side SPF mechanism-selection decision (include: / ip4: / a: / mx: authorising the apex domain's outbound-IP envelope), the Workspace MTA-STS spoke documents the structurally-orthogonal receiver-side authorisation — the policy-file mx: allow-list per RFC 8461 §3.2 (e.g. mx: *.google.com) authorising which sending MTAs may TLS-handshake with the Workspace-tenant inbound MX. SPF mechanism choice and the MTA-STS allow-list bind the same Workspace-tenant traffic at structurally-distinct identity layers.
• SPF for Google Workspace — the Google-Workspace-specific deployment guide. The canonical answer is include:_spf.google.com; this guide expands on the 3-level netblock expansion tree and multi-vendor lookup budgeting.
• DMARC for Google Workspace — the WORKSPACE-TENANT-INCLUDE- MECHANISM-AS-DMARC-SPF-ALIGNED-PASS- UPSTREAM-INPUT companion to this SPF-mechanism-selection reference. Where THIS page documents the RFC 7208 §5.2 SPF mechanism-selection guide (the include: vs ip4: vs a: vs mx: per-mechanism trade-off analysis, the per-receiver §5.2 recursive macro-expansion semantics, the §4.6.4 10-DNS-lookup ceiling budgeting per mechanism), the DMARC- for-Workspace spoke documents the per- tenant DMARC publication discipline at four per-tenant-include-mechanism-to- DMARC-SPF-aligned-pass coupling dimensions: (i) per-tenant include:_spf.google.com as the load-bearing canonical Workspace- tenant SPF mechanism — the Workspace-tenant apex SPF record consistently authorises Workspace- outbound mail via the include:_spf.google.com mechanism THIS page catalogues; the receiver-side recursive macro-expansion of _spf.google.com resolves to the 3-level netblock tree (_netblocks.google.com, _netblocks2.google.com, _netblocks3.google.com) whose per-IP membership at SPF evaluation time IS the per-message SPF-authenticated-envelope-MAIL-FROM identifier the Workspace DMARC SPF- alignment evaluation consumes; (ii) per-tenant cumulative 10-DNS-lookup-ceiling budget arithmetic with multi-ESP includes — the Workspace-tenant include:_spf.google.com mechanism THIS page documents consumes 4 of the 10 receiver-side DNS lookups (1 outer include + 3 inner netblock expansions); additional Workspace- tenant marketing-ESP includes (include:_spf.salesforce.com, include:mailgun.org, per-marketing-ESP includes) compete for the remaining 6-lookup budget; per-tenant SPF-permerror at the receiver-side BREAKS the Workspace DMARC SPF-alignment evaluation — the DMARC-for-Workspace spoke documents the per-tenant include-budget discipline that ensures every Workspace-outbound SPF evaluation stays under the §4.6.4 ceiling; (iii) per-tenant ~all softfail vs -all hardfail terminal qualifier choice as Workspace-tenant DMARC-rollout-phase-gated decision — the Workspace-tenant SPF record's terminal qualifier THIS page's mechanism-vs-qualifier guide catalogues is paired with the Workspace-tenant DMARC policy advancement gate: the ~all softfail is the canonical default during DMARC p=none monitoring mode (per-IP misconfigurations surface in the per-tenant DMARC RUA-aggregate- report stream without immediate receiver-side rejection); advancement to DMARC p=reject ENFORCEMENT mode typically pairs with -all hardfail; (iv) per-tenant Workspace Feb 2024 Google/Yahoo bulk-sender joint SPF-and-DMARC publication baseline — the Feb 2024 bulk-sender requirements enforce per-tenant SPF publication (the include:_spf.google.com mechanism THIS page catalogues) AND per-tenant DMARC publication (p=none minimum) at the same compliance checkpoint for Workspace-tenants sending ≥5000 messages/day to Gmail recipients — the DMARC-for-Workspace spoke documents the joint SPF-and-DMARC publication discipline that satisfies BOTH per-author-domain baselines at the same per-tenant rollout milestone. Read the DMARC-for- Workspace spoke alongside this include-vs-ip4-vs-a-vs-mx mechanism- selection reference when the Workspace-tenant operator is designing the per-tenant apex SPF record byte-grammar in service of the per-tenant DMARC SPF-aligned- pass cascade the DMARC-for-Workspace spoke's per-tenant DMARC publication discipline depends on.
• DMARC for SaaS senders — the MULTI-TENANT-ESP-INCLUDE-TOKEN- AUTHORING-DECISION-AND-CROSS-TENANT- AUTHORISATION-COORDINATION companion to this SPF-mechanism-selection guide. Where THIS page documents the mechanism-selection decision tree (include: vs ip4: vs a: vs mx:) and the canonical per-mechanism trade-off matrix, the saas-senders spoke is the MULTI-TENANT- PLATFORM CONSUMPTION REFERENCE documenting the OPERATIONAL EFFECT of the include: mechanism choice when a customer-domain SPF record cooperatively-extends multiple platform- published include tokens against the customer's 10-DNS-query budget. Four operationally-distinct SaaS-platform- specific include:-mechanism- consumption axes the spoke documents that THIS page's mechanism-selection decision tree individually references but never collectively interconnects: (i) per- platform published include-token catalogue — the spoke catalogues the canonical published include tokens per major SaaS platform (include:_spf.mailchimp.com for Mailchimp, include:spf.marketo.com for Marketo, include:_spf.klaviyo.com for Klaviyo, include:_spf.hubspotemail.net for HubSpot, include:_spf.salesforce.com for Salesforce Marketing Cloud, etc.) and the per-platform RECURSIVE-INCLUDE SUB-CASCADE cost in DNS-query budget that THIS page's include: mechanism documentation references in the abstract; (ii) cumulative customer-apex lookup-budget consumption across 5–8 platform tokens — the canonical operational anti-pattern whereby a marketing-driven customer- domain SPF record cooperatively-extends 5–8 distinct SaaS platform include tokens (each recursive sub-cascade consuming 2–4 lookups), pushing total DNS-query consumption past the RFC 7208 §4.6.4 10-query ceiling — the SPF-permerror root cause this page documents as a consequence of include: over-use at the customer-domain apex; (iii) cooperative-include-vs-ip4- flattening trade-off in the customer- apex authoring decision — the per-mechanism trade-off matrix THIS page documents in the abstract gains operational concreteness when the customer faces the choice between cooperatively-extending a platform's published include token (recursive lookup-budget consumption, automatic platform-IP-pool updates) versus per-platform SPF-flattening into ip4:/ip6: mechanisms (zero lookup cost, manual per-rotation update discipline, operator-managed monitoring of platform-IP-pool changes); and (iv) per-sub-tenant attribution gap in shared-pool include tokens — the operational gap whereby a customer-authorised platform's shared-tenant pool IPs (resolved via the published include token's recursive sub-cascade) produce per-message RUA-aggregate-report auth_results/spf=pass verdicts with no sub-tenant differentiation, leaving the customer-domain operator unable to attribute deliverability anomalies to the correct sub-tenant within the platform — a residual attribution problem the SPF-mechanism-selection- decision-tree THIS page documents structurally cannot resolve at the protocol layer. Read the saas-senders spoke when an operator authoring a customer-apex SPF record is weighing the include: mechanism choice against the lookup-budget ceiling, the platform-IP-pool update-discipline trade-off, or the sub-tenant attribution gap — the spoke is the canonical operational-consumption reference for the include: mechanism decision THIS page documents in the abstract.
• DMARC for shared hosting — the SHARED-HOSTING-TENANT-AT-CONTROL- PANEL-ZONE-EDITOR-SPF-MECHANISM-CHOICE- DECISION-VIEW companion to this four- mechanism comparison reference. Where THIS page documents the mechanism- selection decision tree (include: vs ip4: vs a: vs mx:) and the canonical per- mechanism trade-off matrix in protocol- precise terms, the shared-hosting deployment spoke documents the STRUCTURALLY-DISTINCT non-cPanel shared- hosting tenancy materialisation of the four-mechanism decision at the per- tenant per-control-panel (Plesk / DirectAdmin / ISPConfig / Webmin / Virtualmin / CWP) zone-editor TXT-record authoring boundary across FOUR shared- hosting-tenant-specific mechanism-choice dimensions: (i) per-tenant vendor-managed include:<hosting-vendor-pool> cascade as load-bearing baseline authoriser of the shared-IP egress pool — the shared-hosting tenant inherits the vendor-managed include: sub-record cascade (Plesk's include:_spf.plesk.com, DirectAdmin's per-virtual-host +a mechanism, ISPConfig's +mx +a default, Webmin/Virtualmin's per-domain include: default, CWP's per-account include: cascade) consuming 2-5 DNS lookups BEFORE the tenant supplements anything; THIS page's include: mechanism documentation references the cascade-cost accounting in the abstract, the shared-hosting spoke materialises it at the per-tenant per-vendor-pool inherited-cascade-budget consumption layer with the per-control-panel-vendor published cascade-cost catalogue; (ii) per-tenant supplemental ip4:<CIDR> authoring for outbound-relay IPs the control-panel does not enumerate — when the per-tenant outbound mail egresses via a sibling SaaS-mailer the control-panel does not vendor-manage (the tenant's own VPS at a separate IaaS provider, a third- party transactional-ESP, a marketing- automation platform with a per-tenant dedicated IP), the tenant must supplement the vendor-inherited cascade with explicit ip4:<CIDR> blocks at the per-control-panel zone- editor TXT-record field using the RFC 7208 §5.6.1 ip4-network format byte-precise — the include:-vs-ip4: mechanism-choice trade-off THIS page documents in the abstract gains operational concreteness at the per- tenant per-control-panel zone-editor TXT-record authoring boundary where the tenant types literal SPF-record bytes with NO GUI abstraction layer; (iii) per-tenant a:-vs- mx: mechanism-choice for per-tenant-owned per-virtual-host A-RR / MX-RR authorisation — when the per-tenant application stack publishes a per-virtual-host A-RR or MX-RR (the per-tenant blog.<tenant>, shop.<tenant>, support.<tenant> subdomain stack), the tenant chooses between a:<virtual-host> and mx:<virtual-host> mechanism authorisation to extend the SPF authoriser-set to the per-virtual- host outbound paths; THIS page's a: vs mx: per-mechanism semantics catalogue is the canonical reference the per-tenant operator pivots on when authoring the per-virtual-host SPF supplementation; and (iv) RFC 7208 §4.6.4 10- DNS-lookup ceiling enforcement at the per-tenant supplemental-cascade boundary for the shared-hosting tenant population — the shared-hosting tenant inherits 2-5 lookups from the vendor-managed cascade BEFORE adding per-tenant supplemental include: / a: / mx: tokens, producing a TIGHTER per-tenant supplemental-cascade budget than the dedicated-tenant case — the shared-hosting tenant's per-tenant mechanism-choice between cooperatively-extending an additional include: token (recursive sub-cascade lookup-budget consumption) versus flattening into per-tenant ip4:<CIDR> blocks (zero lookup cost, manual per-rotation update discipline) is the canonical operational decision THIS page's per- mechanism trade-off matrix governs at the shared-hosting tenant population. Pair THIS four-mechanism comparison reference with the shared-hosting deployment spoke when authoring the per-tenant SPF record at the per- control-panel (Plesk / DirectAdmin / ISPConfig / Webmin / Virtualmin / CWP) zone-editor TXT-record field — the per- mechanism decision THIS page documents IS the per-tenant SPF authoring discipline the shared-hosting deployment guide's Phase-1 SPF-prerequisite step demands every tenant complete BEFORE the DMARC publication at the per- tenant _dmarc.<tenant> TXT-record publication boundary.
• Why SPF alone is insufficient — the four structural limitations of SPF that motivate the DMARC + DKIM + ARC additions to the email-authentication stack.
• DKIM explained — the cryptographic-signing companion to SPF. Modern email-authentication best practice is to publish BOTH SPF and DKIM.
• DMARC alignment explained — the identifier-alignment deep dive (strict vs relaxed for both adkim and aspf). SPF alignment depends on the SPF-authenticated MAIL FROM domain matching the From: header domain.
• DMARC record tags explained — the DMARC tag-by-tag reference (p, sp, np, pct, rua, ruf, adkim, aspf, fo, ri, rf). SPF and DKIM are the two underlying authentication mechanisms DMARC consumes.
• 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 mechanism, qualifier, modifier, MAIL FROM, From: header, organisational domain, alignment, and every other vocabulary item this page uses.
• DKIM DNS-record syntax — the DKIM-MESSAGE-LAYER-DNS-RECORD-BYTE- GRAMMAR-AS-LOAD-BEARING-SIBLING- AUTHENTICATION-RECORD-PUBLICATION- DISCIPLINE-TO-SPF-INCLUDE-IP4-A-MX- MECHANISM-BYTE-GRAMMAR-AT-FOUR-PER-DNS- RECORD-BYTE-GRAMMAR-DISCIPLINE-DIMENSIONS companion to this SPF mechanism-breakdown reference. Where THIS page architectures the per-publisher per-domain SPF TXT-record mechanism-byte-grammar discipline (the include: indirection mechanism, the ip4: / ip6: literal-CIDR mechanism, the a forward-DNS-A-record mechanism, the mx forward-DNS-MX-record mechanism, the per-mechanism DNS-lookup cost contributing to the RFC 7208 §4.6.4 10-lookup limit), the DKIM-DNS-record- syntax spoke is the MESSAGE-LAYER per- publisher per-selector TXT-record-byte- grammar reference STRUCTURALLY PARALLELING this SPF byte-grammar discipline at FOUR per-DNS-record-byte-grammar-discipline dimensions: (i) per-publisher per- name FQDN publication-location discipline — DKIM at <selector>._domainkey.<d-tag> per RFC 6376 §3.6.1 vs SPF at the per- domain apex / subdomain <d> per RFC 7208 §3.1 — the DKIM-DNS-record-syntax spoke documents the per-publisher per-selector forward-DNS FQDN publication-location STRUCTURALLY PARALLELING the per- publisher per-domain SPF forward-DNS FQDN publication-location this page documents; both are per-publisher per- name FQDN-publication primitives the receiver-side validator consumes by NAME LOOKUP at the canonical location (one selector-FQDN per signing tenant for DKIM vs one apex-or-subdomain-FQDN per scope for SPF); (ii) per- publisher per-record tag-list-vs- mechanism-list byte-grammar discipline — DKIM tag-list (v=DKIM1; k=rsa; p=<base64>; h=sha256) per RFC 6376 §3.6.1 vs SPF mechanism-list (v=spf1 include:_spf.example.com ip4:198.51.100.0/24 a mx -all) per RFC 7208 §4-§5 — the DKIM- DNS-record-syntax spoke documents the per-publisher per-selector semicolon- delimited tag-value-pair byte-grammar discipline (each tag name + = + value, terminated by ;, whitespace-tolerant) STRUCTURALLY PARALLELING the per-publisher per- domain whitespace-delimited mechanism- list byte-grammar discipline this page architectures (each qualifier-prefixed mechanism name + optional : + optional value, terminated by whitespace); both are per-publisher per- record TXT-record-byte-grammar publication-discipline primitives the receiver-side validator parses deterministically; (iii) per- publisher per-record 255-octet character- string-fragmentation discipline — DKIM and SPF share the same DNS-TXT-record 255-octet character-string-fragmentation rule per RFC 1035 §3.3.14 / RFC 6376 §3.6.2.2 / RFC 7208 §3.3, with per- publisher concatenation discipline at the receiver-side validator — the DKIM-DNS-record-syntax spoke documents the per-publisher per-selector 255-octet character-string-fragmentation discipline STRUCTURALLY IDENTICAL to the per-publisher per-domain SPF 255-octet character-string-fragmentation discipline; both are per-publisher per- record DNS-TXT-record-byte-string- fragmentation publication-discipline primitives the receiver-side validator concatenates before parsing the tag-list / mechanism-list payload; (iv) per-publisher per-record cardinality discipline — DKIM allows exactly one TXT record per selector-FQDN per RFC 6376 §3.6.2.2 vs SPF allows exactly one v=spf1 TXT record per scope per RFC 7208 §3.2 — the DKIM-DNS-record-syntax spoke documents the per-publisher per- selector cardinality discipline (one canonical TXT record per <selector>._domainkey.<d> FQDN; duplicate or conflicting records cause receiver-side permerror) STRUCTURALLY PARALLELING the per- publisher per-domain SPF cardinality discipline this page architectures (one canonical v=spf1 TXT record per scope; duplicate v=spf1 records cause receiver-side permerror); both are per- publisher per-name TXT-record-cardinality publication-discipline primitives the receiver-side validator enforces. Read the DKIM-DNS-record-syntax spoke when publishing or auditing a per-publisher per-domain SPF mechanism-list ALONGSIDE a per-publisher per-selector DKIM tag- list publication — both are per- publisher TXT-record-byte-grammar publication-discipline primitives whose per-record byte-grammar choices the receiver-side validator parses to produce the per-message authentication- results header DMARC alignment depends on.
• Email deliverability — the PER-PUBLISHER-SPF-MECHANISM- CHOICE-AS-LOAD-BEARING-UPSTREAM- DETERMINANT-OF-PER-PUBLISHER-PER- MAILBOX-PROVIDER-DELIVERABILITY- BASELINE companion reference. Where THIS page documents the per-publisher SPF mechanism-choice decision-matrix discipline (the per-publisher per- record per-mechanism authoring choice among include: / ip4: / ip6: / a / mx / ptr / exists: mechanism tokens — their RFC 7208 §4 per-mechanism evaluation-determinism properties, per-mechanism DNS-lookup- cost contributions toward the RFC 7208 §4.6.4 ten-lookup limit, per- mechanism qualifier-prefix authoring choice + / ~ / - / ?, per- mechanism per-record per-publication- event byte-grammar publication discipline), the email-deliverability spoke documents the per-publisher per- mailbox-provider per-day deliverability- baseline outcome (the per-publisher per- receiver-mailbox-provider per-day delivery-placement-rate aggregate signal each per-publisher's per- mailbox-provider per-message SPF- aligned-pass-rate floor manifests at), across four per-SPF-mechanism-choice- to-per-publisher-per-mailbox-provider- deliverability-baseline-coupling dimensions: (i) per-publisher- SPF-mechanism-choice-as-load-bearing- determinant-of-per-publisher-per- mailbox-provider-SPF-aligned-pass-rate- floor — the per-publisher SPF mechanism-choice authoring discipline THIS page documents directly determines the per-publisher per-receiver-side per-message SPF-aligned-pass-rate floor at Gmail / Yahoo / M365 / Apple Mail / Fastmail (per-mechanism evaluation determinism, per-mechanism DNS-lookup- cost reliability, per-mechanism per- record byte-grammar correctness all feed the per-publisher per-receiver- side per-message SPF-aligned-pass-rate floor); per-publisher SPF mechanism- choice authoring defects (excessive include-chain expansion, ptr-mechanism publication, qualifier-prefix mis- authoring) collapse the per-publisher per-mailbox-provider per-day SPF- aligned-pass-rate baseline directly degrading the per-publisher per- mailbox-provider deliverability floor; (ii) per-publisher-SPF-include- chain-expansion-as-load-bearing-input- to-per-mailbox-provider-RFC-7208- §4.6.4-ten-lookup-limit-cliff-edge- risk — per-publisher SPF include-chain authoring choices THIS page documents drive the per-publisher per-record cumulative DNS-lookup cost toward the RFC 7208 §4.6.4 ten-lookup ceiling; per-publisher per-record DNS- lookup cost crossing the ten-lookup ceiling at any per-receiver-side per- message SPF evaluation event produces per-message spf=permerror verdict that collapses the per- publisher per-mailbox-provider per-day SPF-aligned-pass-rate baseline, directly degrading the per-publisher per-mailbox-provider deliverability floor; (iii) per-publisher- SPF-mechanism-qualifier-prefix-choice- as-load-bearing-input-to-per-mailbox- provider-soft-fail-vs-hard-fail- delivery-placement-policy — per-publisher SPF qualifier-prefix choice THIS page documents (-all hard-fail vs ~all soft-fail vs ?all neutral) directly feeds per-receiver per-mailbox-provider per-message delivery-placement-policy decision-tree differently (-all with DMARC-fail triggers per-publisher p=quarantine / p=reject enforcement; ~all with DMARC-fail defers to receiver-side spam-filter scoring); per-publisher SPF qualifier- prefix authoring choices structurally determine per-receiver per-mailbox- provider per-message delivery- placement-policy outcomes; (iv) per-publisher-SPF-record-byte- grammar-publication-discipline-as- load-bearing-input-to-per-receiver- side-SPF-evaluator-parser-determinism — per-publisher SPF record byte- grammar publication discipline THIS page documents (per-record per- mechanism token byte sequence correctness, per-mechanism qualifier- prefix byte placement, per-mechanism operand byte-correctness, per-record TXT-record byte-length budget) directly determines per-receiver-side SPF- evaluator parser-determinism across Gmail / Yahoo / M365 / Apple Mail / Fastmail per-receiver-side per-message SPF evaluation events; per-publisher SPF record byte-grammar publication defects collapse per-receiver-side per- message SPF evaluation determinism, cascading per-publisher per-mailbox- provider per-day SPF-aligned-pass-rate baseline collapse and per-publisher per-mailbox-provider deliverability- baseline degradation. Read this WITH the per-publisher SPF mechanism-choice decision-matrix reference when the per-publisher per-mailbox-provider deliverability-baseline floor design sequence reaches the operator's queue: THIS page documents the per-publisher SPF mechanism-choice authoring discipline, the email-deliverability spoke documents the per-publisher per- mailbox-provider deliverability- baseline outcome whose SPF-aligned- pass-rate floor is STRUCTURALLY DETERMINED by the per-publisher SPF mechanism-choice authoring discipline THIS page documents.
• Reverse DNS / PTR records for mail servers — the PER-PUBLISHER-PER-SENDING-IP- IDENTITY-LAYER REVERSE-ZONE-PUBLICATION- DISCIPLINE companion documenting the IN-ADDR.ARPA / IP6.ARPA reverse-zone PTR-record publication discipline whose Forward-Confirmed reverse DNS (FCrDNS) verification operates on the SAME per-publisher per-sending-IP set THIS page documents the SPF FORWARD-ZONE publication-authoring discipline for. Where THIS page documents the per- publisher SPF FORWARD-zone mechanism- choice authoring discipline (the per- record per-mechanism authoring choice among include: / ip4: / ip6: / a / mx / ptr / exists: tokens that ultimately ENUMERATE the per-publisher per-domain authorised sending-IP set), the reverse-DNS-PTR spoke documents the STRUCTURALLY- PAIRED PER-PUBLISHER PER-SENDING-IP REVERSE-ZONE PUBLICATION DISCIPLINE that EVERY per-publisher per-sending-IP enumerated by the SPF mechanism-choice authoring discipline THIS page documents ALSO REQUIRES — across four per-SPF-IP- mechanism-choice-vs-per-publisher-PTR- record-publication-discipline-coupling dimensions: (i) per-publisher- SPF-FORWARD-zone-mechanism-choice-as- per-publisher-per-sending-IP-set- enumerator-vs-per-publisher-PTR- REVERSE-zone-publication-discipline- as-per-sending-IP-identity-publisher — the per-publisher SPF FORWARD-zone mechanism-choice authoring discipline THIS page documents (include: / ip4: / a / mx mechanism-choice authoring) ULTIMATELY ENUMERATES the per-publisher per-domain authorised sending-IP set; the reverse-DNS-PTR spoke documents the per-sending-IP- identity-publisher discipline that EVERY one of those enumerated per- publisher per-sending-IPs ALSO REQUIRES at the IN-ADDR.ARPA / IP6.ARPA reverse- zone publication boundary (the per- sending-IP per-PTR-record byte-grammar publication discipline whose FCrDNS verification is INDEPENDENT of the per-publisher SPF FORWARD-zone-mechanism choice but operates on the SAME per- publisher per-sending-IP set); (ii) per-publisher-SPF- ptr-mechanism-prohibition- per-RFC-7208-§5.5-vs-per-publisher-PTR- reverse-zone-publication-discipline — RFC 7208 §5.5 DEPRECATES the ptr SPF FORWARD-zone mechanism (the SPF evaluator side querying PTR records during SPF check_host); per-publisher SPF authoring discipline THIS page documents therefore EXCLUDES ptr mechanism authoring from per-publisher SPF records; BUT the per-publisher PTR- record reverse-zone PUBLICATION discipline (the per-sending-IP per-PTR- record authoring publishers DO maintain in the IN-ADDR.ARPA reverse zone) is STRUCTURALLY ORTHOGONAL — it survives the SPF-ptr-mechanism deprecation because PTR record publication is consumed by FCrDNS verification at the receiver-side connecting-IP-identity check layer, not by SPF evaluation; the reverse-DNS- PTR spoke documents WHY publishers STILL maintain per-sending-IP PTR-record publication despite SPF ptr-mechanism prohibition; (iii) per-publisher-SPF- FORWARD-zone-record-byte-grammar- publication-discipline-vs-per-publisher- PTR-REVERSE-zone-record-byte-grammar- publication-discipline — both layers require structurally-analogous per-publisher per-record byte-grammar publication discipline at the authoritative DNS zone boundary; per-publisher SPF FORWARD-zone TXT-record byte-grammar publication discipline (the per-record v=spf1 version-prefix-byte sequence, per-mechanism token byte correctness, per-record TXT-record byte-length budget) THIS page documents STRUCTURALLY PARALLELS the per-publisher PTR-RR REVERSE-zone byte-grammar publication discipline (per-sending-IP per-PTR-RR FQDN-target byte correctness, per-RR TTL discipline, per-publisher per-sending-IP-block FCrDNS round-trip forward-then-reverse byte-match discipline); (iv) per-publisher- per-sending-IP-set-enumerated-by-SPF- FORWARD-zone-mechanism-choice-vs-per- sending-IP-FCrDNS-verification-outcome- as-per-receiver-IP-reputation-aggregate- floor-determinant — every per- publisher per-sending-IP enumerated by the per-publisher SPF FORWARD-zone mechanism-choice authoring discipline THIS page documents is INDEPENDENTLY evaluated at the per-receiver per- message connecting-IP FCrDNS verification layer; per-publisher SPF FORWARD-zone mechanism-choice authoring discipline (perfect include: / ip4: / a mechanism-choice authoring) achieves per-message SPF-aligned-pass verdict but per-sending-IP FCrDNS-misalignment STILL drives per-receiver per-mailbox- provider per-day IP-reputation-aggregate floor degradation — the per-publisher operator-debugging workflow MUST evaluate the per-publisher SPF FORWARD- zone mechanism-choice authoring discipline (THIS page) AND the per- publisher PTR REVERSE-zone publication discipline (the reverse-DNS-PTR spoke) SEPARATELY as STRUCTURALLY-PAIRED per- publisher per-sending-IP publication disciplines whose joint correctness determines the per-publisher per- receiver-side per-message authentication outcome AND the per-publisher per- receiver-mailbox-provider per-day IP- reputation-aggregate floor.
• DMARC for cPanel — the PER-CPANEL-TENANT-PER-DOMAIN-SPF- MECHANISM-CHOICE-AUTHORING-WORKFLOW companion to this include-vs-ip4-vs-a-vs- mx decision-matrix reference. Where THIS page documents the four-mechanism-token SPF authoring decision matrix (include: delegate-to- sender-SPF, ip4:<CIDR> hard-code-the-IP-block, a:<hostname> delegate-to-A-record-lookup, mx:<domain> delegate-to-MX-record-hosts) and the per-mechanism lookup-cost / freshness / operator-burden / security trade-off matrix, the cPanel deployment guide documents the control-panel-operator- facing instantiation of the mechanism- choice decision against the per-cPanel- tenant per-domain SPF record (the per- cPanel-server outbound IP authorisation typically published as ip4:<cpanel-server-cidr> for static cPanel-server outbound IP blocks OR a:<cpanel-server-hostname> for dynamic-IP cPanel-server hosts, plus per-tenant per-domain secondary-sender include:<esp-spf-domain> tokens for SaaS senders the per-cPanel- tenant operator adds through the WHM/cPanel Email Deliverability UI's per-tenant per-domain SPF record editor). Pair this include-vs-ip4-vs-a-vs-mx decision-matrix reference WITH the cPanel deployment guide when AUTHORING per-cPanel-tenant per-domain SPF records whose per-tenant per-domain mechanism- choice composition must traverse the WHM/cPanel Email Deliverability control- panel UI's operator-facing SPF authoring workflow — the per-cPanel-tenant per- domain SPF mechanism-choice authoring decision is the LOAD-BEARING per-tenant per-domain ten-DNS-lookup-budget management discipline every per-cPanel- tenant per-domain DMARC enforcement ramp STRUCTURALLY DEPENDS on for the per-message SPF-aligned-pass-rate floor that gates the per-publisher per- receiver-side per-message authentication outcome.
• CAA records explained — the APEX-ZONE-AUTHORIZATION-RR-CLASS-PEER companion to this SPF mechanism-choice decision matrix. Where THIS page architects the per-publisher per-domain SPF TXT-RR mechanism-choice authoring decision (the include: vs ip4: vs a: vs mx: decision matrix and the per-mechanism DNS-lookup-cost accounting against the RFC 7208 §4.6.4 ten-DNS-lookup budget), the CAA-records-explained spoke is the apex-zone TLS-chain authorization-RR-class peer reference documenting the per-publisher per-domain apex-zone CAA RR publication primitive that coexists with the SPF TXT-RR at the SAME authoritative-DNS apex-zone publication boundary. Joint apex-zone SPF + CAA publication discipline forms the per-publisher per-domain dual-RR-class zone-editor commit cadence covering both the per-message envelope-MAIL-FROM authorization surface (SPF mechanism tokens) and the per-tenant X.509- certificate issuance-authorization surface (CAA property tags) — the per-publisher per-domain apex-zone authorization-RR- class publication discipline architect must coordinate BOTH RR classes at the same per-domain zone-editor publication cadence to maintain the per-publisher per-domain canonical apex-zone authorization-record-class deployment posture.
• Domain Security Checker — verifies your SPF record (mechanism count, cumulative DNS-lookup cost, alignment with DMARC) plus the full SPF / DKIM / DMARC / BIMI / MTA-STS / TLS-RPT / CAA stack.
• DNS Record Generator — the SPF record-generator wizard (Enterprise plan). Interactive mechanism selection that applies this decision matrix.
• DMARC policy modes (p=none / p=quarantine / p=reject) — the SPF-MECHANISM-SELECTION-AS-PER- PUBLISHER-PER-DOMAIN-SPF-ALIGNED-PASS-RATE- FLOOR-PRECONDITION-FOR-DMARC-POLICY-MODE- RAMP-PHASE-ADVANCEMENT companion to THIS SPF mechanism-selection reference. Where THIS page documents the per-publisher per- domain SPF mechanism-selection decision tree (include: vs ip4: vs a: vs mx: per RFC 7208 §5.2–§5.5), the per-mechanism per-DNS-lookup-cost accounting against the RFC 7208 §4.6.4 ten-DNS-lookup permerror budget, and the per-mechanism-choice operational consequences for per-publisher per-domain SPF record-publication maintainability, the DMARC-policy-modes spoke documents the publisher-side three-state p=-tag enforcement-policy ladder (p=none observe-only, p=quarantine probation, p=reject terminal) whose per- phase advancement gate the per-publisher per-domain SPF mechanism-selection structurally co-authors at FOUR per- publisher per-domain envelope-layer-vs- application-layer policy-mode-ramp- coordination dimensions: (i) per- publisher per-domain SPF mechanism-choice's per-receiver per-message spf=pass result-rate as load-bearing per-publisher per-domain SPF-aligned-pass-rate input to the per-receiver per-message DMARC composite- pass evaluator at the per-publisher per- domain policy-mode-ramp phase-advancement readiness boundary — the per- publisher per-domain DMARC policy-mode-ramp phase advancement (p=none → p=quarantine → p=reject) is gated against the per-publisher per-domain SPF-aligned-pass- rate-floor + DKIM-aligned-pass-rate-floor UNION (the per-receiver per-message DMARC composite-evaluator passes the per-message DMARC verdict when EITHER per-message identifier-aligned SPF-pass OR per-message identifier-aligned DKIM-pass holds per RFC 7489 §3.1), so the per-publisher per-domain SPF mechanism-choice mid-ramp materially affects the per-message DMARC composite-pass result-rate at the per-receiver per-policy- mode disposition-verdict computation boundary; (ii) per-publisher per- domain include:-cascade explosion as RFC 7208 §4.6.4 ten-DNS-lookup spf=permerror trigger as per- receiver per-policy-mode rejection blast- radius compounder — under per- publisher per-domain p=quarantine or p=reject phase, every per- message spf=permerror increases the per-message non-SPF-aligned-pass count the per-receiver per-message DMARC composite- evaluator MAY disposition as quarantine or reject at the per-publisher per-domain receiver-side enforcement boundary, so per-publisher per-domain mechanism-selection emphasising ip4: + ip6: terminal-IP mechanisms over include:-cascade chains preserves the per-publisher per-domain SPF-aligned-pass-rate floor during per- policy-mode-ramp phase advancement; (iii) per-publisher per-domain SPF mechanism-publication mid-ramp as per- publisher per-domain DMARC policy-mode- ramp REGRESSION trigger — adding a new include: token to the per-publisher per-domain SPF record during per-publisher per-domain DMARC p=reject phase introduces NEW cumulative-DNS-lookup-budget surface area that MAY trip the ten-DNS-lookup spf=permerror cap and compound the per-receiver per-message rejection blast-radius, so per-publisher per-domain operator-discipline FREEZES per- publisher per-domain SPF record changes during per-policy-mode-ramp phase advancement OR pre-validates the per- publisher per-domain post-edit cumulative- lookup count before per-publisher per- domain SPF-record publication-commit; (iv) per-publisher per-domain per- receiver per-day RUA aggregate-XML report per-source-IP per-record row attribution as joint observability surface for SPF mechanism-choice + DMARC policy-mode-ramp phase enforcement-distribution evidence — the per-receiver per-day per-publisher per-domain RUA aggregate-XML report's per- source-IP per-record row attributes the per-message SPF-pass result to the per- publisher per-domain SPF mechanism-token that authorised the per-source-IP at the per-receiver per-message SPF check boundary, and the per-publisher per-domain operator reads the per-day per-receiver per-source-IP per-record disposition distribution to attribute per-policy-mode- ramp phase disposition-verdict variance to the per-publisher per-domain SPF mechanism- publication root cause. Read THIS SPF mechanism-selection reference when PUBLISHING the per-publisher per-domain SPF record discipline AND when GATING the per- publisher per-domain DMARC policy-mode-ramp phase advancement against the per-publisher per-domain SPF-aligned-pass-rate floor; read the DMARC-policy-modes spoke when COORDINATING the per-publisher per-domain application-layer DMARC enforcement-ramp phase advancement against the per-publisher per-domain envelope-layer SPF mechanism- selection readiness floor THIS page documents.
• DANE explained — the per-publisher per-domain DANE vs MTA-STS transport-layer mechanism- choice decision-matrix companion at four cross-layer mechanism-choice coupling dimensions.
• DKIM for Microsoft 365
• DNS propagation timelines
• DMARC attacker-bypass catalogue
• DKIM alignment with DMARC
• Email spoofing seven-technique attack catalogue
• TLS-RPT TXT-RR record-syntax
• MTA-STS policy file syntax — the PER-PUBLISHER-PER-POLICY-DOMAIN-MTA-STS-POLICY-FILE-MX-LINE-MX-PATTERN-PUBLICATION-DECISION-MATRIX-AS-STRUCTURALLY-PARALLEL-TRANSPORT-LAYER-MX-ALLOWLIST-PUBLICATION-DECISION-COMPANION-TO-PER-PUBLISHER-PER-DOMAIN-SPF-INCLUDE-VS-IP4-VS-A-VS-MX-ENVELOPE-MAIL-FROM-LAYER-MECHANISM-CHOICE-PUBLICATION-DECISION companion at four per-publisher per-domain MTA-STS-policy-file-mx-line-vs-SPF-mechanism-choice coupling dimensions: (i) per-publisher per-policy-domain MTA-STS policy-file mx: MX-pattern publication-discipline per RFC 8461 §3.2 (per-publisher per-policy-domain per-MX-host single-label-wildcard semantics — mx: *.mail.example.com matches mta1.mail.example.com but NOT mta1.eu.mail.example.com) IS structurally parallel transport-layer per-MX-host authorization-discipline publication-decision to per-publisher per-domain SPF mx-mechanism publication-decision per RFC 7208 §5.4 + include-cascade-target-mx publication-decision per RFC 7208 §5.2 THIS page documents the per-publisher per-domain envelope-MAIL-FROM-layer mechanism-choice publication-discipline of — both per-publisher per-domain per-MX-host publication-decisions are per-publisher per-domain operator-side per-MX-host authorization-discipline primitives at the per-publisher per-domain composite envelope-MAIL-FROM-layer-and-transport-layer per-MX-host coordination boundary; (ii) per-publisher per-policy-domain MTA-STS policy-file `mx:` line-list publication-discipline IS structurally parallel envelope-MAIL-FROM-layer authorization-list publication-discipline to per-publisher per-domain SPF mechanism-cascade-list publication-decision (include:-cascade-delegation vs ip4:-static-CIDR vs a:/mx:-DNS-resolution mechanism-class trade-offs THIS page documents the per-publisher per-domain mechanism-choice decision-matrix of) — both per-publisher per-domain per-MX-host-and-authorization-list publication-discipline references are per-publisher per-domain operator-side per-MX-host-authorization-list publication-discipline primitives at the per-publisher per-domain composite per-MX-host-authorization-list publication-decision-matrix coordination boundary; (iii) per-publisher per-policy-domain MTA-STS policy-file `mx:` line publication-discipline drift (per-MX-host wildcard-label crossing single-label-budget / per-MX-host MX-pattern omission cascading into per-receiver per-MX-host policy-failure) surfaces in per-publisher per-policy-domain TLS-RPT JSON-aggregate-report failure-type: sts-mx-mismatch attribution per RFC 8460 §4.3 IS structurally parallel publication-discipline-drift class to per-publisher per-domain SPF mechanism-choice publication-discipline drift (10-DNS-lookup-cap exhaustion / +all permissive-mis-publication / stale-CIDR-publication producing per-receiver per-day per-source-IP spf=permerror attribution per RFC 7208 §4.6.4) surfacing in per-publisher per-domain DMARC RUA aggregate-report policy_evaluated/spf=permerror attribution; (iv) per-publisher per-policy-domain MTA-STS policy-file mx:-line + per-publisher per-domain SPF mx-mechanism + per-publisher per-domain MX-RR cross-protocol publication-discipline triple JOINTLY underpins per-publisher per-domain composite cross-layer per-MX-host authorization-and-policy-publication-discipline floor — per-publisher per-domain composite cross-protocol cross-layer per-MX-host publication-discipline coordination cascades MTA-STS policy-file `mx:`-line publication into per-publisher per-domain transport-layer per-MX-host authorization-floor parallel to per-publisher per-domain SPF mx-mechanism publication into envelope-MAIL-FROM-layer per-MX-host authorization-floor at the per-publisher per-domain composite cross-protocol cross-layer per-MX-host publication-discipline coordination boundary the per-publisher per-domain SPF mechanism-choice decision-matrix THIS page documents the per-publisher per-domain envelope-MAIL-FROM-layer per-MX-host publication-discipline of structurally feeds into.
• DKIM key rotation
• BIMI logo SVG requirements — the include/ip4/a/mx mechanism choice this page weighs governs the SPF leg of the DMARC pass, and a sustained aligned-pass at enforcement (p=quarantine/p=reject) is the gate that lets a BIMI logo render at all. Get the SPF mechanism mix right so the authorization leg stays stable, then fit the logo asset to the SVG Tiny PS constraints documented on this spoke before it will paint in the inbox.
• DMARC monitoring — once the include/ip4/a/mx mechanism mix this page weighs is published, the RUA aggregate stream is how you confirm the SPF leg keeps passing as your senders, hosting IPs, and third-party services change over time. Monitoring surfaces the SPF-fail and SPF-permerror rows that signal a mechanism choice has drifted out of budget. Read the monitoring spoke to set up the ongoing watch over your published mechanism mix.
• DMARC for Office 365 hybrid (on-prem Exchange + Exchange Online) — the canonical dual-egress deployment where the include / ip4 / a / mx mechanism mix THIS page weighs is exercised under load: a hybrid tenant must authorise BOTH egress paths inside one SPF record — include:spf.protection.outlook.com for the Exchange Online outbound pool plus an ip4: (or a) mechanism for the on-prem Exchange Send Connector — all while staying under the RFC 7208 §4.6.4 10-lookup cap. The hybrid guide documents how that combined SPF leg coordinates with per-domain DKIM and the DMARC p=quarantine / p=reject enforcement ramp across the mixed-egress topology.
• 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 now

The fastest way to confirm your SPF record uses the right mechanism for each sender:

1. Enumerate your senders. List every system that originates mail as your domain (Microsoft 365 / Google Workspace, ESPs, helpdesks, CRMs, on-prem MTAs, monitoring systems).
2. For each sender, apply the decision matrix from section 7 to pick the right mechanism.
3. Use the Domain Security Checker to surface your current SPF record, the cumulative DNS-lookup cost, and any permerror conditions.
4. Inspect a real outbound message with the Email Header Analyzer to confirm the Authentication-Results header reports spf=pass for legitimate senders.