Hosted SPF

21 June 2026 · 28 min read

What "hosted SPF" means

SPF (Sender Policy Framework) is the DNS record that tells the world which mail servers are allowed to send email "from" your domain. Every mailbox provider - Gmail, Microsoft 365, Yahoo, and hundreds of smaller ones - checks it on every message they receive from you.

The trouble with SPF is not the concept. It's the maintenance. Every time you add a new sender - a new helpdesk tool, a new marketing platform, a new invoicing system - you have to go back into your DNS, edit a long space-separated string of include: mechanisms, and republish it without breaking the syntax or blowing past a hard limit that SPF itself imposes (more on that shortly). Get it wrong and legitimate mail from your own domain starts landing in spam, or bounces outright.

Hosted SPF removes that maintenance burden. Instead of publishing the actual SPF policy yourself, you publish one line that delegates the policy to DMARC Engine:

v=spf1 include:<slug>.spf.dmarcengine.com ~all

Everything after include: - the actual list of Google, Microsoft, SendGrid, Mailchimp, or whichever senders you use - lives on our infrastructure, not yours. When you add or remove a sender in the app, we update the record we serve instantly. Your DNS never needs to change again. Critically, we also flatten that include chain so it never trips SPF's 10-DNS-lookup ceiling - the single most common reason SPF records silently stop working.

This guide covers:

• How SPF actually works (mechanisms, qualifiers, evaluation order)
• Why the 10-lookup limit exists and how it breaks records in the real world
• How to set up hosted SPF for a domain, step by step
• How to add senders and merge an existing SPF record without losing anything
• The ~all vs -all decision and how to move safely between them
• How to verify your record is live and correct
• Troubleshooting permerror, too many DNS lookups, and other common failures
• An FAQ covering the questions we get most often

Tip: If you haven't yet set up DMARC itself, start there first - SPF is one of the two authentication signals DMARC checks (the other is DKIM), and DMARC is what actually tells receivers what to do with mail that fails. See the complete guide to DMARC and hosted DKIM if you haven't covered those yet.

---

SPF fundamentals: how a receiving mailbox checks your mail

When a receiving mail server gets a message claiming to be from yourdomain.com, it performs an SPF check against the envelope sender (the "MAIL FROM" address used in the SMTP transaction, which is often invisible to the end user and can differ from the visible "From:" header). The steps, in order:

1. The receiver looks up the domain's SPF record: a TXT record on the domain (or subdomain) that starts with v=spf1.
2. It walks through the mechanisms in that record, left to right.
3. The first mechanism that matches the sending IP address determines the result (qualifier) for the whole check. Mechanisms after the match are never evaluated.
4. If nothing matches by the time it reaches the end of the record, the trailing all mechanism applies - this is your default/fallback outcome.

A record only ever has one TXT value starting with v=spf1. Having two is invalid and causes an immediate permerror.

Mechanisms

Mechanisms are the building blocks inside the record. Each one describes a set of IP addresses (or a way of finding a set of IP addresses).

Warning: Avoid the ptr mechanism entirely. It's deprecated in RFC 7208 and consumes a DNS lookup for little benefit - it will only push you closer to the 10-lookup limit for no real gain.

Qualifiers

Every mechanism can be prefixed with a qualifier that decides what happens when it matches:

So include:_spf.google.com with no qualifier is shorthand for +include:_spf.google.com - a pass. The qualifier you'll spend the most time thinking about is the one on the final all mechanism, because it sets your domain's default posture for anything that doesn't match an earlier mechanism. We cover the ~all vs -all decision in its own section below.

Note: SPF qualifiers only ever apply to the SPF check itself. They do not, on their own, decide whether a message ends up in the inbox or is rejected - that's ultimately the receiving server's policy, shaped further by your DMARC record. A softfail can still land in the inbox; DMARC with -all behind it is what actually gives you teeth. See DMARC alignment for how SPF and DKIM results feed into that decision.

Worked example: evaluating a record top to bottom

Take this (deliberately mixed) example record:

v=spf1 ip4:203.0.113.10 -ip4:203.0.113.99 include:_spf.google.com ~all

Here's how a receiver actually works through it for a message claiming to be from your domain:

