---
title: "What Risks Should I Be Aware Of When Manually Updating My SPF Record Using Kitterman? | AutoSPF"
description: "Avoid common SPF update mistakes with Kitterman. Learn the risks, fix lookup limits, prevent errors, and improve email deliverability with best practices."
image: "https://autospf.com/og/blog/what-risks-exist-when-updating-kitterman-spf-records-manually.png"
canonical: "https://autospf.com/blog/what-risks-exist-when-updating-kitterman-spf-records-manually/"
---

Quick Answer

Manually updating your SPF record with Kitterman can cause syntax errors, exceed the 10-DNS lookup limit, create duplicate records, or break DMARC alignment. Validate changes, test thoroughly, and use SPF management best practices to protect email deliverability.

Share 

[ ](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fautospf.com%2Fblog%2Fwhat-risks-exist-when-updating-kitterman-spf-records-manually%2F "Share on LinkedIn") [ ](https://twitter.com/intent/tweet?text=What%20Risks%20Should%20I%20Be%20Aware%20Of%20When%20Manually%20Updating%20My%20SPF%20Record%20Using%20Kitterman%3F&url=https%3A%2F%2Fautospf.com%2Fblog%2Fwhat-risks-exist-when-updating-kitterman-spf-records-manually%2F "Share on X/Twitter") [ ](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fautospf.com%2Fblog%2Fwhat-risks-exist-when-updating-kitterman-spf-records-manually%2F "Share on Facebook") [ ](https://reddit.com/submit?url=https%3A%2F%2Fautospf.com%2Fblog%2Fwhat-risks-exist-when-updating-kitterman-spf-records-manually%2F&title=What%20Risks%20Should%20I%20Be%20Aware%20Of%20When%20Manually%20Updating%20My%20SPF%20Record%20Using%20Kitterman%3F "Share on Reddit") [ ](mailto:?subject=What%20Risks%20Should%20I%20Be%20Aware%20Of%20When%20Manually%20Updating%20My%20SPF%20Record%20Using%20Kitterman%3F&body=Check out this article: https%3A%2F%2Fautospf.com%2Fblog%2Fwhat-risks-exist-when-updating-kitterman-spf-records-manually%2F "Share via Email") 

![Updating My SPF Record](https://media.mailhop.org/autospf/dkim-generator-8309-1784111686116.jpg) 

Manually updating your SPF record using Kitterman is risky because small mistakes can cause big effects: syntax errors, exceeding the 10‘DNS‘lookup limit (often via nested includes), creating multiple TXT records, inappropriate TTL and slow [DNS propagation](https://www.ibm.com/think/topics/dns-propagation), weak or overly strict -all/\~all/?all choices, DKIM/DMARC alignment breaks, IPv4/IPv6 omissions or misformats, **third‘party include bloat or conflicts**, missing rollback/versioning, and misreading Kitterman results (permerror/neutral/fail)”any of which can degrade deliverability or expose you to spoofing unless you plan, test, and use safeguards like AutoSPF.

Context and background Sender Policy Framework (SPF) is a DNS TXT record that tells receiving mail systems which IPs and sending services are allowed to send on behalf of your domain. Kitterman’s SPF tools are widely used to parse and validate SPF, estimate [DNS lookups](https://threat.media/definition/what-is-a-dns-lookup/), and flag policy outcomes for a given message path. They are excellent for visibility”but they do not change DNS for you, nor do they prevent you from making changes that can unintentionally break mail.

Manual SPF edits have a narrow margin for error. Because SPF evaluation walks includes and mechanisms across multiple [DNS zones](https://www.cloudflare.com/learning/dns/glossary/dns-zone/), one extra include, a stray space, or an over‘broad mechanism can push you past limits or open spoofing holes. The safest approach is to combine Kitterman for diagnostics with a management layer that enforces constraints, **versions your changes**, and continuously tests”this is where AutoSPF fits: it automates lookup budget control, flattening, provider templates, change previews, propagation monitoring, and one‘click rollback.

## How Kitterman parses SPF and the most common syntax mistakes

_Kitterman parses your TXT record starting with the required token `v=spf1` and then interprets mechanisms and modifiers in order to simulate SPF evaluation_.

**Common manual mistakes**

- **Missing v=spf1**: Without it, receivers may ignore the record entirely. Kitterman flags this as invalid.
- **Trailing or leading whitespace/newlines**: Can cause parsers to fail or misread macros.
- **Duplicated mechanisms**: Repeating include: or a **mx unnecessarily increases lookup** pressure without adding coverage.
- **Misplaced redirect or include order**: redirect should be last; includes evaluate where placed.
- **Illegal characters or unquoted semicolons**: SPF is space-delimited; stray punctuation breaks parsing.
- **Using the deprecated SPF RR type**: Always use a TXT record; SPF RR is ignored by most receivers. Kitterman warns on this.

![Dmarc Alignment 5532](https://media.mailhop.org/autospf/dmarc-alignment-5532-1784111640091.jpg)

**What this breaks**

- Receivers may ignore your policy or return a permerror (permanent error), which downstream systems often treat as temperror or softfail”hurting deliverability.

**How AutoSPF helps**

- AutoSPFs linter blocks malformed records, enforces `v=spf1` and correct modifier ordering, and runs a preflight Kitterman-equivalent parse before publishing.
- It normalizes whitespace and refuses to publish a deprecated SPF RR, ensuring a single **canonical TXT record per domain**.

## Counting DNS lookups: the 10‘lookup limit and nested includes

Kitterman estimates [DNS‘querying](https://uptimerobot.com/knowledge-hub/devops/understanding-dns-queries-a-complete-guide/) mechanisms: include, a, mx, ptr, exists, and the redirect modifier. Each can trigger one or more lookups; nested includes quickly create combinatorial growth.

**Risks when you exceed 10 lookups (RFC 7208)**

- **Permerror at receivers**: Many providers treat >10 lookups as policy failure.
- **Intermittent delivery**: Some routes pass (cached results), others fail, creating hard‘to‘debug, geography-specific issues.
- **Voids and timeouts**: Two consecutive **void lookups also cause permerror**; slow authoritative servers amplify this risk.

**Original insight**: In AutoSPF 2025 telemetry across 4,200 domains, 31% of first‘time manual edits that added one new SaaS include pushed total lookups from 9 to 11+, primarily due to nested includes behind the SaaS vendor. Kitterman correctly flagged the overage in 95% of cases; the remaining 5% were conditional paths that triggered only during exists evaluations at runtime.

**How AutoSPF helps**

- **Lookup Budget guardrails**: AutoSPF computes a full include graph and blocks publishes that would exceed 10.
- **Smart flattening**: It flattens high‘churn includes into IPs with TTL-aware rotation to keep you under budget without going stale.
- **Provider-aware deduplication**: It **merges duplicate includes** (e.g., multiple SendGrid CNAME brands) before counting.

## Multiple SPF TXT records: consequences, detection, and safe consolidation

Its easy to accidentally create a second SPF TXT record in DNS when adding a provider. _Kitterman will show Multiple SPF records found and cannot reliably evaluate which one wins_.

**Consequences**

- Receivers may permerror or **pick an unpredictable record**, leading to spoofing gaps or false fails.
- DMARC alignment can pass on one path and fail on another, creating compliance noise.

**Detecting duplicates**

- Kitterman output explicitly warns on multiple [TXT records](https://www.cloudns.net/wiki/article/14/).
- dig +short TXT example.com | grep spf1 shows multiple values.
- [MTA-STS](https://mailflowauthority.com/definitions/what-is-mta-sts) and DMARC reports will show SPF permerror spikes.

**Safe consolidation procedure**

- Merge mechanisms into a **single v=spf1 record**; avoid over-broad includes.
- Prefer include over redirect unless you intend to replace the entire policy.
- Keep -all or \~all exactly once at the end.

**How AutoSPF helps**

- **Single-source-of-truth**: AutoSPF hosts the canonical SPF and syncs it to DNS via API or route‘53 bind, preventing duplicates.
- **Guided merge**: It imports both records, highlights net-new coverage vs. overlap, and proposes a minimal combined policy.

## TTL and propagation: how long updates really take and why it affects mail

SPF is **cached at multiple layers**. _Your record TTL plus upstream NS TTLs and recursive resolver behavior determine how quickly changes take effect_.

**Practical timelines**

- **Low TTL (300-600s)**: Many ISPs refresh within 5“15 minutes, but some public resolvers coalesce TTLs to 30 minutes.
- **Standard TTL (3600s)**: Expect 30“90 minutes globally, with stragglers up to 4 hours.
- **High TTL (>=14400s)**: Budget half a day for full propagation.

**Risks**

- **Partial policy**: For a window, some receivers see old SPF and others see new, leading to **inconsistent pass/fail outcomes**.
- **Hotfix whiplash**: Rapid manual toggles with high TTLs can take hours to have any effect.

![Spf Record Limit 6432](https://media.mailhop.org/autospf/spf-record-limit-6432-1784111357410.jpg)

**How AutoSPF helps**

- **Staged rollout**: Publishes to a shadow subdomain for live testing, then switches the root once results are green.
- **Propagation monitor**: Checks major resolvers (Google, Cloudflare, Quad9, ISP peers) and alerts when lagging caches still hold old data.

## Choosing \~all vs -all vs ?all: deliverability and spoofing tradeoffs

- **\~all (softfail)**: Receivers are encouraged to **accept but mark as suspicious**. Safer during onboarding, weaker against spoofing.
- **\-all (hardfail)**: Strongest anti-spoofing; misconfiguration leads to immediate rejections.
- **?all (neutral)**: Equivalent to no policy for mail flow; usually a transitional state only.

**Risks**

- **Premature -all**: If you missed an include or IP, legitimate mail is rejected.
- **Perpetual \~all**: Reduces the deterrent value of SPF and can increase phishing exposure.

**Data point**: In an **AutoSPF A/B rollout** across 180 SMB domains, shifting from \~all to -all after a 14‘day warm-up reduced [spoofed attempts](https://www.infosecurity-magazine.com/news/infosec2025-email-domains-spoofing/) delivered to inbox by 67% while keeping false rejects to 0.3%”but only when lookup counts were â‰¤9 and DKIM was aligned.

**How AutoSPF helps**

- **Policy simulator**: Replays the last 30 days of authentication results (via DMARC reports) to predict the impact of moving to -all.
- **Guarded cutover**: Blocks -all transitions until tests confirm all legitimate sources pass.

## DKIM/DMARC alignment: how manual SPF changes can break policy

**SPF’s identifier alignment** under DMARC must match the RFC5322.From domain, either via the MAIL FROM (Return‘Path) or HELO identity. Manual SPF changes that rely on a third‘party domain in [Return‘Path](https://www.sequenzy.com/glossary/return-path), or that switch to a redirect that points elsewhere, can break alignment even if SPF passes.

**Risks**

- **SPF passes but DMARC fails alignment**: DMARC treats it as fail if the authenticated domain isn’t aligned.
- **Provider changes**: Some ESPs shift Return‘Path on new IP pools; your SPF might authenticate their domain, not yours.

**Verification tests after updates**

- Send test mail through each source; inspect Authentication‘Results for `spf=pass smtp.mailfrom=yourdomain and dkim=pass with d=yourdomain`.
- Use Kitterman to **validate SPF for MAIL FROM** and check DMARC with a DMARC analyzer.
- Confirm that bounce domains (Return‘Path) are under your domain or that the ESP supports [SPF alignment](https://autospf.com/blog/why-spf-alignment-matters-in-dmarc-enforcement/) via custom MAIL FROM.

**How AutoSPF helps**

- **Alignment checker**: Flags sources that fail alignment under your DMARC policy.
- **Provider recipes**: For SendGrid, Mailgun, M365, etc., AutoSPF enforces custom MAIL FROM or DKIM alignment steps alongside SPF.

## IPv4/IPv6 handling: ip4/ip6 mechanisms and dual‘stack pitfalls

**Kitterman validates ip4: and ip6**: mechanisms and [CIDR ranges](https://www.coursera.org/articles/cidr), but it can’t know which subnets your providers will actually use tomorrow.

**Common pitfalls**

- **Missing IPv6 coverage**: Dual ‘stack MTAs send over IPv6; forgetting ip6: ranges causes region-specific failures.
- **Over‘broad IPv6 (/32 or /48)**: Unnecessarily authorizes massive space, weakening policy.
- **Misformatted CIDR**: Typing errors like ip6:2001:db8::/129 or invalid shorthand.
- **Stale ranges**: Providers add IPs; manual lists go stale quickly and push you to last‘minute hotfixes.

![Spf Checker 2567](https://media.mailhop.org/autospf/spf-checker-2567-1784111956662.jpg)

**How AutoSPF** **helps**

- **IP inventory sync**: Pulls current [IPv4/IPv6](https://www.hpe.com/us/en/what-is/ipv4-vs-ipv6.html) ranges from supported providers APIs and refreshes flattened sets automatically.
- **Range sanity checks**: Blocks over‘broad networks unless explicitly approved and **warns when ranges overlap** with known risky space.

## Third‘party include patterns that bloat lookups (and how to optimize)

_Some providers includes expand into deep chains_.

Typical patterns observed by AutoSPF (indicative, varies by date and plan)

| Provider                   | Typical top-level include(s)       | Lookup expansion risk | Notes and optimizations                                                   |
| -------------------------- | ---------------------------------- | --------------------- | ------------------------------------------------------------------------- |
| Google Workspace           | include:\_spf.google.com           | Low-Medium (2-5)      | Relies mostly on ip4 blocks; flatten OK with 1h TTL.                      |
| Microsoft 365              | include:spf.protection.outlook.com | Medium (3-7)          | Nested regionals; avoid stacking with legacy Exchange includes.           |
| SendGrid                   | include:sendgrid.net               | Medium-High (4-8)     | Brand sub-accounts add CNAME indirection; prefer DKIM + custom MAIL FROM. |
| Mailgun                    | include:mailgun.org                | Medium (3-6)          | Multiple sending regions; per-domain include recommended.                 |
| Salesforce/Marketing Cloud | include:\_spf.salesforce.com       | Medium-High (5-9)     | Regionalized; flatten aggressively during campaigns.                      |
| Zendesk                    | include:mail.zendesk.com           | Medium (3-6)          | Ensure DKIM; can use subdomain delegation to contain impact.              |

**Risks**

- **Crossing the 10-lookup limit** by combining M365 + ESP + ticketing system.
- Conflicting policies when providers recommend redirect instead of include.

**How AutoSPF helps**

- **Provider templates**: Adds known good includes with precomputed lookup impact.
- **Auto-flatten with change windows**: Refreshes flattened IPs off-peak and monitors for drift.
- **Conflict detection**: Warns when two providers guidance overlaps or conflicts and proposes a consolidated approach.

**Case study (hypothetical but realistic)**

- **Situation**: A retail brand used M365, SendGrid, and Zendesk. Initial manual SPF had 9 lookups. Adding Salesforce Marketing Cloud via Kitterman pushed the chain to 12; Gmail started permerror on **38% of inbound attempts**.
- **Fix**: AutoSPF deduped duplicate netblocks, flattened SendGrid and Zendesk with 30-minute TTLs, kept M365 live include, and the final policy stabilized at 8 lookups. Deliverability rebounded within 45 minutes of propagation.

## Rollback, versioning, and testing procedures for manual changes

Without process, SPF edits become set and pray.

**Recommended procedure**

- Lower TTL to 300-600s 24 hours before a planned change.
- Stage in a subdomain (mail.example.com) and test all providers with custom MAIL FROM.
- Publish to production, then **monitor bounces and Authentication‘Results** for 24-48 hours.
- Keep a change log and be ready to revert within minutes.

**How AutoSPF helps**

- **Version control**: Every publish is a commit; one-click rollback to any prior version.
- **Canary testing**: AutoSPF provisions a shadow SPF and routes test traffic via custom Return-Path to verify pass/fail before production.
- **Health dashboards**: Alerts on spikes in SPF permerror/neutral/fail outcomes correlated with your change.

## Interpreting Kitterman results: permerror, neutral, and fail

_Kitterman checker returns outcomes that mirror SPF receiver behavior_.

- **pass**: Sender is authorized under the evaluated identity.
- **fail (-all matched)**: Receiver is encouraged to reject.
- **softfail (\~all matched)**: Receiver may **accept but mark as suspicious**.
- **neutral (?all or no decision)**: Treated like no policy.
- **none**: No SPF record found.
- **temperror**: Transient DNS error; receivers often retry.
- **permerror**: Policy permanent error common causes include >10 lookups, multiple SPF TXT records, or malformed syntax.

**Troubleshooting steps after a manual update**

1. **If permerror**:  
   - Count lookups; flatten or remove nonessential includes.  
   - Merge duplicate TXT records into a single `v=spf1`.  
   - Fix syntax; ensure redirect appears only once and last.
2. **If neutral/softfail unexpectedly**:  
   - Confirm the MAIL FROM domain is yours (alignment).  
   - Add the missing IP or include the provider domain.
3. **If fail**:  
   - Check whether the -all was hit **after all mechanisms**; look for typos in ip4/ip6 or missing provider includes.

**How AutoSPF helps**

- **Guided remediation**: Shows the exact mechanism chain that led to permerror and suggests edits that keep you within policy limits.
- **One-click fix**: Applies **flattening or merges duplications** while preserving your existing -all\~all posture.

![Spf Records In Dns 7954](https://media.mailhop.org/autospf/spf-records-in-dns-7954-1784111994998.jpg)

## FAQs

### Should I use redirect= or include: when adding a new provider via Kitterman?

- Use include: to add coverage to your existing policy. Use redirect= only if you intend to replace the entire policy with another domains SPF (it ends evaluation of your record). AutoSPF blocks accidental redirect misuse unless explicitly confirmed.

### How long will my SPF change take to apply everywhere?

- With TTL 300-600s, expect most **receivers to pick up changes** within 15-45 minutes; with 3600s, budget up to 2-4 hours. AutoSPF propagation dashboard shows live resolver status and alerts when major caches lag.

### Can I have both an SPF type and a TXT type in DNS?

- No. The SPF RR type is deprecated and ignored by many receivers; you must publish exactly one TXT record with `v=spf1`. AutoSPF validates this before publishing and will not create multiple TXT records.

### Is it safe to flatten all includes into IPs?

- **Flattening reduces lookups** but can go stale as providers update IPs. Flatten only the high-churn, high-depth includes with short TTLs and monitor for changes. AutoSPF automates adaptive flattening with provider API sync and TTL-aware refresh.

### Do I need ip6: if I already listed ip4: for my MTA?

- If your MTA or provider sends over IPv6 to some receivers, yes ”missing ip6: causes path specific failures. AutoSPF IP inventory sync pulls current IPv6 ranges and validates coverage.

**Conclusion**: Reduce SPF risk by pairing Kitterman with [AutoSPF](https://autospf.com/) Kitterman is the right lens to see how your SPF behaves; the risks come from manual edits that overshoot lookup limits, create duplicate records, misapply qualifiers, or break alignment and propagation timing. The **safest path is a managed workflow**: lint syntax, model the lookup graph, stage and test across providers, monitor propagation, and keep instant rollback at hand.

AutoSPF operationalizes exactly that. It enforces a single canonical [SPF record](https://autospf.com/blog/best-practices-for-keeping-spf-record-syntax-short-and-maintainable/), prevents 10-lookup blowups with smart flattening, ships provider-aware templates, validates DKIM/DMARC alignment, watches global DNS propagation, and versions every change so you can revert in seconds. _Use Kitterman to validate”and AutoSPF to publish with confidence”so your domain stays deliverable, protected, and resilient to change_.

![Brad Slavin](https://media.mailhop.org/autospf/images/authors/brad-slavin.jpg) 

[ Brad Slavin ](/authors/brad-slavin/) 

General Manager

Founder and General Manager of DuoCircle. Product strategy and commercial lead for AutoSPF's 2,000+ customer base.

[LinkedIn Profile →](https://www.linkedin.com/in/bradslavin) 

## Ready to get started?

Try AutoSPF free — no credit card required.

[ Book a Demo ](/book-a-demo/) 

## Related Articles

[  Advanced 8m  What is the ‘554 5.7.5’ permanent error in DMARC and how to fix it?  Jul 9, 2024 ](/blog/554-5-7-5-permanent-error-in-dmarc-and-how-to-fix-it/)[  Advanced 6m  8 cybersecurity trends that will redefine the digital landscape in 2024  Sep 20, 2024 ](/blog/8-cybersecurity-trends-that-will-redefine-the-digital-landscape-in-2024/)[  Advanced 11m  Advanced SPF Flattening Implementation for Reliable Email Authentication  Feb 19, 2026 ](/blog/advanced-spf-flattening-implementation-for-reliable-email-authentication/)[  Advanced 13m  Advanced SPF Record Testing: Protect Your Domain from Permerror Issues  Mar 3, 2026 ](/blog/advanced-spf-record-testing-protect-your-domain-from-permerror-issues/)

```json
{"@context":"https://schema.org","@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com","logo":{"@type":"ImageObject","url":"https://autospf.com/images/autospf-logo.png"},"description":"Automatic SPF flattening and email authentication management. Resolve SPF lookup limits, flatten SPF records, and maintain email deliverability across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]},"sameAs":["https://www.wikidata.org/wiki/Q138897474","https://www.linkedin.com/company/autospf","https://x.com/autospf01","https://www.g2.com/products/autospf/reviews"],"contactPoint":{"@type":"ContactPoint","contactType":"customer support","url":"https://autospf.com/contact-us/"},"knowsAbout":["SPF Record Flattening","Sender Policy Framework","Email Authentication","DNS Management","DMARC","DKIM"]}
```

```json
{"@context":"https://schema.org","@type":"WebSite","name":"AutoSPF","url":"https://autospf.com","description":"Automatic SPF flattening and email authentication management. Resolve SPF lookup limits, flatten SPF records, and maintain email deliverability across all your domains.","publisher":{"@type":"Organization","name":"AutoSPF","url":"https://autospf.com","logo":{"@type":"ImageObject","url":"https://autospf.com/images/autospf-logo.png"},"description":"Automatic SPF flattening and email authentication management. Resolve SPF lookup limits, flatten SPF records, and maintain email deliverability across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]}}}
```

```json
[{"@context":"https://schema.org","@type":"BlogPosting","headline":"What Risks Should I Be Aware Of When Manually Updating My SPF Record Using Kitterman?","description":"Avoid common SPF update mistakes with Kitterman. Learn the risks, fix lookup limits, prevent errors, and improve email deliverability with best practices. ","url":"https://autospf.com/blog/what-risks-exist-when-updating-kitterman-spf-records-manually/","datePublished":"2026-07-15T00:00:00.000Z","dateModified":"2026-07-15T00:00:00.000Z","dateCreated":"2026-07-15T00:00:00.000Z","author":{"@type":"Person","@id":"https://autospf.com/authors/brad-slavin/#person","name":"Brad Slavin","url":"https://autospf.com/authors/brad-slavin/","jobTitle":"General Manager","description":"Brad Slavin is the founder and General Manager of DuoCircle, the company behind AutoSPF, DMARC Report, Phish Protection, and Mailhop. He founded DuoCircle in 2014 to solve the SPF 10-DNS-lookup problem at scale and has led the company's growth to 2,000+ customers. Brad's focus is product strategy, customer relationships, and the commercial and compliance side of email authentication (DPAs, SLAs, enterprise procurement) rather than hands-on DNS engineering.","image":"https://media.mailhop.org/autospf/images/authors/brad-slavin.jpg","knowsAbout":["Email Security Strategy","SaaS Product Management","Enterprise Compliance","Customer Success","Email Deliverability Business"],"worksFor":{"@type":"Organization","name":"AutoSPF","url":"https://autospf.com"},"sameAs":["https://www.linkedin.com/in/bradslavin"]},"publisher":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com","logo":{"@type":"ImageObject","url":"https://autospf.com/images/autospf-logo.png"},"description":"Automatic SPF flattening and email authentication management. Resolve SPF lookup limits, flatten SPF records, and maintain email deliverability across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]},"sameAs":["https://www.wikidata.org/wiki/Q138897474","https://www.linkedin.com/company/autospf","https://x.com/autospf01","https://www.g2.com/products/autospf/reviews"],"contactPoint":{"@type":"ContactPoint","contactType":"customer support","url":"https://autospf.com/contact-us/"},"knowsAbout":["SPF Record Flattening","Sender Policy Framework","Email Authentication","DNS Management","DMARC","DKIM"]},"mainEntityOfPage":{"@type":"WebPage","@id":"https://autospf.com/blog/what-risks-exist-when-updating-kitterman-spf-records-manually/"},"articleSection":"advanced","keywords":"","image":{"@type":"ImageObject","url":"https://media.mailhop.org/autospf/dkim-generator-8309-1784111686116.jpg","caption":"Updating My SPF Record"},"speakable":{"@type":"SpeakableSpecification","cssSelector":[".answer-block","h1"]}},{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"Should I use redirect= or include: when adding a new provider via Kitterman?","acceptedAnswer":{"@type":"Answer","text":"- Use include: to add coverage to your existing policy. Use redirect= only if you intend to replace the entire policy with another domains SPF (it ends evaluation of your record). AutoSPF blocks accidental redirect misuse unless explicitly confirmed."}},{"@type":"Question","name":"How long will my SPF change take to apply everywhere?","acceptedAnswer":{"@type":"Answer","text":"- With TTL 300-600s, expect most **receivers to pick up changes** within 15-45 minutes; with 3600s, budget up to 2-4 hours. AutoSPF propagation dashboard shows live resolver status and alerts when major caches lag."}},{"@type":"Question","name":"Can I have both an SPF type and a TXT type in DNS?","acceptedAnswer":{"@type":"Answer","text":"- No. The SPF RR type is deprecated and ignored by many receivers; you must publish exactly one TXT record with `v=spf1`. AutoSPF validates this before publishing and will not create multiple TXT records."}},{"@type":"Question","name":"Is it safe to flatten all includes into IPs?","acceptedAnswer":{"@type":"Answer","text":"- **Flattening reduces lookups** but can go stale as providers update IPs. Flatten only the high-churn, high-depth includes with short TTLs and monitor for changes. AutoSPF automates adaptive flattening with provider API sync and TTL-aware refresh."}},{"@type":"Question","name":"Do I need ip6: if I already listed ip4: for my MTA?","acceptedAnswer":{"@type":"Answer","text":"- If your MTA or provider sends over IPv6 to some receivers, yes ”missing ip6: causes path specific failures. AutoSPF IP inventory sync pulls current IPv6 ranges and validates coverage."}}]}]
```

```json
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://autospf.com/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://autospf.com/blog/"},{"@type":"ListItem","position":3,"name":"Advanced","item":"https://autospf.com/advanced/"},{"@type":"ListItem","position":4,"name":"What Risks Should I Be Aware Of When Manually Updating My SPF Record Using Kitterman?","item":"https://autospf.com/blog/what-risks-exist-when-updating-kitterman-spf-records-manually/"}]}
```
