Email authentication is a set of DNS records, and every one of them can be wrong in a way that still delivers mail. SPF can pass because the sending server is listed, while the domain still has no DMARC policy. DKIM can sign with a key that receivers ignore. A message lands in the inbox during a test and starts landing in spam a week later, after the provider tightens a filter.
The email authentication endpoint reads SPF, DMARC, DKIM and MX for one domain in a single request and returns a verdict with the specific problems. It is the check to run before a campaign, after a provider change, and once a month for domains that only send transactional mail.
Why one call beats three
SPF, DMARC and DKIM are separate TXT records, but a diagnosis uses them together. A missing DMARC record matters more when SPF ends in a soft policy. A DKIM key in testing mode explains a pass that receivers do not count. Reading three records by hand means three terminal commands and a mental model of how they interact.
The endpoint returns the SPF record parsed into mechanisms, with the lookup count that RFC 7208 limits to ten. Includes and redirects are resolved, so a chain that exceeds the limit is reported even when the top level record looks short. A record ending in +all fails the verdict, because any host can then send as the domain.
curl "https://api2.globus.studio/v2/mail-auth?domain=globus.studio"The DMARC block carries the policy, the subdomain policy, the percentage, the alignment modes and the report addresses. The DKIM block is returned per selector, because the selector is chosen by the sender and one domain can have several.
The checks that catch real problems
A null MX record means the domain refuses mail on purpose, and the endpoint reports it as a statement rather than a failure. A missing MX is different: the domain is expected to receive mail and cannot.
A DMARC policy of none gives reports without enforcement. It is a reasonable first step during a migration and a permanent setting on far too many domains. The verdict marks it as a warning, and so does a pct below 100, which applies the policy to only part of the traffic.
Missing report addresses are easy to ignore and hard to recover from. Without rua, nobody sees which senders fail authentication, so the next change is made blind.
A default selector often returns nothing. That is not a broken key: many providers use names like google, selector1 or a date. Pass up to five selectors separated by commas and the endpoint checks each one.
Reading the verdict
The level field is ok, warn or fail. A monitor can alert on the level and keep the issue list for the person who fixes the record. The issues are written as sentences on purpose: a log line that says dmarc p=none needs a second lookup, while “DMARC policy is none: reports only, no enforcement” does not.
The endpoint never claims a message will be delivered. Authentication is one input among many, and reputation, content and volume matter as much. What it can say is whether the DNS side of the setup is complete.
Limits
Answers are cached for fifteen minutes, which matches how often these records change. The whole lookup has a five second budget, and nested SPF includes share it. A domain with a deep include chain and a slow resolver may come back with partial: true, and a retry fills the gaps.
The catalogue page has the parameter table and a live example: email authentication API.