DKIM, SPF, and DMARC

Email platforms commonly require several DNS records. Treat the exact values from your mail service as trusted application configuration and create them in the same connection intent.

SPF

SPF is a TXT record, usually at the zone root. A domain must not publish multiple independent SPF policies.

{
  host: '@',
  type: 'TXT',
  value: 'v=spf1 include:_spf.example.net ~all',
  ttl: 300,
}

Domain0 inspects existing records before preparing an automatic change plan. The customer sees the effective change before anything is written.

DKIM

DKIM records use a selector supplied by the mail service. Depending on the service, the record is TXT or CNAME.

{
  host: 'mail-2026._domainkey',
  type: 'CNAME',
  value: 'mail-2026.dkim.example.net',
  ttl: 300,
}

Enable post-connection DKIM guidance when your customer may need to finish mail-provider activation after DNS is ready:

await domain0.connectDomain({
  client,
  connectionId,
  enableDkim: true,
  dkimSelectors: ['mail-2026'],
})

DNS evidence proves only that the expected record is published. It does not prove that outbound signing is enabled inside the customer's mail account.

DMARC

DMARC is a TXT record at _dmarc and requires a valid v=DMARC1 policy value.

{
  host: '_dmarc',
  type: 'TXT',
  value: 'v=DMARC1; p=none; rua=mailto:dmarc@example.com',
  ttl: 300,
}

When your product needs an explicit mutation policy, attach bounded advanced options to that record:

{
  host: '_dmarc',
  type: 'TXT',
  value: 'v=DMARC1; p=none',
  advancedDmarcOptions: {
    inheritRootDmarc: true,
    overrideTags: { p: 'quarantine' },
    removeTags: ['pct'],
    addTagsIfNotExist: { aspf: 's' },
  },
}

Advanced options are accepted only for a valid DMARC TXT record. Domain0 uses the supplied value unchanged when existing policy cannot be interpreted unambiguously.