{
"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]"]}'
{
"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 के साथ बस अपने बेयरर टोकन को Authorization हेडर में शामिल करें।
| हेडर | विवरण |
|---|---|
Authorization
|
आवश्यक
होना चाहिए Bearer access_key. जब आप सब्सक्राइब हों तो ऊपर "Your API Access Key" देखें।
|
कोई लंबी अवधि की प्रतिबद्धता नहीं। कभी भी अपग्रेड, डाउनग्रेड या कैंसल करें।
नहीं स्कोर कॉन्फ़िगरेशन पूर्णता को गिनता है - कौन सा MX SPF DMARC और DKIM-साधारण-चुनाव प्रकाशित हैं और रिकॉर्ड कैसे सेट किए गए हैं डिलीवरी प्रेषक की प्रतिष्ठा सामग्री और रिसीवर नीति पर निर्भर करती है जिनमें से कोई भी इस एपीआई द्वारा पढ़ी नहीं जाती या पढ़ने का दावा नहीं किया जाता
नहीं इसका मतलब है कि 12 सामान्य चयनकों में से कोई भी रिकॉर्ड नहीं है कस्टम चयनकर्ता के साथ साइन करने वाले डोमेन (जो बड़े प्रेषकों के लिए सामान्य है) इस जांच द्वारा पता नहीं लगाए जाते और प्रतिक्रिया के कवरेज नोट में इसका उल्लेख है
नहीं यह डोमेन मेल रूटिंग (MX) पंजीकरण डेटा और डोमेन स्तर पर जोखिम संकेतों की जांच करता है मेलबॉक्स स्तर पर जांच भरोसेमंद नहीं है इसलिए हम इसे नहीं करते और इस पर दावा नहीं करते
हाँ एक कॉल ठीक एक डोमेन लेता है और वैकल्पिक रूप से 100 पते तक ले सकता है ईमेल क्षेत्र को छोड़ दें ताकि केवल डोमेन का ऑडिट किया जा सके
ऑडिट लेग और एड्रेस लेग समानांतर चलते हैं और स्वतंत्र रूप से असफल होते हैं अगर एक इंजन अनुपलब्ध होता है तो दूसरे लेग के परिणाम अभी भी लौटाए जाते हैं जिसमें असफल लेग के ब्लॉक में एक नामित त्रुटि होती है