DNS Records

In short: Entries in a domain’s DNS zone that determine, among other things, which server is responsible for the domain (A record), which address an alias points to (CNAME), or which servers may receive emails (MX).

In more detail: Important types: A (domain → IP address), CNAME (domain → another domain), TXT (arbitrary text, e.g. for domain verification or SPF/DKIM), MX (mail server responsibility). A wildcard record (*.domain.com) covers any number of subdomains at once — with externally managed DNS providers (like OVH here) this can’t be solved with individual A/CNAME records; for that, the hosting provider would have to take over the complete nameserver management.

Our context: Managed at OVH — including TXT records for Vercel domain verification, as well as DKIM/SPF for Resend. A wildcard record will later be needed for the planned multi-tenant model (subdomains per customer).

In Depth

SPF and DKIM in detail

SPF and DKIM (both set up via TXT records) are two different, complementary mechanisms that email recipients use to check whether an email really comes from the stated domain and isn’t forged:

• SPF (Sender Policy Framework) lists which mail servers are authorised to send on behalf of the domain at all — the recipient checks whether the server that actually sent the mail is on this list. A typical SPF record looks like v=spf1 include:_spf.resend.com ~all — include points to the mail service provider’s server list, ~all marks unlisted senders as a “soft fail” (suspicious, but not rejected outright).
• DKIM (DomainKeys Identified Mail) cryptographically signs every outgoing email with a private key; the recipient checks the signature against the public key published as a TXT record — confirming that the email wasn’t altered in transit. Unlike SPF (which only checks the SENDING server), DKIM additionally secures the integrity of the content itself.

A third, often overlooked mechanism is DMARC (also a TXT record), which specifies what should happen to emails that fail SPF and/or DKIM (reject, move to spam, or just log) — and optionally names an address for reports about failed checks. Without a DMARC record, each receiving mail server decides at its own discretion what happens with failed SPF/DKIM checks.

Consequences of a missing setup

Without both set up correctly, outgoing emails automatically end up in the spam folder for many recipients (especially Gmail, Outlook) or are rejected entirely — mail services such as Resend provide the required TXT record values in their dashboard, which you then enter at your own DNS provider (OVH here). A common stumbling block: DNS changes take time to propagate through the global DNS system — depending on the previous record’s TTL and caching at various resolvers, this can take anywhere from minutes to 48 hours, which is why a freshly set-up mail domain doesn’t work reliably right away.

Record types compared

Beyond the types mentioned in the short section, there are, among others, AAAA (like A, but for IPv6 addresses instead of IPv4), NS (determines which nameservers are authoritative for the domain at all — the “meta level” above all other records), and SRV (for services that need a specific host AND port combined, e.g. some VoIP or chat protocols). Each record type has its own TTL, which can be configured independently of other records of the same domain — sensibly set low shortly before a planned change so that the change takes effect faster.

See also: Multi-tenant architecture, Resend, TTL, CNAME