DMARC, DKIM, and SPF for Invoice Email

This page explains how invoice email from your domain is authenticated, so you or your IT team can check it against your email policy. The short version: Keito’s messages carry a DKIM signature for your domain, which is what DMARC needs. You don’t need to change your SPF or DMARC records.

DKIM: the signature for your domain

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message. Receiving mail servers check it against a public key published in your DNS.

The three CNAME records from the setup point your domain’s DKIM selectors at keys that the email provider manages for you. Every invoice email from your domain is signed with the domain in your From address, for example d=acme.example for billing@acme.example. Because the signing domain is exactly the From domain, the signature is aligned for DMARC in both relaxed and strict mode.

Keep the three CNAME records published. If one is removed or changed, Keito’s next check finds it and holds invoice emails from your domain until the record is fixed.

SPF: passes for the email provider, not aligned with your domain

SPF checks the envelope sender, also called the return path, rather than the From address that your clients see. Keito doesn’t set up a custom return-path (MAIL FROM) domain, so the return path uses the email provider’s domain. SPF passes for that domain, but it isn’t aligned with your domain.

That is fine for DMARC, which passes when either SPF or DKIM passes and is aligned. Aligned DKIM covers it.

  • You don’t need to change your SPF record for Keito.
  • Adding the email provider to your SPF record, for example with include:amazonses.com, doesn’t make Keito’s mail SPF-aligned, because SPF is evaluated for the return-path domain, not yours.
  • Keito never asks you to replace your SPF or MX records.

DMARC: your policy, unchanged

DMARC tells receiving servers what to do with mail that claims to be from your domain but fails authentication. It is published as a TXT record at _dmarc.<your domain>.

Invoice email from your domain passes DMARC through aligned DKIM, whatever your policy is:

Your DMARC policy Effect on Keito’s invoice email
p=reject Passes. Keep your policy.
p=quarantine Passes. Keep your policy.
p=none Passes. Receivers only report, as before.
No DMARC record DMARC isn’t evaluated. Aligned DKIM still authenticates the email. DMARC is recommended but not required.

Keito never changes your DMARC record and never recommends weakening it. If anyone suggests lowering your policy to make Keito work, the cause is something else, usually a DKIM record that isn’t published correctly.

In DMARC aggregate reports, Keito’s invoice email shows DKIM passing and aligned for your domain, and SPF passing for the email provider’s domain without alignment. That pattern is expected.

The DMARC advisory in Keito

The Verify step shows a DMARC (advisory, not required) panel. It reports the policy that applies to your sending domain. Keito looks it up the way receiving servers do:

  1. Your exact sending domain first, for example _dmarc.billing.acme.example for invoices@billing.acme.example.
  2. Then the organizational domain, only when the exact name has no DMARC record. For billing.acme.example that is _dmarc.acme.example. A record found there governs subdomains through its sp= tag, or through p= when it has no sp= tag.

The panel shows the record it checked, the policy it found, and when it checked. Typical messages:

  • An existing DMARC policy was found: “An existing DMARC policy (p=quarantine) was found for acme.example. Keito signs with aligned DKIM for acme.example, which satisfies DMARC alignment; do not weaken this record.”
  • Inherited from the organizational domain: “billing.acme.example has no DMARC record of its own, so it inherits the policy published for acme.example (sp=reject).”
  • No record: “No DMARC record was found at _dmarc.billing.acme.example or _dmarc.acme.example. DMARC is recommended but not required.”
  • Invalid record: the record is published but receivers ignore it, for example because it has a repeated tag or no valid p=. Several DMARC records at one name are also ignored. Ask your DNS administrator to publish a single valid record.
  • DNS didn’t answer: Keito shows the previous result, if it has one, and tries again. A failed lookup is never reported as a missing record.

The advisory never blocks setup or sending.

Your domain’s other email

The Keito records live on their own host names: _keito-verification.<your domain> and three <token>._domainkey.<your domain> names. They don’t replace or conflict with:

  • your MX records, so mail to your domain is delivered as before;
  • your SPF record;
  • your DMARC record; or
  • DKIM records for other services, such as Google Workspace or Microsoft 365, which use different selectors.