Email authentication explained

If you have set up a sending domain before, you probably copied SPF, DKIM, and DMARC records into a DNS panel without needing to inspect them. This page explains what those records do and why comail asks for two DKIM records instead of one.

For the literal record values, see DNS records. This page is the concept side.

How receivers check the From header

The From: header in an email is unverified. Anything can put anything there. So when Gmail receives a message claiming to be from you@yourdomain.com, it has to answer two questions:

1. Is the sending server allowed to send for yourdomain.com?
2. Did the message arrive unmodified from that server?

SPF answers question 1. DKIM answers question 2. DMARC ties them back to the From header and tells receivers what to do if either fails.

SPF: “this IP is allowed to send for my domain”

Your domain publishes a TXT record listing which IPs are authorised to send mail for it. The receiver checks the connecting IP against that list. Pass or fail.

yourdomain.com  TXT  "v=spf1 ip4:203.0.113.77 -all"

The -all at the end marks other senders as unauthorized. The right SPF policy depends on every service that sends mail for your domain. Use the value Comail gives you and do not replace records used by other senders.

SPF checks the envelope sender, not the From: header. The envelope sender is the address the receiving server uses for bounces (the MAIL FROM in SMTP). Comail uses a return-path domain under atmos.email. That domain does not align with your domain, so SPF does not pass DMARC alignment for your mail. Your domain’s DKIM signature provides the aligned DMARC result.

DKIM: “this message was not modified in transit”

Your sending server hashes the message body and selected headers, then signs the hash with a private key. Your domain publishes the matching public key in DNS. The receiver uses that key to verify the signature and message hash.

If verification passes, the signed parts match the message and the signature matches the published key.

The DNS record looks like:

<selector>._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=<public-key>"

The <selector> is a short tag (like selector1 or cm2026) that lets you rotate keys without breaking old messages still in transit. The selector is included in the signature header, so the receiver knows which DNS record to look up.

DMARC: “what should happen when SPF or DKIM fails”

DMARC tells receiving servers what policy you request when neither an aligned SPF result nor an aligned DKIM signature passes.

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=reject; ..."

The three policy modes:

• p=none: observe only. Note that comail’s enrollment check rejects p=none, so a domain cannot verify while set to it. For an observation window, use p=quarantine (optionally with a pct= ramp) instead.
• p=quarantine: ask the receiver to quarantine failing mail.
• p=reject: ask the receiver to reject failing mail.

DMARC checks whether a passing SPF or DKIM result aligns with the visible From domain. It supports two alignment modes:

• Strict (adkim=s / aspf=s): domains must match exactly.
• Relaxed (adkim=r / aspf=r): the organisational domain must match (subdomains are fine).

Comail’s return-path domain does not align with your domain in either mode. The DKIM signature under your domain provides DMARC alignment.

Why comail signs under two domains

Open an email comail sent and look at the headers. You will see four DKIM-Signature lines: an RSA and Ed25519 pair from your domain, plus another pair from d=atmos.email.

Comail also signs mail with d=atmos.email. This gives Comail a shared signing domain across member traffic. Receiving providers choose how to use this signal; Comail cannot guarantee that the signatures improve delivery or reputation.

Your domain’s DKIM signature can align with your DMARC record. The d=atmos.email signature does not replace it.

The pool signatures do not affect alignment, do not appear in your DNS, and do not replace your domain DKIM. They are additional credentials the receiver can evaluate.

The shared signing domain is operated by Comail. The way a receiver uses it depends on that receiver.

RSA + Ed25519: why two algorithms

Your domain DKIM uses two records, not one:

<selector>r._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=..."
<selector>e._domainkey.yourdomain.com  TXT  "v=DKIM1; k=ed25519; p=..."

Receiving servers can verify a signature only if they support its algorithm. Comail publishes both keys; it does not control which signature a receiver uses.

How authentication failures appear

An authentication failure can affect delivery. Each receiving provider applies its own rules, so a failure does not always cause the same result.

What you’ll see instead, if you look:

• DMARC aggregate reports (the rua= address in your DMARC record) start showing failure counts.
• Provider dashboards may report authentication failures.
• /account shows domain and sending status. See Atproto labels for label status.

comail requires p=quarantine or p=reject to verify your domain. Start at p=quarantine, watch your rua= aggregate reports, and tighten to p=reject once they look clean. Setting p=none will fail verification.

What you and Comail do

You handle:

• Publishing all four DNS records at enrollment.
• Verifying they propagate (the enrollment flow checks for you, but DNS can be slow).
• Reviewing DMARC reports and choosing a policy that fits your domain.

Comail handles:

• Generating and storing the DKIM key pairs. Members publish only the public keys in DNS.
• Signing outbound messages with your domain’s DKIM key and Comail’s operator key.
• Showing domain and sending status in /account.

You publish the records in your DNS. Comail operates the mail relay and its signing keys.

Back to docs