[ Sending-service guides ]

Authenticate email sent through Kinsta Hosting: configuration and verification

Understand Kinsta’s default transactional-email alignment limit and move mail to a verified external route when your domain needs DMARC alignment.

By the EmailAuth research team · 4 min read

[ Key points ]

  • The default Kinsta transactional route lacks customer-domain DMARC alignment.
  • Adding an SPF include cannot change the provider-controlled envelope.
  • Choose a verified aligned replacement without weakening domain policy.
On this page
  1. Key points
  2. Takeaway
  3. By role
  4. Frequently asked questions
  5. Sources
  6. Glossary
  7. Related guides

[ Takeaway ]

Choose a verified aligned replacement without weakening domain policy.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Inspect the actual sender chain

DNS hosting and SPF authorization do not establish aligned customer-domain sending.

Next steps

  1. Inventory plugins and routes.
  2. Publish only approved account records.
  3. Compare actual From, envelope and signatures.

CISO / SecOps

Preserve existing enforcement

Removing keys or lowering policy does not create the missing aligned identity.

Next steps

  1. Reject broad policy shortcuts.
  2. Review credential handling.
  3. Approve a tested recovery route.

Founder / Non-technical

Choose a route that meets the requirement

Kinsta’s included transactional route is documented as lacking DMARC alignment.

Next steps

  1. Identify critical site mail.
  2. Approve a suitable replacement when needed.
  3. Require functional and authentication evidence.

[ FAQs ]

Frequently asked questions

Does Kinsta’s default MailChannels route support DMARC alignment?

The cited current documentation says it does not.

Tools - Email - Kinsta® Docs Domains and DNS - Kinsta's DNS - Kinsta® Docs RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC

Will adding the documented SPF include fix alignment?

No. Authorization cannot change the provider-controlled envelope identity.

Tools - Email - Kinsta® Docs Domains and DNS - Kinsta's DNS - Kinsta® Docs RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC

Can I change the default envelope address?

Kinsta’s DNS guide says that identity cannot be changed for the included service.

Tools - Email - Kinsta® Docs Domains and DNS - Kinsta's DNS - Kinsta® Docs RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC

Does included DKIM prove my own domain is signed?

No. Inspect d=; provider-domain signing is different from customer-domain alignment.

Tools - Email - Kinsta® Docs Domains and DNS - Kinsta's DNS - Kinsta® Docs RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC

Should I delete a working DKIM record to accommodate this route?

No. That can break another sender without creating the missing aligned identity.

Tools - Email - Kinsta® Docs Domains and DNS - Kinsta's DNS - Kinsta® Docs RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC

Does hosting DNS at Kinsta make it my mailbox provider?

No. DNS hosting, website hosting and mailbox delivery are separate roles.

Tools - Email - Kinsta® Docs Domains and DNS - Kinsta's DNS - Kinsta® Docs RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC

Can I use the included service for newsletters?

Kinsta’s documented scope excludes non-transactional campaign mail.

Tools - Email - Kinsta® Docs Domains and DNS - Kinsta's DNS - Kinsta® Docs RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC

What remains before approving an external route?

Current provider setup, live DNS and original received-message identity evidence, business-flow tests and human review.

Tools - Email - Kinsta® Docs Domains and DNS - Kinsta's DNS - Kinsta® Docs RFC 7208 SPF RFC 6376 DKIM RFC 9989 DMARC

[ Sources ]

Sources

  1. Tools - Email - Kinsta® Docs

    Sections MailChannels286–292; transactional scope293–302; plan limits306–314

  2. Domains and DNS - Kinsta's DNS - Kinsta® Docs

    Sections Alignment514–525; immutable envelope578–580; unsafe policy advice584 not adopted; include594–611

  3. RFC 7208 SPF

    Sections §3.2; 3.3; 4.6.4

  4. RFC 6376 DKIM

    Sections §3.5; 3.6.2; 6.1

  5. RFC 9989 DMARC

    Sections §4.4; 4.7; 4.10; 5

[ Glossary ]

Glossary

Transactional email
A message generated in response to an application or user event, such as a password reset.
Header From
The visible sender address in the message, which DMARC uses as its domain reference.
Provider-controlled envelope
An SMTP sender identity managed by the sending service rather than chosen freely by the customer.
SMTP integration
A configured application connection to a mail submission service.
Recovery route
A previously approved sending configuration available if a replacement fails.

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base