1. Is the sending IP 203.0.113.10? If yes, stop here - pass, mail accepted. This mechanism has no qualifier written, so it defaults to + (pass).
2. Is the sending IP 203.0.113.99? If yes, stop here - this one is explicitly prefixed -, so it's a hard fail, even though it's earlier in the record than the catch-all. Order matters more than which mechanism "sounds" more permissive.
3. Is the sending IP anywhere in Google Workspace's published ranges? (This is where the include: lookup happens - potentially several nested lookups depending on Google's own record.) If yes, pass.
4. Nothing matched by this point - fall through to ~all: softfail. The message is probably not from an authorised source, but most receivers will still accept it, likely with a spam-score penalty.

The key lesson: mechanisms are evaluated strictly in order, and the first match wins. A narrow, specific mechanism placed before a broader one can override it - which is exactly why some legacy records that look redundant (a specific -ip4: carve-out before a permissive include:) were written deliberately, often to block a single decommissioned server without waiting for its provider's shared record to update.

Tip: This ordering behaviour is also why simply appending a new include: to the end of an existing record is nearly always safe, but inserting one in the middle - ahead of a - mechanism - is the kind of edit that can quietly change behaviour for IPs you didn't intend to touch. With hosted SPF this isn't something you need to think about: the app manages ordering and evaluation for you and only ever exposes a flat list of senders to add or remove.

---

The 10-DNS-lookup limit - and why SPF records break

This is the part of SPF that catches almost everyone eventually, and it's the entire reason hosted SPF flattening exists.

RFC 7208 caps the number of DNS lookups a receiver is allowed to perform while evaluating your SPF record at 10. Mechanisms that count towards this limit:

• include:
• a
• mx
• ptr
• exists:

ip4:, ip6:, and all do not count - they're literal values or the terminal fallback, no lookup required.

Here's the problem in practice. Each include: doesn't just cost you one lookup for itself - the record it points to might contain its own include: mechanisms, each of which costs another lookup, and so on. A single include:_spf.google.com can itself resolve through several nested includes. Add Microsoft 365, then SendGrid for transactional mail, then Mailchimp for the newsletter, then your helpdesk platform, then a CRM, and you can blow past 10 lookups with a record that looks perfectly reasonable to read:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:servers.mcsv.net include:mail.zendesk.com include:spf.hubspotemail.net ~all

That looks like six mechanisms. In practice, several of those includes chain into two or three further lookups each, and the real total is easily 12-15.

Roughly, this is what common senders cost you in nested lookups once you add them via their standard include: (these numbers can and do shift as providers restructure their own records, which is itself part of the problem - a record that was safely under 10 can drift over the line without you touching it):

Add your own mx mechanism on top (common in older templates, to cover an on-prem relay) and you've spent another lookup before counting a single third-party sender. Five or six real-world senders is often all it takes to reach the ceiling - which is precisely why organisations with more than two or three sending platforms are the ones who hit this limit, usually without realising it until mail starts failing.

What happens when you exceed 10 lookups is not a "soft" degradation - it's total failure. Per the RFC, a receiver that hits the limit must return permerror for the entire SPF check, for every sender covered by every mechanism in the record, not just the one that pushed it over. That means your Google Workspace mail - which was fine on its own - can start failing SPF purely because a newsletter tool was added six mechanisms later in the same record.

Warning: permerror isn't a warning receivers treat gently. Combined with a DMARC policy at quarantine or reject, a permerror'd SPF check plus a DKIM misalignment is exactly the combination that gets legitimate mail bounced or spam-foldered. If you've ever had a sender "randomly" start failing with no code change on your end, an SPF record that quietly crossed 10 lookups when someone added one more include: is one of the most common causes.

The other subtlety: DNS resolvers don't always agree on the exact count, because nested includes can also depend on %{i} macros or exists: mechanisms with variable results. That means an SPF record sitting right at 9 or 10 lookups can pass at some receivers and permerror at others - an intermittent, maddening failure mode that's genuinely hard to debug by hand.

---

How hosted SPF flattening solves this

DMARC Engine's hosted SPF works by moving the complexity off your DNS and into ours:

1. In the app, you tell us which senders you use (Google Workspace, Microsoft 365, your ESP, your helpdesk, and so on) - either by picking them from a list or importing your existing record.
2. We resolve every one of those senders' SPF chains ourselves, on our infrastructure, and flatten the result down to the underlying ip4:/ip6: ranges wherever it's safe to do so, or to a minimal set of include: mechanisms where flattening isn't appropriate.
3. We serve the result from <slug>.spf.dmarcengine.com, kept permanently under the 10-lookup ceiling.
4. If a provider changes their published IP ranges (which happens more often than people expect), we detect it and update the served record automatically - you never have to notice or react.
5. Your domain's DNS only ever has one line, forever:

