域信任审计 API

API ID 14803

域名邮件验证审计 API:MX SPF DMARC 和 DKIM 选择器检查来自公共 DNS 的信息,0-100 配置完整性评分,以及地址筛选

API 文档

端点

请求
{"domain": "...", "emails": ["...", "..."]}(仅限POST;emails是可选的,最多可包含100个地址)。示例响应(来自真实响应的摘要块;每个响应还包含完整的审计块、每个地址发送时的结果和范围声明):{"summary": {"audit": {"score": 97, "grade": "A", "issueCount": 1, "issuesBySeverity": {"error": 0, "warning": 0, "info": 1}}, "addresses": {"total": 5, "valid": 2, "risky": 2, "invalid": 1, "disposable": 1, "typoLikely": 1}, "flagged": {"total": 3, "domainContext": {"count": 0, "byVerdict": {"risky": 0, "invalid": 0}, "addresses": []}, "addressLevel": {"count": 3, "byVerdict": {"risky": 2, "invalid": 1}}}}}错误名称为:MISSING_DOMAIN,INVALID_DOMAIN,INVALID_FIELD,EMPTY_BATCH,BATCH_TOO_LARGE
Endpoint ID: 38381
POST https://zylalabs.com/api/14803/domaintrust+audit+api/38381/audit+domain
输入参数

审核域 — 端点功能

对象 描述
请求体 必需 Json

剩余免费测试请求:3 / 3。


输入参数

API 示例响应
JSON
{
    "scope": "DomainTrust Audit joins two checks, each with a stated limit. The audit leg verifies, from public DNS records, whether the domain publishes MX, SPF and DMARC (with its policy), and whether DKIM records exist under 12 common selectors; it returns a configuration-completeness score (0-100) and an issues list. It does not measure inbox deliverability, sender reputation, or whether mail is actually signed, and a DKIM 'not found' means only that none of the 12 common selectors holds a record. Two readings to know: a null MX record (RFC 7505, 'this domain accepts no mail') currently counts as MX present and raises no issue, and a DKIM selector holding an empty or revoked key counts as found - 'found' means a DKIM-shaped record exists there, not that the key is usable. The email leg screens addresses at domain level only (syntax, domain and MX existence, disposable signals, domain age) - it does not probe whether a mailbox exists, and its catch-all field is a risk signal inferred from MX/provider patterns, never a probed conclusion. Flagged addresses are grouped by whether their domain is the audited domain; that grouping is shown so configuration findings and address findings can be read side by side - it is a grouping, not proof of what caused any single flag.",
    "domain": "example.com",
    "audit": {
        "domain": "example.com",
        "score": 98,
        "grade": "A",
        "checks": {
            "mx": {
                "present": true,
                "records": [
                    "0 ."
                ]
            },
            "spf": {
                "present": true,
                "records": [
                    "v=spf1 -all"
                ]
            },
            "dmarc": {
                "present": true,
                "records": [
                    "v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s"
                ],
                "policy": "reject"
            },
            "dkim": {
                "commonSelectorFound": true,
                "selectorsFound": [
                    "selector1",
                    "selector2",
                    "dkim",
                    "default",
                    "mail",
                    "google",
                    "s1",
                    "k1",
                    "s2",
                    "k2",
                    "smtp",
                    "mandrill"
                ],
                "selectorsChecked": [
                    "default",
                    "google",
                    "selector1",
                    "selector2",
                    "mail",
                    "dkim",
                    "s1",
                    "s2",
                    "k1",
                    "k2",
                    "mandrill",
                    "smtp"
                ],
                "coverageNote": "Only the common selectors listed in selectorsChecked are probed. Domains that sign with a custom selector (common for large senders — e.g. Google signs with date-based selectors such as 20230601) are NOT detected by this check, so a 'not found' result here does not prove DKIM is missing or that mail is unsigned."
            }
        },
        "issues": [
            {
                "severity": "info",
                "check": "dmarc",
                "message": "DMARC record has no rua= reporting address — you will not receive aggregate reports."
            }
        ],
        "source": "DNS-over-HTTPS (Cloudflare)"
    },
    "emails": {
        "results": [
            {
                "email": "[email protected]",
                "valid": true,
                "score": 100,
                "verdict": "valid",
                "checks": {
                    "syntax": true,
                    "domainExists": true,
                    "mxFound": true,
                    "disposable": false,
                    "roleAccount": false,
                    "freeProvider": false
                },
                "mxRecords": [],
                "suggestion": null,
                "typoLikely": false,
                "domainAgeDays": 11410,
                "domainAgeSource": "RDAP",
                "catchAllRisk": "unknown",
                "note": "Checks domain mail routing (MX) and risk signals. Does not probe individual mailbox existence. Catch-all risk is a risk signal based on MX/provider patterns, not a probing conclusion."
            },
            {
                "email": "[email protected]",
                "valid": true,
                "score": 100,
                "verdict": "valid",
                "checks": {
                    "syntax": true,
                    "domainExists": true,
                    "mxFound": true,
                    "disposable": false,
                    "roleAccount": false,
                    "freeProvider": false
                },
                "mxRecords": [],
                "suggestion": null,
                "typoLikely": false,
                "domainAgeDays": 11410,
                "domainAgeSource": "RDAP",
                "catchAllRisk": "unknown",
                "note": "Checks domain mail routing (MX) and risk signals. Does not probe individual mailbox existence. Catch-all risk is a risk signal based on MX/provider patterns, not a probing conclusion."
            }
        ],
        "summary": {
            "total": 2,
            "valid": {
                "count": 2,
                "percent": 100
            },
            "risky": {
                "count": 0,
                "percent": 0
            },
            "invalid": {
                "count": 0,
                "percent": 0
            },
            "disposable": {
                "count": 0,
                "percent": 0
            },
            "typoLikely": {
                "count": 0,
                "percent": 0
            }
        }
    },
    "summary": {
        "audit": {
            "score": 98,
            "grade": "A",
            "issueCount": 1,
            "issuesBySeverity": {
                "error": 0,
                "warning": 0,
                "info": 1
            }
        },
        "addresses": {
            "total": 2,
            "valid": 2,
            "risky": 0,
            "invalid": 0,
            "disposable": 0,
            "typoLikely": 0
        },
        "flagged": {
            "total": 0,
            "domainContext": {
                "count": 0,
                "byVerdict": {
                    "risky": 0,
                    "invalid": 0
                },
                "addresses": []
            },
            "addressLevel": {
                "count": 0,
                "byVerdict": {
                    "risky": 0,
                    "invalid": 0
                },
                "addresses": []
            },
            "note": "Flagged = the email leg's risky + invalid verdicts, grouped by whether the address's domain is the audited domain. Addresses grouped under domainContext sit next to the domain's own configuration findings in the audit block above; addressLevel flags rest on the address's own signals (listed per address) or on a different domain. Grouping only - it does not prove what caused any single flag."
        }
    }
}
审核域 — 代码片段

