Four DNS records, and a domain that receivers trust.

What each record proves.

SPF is a TXT record that lists the servers allowed to send mail whose return path is your domain. A receiver reads the return-path domain from the envelope, fetches its SPF record and checks that the connecting server is on the list. It proves the message came from somewhere you authorised; it says nothing about whether the content is intact. The record has a hard limit of ten DNS lookups, which is easy to exceed once several services are included. The SPF page covers the syntax, the lookup limit and how to stay under it.

DKIM is a signature. The sending service signs selected headers and the body with a private key and adds the signature as a header; the matching public key is published in DNS at selector._domainkey.yourdomain. A receiver fetches the key named by the selector and checks the signature, which proves the message was not altered in transit and was signed by someone holding your key. Each service that sends for you gets its own selector, so keys never collide. The DKIM page explains selectors, key rotation and what a failed signature looks like.

DMARC ties the two together. It is a TXT record at _dmarc.yourdomain that tells receivers what to do when a message fails both SPF and DKIM, or passes one without the passing identity matching the visible from domain, which is called alignment. The policy is none (deliver and report), quarantine (spam folder) or reject. It also names an address for aggregate reports, which is how you find out what is sending as you. The DMARC page has example records for each policy and how to read the reports.

The one-click path: Domain Connect.

Domain Connect is an open protocol between services that need DNS records and the providers that host DNS. A provider that supports it publishes a _domainconnect TXT record on each zone and keeps a catalogue of service templates; a service that supports it hands the provider a signed link, the provider shows you the records it is about to write, and you approve them in one click.

Notix does the discovery when you add a domain. It walks up from the domain to the zone that holds it, looks for the _domainconnect record, asks the provider whether the Notix template is available there, and if it is, the domain page offers a “Set up automatically at” button naming your provider, beside the records table. The link is signed and expires after fifteen minutes; it opens your provider’s confirmation screen and brings you back to Notix once the records are written. Verification then runs as it would for records you typed. If the zone has no _domainconnect record, or the provider has not synced the template, the page shows the manual records and says nothing about Domain Connect; there is no degraded half-automatic mode.

Verification, and how long it takes.

Notix checks the DKIM key, the mail-from records and, for the dashboard’s recommendation, the DMARC record. A domain that has never verified is rechecked every six hours, and the domain page’s “Verify domain” button runs a check on demand; once verified it is rechecked every thirty days so a record deleted in a DNS tidy-up is noticed. You get an email when the status changes to verified. Records that were not there before usually resolve within minutes of your provider publishing them; a record you corrected can take as long as its previous TTL to clear from resolvers that cached the old value.

The quickest check is to ask DNS yourself, from a machine that is not your provider’s own resolver:

If the values come back and the dashboard still shows the record pending, wait for the next automatic check or trigger one. If a value comes back empty or different, the record is on the wrong host or the value was mangled on the way in; the mistakes below account for nearly every case.

Check your setup.

The domain page in the dashboard shows a status per record: not started, pending or verified for DKIM and the mail-from pair, and added or missing for DMARC. A domain sends only once DKIM and the mail-from records are verified; until then the transactional email API refuses a from address on that domain, and the pre-send deliverability check reports domain_unverified as a blocking finding and dmarc_missing as a warning. Once everything is green, the records need no further attention unless you rotate keys, change providers or tighten the DMARC policy, and deliverability becomes a question of what you send and to whom, rather than whether receivers can tell it is you.