v=spf1 include:<slug>.spf.dmarcengine.com ~all

That one include: costs exactly one DNS lookup, no matter how many senders you add or remove behind it in the app. You could have two senders or twenty; your published record stays a single line and a single lookup.

Note: This is the same delegation pattern DMARC Engine uses for DMARC, DKIM, MTA-STS, and BIMI - you publish a CNAME (or, for SPF, an include: pointing at our subdomain) once, and we manage the served content going forward. See hosted DKIM for the equivalent pattern on DKIM selectors.

---

Set up hosted SPF, step by step

Before you start

Gather a list of everything that currently sends email using your domain in the "From:" address - not just your primary mailbox provider. Common categories people forget:

• Helpdesk / support ticketing tools (Zendesk, Freshdesk, Help Scout)
• Marketing/newsletter platforms (Mailchimp, Klaviyo, Constant Contact)
• Transactional email APIs (SendGrid, Postmark, Amazon SES, Mailgun)
• CRM and sales tools (HubSpot, Salesforce, Pipedrive)
• Invoicing/accounting software (Xero, QuickBooks, FreshBooks)
• HR/payroll platforms
• Any on-premises mail relay or application server that sends mail directly

Tip: The fastest way to build this list accurately is to look at your DMARC aggregate report data once reports start arriving - it shows you every source actually sending as your domain, including the ones nobody remembers signing up for. Check Analytics and Reports after a few days of DMARC monitoring.

Step-by-step: enabling hosted SPF for a domain

1. Sign in at app.dmarcengine.com and open Domains.
2. If the domain isn't added yet, click Add domain and enter it. Adding a domain automatically provisions its unique hosting slug, which you'll see referenced throughout the app and in the records below.
3. Open the domain and go to its SPF tab, or go directly to /spf and select the domain.
4. Add each sender from the list you built above. For well-known providers, pick them from the built-in catalogue (Google Workspace, Microsoft 365, SendGrid, Mailchimp, etc.) so we always resolve the current, correct include for that provider. For anything custom - your own mail server, an on-prem relay - add its IP address or range directly.
5. Once your senders are listed, the SPF builder shows you the exact TXT record to publish. It will look like this (with your real slug in place of <slug>):

   Type:  TXT
   Host:  @               (i.e. the bare domain, yourdomain.com)
   Value: v=spf1 include:<slug>.spf.dmarcengine.com ~all
   

