SentraDMARC

How hosting works (CNAME delegation)

You point a name on your domain at a record we publish, once. From then on, the record's contents change from the dashboard rather than at your registrar.

Why delegate

  • The SPF lookup limit. SPF allows 10 DNS lookups per check. Every include: costs one, plus those nested inside it, and the nested records belong to your providers. Hosted SPF resolves your senders to their addresses and publishes the result. See SPF flattening.
  • Fewer hand edits. A hand-edited TXT record is easy to break and slow to correct: a fix reaches resolvers only as the old answer's TTL expires, often an hour or more at a registrar.
  • One place to change things. Your DMARC policy, your SPF senders, your MTA-STS policy and your BIMI logo all change from the dashboard.

What changes from the dashboard, and what still needs a DNS edit

After setup, these are changed without a registrar login: your DMARC policy and subdomain policy, the senders in hosted SPF, your MTA-STS mode, MX list and cache window, and your BIMI logo and certificate. A few things still need you at your DNS host, because the record lives on your domain:

  • The one-time SPF swap, replacing your apex SPF record with ours.
  • The SPF qualifier in "Keep control" mode: the ~all or -all at the end of your record is yours to change. In "Set once" mode the dashboard sets it. See Moving your SPF.
  • A new DKIM selector, which is a new name on your domain (<selector>._domainkey).
  • The BIMI CNAME at default._bimi, added once after your logo is uploaded.

When changes reach receivers

A policy change you approve is written to our zone when you save it. Resolvers that cached the previous answer pick up the new one within the record's 300-second TTL.

Hosted SPF is different: nobody approves each update. The worker re-resolves your senders on an hourly schedule, in batches, and republishes your record only when its addresses change. A result that looks broken is held rather than published. See SPF flattening.

What we do not do

  • We hold no signing keys. DKIM signs at send time, so only your mail provider can hold the private key. We host the public record your provider issued, at the selector it signs with. Providers that issue a CNAME (Microsoft 365, SendGrid, Amazon SES…) rotate their own key behind it.
  • We issue no certificates. The certificate for your mta-sts host is obtained by Traefik, the proxy in front of our policy server, on the first HTTPS request after your CNAME resolves.
  • We do not block mail. Receivers apply your policy. We publish it.

Where your records live

Every hosted record is written to our zone in AWS Route 53, which answers from AWS's anycast nameservers. Your DNS keeps resolving even if the SentraDMARC application is down: the dashboard changes records, it does not serve them. MTA-STS is the exception. Its policy file is fetched over HTTPS from our policy server, so an outage there stops senders retrieving it; senders that already hold your policy keep using it for its cache window.