DomainTrust Audit API

API ID 14803

Domain mail-authentication audit API: MX, SPF, DMARC and DKIM-selector checks from public DNS, a 0-100 configuration completeness score, plus address screening.

API Documentation

Endpoints

Request
JSON body {"domain": "...", "emails": ["...", "..."]} (POST only; emails is optional, up to 100 addresses). Example response (summary block from a real response; every response also carries the full audit block, per-address results when emails were sent, and a scope statement): {"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}}}}} Errors are named: 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
INPUT PARAMETERS

Audit domain — Endpoint Features

Object Description
Request Body Required Json

Free test requests remaining: 3 of 3.


INPUT PARAMETERS

API EXAMPLE RESPONSE
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."
        }
    }
}
Audit domain — CODE SNIPPETS

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]"]}'

    
Request
Service status check: returns whether the API service is up and responding normally, so callers can verify availability before running an audit.
Endpoint ID: 38382
GET https://zylalabs.com/api/14803/domaintrust+audit+api/38382/health+check
INPUT PARAMETERS

Free test requests remaining: 3 of 3.

This endpoint does not require any input parameters.

API EXAMPLE RESPONSE
JSON
{
    "ok": true,
    "service": "DomainTrust Audit",
    "version": 1
}
Health check — CODE SNIPPETS

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


    

API Access Key & Authentication

After signing up, every developer is assigned a personal API access key, a unique combination of letters and digits provided to access to our API endpoint. To authenticate with the DomainTrust Audit API simply include your bearer token in the Authorization header.

Headers
Header Description
Authorization Required Should be Bearer access_key. See "Your API Access Key" above when you are subscribed.

No long-term commitment. Upgrade, downgrade, or cancel anytime.

Starts at
$10,000/Year


  • Custom Volume
  • Custom Rate Limit
  • Specialized Customer Support
  • Real-Time API Monitoring

Overview

Domain mail-authentication audit API: MX, SPF, DMARC and DKIM-selector checks from public DNS, a 0-100 configuration completeness score, plus address screening.

DomainTrust Audit API FAQs

No. The score counts configuration completeness — which of MX, SPF, DMARC and DKIM-under-common-selectors are published, and how the records are set. Delivery depends on sender reputation, content and receiver policy, none of which this API reads or claims to read.

No. It means none of the 12 common selectors holds a record. Domains that sign with a custom selector (common for large senders) are not detected by this check, and the response's coverage note says so.

No. It checks domain mail routing (MX), registration data and risk signals at domain level. Mailbox-level probing is unreliable, so we do not do it and do not claim it.

Yes. One call takes exactly one domain and, optionally, up to 100 addresses. Omit the emails field to audit the domain only.

The audit leg and the address leg run in parallel and fail independently: if one engine is unreachable, the other leg's results are still returned, with a named error in the failed leg's block.

General FAQs

To obtain your API key, first sign in to your account and navigate to the API you want to use. From the API's Pricing section, choose a plan and complete the subscription process. Once subscribed, return to the API page and you will see your API Access Key displayed at the top of the documentation page. You can use this key to authenticate your requests.

You can’t switch APIs during the free trial. If you subscribe to a different API, your trial will end and the new subscription will start as a paid plan.

The free trial lasts for 7 days and allows you to make up to 50 API requests.

No, the free trial is available only once, so we recommend using it on the API that interests you the most. Most of our APIs offer a free trial, but some may not include this option.

Yes. If the API offers a free trial, you will see a "Free 7-Day Trial" option in its Pricing section. The trial lasts for 7 days and allows up to 50 API requests, enabling you to evaluate the API before subscribing to a paid plan.

Zyla API Hub is like a big store for APIs, where you can find thousands of them all in one place. We also offer dedicated support and real-time monitoring of all APIs. Once you sign up, you can pick and choose which APIs you want to use. Just remember, each API needs its own subscription. But if you subscribe to multiple ones, you'll use the same key for all of them, making things easier for you.

Prices are listed in USD (United States Dollar), EUR (Euro), CAD (Canadian Dollar), AUD (Australian Dollar), and GBP (British Pound). We accept all major debit and credit cards. Our payment system uses the latest security technology and is powered by Stripe, one of the world's most reliable payment companies. If you have any trouble paying by card, just contact us at [email protected]

Additionally, if you already have an active subscription in any of these currencies (USD, EUR, CAD, AUD, GBP), that currency will remain for subsequent subscriptions. You can change the currency at any time as long as you don't have any active subscriptions.
The local currency shown on the pricing page is based on the country of your IP address and is provided for reference only. The actual prices are in USD (United States Dollar). When you make a payment, the charge will appear on your card statement in USD, even if you see the equivalent amount in your local currency on our website. This means you cannot pay directly with your local currency.
Occasionally, a bank may decline the charge due to its fraud protection settings. We suggest reaching out to your bank initially to check if they are blocking our charges. Also, you can access the Billing Portal and change the card associated to make the payment. If these does not work and you need further assistance, please contact our team at [email protected]
Prices are determined by a recurring monthly or yearly subscription, depending on the chosen plan.
API calls are deducted from your plan based on successful requests. Each plan comes with a specific number of calls that you can make per month. Only successful calls, indicated by a Status 200 response, will be counted against your total. This ensures that failed or incomplete requests do not impact your monthly quota.
Zyla API Hub works on a recurring monthly subscription system. Your billing cycle will start the day you purchase one of the paid plans, and it will renew the same day of the next month. So be aware to cancel your subscription beforehand if you want to avoid future charges.
To upgrade your current subscription plan, simply go to the pricing page of the API and select the plan you want to upgrade to. The upgrade will be instant, allowing you to immediately enjoy the features of the new plan. Please note that any remaining calls from your previous plan will not be carried over to the new plan, so be aware of this when upgrading. You will be charged the full amount of the new plan.
To check how many API calls you have left for the current month, refer to the 'X-Zyla-API-Calls-Monthly-Remaining' field in the response header. For example, if your plan allows 1,000 requests per month and you've used 100, this field in the response header will indicate 900 remaining calls.

You can monitor your API usage through the response headers included with every request:

x-zyla-api-calls-monthly-used: Shows the total number of API requests you have used during the current billing period.
x-zyla-api-calls-monthly-remaining: Shows the number of API requests you have remaining for the current billing period.

The 'X-Zyla-RateLimit-Reset' header shows the number of seconds until your rate limit resets. This tells you when your request count will start fresh. For example, if it displays 3,600, it means 3,600 seconds are left until the limit resets.

Yes, you can cancel your subscription at any time. Simply go to the Pricing section of the API you're subscribed to and click the "Unsubscribe" button.

Please note that upgrades, downgrades, and cancellations take effect immediately. Once your subscription is canceled, access to the service will end immediately, regardless of any remaining API calls in your quota.

After 7 days, you will be charged the full amount for the plan you were subscribed to during the trial. Therefore, it's important to cancel before the trial period ends. Refund requests for forgetting to cancel on time are not accepted.
When you subscribe to an API free trial, you can make up to 50 API calls. If you wish to make additional API calls beyond this limit, the API will prompt you to perform an "Start Your Paid Plan." You can find the "Start Your Paid Plan" button in your profile under Subscription -> Choose the API you are subscribed to -> Pricing tab.
You can contact us through our chat channel to receive immediate assistance. We are always online from 8 am to 5 pm (EST). If you reach us after that time, we will get back to you as soon as possible. Additionally, you can contact us via email at [email protected]

Please have a look at our Refund Policy: https://zylalabs.com/terms#refund


Related APIs