curl --location --request POST 'https://zylalabs.com/api/14803/domaintrust+audit+api/38381/audit+domain' --header 'Authorization: Bearer YOUR_API_KEY' 

--data-raw '{"domain": "example.com", "emails": ["[email protected]", "[email protected]"]}'

    
请求
服务状态检查:返回API服务是否正常运行和响应,以便调用者在运行审核之前可以验证可用性
Endpoint ID: 38382
GET https://zylalabs.com/api/14803/domaintrust+audit+api/38382/health+check
输入参数

剩余免费测试请求:3 / 3。

此端点不需要任何输入参数。

API 示例响应
JSON
{
    "ok": true,
    "service": "DomainTrust Audit",
    "version": 1
}
健康检查 — 代码片段

curl --location --request GET 'https://zylalabs.com/api/14803/domaintrust+audit+api/38382/health+check' --header 'Authorization: Bearer YOUR_API_KEY' 


    

API 访问密钥和身份验证

注册后,每个开发者都会被分配一个个人 API 访问密钥,这是一个唯一的字母和数字组合,用于访问我们的 API 端点。要使用 域信任审计 API 进行身份验证,只需在 Authorization 标头中包含您的 bearer token。

标头
标头 描述
授权 必需 应为 Bearer access_key. 订阅后,请查看上方的"您的 API 访问密钥"。

无长期承诺。随时升级、降级或取消。

起价
$10,000/年


  • 自定义数量
  • 自定义速率限制
  • 专业客户支持
  • 实时 API 监控

概览

域名邮件认证审核API:来自公共DNS的MX、SPF、DMARC和DKIM选择器检查,0-100配置完整性得分,以及地址筛查

域信任审计 API FAQs

不 评分计算配置完整性 - 哪些 MX SPF DMARC 和 DKIM-共用选择器已发布 以及记录的设置方式 投递依赖于发件人声誉 内容和接收者策略 这些 API 并未读取或声称读取

不这意味着12个常见选择器中没有一个持有记录使用自定义选择器的域名(对于大型发送者来说很常见)不会被此检查检测到且响应的覆盖注释也这么说

不 它检查域邮件路由(MX) 注册数据和域级的风险信号 邮箱级的探测是不可靠的 所以我们不这样做也不声称这样做

是的 一个调用可以获取一个域名,并且可以选择最多100个地址 省略电子邮件字段仅审计该域名

审计路径和地址路径并行运行并独立失败:如果一个引擎不可访问,另一条路径的结果仍然会返回,同时在失败路径的块中会有一个命名错误

一般常见问题

