Viesti Sign in

DKIM, SPF and DMARC setup for your sending domain

Before a domain can send, it needs DNS records that prove you control it and let receivers authenticate its mail with DKIM, SPF and DMARC. The Sending domains page lists the exact values for each domain and checks them for you.

The records

For a sending domain yourdomain.com:

Record Type Name Value Required
Ownership TXT _viesti.yourdomain.com viesti-verification=<token> yes
DKIM CNAME v1._domainkey.yourdomain.com v1.<id>.dkim.viesti.email yes
SPF TXT yourdomain.com v=spf1 include:spf.viesti.email ~all, merged with your existing record yes
DMARC TXT _dmarc.yourdomain.com v=DMARC1; p=none, listed only when no policy covers the domain a policy must exist
Return-Path CNAME viesti.yourdomain.com bounce.viesti.email no
Replies MX or A yourdomain.com Any mail host no

The token and the 8-character <id> are unique to each domain; copy them from the domain's card. Some DNS providers append your domain to every name you enter; if yours does, enter only the part before yourdomain.com, such as _viesti. On Cloudflare or any provider with a proxy toggle, set the records to DNS only.

Ownership TXT

_viesti.yourdomain.com must return exactly viesti-verification= followed by the domain's token. It proves the workspace adding the domain controls its DNS. Until a domain verifies, any workspace can add it; once verified, no other workspace can verify it. A domain that has never verified is removed after 30 days.

DKIM CNAME

Viesti generates a 2048-bit RSA signing key for each domain and signs every message with it, as d=yourdomain.com with selector v1. You do not publish the key. You publish a CNAME that delegates the selector to Viesti's DKIM zone, dkim.viesti.email, which serves the public key. Because the key lives behind your CNAME, Viesti can replace it without any DNS change on your side.

Publish a CNAME, not a TXT record, at v1._domainkey. The check looks up TXT at that name, follows the CNAME, and compares the key it finds with the domain's key.

SPF TXT

Your domain's SPF record must include spf.viesti.email, the SPF record that lists the servers Viesti sends from. A domain may publish only one SPF record: with two, SPF evaluation returns a permanent error (RFC 7208, section 4.5; checked 26 September 2026). So the page reads the record you publish today and shows one merged value:

  • No SPF record yet: v=spf1 include:spf.viesti.email ~all.
  • An existing record: the include is inserted before its all mechanism or redirect= modifier, and the rest is kept. v=spf1 include:_spf.example.net ~all becomes v=spf1 include:_spf.example.net include:spf.viesti.email ~all.
  • More than one SPF record: the page merges the first and says so. Fold anything the others need into it and publish it as the only one.

Replace your existing record with the merged value. SPF evaluation allows at most 10 DNS-querying terms, such as include, a and mx, and returns a permanent error beyond that (RFC 7208, section 4.6.4; checked 26 September 2026). If your record already has many includes, remove the ones for services you no longer use.

DMARC TXT

DMARC tells receivers what to do with mail that fails authentication. Verification requires a valid DMARC policy (v=DMARC1 with p=none, quarantine or reject) at _dmarc.yourdomain.com or, when there is none, at your organizational domain: for notifications.yourdomain.com, that is _dmarc.yourdomain.com.

If such a policy exists, the page does not list a DMARC record and you have nothing to do. Publishing p=none at a subdomain would override a stricter policy it inherits. If none exists, the page asks for v=DMARC1; p=none, which changes nothing about how your mail is handled: receivers must not change their handling because of p=none (RFC 9989, which replaced RFC 7489 in May 2026; checked 26 September 2026). To receive aggregate reports, add a rua=mailto: tag with your own address. Move to quarantine or reject once all mail from the domain authenticates.

Return-Path CNAME (optional)

Every message leaves with an envelope sender (Return-Path) that Viesti signs, so bounces and complaints come back to Viesti and can be attributed. By default it is an address at bounce.viesti.email. With viesti.yourdomain.com pointing at bounce.viesti.email, it becomes an address at viesti.yourdomain.com, which aligns SPF with your From domain, as described under alignment. The name is prefixed so it does not collide with records you may already have.

Viesti switches to the aligned Return-Path only after a DNS check sees the record, so press Check DNS after you publish it. A provider that flattens CNAMEs also passes, as long as the name returns an SPF record that includes spf.viesti.email and has a mail host.

Replies: MX or A (optional)

Replies to your From address go to your domain's mail host. If the domain has no MX or A record, a recipient's reply cannot be delivered. Viesti does not receive or forward replies, so any mail host you already use works.

How verification works

Press Check DNS on the domain's card. Viesti looks up every record and gives each a status:

  • published: the record is there with the expected value.
  • missing: nothing is published at that name.
  • mismatch: something is published there, but not the expected value. Correct the record you have instead of adding another.
  • no answer: DNS did not answer in time. Nothing changes; check again in a few minutes.

When every required record is published, the domain is verified and can send. Viesti checks verified domains again every 24 hours and whenever you press Check DNS. If a required record is conclusively missing or wrong, the domain loses its verification and mail from it is refused until you fix the record and check again. Mail already queued waits, and fails if the domain is not verified again within 72 hours of submission. A lookup that gets no answer never unverifies a domain.

Viesti's DKIM zone serves keys with a 300-second TTL. How soon your own records are visible depends on your DNS provider and the TTLs in your zone. To look them up yourself:

dig +short TXT _viesti.yourdomain.com
dig +short CNAME v1._domainkey.yourdomain.com
dig +short TXT yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short CNAME viesti.yourdomain.com

Alignment: why DMARC passes

A message passes DMARC when SPF or DKIM passes for a domain aligned with the domain in its From header. Relaxed alignment, the default for both, only requires the two domains to share an organizational domain; strict alignment requires them to be identical (RFC 9989; checked 26 September 2026).

  • DKIM is signed with d=yourdomain.com, the From domain itself, so it aligns under both relaxed and strict alignment.
  • SPF is checked for the Return-Path domain. At bounce.viesti.email it passes but is not aligned with your domain, so DMARC relies on DKIM. With the Return-Path CNAME, the envelope is at viesti.yourdomain.com, which shares your organizational domain, so SPF aligns under relaxed alignment. With aspf=s in your DMARC record, it does not.

DKIM alone is enough for DMARC to pass. Aligned SPF adds a second path, and the two fail in different situations: mail relayed by a forwarder usually fails SPF while its DKIM signature generally stays valid (RFC 9989, section 7.4), and a mailing list that adds a footer or subject prefix invalidates DKIM (RFC 6377; both checked 26 September 2026).

Next: send a first email, or see how bounces come back through the Return-Path.