1. Log in to your DNS provider (Cloudflare, GoDaddy, Namecheap, Route 53, your registrar, wherever your domain's nameservers point) and add that TXT record on the apex/root of the domain - not on a subdomain, unless you're specifically configuring SPF for a subdomain that sends mail independently.
2. If a TXT record already exists at the root starting with v=spf1, do not add a second one - replace it, or merge it first (see the next section). Multiple v=spf1 TXT records on the same host is invalid and causes permerror.
3. Save the DNS change. Propagation is typically minutes with most providers, though it can take up to 24-48 hours depending on your DNS host's TTL and any caching resolvers in between.
4. Back in the app, use the DNS Lookup tool to confirm the live record matches what was published. It will flag if it still sees your old record, a duplicate, or nothing at all.
5. Once confirmed, hosted SPF is live. From here on, manage senders entirely from /spf in the app - never touch the DNS record again for routine changes.

Note: Steps 6-8 are the only time you'll ever need to log into your DNS host for SPF, assuming you don't change registrars or migrate your nameservers. Every future sender addition or removal happens inside the app and takes effect immediately on our served record.

Adding a new sender later

1. Go to app.dmarcengine.com/spf and select the domain.
2. Click Add sender.
3. Choose the provider from the catalogue, or enter a custom IP/CIDR if it's a private mail server.
4. Save. The change is reflected in the record we serve from <slug>.spf.dmarcengine.com immediately - no DNS edit required on your side.
5. Optional but recommended: send a test email through the new sender and re-check SPF status on /lookup to confirm it now passes.

Removing a sender

1. Go to /spf, find the sender in the list.
2. Click Remove.
3. Confirm. This takes effect immediately - useful the moment you decommission a marketing platform or switch transactional email providers, since a stale include: left behind is a common way old, decommissioned infrastructure quietly stays "authorised" to send as your domain.

---

Merging an existing SPF record

If you already have a working (or half-working) SPF TXT record before switching to hosted SPF, don't just delete it - pull every real sender out of it first so nothing gets dropped.

1. Copy your current SPF record's full text. Example of what you might find:

   v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all
   

1. Go to /spf and use Import existing record (or add senders manually, one per mechanism found).
2. For each include: mechanism, add the corresponding provider in the app's catalogue (e.g. include:_spf.google.com → add "Google Workspace"; include:sendgrid.net → add "SendGrid").
3. For each ip4:/ip6: mechanism pointing at infrastructure you actually control, add it as a custom IP entry.
4. Ignore any a or mx mechanisms unless you're certain your web/mail server IPs are also used to send the mail in question - these are frequently leftover cruft from an old template and not doing anything useful.
5. Once every real sender from the old record has an equivalent entry in the app, follow the step-by-step setup above to publish the new single-line record, replacing the old one at your DNS host.
6. Keep the old record's text somewhere for a few days (a note, a ticket) in case you need to cross-check a sender you might have missed once real mail volume runs through the new setup.

Warning: Never publish both the old record and the new include:<slug>.spf.dmarcengine.com record at the same time as two separate TXT values starting with v=spf1. A domain must have exactly one SPF record. Two is an automatic permerror, exactly like the problem you're trying to fix.

---

~all vs -all: choosing your enforcement

The qualifier on the trailing all mechanism decides what happens to mail from a source that isn't in your SPF list at all.

Our hosted SPF builder defaults new records to ~all. That's deliberate: it gives you a safety net while you're still confirming you've captured every real sender, without silently blocking mail the moment you turn it on.

When to move to -all:

1. Run hosted SPF at ~all for at least a couple of weeks.
2. Watch your DMARC aggregate reports in Analytics for any sending source that shows an SPF failure you don't recognise or haven't yet added.
3. Add any missing senders in /spf as you find them.
4. Once reports are clean - every legitimate source passing, nothing unexplained failing - switch the builder's setting from ~all to -all. Since the record you publish never changes (still just the one include: line), this switch happens entirely inside the app; there's nothing to touch in your DNS.
5. Continue monitoring for a further cycle to make sure nothing was missed before you also move your DMARC policy itself towards enforcement.

Tip: -all on SPF alone doesn't reject mail on its own - SPF failing a message only matters as much as the receiver's local policy, or your domain's DMARC policy, decides it should. Moving SPF to -all is a meaningful step, but the real enforcement lever is your DMARC policy (p=quarantine or p=reject). See the DMARC enforcement playbook and will enforcing DMARC break my email? before ramping DMARC itself.

Warning: Never jump straight to -all on a brand-new domain, and never do it without at least one full monitoring cycle behind you. A sender you forgot - a one-off invoicing tool, a departmental newsletter list, a service account nobody documented - will have its mail hard-rejected the moment you do, with no warning to you unless you're watching aggregate reports.

---

The manual (self-managed) alternative

Hosted SPF is optional. If you'd rather manage the full include chain yourself, publish your senders' real SPF includes directly instead of delegating to us:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

This works, but you take on:

• Counting your own DNS lookups and keeping the total at or under 10 as you add senders (using the worked-example table above as a rough guide, and re-checking it whenever a provider changes their own record structure)
• Noticing (yourself) when a third-party provider changes their published SPF ranges - there's no notification for this; you find out when mail starts failing
• Editing your DNS every single time a sender is added, removed, or migrated, and waiting out propagation each time
• Manually flattening the record yourself if you get close to the limit - replacing include: mechanisms with the literal ip4:/ip6: ranges they resolve to, then keeping that flattened list in sync by hand as the provider's ranges change
• No single source of truth for "who is actually allowed to send as us" beyond the raw DNS text itself, which is a poor audit trail compared with a managed sender list

We'd recommend the manual route only if you have a specific reason to keep the raw record on your own infrastructure - for example, a compliance requirement that DNS content never be delegated to a third party, or a very simple setup with a single sender that's unlikely to ever grow. Otherwise, hosted SPF gives you the identical outcome - a valid, always-under-the-limit record - without the ongoing maintenance, and without the risk of a permerror reappearing months later because someone added "just one more" include: and nobody re-counted.

---

Verify it worked

1. Go to app.dmarcengine.com/lookup and enter your domain.
2. Confirm the tool shows a single v=spf1 TXT record at the root, and that its include: target matches <slug>.spf.dmarcengine.com.
3. Confirm the flattened lookup count reported by the tool is comfortably under 10 (with hosted SPF it should show as 1, since your published record only ever has the one include:).
4. Confirm the all qualifier matches what you intended (~all during rollout, -all once you've moved to enforcement).
5. Send a real test email from each of your major senders (primary mailbox provider, main ESP, any transactional sender) to an external mailbox you control - Gmail is a good, freely-available check.
6. In the received message, view the original/raw headers and look for Authentication-Results: - confirm spf=pass for each sender.
7. Give it a few days, then check /reports and /analytics for aggregate DMARC data confirming SPF is passing at scale, across real mail volume, not just your one test message.
8. If you're also running DMARC, use the free DMARC/SPF checker under Tools for a quick outside-in check that doesn't require logging in - handy for sharing a link with a colleague or client who wants to self-verify.

Note: SPF passing on a single test email doesn't guarantee every sender is covered - it only confirms the one path you tested. The aggregate report data in step 7 is what actually proves the whole domain is clean before you move to -all.

---

Common problems and fixes

Problem: permerror - too many DNS lookups
Your record (old, manually-managed one, most likely) exceeds the 10-lookup ceiling once nested includes are counted. Fix: switch to hosted SPF so your published record is a single include: (one lookup) regardless of how many senders sit behind it. If you're merging an existing record, see Merging an existing SPF record above.

Problem: Two SPF records on the same domain
Someone added a new TXT record instead of editing/replacing the existing v=spf1 one - often a marketing tool's setup wizard doing this automatically. Fix: check with /lookup, keep only one v=spf1 TXT record, merging any senders from the duplicate into it (or into the app if using hosted SPF).

Problem: SPF passes in testing but real customer mail still fails
Usually means a sending source isn't in your SPF list at all - a legacy system, an internal tool, or a source someone set up after your last review. Fix: check DMARC aggregate reports in /analytics for the failing source's IP, identify the service it belongs to, and add it as a sender in /spf.

Problem: SPF fails after switching email providers (e.g. migrating from one ESP to another)
The old provider's include: is still doing nothing useful and the new provider was never added. Fix: add the new provider's sender entry in /spf; remove the old one once migration is fully complete.

Problem: Mail sent via a "Send As" alias or forwarding fails SPF
This is expected and usually not fixable via SPF alone - SPF checks the envelope sender, and forwarding frequently changes or breaks that alignment at the forwarding hop. This is precisely the scenario DKIM (which survives forwarding, since it's a cryptographic signature rather than an IP check) and DMARC's relaxed alignment options exist to handle. Make sure DKIM is set up correctly - see hosted DKIM - so DMARC can still pass via DKIM alignment even when SPF can't survive the forward.

Problem: none result / no SPF record found
Either nothing has been published yet, propagation hasn't completed, or the record was added to the wrong host (a subdomain instead of the apex, or vice versa). Fix: re-check the exact host you published to; confirm with /lookup; allow up to 24-48 hours for full propagation if the record is genuinely new.

Problem: Record looks fine but still shows permerror at some receivers and not others
Almost always a borderline lookup count (sitting right at, or just over, 10) combined with a receiver whose nested resolution differs slightly - a classic symptom of an unflattened record. Fix: move to hosted SPF, which removes the ambiguity entirely by keeping your published record at a fixed one-lookup count.

Problem: A sender says their SPF include changed and now nothing matches
Third-party providers occasionally change their published SPF ranges (adding new sending infrastructure, migrating cloud regions, etc.). With a manually-managed record, this is invisible until mail starts failing. With hosted SPF, we track and reflect provider changes automatically, so this class of failure shouldn't recur once you've switched.

---

Frequently asked questions

Do I need SPF if I already have DKIM set up?
Yes. DMARC only requires one of SPF or DKIM to pass (with correct alignment) for a message to pass DMARC overall - but relying on DKIM alone leaves you exposed if a sending platform ever fails to sign correctly, and some receivers still weight SPF meaningfully in spam filtering independent of DMARC. Run both. See hosted DKIM if it isn't set up yet.

Will switching to hosted SPF break my mail while it propagates?
No, as long as you don't remove the old record before the new one is confirmed live. Publish the new include:<slug>.spf.dmarcengine.com record in place of the old one in a single DNS edit, then confirm with /lookup. There's no window where both need to coexist.

Can I still see the actual list of IPs/senders behind my flattened record?
Yes - the full, human-readable sender list is exactly what you manage on /spf in the app. The flattened DNS output is what receivers see; the readable list is what you edit.

What happens if I exceed some huge number of senders - does hosted SPF ever hit the limit itself?
The one-lookup published record never grows, regardless of how many senders you add behind it, because flattening resolves them down to ip4:/ip6: ranges (or minimal includes) at serve time rather than stacking include: mechanisms in what we publish.

Do I need to update my SPF record if a provider like Google or Microsoft changes their sending IPs?
Not with hosted SPF - we track upstream changes for supported providers and update the served record automatically. With a manually-managed record, yes, you'd need to catch and republish that change yourself.

Should subdomains have their own SPF record?
Only if a subdomain sends mail independently of the parent domain and needs its own authorisation list. Most organisations only need SPF on the apex domain plus, in some setups, a few specific subdomains used for bulk/marketing mail. Add a domain entry per subdomain in /domains if that applies to you.

Does SPF alone stop phishing/spoofing of my domain?
No - SPF only authorises sending IPs for the envelope sender; it doesn't, by itself, control what happens to unauthorised mail, and it doesn't protect the visible "From:" header a recipient actually sees unless DMARC alignment is enforced on top of it. DMARC is what ties SPF (and DKIM) results to real enforcement action. See stopping email fraud (BEC, phishing, spoofing) and DMARC alignment.

Can I check another domain's SPF setup without logging in?
Yes - the free DMARC/SPF/DKIM checker under Tools works on any public domain, no account required.

I moved from ~all to -all and now something's broken - can I roll back?
Yes, instantly - flip the setting back to ~all in the SPF builder at /spf. Because your published DNS record never changes text, there's no propagation delay for this rollback the way there would be for a manually-managed record.

Does hosted SPF work alongside a manually-managed DKIM or DMARC record, or do I need all three hosted?
They're independent. You can host SPF while self-managing DKIM or DMARC, or any combination. Each service's setup page - /spf, /dkim, /dmarc - always shows both the hosted CNAME/include option and the manual record as an alternative.

How is hosted SPF different from just shortening my record by hand?
Manual flattening (replacing include: mechanisms with the literal IP ranges they resolve to) is a legitimate technique, but it's a one-time snapshot - the moment the underlying provider changes their sending ranges, your hand-flattened record is stale and you won't know until mail starts failing. Hosted SPF re-resolves and re-serves the flattened result continuously, so it never goes stale.

Does adding hosted SPF change anything about how my mail is actually sent?
No. SPF, hosted or not, only affects how receivers verify who's allowed to send as your domain - it doesn't touch your mail flow, your sending infrastructure, or how messages are composed. Switching to hosted SPF is a DNS-only change; your mail servers, ESPs, and mailboxes keep working exactly as before.

What if my domain registrar doesn't let me publish a TXT record with an include: that long, or restricts TXT record length?
The published hosted SPF record is short by design - just v=spf1 include:<slug>.spf.dmarcengine.com ~all - specifically so it fits comfortably within every registrar's TXT record limits, unlike a manually-maintained record listing several providers' full include chains, which can bump into per-string length limits on some older DNS panels.

I manage several domains - do I need to repeat this setup for each one?
Yes, each domain gets its own hosting slug and its own SPF sender list in /domains, since different domains often send through different platforms. The setup steps are identical for each; there's no bulk shortcut required, and the app's per-domain builder makes each one quick once you know your sender list.

---

Where to go next

• Complete guide to SPF - deeper background on the standard itself
• Hosted DKIM - the signature-based half of your authentication setup
• DMARC alignment - how SPF and DKIM results combine into a DMARC pass/fail
• Authenticate mail from multiple senders - for organisations juggling many ESPs, CRMs, and internal tools
• Check DMARC is working - a broader verification pass once SPF, DKIM, and DMARC are all live
• DMARC enforcement playbook - for ramping from monitoring to p=reject safely

Manage everything covered in this guide from app.dmarcengine.com/spf, and keep app.dmarcengine.com/lookup bookmarked for quick record checks whenever you make a change.