Zyla API Hub 就像一个大型 API 商店,您可以在一个地方找到数千个 API。我们还为所有 API 提供专门支持和实时监控。注册后,您可以选择要使用的 API。请记住,每个 API 都需要自己的订阅。但如果您订阅多个 API,您将为所有这些 API 使用相同的密钥,使事情变得更简单。
价格以 USD(美元)、EUR(欧元)、CAD(加元)、AUD(澳元)和 GBP(英镑)列出。我们接受所有主要的借记卡和信用卡。我们的支付系统使用最新的安全技术,由 Stripe 提供支持,Stripe 是世界上最可靠的支付公司之一。如果您在使用卡片付款时遇到任何问题,请通过 [email protected]

此外,如果您已经以这些货币中的任何一种(USD、EUR、CAD、AUD、GBP)拥有有效订阅,该货币将保留用于后续订阅。只要您没有任何有效订阅,您可以随时更改货币。
定价页面上显示的本地货币基于您 IP 地址的国家/地区,仅供参考。实际价格以 USD(美元)为单位。当您付款时,即使您在我们的网站上看到以本地货币显示的等值金额,您的卡片对账单上也会以美元显示费用。这意味着您不能直接使用本地货币付款。
有时,银行可能会因其欺诈保护设置而拒绝收费。我们建议您首先联系您的银行,检查他们是否阻止了我们的收费。此外,您可以访问账单门户并更改关联的卡片以进行付款。如果这些方法不起作用并且您需要进一步帮助,请通过 [email protected]
价格由月度或年度订阅决定,具体取决于所选计划。
API 调用根据成功请求从您的计划中扣除。每个计划都包含您每月可以进行的特定数量的调用。只有成功的调用(由状态 200 响应指示)才会计入您的总数。这确保失败或不完整的请求不会影响您的月度配额。
Zyla API Hub 采用月度订阅系统。您的计费周期将从您购买付费计划的那一天开始,并在下个月的同一日期续订。因此,如果您想避免未来的费用,请提前取消订阅。
要升级您当前的订阅计划,只需转到 API 的定价页面并选择您要升级到的计划。升级将立即生效,让您立即享受新计划的功能。请注意,您之前计划中的任何剩余调用都不会转移到新计划,因此在升级时请注意这一点。您将被收取新计划的全部金额。
要检查您本月剩余多少 API 调用,请参考响应标头中的 "X-Zyla-API-Calls-Monthly-Remaining" 字段。例如,如果您的计划允许每月 1,000 个请求,而您已使用 100 个,则响应标头中的此字段将显示 900 个剩余调用。
要查看您的计划允许的最大 API 请求数,请检查 "X-Zyla-RateLimit-Limit" 响应标头。例如,如果您的计划包括每月 1,000 个请求,此标头将显示 1,000。
"X-Zyla-RateLimit-Reset" 标头显示您的速率限制重置之前的秒数。这告诉您何时您的请求计数将重新开始。例如,如果它显示 3,600,则意味着还有 3,600 秒直到限制重置。
是的,您可以随时通过访问您的账户并在账单页面上选择取消选项来取消您的计划。请注意,升级、降级和取消会立即生效。此外,取消后,您将不再有权访问该服务,即使您的配额中还有剩余调用。
为了让您有机会在没有任何承诺的情况下体验我们的 API,我们提供 7 天免费试用,允许您免费进行最多 50 次 API 调用。此试用只能使用一次,因此我们建议将其应用于您最感兴趣的 API。虽然我们的大多数 API 都提供免费试用,但有些可能不提供。试用在 7 天后或您进行了 50 次请求后结束,以先发生者为准。如果您在试用期间达到 50 次请求限制,您需要"开始您的付费计划"以继续发出请求。您可以在个人资料中的订阅 -> 选择您订阅的 API -> 定价标签下找到"开始您的付费计划"按钮。或者,如果您在第 7 天之前不取消订阅,您的免费试用将结束,您的计划将自动计费,授予您访问计划中指定的所有 API 调用的权限。请记住这一点以避免不必要的费用。
7 天后,您将被收取试用期间订阅的计划的全额费用。因此,在试用期结束前取消很重要。因忘记及时取消而提出的退款请求不被接受。
当您订阅 API 免费试用时,您可以进行最多 50 次 API 调用。如果您希望超出此限制进行额外的 API 调用,API 将提示您执行"开始您的付费计划"。您可以在个人资料中的订阅 -> 选择您订阅的 API -> 定价标签下找到"开始您的付费计划"按钮。
付款订单在每月 20 日至 30 日之间处理。如果您在 20 日之前提交请求,您的付款将在此时间范围内处理。
您可以通过我们的聊天渠道联系我们以获得即时帮助。我们始终在线,时间为上午 8 点至下午 5 点(EST)。如果您在该时间之后联系我们,我们将尽快回复您。此外,您可以通过 [email protected]

相关 API