什么是域名欺骗？
域名欺骗指的是：恶意行为者冒充合法域名来欺骗用户或系统的攻击。在实际项目中，应把它放在域名注册、DNS解析、邮件路由、安全控制和用户访问体验的完整链路中理解。
它通常涉及所有者、注册商、注册局、DNS记录、解析器、邮件系统或Web服务器之间的关系。理解其边界、责任方和可见信号，可以帮助排查配置错误、评估风险，并向非技术团队解释影响。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
域名欺骗的类型
在“域名欺骗的类型”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
常见类型或场景会因注册商、TLD、DNS提供商、邮件平台和托管架构而不同。比较这些差异时，应关注是否影响解析、转移、续费、邮件送达、安全告警、SEO信号或品牌可信度。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
邮件欺骗
在“邮件欺骗”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
安全角度下，需要关注冒用、钓鱼、错误授权、缓存污染、证书误发、品牌混淆和访问中断等问题。建议结合日志、DNS查询、邮件认证结果、证书透明度记录以及注册商审计记录来判断。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
Legitimate:
From: support@paypal.com
Actual sender: PayPal's mail servers
Spoofed:
From: support@paypal.com
Actual sender: attacker's server
Without SPF/DKIM/DMARC, appears legitimate
显示名称欺骗
在“显示名称欺骗”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
安全角度下，需要关注冒用、钓鱼、错误授权、缓存污染、证书误发、品牌混淆和访问中断等问题。建议结合日志、DNS查询、邮件认证结果、证书透明度记录以及注册商审计记录来判断。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
Display: CEO John Smith <john.smith@company.com>
Actual email: attackercontrol@malicious.com
Many email clients show only display name prominently
相似域名欺骗
在“相似域名欺骗”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
安全角度下，需要关注冒用、钓鱼、错误授权、缓存污染、证书误发、品牌混淆和访问中断等问题。建议结合日志、DNS查询、邮件认证结果、证书透明度记录以及注册商审计记录来判断。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
Legitimate: paypal.com
Lookalikes:
paypa1.com (1 instead of l)
paypal-secure.com (added word)
paypai.com (typo)
paypаl.com (Cyrillic 'а' instead of Latin 'a')
DNS欺骗 (Cache Poisoning)
在“DNS欺骗 (Cache Poisoning)”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
安全角度下，需要关注冒用、钓鱼、错误授权、缓存污染、证书误发、品牌混淆和访问中断等问题。建议结合日志、DNS查询、邮件认证结果、证书透明度记录以及注册商审计记录来判断。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
User types: bank.com
DNS poisoned: Returns attacker's IP instead of real bank
User arrives at: Fake bank.com (phishing site)
User thinks: They're on real site (URL shows bank.com)
Caller ID Spoofing (VoIP)
在“Caller ID Spoofing (VoIP)”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
安全角度下，需要关注冒用、钓鱼、错误授权、缓存污染、证书误发、品牌混淆和访问中断等问题。建议结合日志、DNS查询、邮件认证结果、证书透明度记录以及注册商审计记录来判断。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
邮件欺骗如何工作
在“邮件欺骗如何工作”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
处理流程通常包括确认权威来源、检查当前状态、修改配置、等待缓存或注册局状态更新，并通过独立工具复核结果。对生产域名操作时，应记录变更时间、操作者、回滚方式和验证结果。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
SMTP Protocol Gap
在“SMTP Protocol Gap”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
实际使用中，应关注它对可用性、可信度、迁移、自动化、监控和用户体验的影响。把配置写入文档并定期复查，可以避免域名生命周期中的隐性故障。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
SMTP Conversation:
Client: HELO attacker.com
Server: 250 Hello
Client: MAIL FROM: <ceo@victimcompany.com>
Server: 250 OK (accepts without verification)
Client: RCPT TO: <employee@victimcompany.com>
Server: 250 OK
Client: DATA
From: ceo@victimcompany.com
Subject: Urgent wire transfer needed
→ Server delivers it
Header Manipulation
在“Header Manipulation”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
实际使用中，应关注它对可用性、可信度、迁移、自动化、监控和用户体验的影响。把配置写入文档并定期复查，可以避免域名生命周期中的隐性故障。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
From: "CEO John Smith" <ceo@legitimate.com>
Reply-To: attacker@malicious.com
User sees trusted sender
Replies go to attacker
Real-World Spoofing 攻击 Scenarios
在“Real-World Spoofing 攻击 Scenarios”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
安全角度下，需要关注冒用、钓鱼、错误授权、缓存污染、证书误发、品牌混淆和访问中断等问题。建议结合日志、DNS查询、邮件认证结果、证书透明度记录以及注册商审计记录来判断。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
Business 电子邮件 Compromise (BEC)
在“Business 电子邮件 Compromise (BEC)”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
实际使用中，应关注它对可用性、可信度、迁移、自动化、监控和用户体验的影响。把配置写入文档并定期复查，可以避免域名生命周期中的隐性故障。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
1. Attacker researches company structure
2. Spoofs CEO's email to CFO
3. "Urgent wire transfer needed for acquisition"
4. CFO transfers funds thinking it's legitimate
5. Company loses millions
网络钓鱼 Campaigns
在“网络钓鱼 Campaigns”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
安全角度下，需要关注冒用、钓鱼、错误授权、缓存污染、证书误发、品牌混淆和访问中断等问题。建议结合日志、DNS查询、邮件认证结果、证书透明度记录以及注册商审计记录来判断。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
1. Spoof bank or tech company domain
2. Send emails about "suspicious activity"
3. Link goes to lookalike domain
4. User enters credentials on fake site
5. Attacker steals credentials
Invoice Fraud
在“Invoice Fraud”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
实际使用中，应关注它对可用性、可信度、迁移、自动化、监控和用户体验的影响。把配置写入文档并定期复查，可以避免域名生命周期中的隐性故障。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
1. Attacker spoofs supplier's domain
2. Sends updated invoice with attacker's bank details
3. Victim pays attacker instead of real supplier
4. Legitimate supplier never receives payment
Malware Distribution
在“Malware Distribution”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
实际使用中，应关注它对可用性、可信度、迁移、自动化、监控和用户体验的影响。把配置写入文档并定期复查，可以避免域名生命周期中的隐性故障。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
1. Spoof trusted software company
2. Email with "critical security update"
3. Attachment contains malware
4. User trusts "legitimate" sender and opens it
检测域名欺骗
在“检测域名欺骗”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
安全角度下，需要关注冒用、钓鱼、错误授权、缓存污染、证书误发、品牌混淆和访问中断等问题。建议结合日志、DNS查询、邮件认证结果、证书透明度记录以及注册商审计记录来判断。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
电子邮件 Header Analysis
在“电子邮件 Header Analysis”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
实际使用中，应关注它对可用性、可信度、迁移、自动化、监控和用户体验的影响。把配置写入文档并定期复查，可以避免域名生命周期中的隐性故障。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
From: support@paypal.com
Return-Path: <random@suspicious.com> ← Red flag
Received: from unknown.net [1.2.3.4] ← Not PayPal's servers
Real email would have:
Received: from mx.paypal.com [verified PayPal IP]
Return-Path: <support@paypal.com>
SPF/DKIM/DMARC Check
在“SPF/DKIM/DMARC Check”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
实际使用中，应关注它对可用性、可信度、迁移、自动化、监控和用户体验的影响。把配置写入文档并定期复查，可以避免域名生命周期中的隐性故障。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
Authentication-Results: recipient.com;
spf=fail smtp.mailfrom=paypal.com ← Spoofed
dkim=none ← Not signed
dmarc=fail ← Failed policy
Visual Inspection
在“Visual Inspection”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
实际使用中，应关注它对可用性、可信度、迁移、自动化、监控和用户体验的影响。把配置写入文档并定期复查，可以避免域名生命周期中的隐性故障。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
Real: paypal.com
Fake: paypal-secure.com (extra word)
Fake: paypαl.com (Cyrillic character)
Fake: paypal.co (missing 'm')
Behavioral Anomalies
在“Behavioral Anomalies”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
实际使用中，应关注它对可用性、可信度、迁移、自动化、监控和用户体验的影响。把配置写入文档并定期复查，可以避免域名生命周期中的隐性故障。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
预防域名欺骗
在“预防域名欺骗”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
安全角度下，需要关注冒用、钓鱼、错误授权、缓存污染、证书误发、品牌混淆和访问中断等问题。建议结合日志、DNS查询、邮件认证结果、证书透明度记录以及注册商审计记录来判断。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
Implement 邮件认证 (Critical)
在“Implement 邮件认证 (Critical)”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
实际使用中，应关注它对可用性、可信度、迁移、自动化、监控和用户体验的影响。把配置写入文档并定期复查，可以避免域名生命周期中的隐性故障。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
example.com. IN TXT "v=spf1 include:_spf.google.com -all"
Authorizes which servers can send for your domain
Cryptographically signs outgoing emails
Receivers verify signature using DNS public key
Tampered emails fail verification
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
Tells receivers to reject emails that fail SPF/DKIM
Provides reports on spoofing attempts
p=none Monitor only (start here)
p=quarantine Send failures to spam
p=reject Block failures completely (goal)
Register Defensive 域名
在“Register Defensive 域名”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
实际使用中，应关注它对可用性、可信度、迁移、自动化、监控和用户体验的影响。把配置写入文档并定期复查，可以避免域名生命周期中的隐性故障。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
Primary: company.com
Register:
- Common typos: conpany.com, compamy.com
- Different TLDs: company.net, company.org, company.co
- Hyphenated: com-pany.com, company-inc.com
- Plurals: companies.com
监控 Brand Mentions
在“监控 Brand Mentions”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
验证时不要只依赖单一工具。应同时检查权威DNS、递归解析结果、RDAP或WHOIS数据、HTTP响应、邮件头、证书状态和监控告警，并把缓存、TTL、地理位置和提供商差异纳入判断。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
Employee Training
在“Employee Training”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
实际使用中，应关注它对可用性、可信度、迁移、自动化、监控和用户体验的影响。把配置写入文档并定期复查，可以避免域名生命周期中的隐性故障。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
Controls技术要点
在“Controls技术要点”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
实际使用中，应关注它对可用性、可信度、迁移、自动化、监控和用户体验的影响。把配置写入文档并定期复查，可以避免域名生命周期中的隐性故障。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
p=reject (block spoofed email entirely)[EXTERNAL EMAIL] This email originated outside the organization高级 Spoofing 技术
在“高级 Spoofing 技术”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
安全角度下，需要关注冒用、钓鱼、错误授权、缓存污染、证书误发、品牌混淆和访问中断等问题。建议结合日志、DNS查询、邮件认证结果、证书透明度记录以及注册商审计记录来判断。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
同形字攻击s
在“同形字攻击s”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
安全角度下，需要关注冒用、钓鱼、错误授权、缓存污染、证书误发、品牌混淆和访问中断等问题。建议结合日志、DNS查询、邮件认证结果、证书透明度记录以及注册商审计记录来判断。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
Latin 'a' vs Cyrillic 'а' (U+0430)
Latin 'o' vs Cyrillic 'о' (U+043E)
googlе.com (Latin 'e' replaced with Cyrillic 'е')
Looks identical to: google.com
googlе.com → xn--googl-6nd.com (encoded)
Browsers show: ⚠️ xn--googl-6nd.com
子域名 Spoofing
在“子域名 Spoofing”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
安全角度下，需要关注冒用、钓鱼、错误授权、缓存污染、证书误发、品牌混淆和访问中断等问题。建议结合日志、DNS查询、邮件认证结果、证书透明度记录以及注册商审计记录来判断。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
legitimate-bank.attacker.com
Appears as: legitimate-bank (subdomain of attacker.com)
Users see: "legitimate-bank" and assume it's safe
Man-in-the-Middle with DNS Hijacking
在“Man-in-the-Middle with DNS Hijacking”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
实际使用中，应关注它对可用性、可信度、迁移、自动化、监控和用户体验的影响。把配置写入文档并定期复查，可以避免域名生命周期中的隐性故障。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
1. Attacker compromises DNS server or router
2. Changes bank.com resolution to attacker's IP
3. Serves fake bank site
4. Uses valid SSL cert (from Let's Encrypt, free)
5. User sees https://bank.com with padlock
6. User thinks it's safe, enters credentials
法律 and 监管 方面
在“法律 and 监管 方面”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
法律、合规或政策层面通常涉及商标、注册协议、注册局规则、ICANN政策、争议解决和滥用举报。保留截图、日志、WHOIS/RDAP记录和通信证据，可以降低后续处置成本。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
Anti-域名抢注 Consumer Protection Act (ACPA)
在“Anti-域名抢注 Consumer Protection Act (ACPA)”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
最佳实践是先明确目标，再用最小变更完成配置；为关键域名启用锁定、续费提醒、监控和多因素认证；对DNS、邮件和安全策略使用版本化记录，并在变更后进行端到端测试。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
Uniform 域名-名称 Dispute-Resolution Policy (UDRP)
在“Uniform 域名-名称 Dispute-Resolution Policy (UDRP)”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
法律、合规或政策层面通常涉及商标、注册协议、注册局规则、ICANN政策、争议解决和滥用举报。保留截图、日志、WHOIS/RDAP记录和通信证据，可以降低后续处置成本。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
Criminal Penalties
在“Criminal Penalties”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
实际使用中，应关注它对可用性、可信度、迁移、自动化、监控和用户体验的影响。把配置写入文档并定期复查，可以避免域名生命周期中的隐性故障。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
响应域名欺骗
在“响应域名欺骗”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
安全角度下，需要关注冒用、钓鱼、错误授权、缓存污染、证书误发、品牌混淆和访问中断等问题。建议结合日志、DNS查询、邮件认证结果、证书透明度记录以及注册商审计记录来判断。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
If Your 域名 is Being Spoofed
在“If Your 域名 is Being Spoofed”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
安全角度下，需要关注冒用、钓鱼、错误授权、缓存污染、证书误发、品牌混淆和访问中断等问题。建议结合日志、DNS查询、邮件认证结果、证书透明度记录以及注册商审计记录来判断。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:abuse@example.com"If You Discover a Lookalike 域名
在“If You Discover a Lookalike 域名”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
实际使用中，应关注它对可用性、可信度、迁移、自动化、监控和用户体验的影响。把配置写入文档并定期复查，可以避免域名生命周期中的隐性故障。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
测试Your Defenses
在“测试Your Defenses”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
验证时不要只依赖单一工具。应同时检查权威DNS、递归解析结果、RDAP或WHOIS数据、HTTP响应、邮件头、证书状态和监控告警，并把缓存、TTL、地理位置和提供商差异纳入判断。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
测试 邮件欺骗 Protection
在“测试 邮件欺骗 Protection”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
安全角度下，需要关注冒用、钓鱼、错误授权、缓存污染、证书误发、品牌混淆和访问中断等问题。建议结合日志、DNS查询、邮件认证结果、证书透明度记录以及注册商审计记录来判断。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
# Send test spoofed email to yourself
swaks --to employee@yourcompany.com \
--from ceo@yourcompany.com \
--server test-smtp-server.com \
--header "Subject: Test Spoofed Email"
# Check if it's delivered or blocked
# Check authentication results in headers
Check DMARC 配置
在“Check DMARC 配置”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
实际使用中，应关注它对可用性、可信度、迁移、自动化、监控和用户体验的影响。把配置写入文档并定期复查，可以避免域名生命周期中的隐性故障。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
dig _dmarc.example.com TXT
# Should return policy (p=reject ideally)
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
Verify SPF and DKIM
在“Verify SPF and DKIM”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
实际使用中，应关注它对可用性、可信度、迁移、自动化、监控和用户体验的影响。把配置写入文档并定期复查，可以避免域名生命周期中的隐性故障。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。
# SPF
dig example.com TXT | grep spf
# DKIM (check common selectors)
dig google._domainkey.example.com TXT
dig default._domainkey.example.com TXT
使用 Online 工具
在“使用 Online 工具”这一部分，重点是把域名欺骗放到真实运维和业务场景中看待，而不只停留在术语解释本身。
实际使用中，应关注它对可用性、可信度、迁移、自动化、监控和用户体验的影响。把配置写入文档并定期复查，可以避免域名生命周期中的隐性故障。 英文源内容中的命令、代码、域名示例、产品名和表格如果出现在本节，会在下方原样保留，以避免误改技术细节。